Spark

Subscribe via Email

Subscribe to RSS feed

Archives

Follow Us on Twitter

Archive for the ‘UX’ Category

Designing for accessibility does no one any favors

Book

For some time now I have contemplated, as a design practitioner, is my perception of design for users inclusive, empathic and universal? This has been nagging at me for some time. Actually it’s been calling my name, Psst. Lisa, you’re behind the curve in your understanding of designing the user experience for people that are, well, disabled.” Let me be more candid; my own perception of disabled people hasn’t been accurate, empathic or inclusive of the various impaired users attempting to access and benefit from the online world. My thinking on this topic needed a significant update, a DIY project in the making.

To start, I didn’t have an accurate definition of disabled people, nor of impairment. To my credit I had read the important book Design meets disability about two years ago. The author, Graham Pullin, raised my awareness of several issues and possibilities when designing for disabled people. For one, he helped me understand that disabled people is an appropriate expression “in the context of an environment or society that takes little or no account of impairment.” This is a troubling thought – “people disabled by the society they live in” due to the “designed” barriers and restrictions that limit participation in hmmm…life.  Read the rest of this post »

Less PowerPoints, More Prototypes

At the 2015 Adobe Summit, Todd Copeland of the National Australia Bank described how his organization is able to deliver digital experiences with the speed and velocity that customers expect. As Todd stated, “it’s a pretty simple equation: Less PowerPoints and More Prototypes. Less detailed specifications to justify business cases and more iterative customer testing.”

That “simple equation” is one of the key principles that is driving digital transformation. In today’s world, organizational velocity wins. Companies that are quick to adapt and respond to customers have a clear advantage. Those that are slow to respond are subject to digital disruption (see Blockbuster). In order to effectively compete, organizations must find ways to provide better customer experiences more efficiently. Enter Lean UX.

Lean UX abandons the idea of deliverables as milestones in favor of a progressive working model developed across multiple sprints. This is an important concept when you think about organizational velocity. Because deliverables eat up time. There is time required to create the deliverable, time to develop a presentation around the deliverable, time to present the deliverable and time to review and revise the deliverable. That is time that could be spent developing the actual solution. Lean UX enables the designers and developers to work collaboratively to establish a shared understanding without the need for detailed specifications or other paper-based deliverables. It also promotes transparency and trust, which can lead to a better solution.Lean UX Model
The Lean UX process involves 3 core steps:

  • Think: In the think stage, designers, developers and business owners collaborate on a particular problem and sketch out ideas for the solution. The goal is to get the core components of the solution visualized quickly so the development team can provide insights on the direction of the design, including feasibility. The initial investment in sketching is so minimal that there is no significant cost to completely rethinking the direction.
  • Make: Once a general direction is agreed upon, the team elaborates upon the solution through interactive prototypes. The interactive prototypes define the layout, functionality, relative importance or priority of information of the user interface and allow the team to experience the solution faster.
  • Test: Once the prototype is developed, it can be used to test the effectiveness of the design. By conduction usability testing sessions with representative users, the team can collect valuable feedback that will improve or enhance the solution. Based on the feedback received in the usability testing, the team makes revisions to the design concepts. And the cycle continues until all features and functionality are designed an incorporated into the working model.

Through this approach, a small, focused team can quickly prototype a working model that demonstrates the solution within a matter of weeks, instead of months. That difference is huge in terms of velocity, and may be the difference between meeting expectations and leaving your customers dissatisfied.

 

Designing the small details – “Microinteractions”

Dan Saffer's text

Dan Saffer’s text

Part 1 of 2

As a usability researcher it’s important for me to stay aware and informed of guidelines for designing user interactions. Also, I want to be literate about topics within user experience design. So Dan Saffer’s book Microinteractions – Designing with Details caught my attention. His text is interesting; it focuses on the importance of the small details, the small pieces of functionality within a digital design. Saffer thinks these small details are really important because they can be “signature moments” that impact the entire experience of a product. Now that I’ve read his book, I would agree. To illustrate his perspective Saffer has included numerous examples of when a microinteraction created an enduring signature moment, for example Larry Tesla’s creation of Copy/Paste in 1973, and a lackluster one, “the initial intrigue with Google + Circles fell flat against Facebook when sorting users into circles became tiresome and gimmicky.”

What are Microinteractions?

