The traditional way of building software focused on requirements, driven by a competitive view of the market, and responded to perceived needs with additional features and functions. Our new way of developing products focuses on people first: on spending lots of time with them in order to build an almost intuitive sense for their emotional journey. We design with that journey and those emotions in mind, and as a result, we can produce great products that people love.
—Jon Kolko, Understanding our product design strategy and ecosystem.
Posts tagged “user experience”
New e-book: Practical User Research for Enterprise UX
I worked with the wonderful folks at UXPin to write a short e-book on how to overcome some of the challenges of doing user research in large organizations. From the introduction:
Once a company grows over a certain size, the internal politics and number of people involved in every decision increase so much that it becomes virtually impossible to stay focused on fulfilling user needs and business goals. Instead, the focus turns inward to the opinions and whims of individuals inside the company. Add the complexity of designing B2B products to the mix and, well, things go bad very quickly.
When an abundance of stakeholders are involved in a product, user research is the only way to focus a whole team on the real needs and goals required for success. It’s also the only way to get people out of the habit of thinking “Well, I want this, so everyone else must want it too”—a view that I find much more common in enterprises than in smaller organizations.
If that sounds familiar to you, you’ll hopefully find the e-book useful. I discuss why it’s often so hard to get support for user research in enterprises. Then I provide some advice on how to sell the value of user research. Finally, I offer some practical tips for addressing the subtle differences of conducting research in larger organizations with users who aren’t buyers.
You can download the (free) e-book here: Practical User Research for Enterprise UX.
Why everyone should do usability testing (even you)
I vividly remember the first usability test I attended. I was a brand new employee at eBay, and I walked into a dark observation room with no idea what to expect. I came out of that room 60 minutes later with the strangest mix of emotions—heartbroken that our product clearly had usability issues that made users incredibly frustrated, but also relieved and excited that we now had the information we needed to fix those issues. I became a usability testing convert for life, and have been making it a part of my product design process ever since.
I’m deeply passionate about this methodology and how it makes us better designers (and improves the experiences of our users), so I don’t think it should be something that we reserve only for the “highly trained” to do. Usability testing is something all of us should do as a regular part of our design process. But that doesn’t mean it’s straight-forward—there are many pitfalls and ways to generate bad data with usability testing. So I wanted to write a brief introduction to the methodology and why it’s so important, as a foundation for people who haven’t had training in the method but would like to make it part of their process1.
So, let’s start at the beginning.
Usability testing is a very powerful (and shamefully underused) user research methodology—when it is used correctly. In fact, usability testing is probably the only method that can be relied on to consistently produce measurable improvements to the usability of a product. Bruce Tognazzini once said:
Iterative design, with its repeating cycle of design and testing, is the only validated methodology in existence that will consistently produce successful results. If you don’t have user-testing as an integral part of your design process you are going to throw buckets of money down the drain.
But that all depends on the all-important “when it is used correctly” caveat. To make sure we do that, we need to understand when to do usability testing, and what to use it for.
When to do usability testing
To answer the “when” question I need to bring back the three buckets of user research I first discussed in Making It Right:
- Exploratory Research is used before a product is designed, to uncover unmet user needs and make it easier to get to product-market fit. Ethnography and contextual inquiries are the most-used methods in this bucket.
- Design Research helps to develop and refine product ideas that come out of the user needs analysis. Methods include traditional usability testing, RITE testing (rapid iterative testing and evaluation), and even quantitative methods like eye tracking.
- Assessment research helps us figure out if the changes we’ve made actually improved the product, or if we’re just spinning our wheels for nothing.
Usability testing is best used during the design research phase of a product. Ideally you’ll have an interactive prototype or some other lightweight interface to work with. It needs to be detailed enough to make sense to a user, but not so detailed that you’re reluctant to make changes based on feedback. Of course, you can also do usability testing on an existing live product, as long as the team has an appetite to make changes based on the insights that come back.
Usability testing shines during the design research phase since it plays on its strengths as a way to uncover the issues with an existing product or prototype. Trying to shoehorn usability testing into one of the other user research phases leads to trouble, since the nature of the data you get from it simply won’t help you make good decisions (i.e., don’t use it to try to decide what products to build, or if something you built objectively improved user satisfaction).
What to use usability testing for
This leads into what usability testing is good at: refining a product. It’s not good at finding out what to build (unless it’s combined with an ethnographic component). To put a finer point on what usability testing is most useful for, here’s a much-simplified diagram to put it in context with some other research methods.