I have to agree with Saffer on the importance of the details in designing, but it’s difficult to always know which design elements are microinteractions. As Saffer would say they “are all around us, from the turning on of an appliance to logging into an online service.” And, these “small pieces of functionality,” as simple and brief as they are, can delight or frustrate us over and over with every interaction. I can think of a situation in which I experienced the feeling of frustration when I had to log into a retail site to access tracking details on my purchase. This merchant’s microinteraction “rule” wasn’t a wise choice because it sacrificed my user experience by adding unnecessary complicatedness. It could have been much easier with an email that contained the shipper’s tracking number linked to the carrier’s site. Read the rest of this post »

For Enlightened CIOs, the “I” Stands for Insight

Who’s the most important marketing person at your company? Your CMO? Someone on her team? Maybe your CEO? What about your CIO? While your Chief Information Officer isn’t likely to craft your next campaign, the impact he or she has on customer experience is becoming more direct and more critical every day.

shutterstock_234372760The reason is simple, and it has to do with insight. More and more, CIOs and their teams hold the keys to unlocking the customer understanding that designers and marketers crave. A convergence of trends — abundant customer data, demand for greater insight in defining and managing customer experiences and a growing need to empathize with a wider range of customers — are driving CIOs into the insights business. A question remains, however, in how effective marketing and IT teams will be in working together to uncover customer data and convert it into meaningful actions.

Insight into customer behavior is what separates good customer experiences from bad. Insight drives empathy, a raw ingredient in the effort to humanize technology and harness its brand-building potential. The astute use of customer insight is so vital that we include it as one of seven factors in Perficient’s CXIQ Assessment, our measure of an organization’s customer experience maturity. While every company offers its customers an experience, few understand what it takes to systematically turn customer insight into the superior experiences that lead to increased preference and loyalty.

Read the rest of this post »

Project Off Track? Why Client, Agent and User Balance is Critical

From a PM/AM perspective, we are expected to keep the client happy (fulfill their objectives and vision), be the voice for our internal team and help produce a relevant and useful product while staying on time and in budget. Neglecting one and overdoing the others can cause issues with the overall success of the project, ultimately placing strain on the client relationship and internal morale. Catering to the client only can result in delivering a product solely focused on business objectives. This tends to overlook the user’s satisfaction, delays development and produces a less than successful product. It is our job to figure out what those objectives are and how they translate to the end-user. On the flip side, if we as the agency look out for our sole interests, rogue creativity may result in irrelevancy and dismiss the client’s primary business objectives. There is a balance, but how do we get there?

There was a similar discussion in the book, SCRUM: The Art of Doing Twice the Work in Half the Time, which sparked my interest on the topic. In software/web development, teams can be overwhelmed with a never-ending list of requirements that become irrelevant and outdated as the project develops, and they tend to serve more as roadblocks. Features become wasteful and not needed. These requirements are gathered at the beginning of the project and are thought to be essential to success. Things change, however, and we must be willing to be flexible.

To get to the overall purpose and desired outcome, we need to prioritize with our clients and internally: what is important, what is a must have, what is a nice to have, and what can get left out all together?

Look at the requirements through the lens of the Kano model, a method that has helped me wrangle in my own grandiose ideas.

Must-be Quality – Expected qualities of a deliverable. (The table stands up – woo hoo!)

One-dimensional Quality – User is satisfied when achieved, dissatisfied if not. (Table says it raises up and down. It does not – boo!)

Attractive Quality – Not expected or desired but a bonus. (Table was also made with recycled tires – cool) If it wasn’t, still cool table.

Indifferent Quality – Neither good nor bad, doesn’t really make much of a difference.

Reverse Quality – Too many features/options, not all customers are alike. (Table can also fold into a sofa, a ping-pong table, a sled and be used as a trampoline. I just want to put my computer on it!)

I’ll never forget a project that was delayed for one small feature that eventually was removed anyway. At the time for the client, they thought it was the make-or-break feature for the site. They had lost sight of their goals which cost them in the long run. (Of course, I tried to stop them, they just wouldn’t listen…LOL)

My Favorite Example of an Indifferent Quality

“Think about it: when was the last time you used Visual Basic Editor in Microsoft Word? …But it’s there, and someone spent time implementing it, but I guarantee you, it doesn’t increase the value of Word by much”

Here are two projects with the same intention (success and increased usage), yet two very different results:

FAIL: Windows 8 Metro UI

windows metro screen

Here is a unique example of having the user experience in mind, so they thought. The Metro worked very well across mobile, tablets and the Xbox interface. The move to PC caused confusion as they forgot to examine what the experience would be like for the user and focused more on the continuity of look/feel between devices. Hidden gestures, a clunky start screen and other usability issues put the desktop user last, not remembering that desktop browsing is still very relevant. It solved the problem for creating the same interface to multiple devices, which is more of a design conflict, not solving a real problem for the user.

YAY: McDonald’s App (Netherlands)

mcdonalds_2

This UX team had great attention to detail on what the users wanted (locations with directions, relevant coupons, favorites, build a meal with nutritional values) while still meeting the business needs. The app had delivered on its KPI’s, impact on sales. 2.1% of all McDonald’s customers brought in a mobile coupon, and there was a 47% increase in spending through upsells using the coupons. On top of that, it was the #1 download in the app store and Google play, downloaded by more than 1 million Dutch consumers, according to UX Magazine.

This thinking can be used throughout the project cycle; there is not one definitive moment that it is more useful than another. Project is off track? Look at where you are in the development cycle. What can be removed? Does it still have the same effectiveness without it? Will it still remain relevant and useful to the user? As we all know, projects are evolving pieces of work and have elements of upkeep to them. Does the product still engage the user? Have the business metrics flat-lined? Are there new technologies/techniques that we have access to now that will make this better? Moral of the story: take a step back from the chaos and reflect on what it is that you are trying to accomplish and how you are trying to get there.

QR Codes Rule!

QR Codes Rule…if you happen to live in China, that is.

According to a recent article from Fast Company,

In China, QR codes are everywhere, and most apps have their own QR code readers built-in.

What seems like a pointless piece of technology in the U.S., can be central to an entire infrastructure in another country.

Here’s another example: voicemail.

I’m one of those people who would like to change my voicemail message to say: “Thank you for calling. If you want to reach me, please send a text.” I find the entire process of calling my voicemail and listening to a lengthy message to be a time-waster. I’ll take 10 texts over one voicemail any day. But in China, it’s reversed. Writing and reading Chinese is very laborious. It’s even harder when there are multiple dialects. The solution?

Voicemail.

When creating a technology or determining its usefulness, it’s vital to understand the culture of the people who will be using it. This is true whether you are creating an app for a specific country, a specific demographic or a specific industry.

Great UI design is only great if the end user says that it is, regardless if they say it via text or on voicemail.

Tags: , , , ,

Posted in UX

Why Good Is Not Good Enough: What I Learned at Forrester CX Forum

Last week, I ventured to Anaheim, CA, for Forrester Research’s Why Good Is Not Good Enough conference. I wanted to find out how, in a world of same-day e-commerce, self-driving cars and ubiquitous Wi-Fi, the stewards of the world’s top brands were managing to keep their customers happy.

CXW_Brochure_COVER_finalAcross the two days, mic’ed-up presenters and tweeting colleagues agreed that customer experience (CX) couldn’t be left to chance. Like any business asset, it must be monitored, measured and optimized in accordance with shifting market demands. And now that we’re a few years into the optimizing, we sense that “good” just won’t cut it anymore.

But despite the agreement, two distinct camps emerged; one asserting that as customer demands grow, brands must keep pace by exerting maximum control over experiences, even extending their influence beyond traditional boundaries and into external ecosystems. The other held that doing too much planning and seeking too much control was impractical and unwise. Organizations should instead pursue a more enlightened path of responsiveness, flexibility and empowerment.

So who’s right? Here are my six takeaways from the conference…

#1. Mastering CX is not easy. Forrester VP John Dalton opened with a story of Walt Disney, pioneer of experiences for the pint-sized customer. Despite years of planning and a drive to control every detail, Disneyland’s opening was a near-disaster. On that sweltering day in 1955, throngs of parents and children endured hours-long wait times for rides. Newly paved asphalt melted under the July sun, devouring ladies’ heels. A plumber’s strike deprived the park of drinking water and a gas leak required much of it to be closed. Negative press followed. But Disney stayed true to his vision and eventually things turned around. With this tale, Mr. Dalton seemed to suggest: if Walt Disney had trouble with this customer experience thing, maybe the rest of us should lighten up a bit. As in most situations, progress is better than perfection.

“If Walt Disney had trouble with this customer experience thing, maybe the rest of us should lighten up a bit.” (tweet this)

 

#2. Firms are getting better at CX delivery. Forrester’s Megan Burns took the stage to talk about CX maturity. She reported that the concept of customer experience, which Forrester has tracked since 2007 with its annual Customer Experience Index, has now reached its gangly adolescence years. While great experiences are still rare (hence the title of the conference) truly awful ones are on the decline. Until recently, few organizations knew that measuring their CX maturity was something they should, or even could, do. Now with eight years of data as evidence, she offered three “universal drivers” for CX maturity and loyalty:

  • Make customers feel valued.
  • Resolve customer issues and problems quickly.
  • Talk to customers in plain language.