We use methods like analytics and surveys to understand what happens in the product. We use analytics to figure what users do, and we use surveys or other interview techniques to figure out what they say about the experience. The problem is that this doesn’t help us understand why something happens, and without that information we won’t be able to fix any of the problems we come across. That’s where usability testing comes in.
What makes usability testing so perfect for understanding the issues with an interface is that it is an observational research method. It’s not about asking people what they think about an interface. It’s about showing them an interface, giving them tasks to do in that interface, and then watching them as they go through those tasks. We can ask them questions about the experience, but that’s just to provide context.
At its core, usability testing means that we observe users as they make their way around an interface, and use that data to understand what issues we need to fix. So, for example, if we see in our analytics that there is a large drop-off in our checkout flow, usability testing can help us figure out why that drop-off happens, and how to fix it.
Haters gonna stop hating
I’ve seen usability testing abused in several ways that have ended up giving it a bad name in some circles. Here are some guidelines to keep in mind to help break through those prejudices.
First, don’t confuse usability testing with focus groups. They are very different methodologies, and they are certainly not interchangeable. Focus groups are good for some marketing purposes—to understand brand sentiment or positioning. It is a terrible way to get feedback on an interface. Usability testing is so good at what it does precisely because it is a 1:1 methodology. There is no groupthink, no way to get influenced by other users. In that sense, it is controlled environment. Focus groups are anything but.