#3. We’re all competing with the best. Katy Keim of Lithium Social Web spoke about the social media revolution and its impact on customer experience. Noting that “CX = delivery – expectation,” Ms. Keim neatly distilled the challenge to its essence. As customer expectations have become more and more “extreme,” firms find it harder to stay ahead of their customers’ needs. And when it comes to expectations, companies no longer compete only with others in their industries. Instead they go head-to-head with the Netflixes, Ubers and Amazons of the world. These brands have redefined what customers should want, and in doing so, have recalibrated the CX benchmark for every category. Increasingly, firms that fail to live up to these extreme expectations will been seen as “unresponsive.”

Read the rest of this post »

Are Two Pizzas Enough?

Imagine being an executive for one of the largest pizza chains in the world and being invited to a meeting titled “Why Two Pizzas Are Enough”. How would you react? Would you be concerned a few zeroes had been left off? I did a contract role as an agile coach for just such a major pizza chain a few years ago. When it was time to give the executive management team an overview of Agile and Scrum (the specific methodology the company was interested in implementing) I was advised to not call the meeting Agile or Scrum. After asking why I should avoid this I was told that the business was sick and tired of hearing about both Agile and Scrum and they wouldn’t come if they knew what it was about. I used the analogy of two pizza teams to grab their attention and boy did I grab their attention! Every Executive attended the meeting.

In last week’s article “Agile and UX Design: Can they work together?” I mentioned the concept of a two pizza team. In this article I give more definition behind this concept and how it applies to agile approaches.2 Pizza Teams

The two Pizza team terminology was coined by Jeff Bezos, founder and CEO of Amazon. You can read more about his concept and how it has become part of the culture at Amazon by reading the Fast Company article “Inside the Mind of Jeff Bezos”.

What is the two pizza team analogy? In Scrum, and most Agile methodologies, the team is meant to be a small, cross-functional, empowered team of approximately 5 – 9 people, depending on the project size. Therefore when your team has to work through lunch or late into the evening, as you know you do when you work on a project, the company can feed the team with two pizzas. I.e. Two pizza teams.

There is more accountability in smaller teams and they tend to avoid the issue of social loafing. According to social psychology, social loafing is the phenomenon where individuals tend to put forth less effort when working in a group than when they are working individually or coactively. Small teams in which each member is accountable for specific tasks for the project will avoid this concern and hold each other accountable on a daily basis for the work being produced.

There is, on occasion, a concern raised with the small number of team members when a project may be extremely large and require more than the recommended 5 – 9 person team. In this event, review the project goals and determine a team structure in which multiple Scrum (or whichever agile methodology is being used) can be structured reporting into one Project Manager or Product Owner (whichever role title your project is using). In many projects a quick review of the goals or epics will show a natural delineation into individual teams. These teams should be able to communicate with each other, but limit the communication paths necessary between the teams. In other words, if team A is unable to complete their work because they must first coordinate with additional teams the project will stall. Minimizing communication overhead while still encouraging communication between teams is a key strategy to the success of multiple teams within the same project.

Try the two pizza team concept when your organization on a smaller scale first. Something as simple as a meeting in which a decision or consensus needs to be reached or if there is a larger problem which you are attempting to solve, break it into smaller chunks and assign a small team to each chunk to solve. See how quickly and effectively these small teams can work. Not only will your problem get resolved, your corporate lunch bill will go down.

Agile and UX Design: Can they work together? Part One

Diet pills and Agile have a commonality – people want a quick fix to lose weight only slightly more than they want a fix to all their project management issues. Unfortunately, diet pills nor agile are silver bullets to correct either concern. It takes dedication, work and an understanding of the principles behind the body’s metabolism to lose weight. Likewise, it takes dedication, work and an understanding of the principles behind agile to improve delivery of a project. Once you understand these principles you can become a two pizza team, improve project delivery and lose weight at the same time.

This is the first part of an ongoing series attempting to not only bring clarity to what it means to be agile, but also to answer the question, can agile methodologies work during the UX design phase of a project? I have heard arguments on both sides of that debate. Many designers saying ‘no’ it doesn’t work and the more traditional waterfall methodology works best. Why? Because you have to business requirements before you can start wireframes and you have to have wireframes before you can start creative design. Before starting creative you have to have a content strategy which depends on the wireframes, which depends on the business requirements and on and on. While I am not arguing these needs I want to explore the possibility of providing these needs within an agile process.

But, before the exploration of this feasibility can begin let’s first define what agile means. I hear the word tossed about to describe a single methodology of project management or software development. Ask a project team what methodology they are following and often you hear “we are using agile”. What does that mean? Each week we change our process because we didn’t like what we did last week? Or, the client wants us to change how we are doing things because they didn’t like what we did last week? That isn’t agile, that’s chaotic and reactive. So, what is agile?

It’s difficult to define as agile is an umbrella term for multiple approaches to project management of software development projects. At the core, agile is a group of methods that enable small, cross-functional teams to quickly deliver business value in an iterative, collaborative approach. Where change is expected, not feared and where requirements can be expanded upon as the team learns more. Where conversation and collaboration are valued over strict adherence to a set plan defined before the requirements are even made clear to the customer, let alone the team.

The agile manifesto describes the values and principles of agile software development practices and I won’t take the time to reiterate them here, but if you don’t know them I suggest checking out that link. The manifesto itself is made up of four key values supported by twelve principles.

Agile Manifesto Values

Agile Manifesto Values

Some agile methods which exhibit these values and principles are:

• Scrum – arguably the most popular
• Kanban
• XP (Extreme Programming)
• Lean Software Development
• Feature Driven Development
• DSDM (Dynamic Systems Development Method)
• Crystal

This is not an exhaustive list of all agile methodologies, but some of the more popular ones currently in use. Which of the approaches to use depends on the team’s knowledge and expertise in each methodology, their culture and sometimes the project goals.

Making a move to agile is a cultural change that impacts the entire organization, not just the IT department. It’s a marathon, not a sprint. An evolution not a revolution. There is compelling evidence that iterative methods reduce project risk, compared to more traditional waterfall approaches. Next time we’ll move into the discussion of bringing Agile and UX together.

In the meantime, have you been involved in a cultural shift to using agile? What pain points did you find and how did you resolve them?

Abstracting the UI Layer

Last month at the IBM Digital Experience Conference, Shyam Sunter, a Perficient Technical Solution Architect, and I presented on a method for abstracting the user interface code (HTML, CSS, and JavaScript) out of WebSphere Portal. A key part of this presentation was going over why this abstraction was important.. It’s of my opinion, that abstracting the UI code out any platform, be it WebSphere Portal, Sharepoint, SiteCore, what have you, is vital for building modern, cross channel digital experiences. Supporting an abstracted UI layer is a common practice for many digital platforms, especially in the start up space. It’s time that the enterprise world starts to consider adopting this practice as digital solutions become more pervasive and complex.

 

Diagram showing the various layers that make up a user's digital experience.

Elements of User Experience

 

For a long time now, User Experience professionals have been working in a world of abstracted layers. This is best illustrated by Jesse James Garret’s famous 2010 diagram of the Elements of User Experience. Even when the web was simply made up of two layers, structure and style, designers used these abstracted layers to map out the overall structure, information design, behavioral touchpoints, and visual design elements of a given solution. As the web matured and additional technical layers were added, such as behavior, content, and contextual awareness, these layers became more important for us to work through and support. Modern digital solutions, such as Disney’s My Disney Experience, Airbnb, Uber, and many many more, are ones built on top of these abstracted layers so that their overall solution is more scalable and maintainable.

Modern Web Architecture

Several other benefits manifest themselves as well, including:

  • Design teams being given ownership and control over the development and deployment of the user interface layer. Design is naturally an iterative process, which involves creating and testing various solutions to a given problem. Having control over the UI layer, gives design teams the freedom and flexibility to try out new solutions and to simply “play” with the overall design.
  • Publishing UI code more frequently. With the control of the UI layer living in the hands of the design team, code can be pushed out more “real time”. This doesn’t always mean to the production environment, but users and stakeholders are able to touch, feel, and play with a new design quicker and in a realistic environment.
  • Easier to support cross channel solutions. It isn’t news that the days of people being chained to a desktop computer and chair are over. But, the new world of multiple digital devices and varying resolution sizes is a still new, and it’s really complex. By supporting a stand-alone UI layer, it’s easier to contextual deliver the right design for the right environment.
  • Proper support for accessibility standards. Accessibility doesn’t just apply to UI code, but a good chunk of it does. If you don’t have a backend platform interjecting its own code or compiling code that a UI developer has written, many accessibility issues can be addressed in a more streamlined fashion.

 

Ultimately why does having an abstracted UI layer matter though? Because there is no such thing as just having a website or just having an app anymore. It’s about providing a digital service that people can interact with, play with, and enjoy at any time from any device. Many things go into ensuring that the resulting experience is a pleasing one, but taking the time to build a UI layer that isn’t, at least fully, dependent on a backend platform is one of the key methods for properly serving people who use your digital solution.