Second, remember the golden rule that usability testing is about observation. It can’t tell you which interface people like more than another, so don’t try to use it to settle those disputes. It’s the wrong question to answer anyway. It doesn’t matter what users like—it matters what they can use effectively to accomplish their goals. So usability testing is not “lightweight A/B testing”, as I’ve heard it described. It is meant to be part of an ongoing iterative design process with the goal of improving the product incrementally.
Finally, remember that you don’t need to be in a large organization or have tons of money to do usability testing. This is a methodology that scales really well. For startups who just have an afternoon to get some feedback, you can take some paper prototypes to a coffee shop. For large companies who need to convince a bunch of stakeholders to make changes, you can run a series of formal usability testing sessions. Whatever works—and don’t be mistaken, every little bit helps.
Go and make it so
I want to end this introduction with a small call to arms. Usability testing is an inherently uncomfortable methodology because it assumes and embraces the fact that your product isn’t perfect. That’s a difficult thing to make peace with—especially as a designer. But taking that position is the only way your product is going to get better. You can’t fix something that you don’t think is broken. Clayton Christensen made a similar point in The Innovator’s Dilemma. He calls this mindset “discovery-based planning”:
Discovery-based planning suggests that managers assume that forecasts are wrong, rather than right, and that the strategy they have chosen to pursue may likewise be wrong.
Investing and managing under such assumptions drives managers to develop plans for learning what needs to be known, a much more effective way to confront disruptive technologies successfully.
Or to repeat one of my other favorite quotes: “Design like you’re right, listen like you’re wrong.” Usability testing gives us a proven process to understand what we got wrong so we can get more of it right. That makes it a methodology we should all invest in more.
- Who knows, maybe I’ll turn it into a longer, very practical series if there’s interest. ↩
Quote: Chloe Green on the ROI of user experience
Numerous studies have found that every dollar spent on UX brings in between $2 and $100 dollars in return. Forrester revealed that ‘implementing a focus on customers’ experience increases their willingness to pay by 14.4 %, reduces their reluctance to switch brands by 15.8 %, and boosts their likelihood to recommend your product by 16.6 %’.
–Chloe Green, The business of user experience: how good UX directly impacts on company performance.
The rise of inclusive design
Cliff Kuang wrote an excellent article on Microsoft’s push for more inclusive design. From Microsoft’s Radical Bet On A New Type Of Design Thinking:
Dubbed inclusive design, it begins with studying overlooked communities, ranging from dyslexics to the deaf. By learning about how they adapt to their world, the hope is that you can actually build better new products for everyone else.
What’s more, by finding more analogues between tribes of people outside the mainstream and situations that we’ve all found ourselves in, you can come up with all kinds of new products. The big idea is that in order to build machines that adapt to humans better, there needs to be a more robust process for watching how humans adapt to each other, and to their world. “The point isn’t to solve for a problem,” such as typing when you’re blind, said Holmes. “We’re flipping it.” They are finding the expertise and ingenuity that arises naturally, when people are forced to live a life differently from most.
This is similar to the points I tried to make in Beyoncé, Coldplay, and the myth of the “average” user. The advantages of having more diversity in our design and development processes go far beyond the moral rightness of it. We end up with better products that serve a much wider cross-section of a population.
The ethics of "empowering" users
Katherine Benjamin wrote a fantastic essay on designing for user empowerment, and what that really means. She asks, specifically in the context of digital health, When are we empowering users, and when are we just being lazy?
The World Bank talks about empowerment in terms of two things. Firstly, they talk about enhancing an individual’s capacity to make choices. They then talk about leveraging those choices into desired actions or outcomes. […]
When we think about things like wearable devices that enable people to actualise the “quantified-self”, we are usually realising just the ability of someone to self-monitor. In other words, we can make it possible for people to take better care of themselves by developing new technologies that support self-care. However, these innovations will only help those who are genuinely interested in taking greater control of their health. This type of self-determination with regard to health is a necessary pre-condition for successful adoption of digital health solutions.
Unfortunately, all too often, in the digital health industry, we get lazy and speak as though technology itself can create that individual level of empowerment. This fails to consider the inherent power dynamics between providers and users of health services, and the role this dynamic plays in facilitating agency among the users of health services.
When we design to empower users we can’t just think about giving people the information they need to act. We also need to help them develop the desire to act on that information.
We need a renewed focus on Information Architecture
Abby Covert wrote a brilliant and passionate plea for a return to the basic principles of Information Architecture in our design work. From The Pain With No Name:
In too many cases, educational programs in design and technology have stopped teaching or even talking about IA. Professionals in the web industry have stopped teaching their clients about its importance. Reasons for this include “navigation is dead,” “the web is bottom up, not top down,” and “search overthrew structure”—but these all frame IA as a pattern or fad that went out with tree controls being used as navigation.
These misconceptions need to be addressed if we are going to deal with the reality of the impending “tsunami of information” approaching our shores. The need for clarity will never go out of style, and neither will the importance of language and structure. We will always need to have semantic and structural arguments to get good work done.
The most dangerous thing about self-driving cars
Cliff Kuang makes some interesting points in his essay The Secret UX Issues That Will Make (Or Break) Self-Driving Cars:
Recall that first principle that [Brian Lathrop at Volkswagen] laid out for designing autonomous cars—that the driver has to know whether the car is driving itself. That harks to probably the oldest dictate in interface design; mode confusion causes 90% of airplane crashes, and that insight helped invent the field of human-computer interaction. Think about all the times you’ve heard news reports about a pilot being confused about whether the flaps of the wings were down, or whether to auto-pilot was properly set. If you’ve ever failed to realize that your car was in park when you hit the accelerator, or you’ve ever tried typing into the wrong window on your computer screen, you’ve been a victim of mode confusion.
So, the scariest thing about self-driving cars is not whether or not the car can drive safely, but whether it can effectively communicate when it is driving and when it is not. It’s the age-old Visibility of system status UI heuristic in action.
Beyoncé, Coldplay, and the myth of the “average” user
I am not qualified to talk about politics so don’t worry, I won’t. That said, Spencer Kornhaber’s essay on Beyoncé’s Radical Halftime Statement is so incredibly good (and very applicable to product design) that it’s worth discussing here. The part that I found particularly interesting is how differently Beyoncé and Coldplay view their “target markets”. Beyoncé is very focused:
But in pop and in politics, “everyone” is a loaded term. Stars as ubiquitous as Beyoncé have haters, the “albino alligators” who “Formation” informs us she twirls upon. And in a more general historical sense, “everyone” can be a dangerous illusion that elevates one point of view as universal while minimizing others. Beyoncé gets all of this, it seems. As a pop star, she surely wants to have as broad a reach as possible. But as an artist, she has a specific message, born of a specific experience, meaningful to specific people. Rather than pretend otherwise, she’s going to make art about the tension implied by this dynamic. She’s going to show up to Super Bowl with a phalanx of women dressed as Black Panthers.
Whereas Beyoncé is very specific about who her music is for (and not for), Coldplay tries to please everyone:
The poor guys of Coldplay, meanwhile, actually think they can work solely at the level of the universal. “Wherever you are, we’re in this together,” Chris Martin cried out, early on, last night. I don’t want to diss that intention, nor the take-home message at the end: “Believe in Love.” But from their first hit, “Yellow,” to their recent Holi-appropriating music video with Beyoncé, to their pan-cultural rainbow rally at Levi’s Stadium last night, their theme has only been about love to the extent that it’s been about how everyone loves colors. It’s music about being awed by the blandest kind of harmony: ROYGBIV, yeah yeah yeah!
Coldplay’s approach reminds me of this classic Sharp Suits poster:

The problem with a target market of literally everyone is that you end up with a heavily compromised experience that appeals only to the very few people who identify with the “average” experience. Bringing this back to product design, this is why I’m still such a big fan of design personas. As opposed to a mythical “average” user, personas are solid people we can imagine using our product to achieve their goals. This is helpful because by focusing on a few different individuals that are closer to the edges of an experience, instead of the average, we end up catering for a larger portion of the user base:

This is what Beyoncé does so well. She makes music at the edges, so it’s exciting and anything but bland. It’s a lesson that Coldplay clearly hasn’t learned yet.
Netflix and the problem with established interface mental models
There were some interesting Netflix articles over the past week or so. First, Nathan McAlone writes that Netflix wants to ditch 5-star ratings:
The problem, [CPO Neil] Hunt tells Business Insider, is that people subconsciously try to be critics. When they rate a movie or show from one to five stars, they fall into trying to objectively assess the “quality,” instead of basing the stars on how much “enjoyment” they got out of it.
Here’s an example. Let’s say you had fun watching a crappy movie, but still gave it a two-star rating because you know it’s not a “good” film. That presents Netflix with a problem. The system thinks you hated the movie.
I think embarrassment plays a part in this as well. Even when ratings are private, we’re worried that word might get out. For example, I’d be happy if all my Netflix recommendations consist of “Movies similar to Battleship”, but I certainly don’t want any of you to know how much I liked that terrible movie.
Related to this, McAlone also wrote about Netflix’s most important metric:
That means that the most important economic metric for Netflix is how much a TV show or movie contributes to Netflix’s ability to sign up and retain customers.
The problem is that the current star rating system doesn’t give them that metric because it’s associated with “quality”, not “enjoyment”. So I might rate Out of Africa 5 stars because I objective know it’s a good movie, but if Netflix starts recommending “Boring movies with Meryl Streep” to me, I’m out of there.
Netflix has a very difficult product design challenge ahead of them. They have to change an established user mental model (“stars=quality”) to something different (“tell us what you enjoy watching”) that will help them provide a better and more compelling service.