For UX designers, some of the most exciting projects to work on are new-to-the-world or breakthrough products that solve real problems people didn’t even realize they had. Get them right and they may be hugely successful in the marketplace, but they’re also the riskiest projects. While user-centered design (UCD) techniques can sometimes be valuable on new-product projects, more often, they don’t seem to work particularly well when designing breakthrough products. Here are some lessons I’ve learned from my own work on new-product projects.
Know when UCD techniques aren’t what you need.
Champion Advertisement
Continue Reading…
When it comes to matters of aesthetics and fashion, UCD techniques offer little assistance. They can’t tell you how people will respond to products they’ve never seen before, products people have difficulty imagining—for example, imagine trying to explain today’s Internet to someone 30 years ago—or products whose success is simply a matter of taste. For example, the House of Dior once had a fashion-show hit with a dress they made out of newspaper. So, they created a version of the dress in newsprint-look fabric, which became a huge commercial success.
In the online world, there are many examples of Web sites that people have discovered by word of mouth, because they’ve caught the public’s fancy. A notable example was the Burger King® “Subservient Chicken” Web site, shown in Figure 1, which had 20 million hits within the first week and resulted in a nine-percent growth in sales of their TenderCrisp sandwiches and double-digit product awareness.
Figure 1—Subservient Chicken
There are many more examples of such products from the non-digital world—think of the clothing and movie industries. It’s hard to imagine UCD techniques would have uncovered a latent desire for newsprint-look dresses or subservient chickens. These were cases where the power of the designers’ vision created the demand, showing vision-driven design is sometimes the right approach. In such cases, the role of UCD is to help better the odds that a particular idea will resonate with a product’s target market and screen out those ideas that won’t, as I’ll discuss below.
Look for real problems people don’t realize they need to solve.
Identifying problems that need solutions is one area where UCD techniques offer a major advantage over traditional market-research techniques that rely on people’s ability to articulate their problems, needs, and desires.
Figure 2 shows Yahoo!® MyWeb, which I helped design. It had its genesis in field research that showed people had great difficulty again finding information they’d saved from previous searches. None of the interviewees mentioned they wanted something like MyWeb, but Yahoo! designers could envision something users couldn’t, because we were aware of the technology we could bring to bear on the problem.
Figure 2—Yahoo! MyWeb
Help solutions find problems.
Most startups begin with a vision. The Vocera Communications® System, shown in Figure 3, began as an idea: What if we could make something that really was the equivalent of the Star Trek communicator badges? Cool, huh? The problem was: Who would buy such a communicator? Vocera originally envisioned IT Help Desks using its communicators, but quickly discovered that there wasn’t a market there. So, Vocera took its product demo on the road and showed it to dozens of industries. Finally, they presented the communicator to a group of health-care professionals—one of whom broke down crying, saying she’d waited 20 years for something like it. The product provided hands-free, instant communications for nurses and doctors who were constantly on the move— among both individuals and groups of people. This method of communication was far more efficient than the old system of paging people working at a hospital, then waiting for them to call back. Needless to say, Vocera went after that market.
Figure 3—Vocera Communications System
When a product team encounters a situation like this, user research techniques can be useful in determining whether there’s a real problem they can solve, enough people need a solution to the problem to create a viable market, or people are willing to pay—in money or their time—for a solution to the problem. In such cases, combining UCD techniques with approaches that market researchers traditionally use, such as survey research, can help a product team identify a product need.
Help users visualize solutions.
In my experience, users aren’t very good at imagining possible solutions—either they picture something quite similar to products they’re already using, or they go off into unproductive flights of fancy. Even professionals in a product domain aren’t always good at identifying needs and their solutions. For example, in 1943, Thomas Watson, chairman of IBM®, predicted that “there is a world market for five computers.” In fairness to Watson, if computers had remained the building-sized behemoths they were at that time, he probably would’ve been right. However, the failure of his imagination was to think about what would happen if computers shrank is size.
Mockups and prototypes provide an excellent means of helping users understand product concepts. In addition, they are often useful to product teams in prioritizing what must be in a first release and in defining a product’s core features and functionality—in other words, things the product wouldn’t make sense without. You can distill such information into proofs of concept.
Recognize that users may not get a product concept immediately.
Be cautious in evaluating user feedback you receive regarding mockups and prototypes. When doing rapid, iterative usability testing of prototypes for one product concept at Yahoo!, I was frankly skeptical that an hour-long usability test would provide useful feedback about the appropriate conceptual model for the product when it wasn’t clear that the test subjects fully grasped the product concept in the first place.
When you’re testing a new and difficult-to-comprehend product concept, one solution is to create a functioning proof-of-concept prototype and make it available to people, so they can use it for several days—or even weeks—and have enough time to understand what you’re trying to do. Obviously, creating and testing such a prototype can be a tough sell in a startup environment where burn rate and time to market are ever-present concerns. On the other hand, one of the main reasons effective entrepreneurs want to get to market fast is to get feedback about their products’ viability in the marketplace. So, just as manufacturers of physical products do test releases in small markets before investing in tooling a factory for full production, a longitudinal study can provide a far cheaper way of learning how users will use a product before actually going to market.
Ask how users might use a product.
Show users something that’s technologically cool, and they’re likely to say they’d use it, even if they really wouldn’t. So, rather than asking users whether they’d use a product, it’s far better to ask them how they’d use it in their everyday lives.
For example, when we did the field research for Yahoo! MyWeb, people complained that irrelevant search results got in the way of what they were looking for. Although no one asked for this capability, we thought one solution would be to allow users to block irrelevant results from their search results. But what constituted an irrelevant result? Through follow-up research, we learned users were forgiving of wrong result s—things that were reasonable responses to their search queries, even if they weren’t what they were looking for. What they disliked were results that included spam farms, URLs that were redirected to porn sites, and sites that were otherwise deceitful. That knowledge helped us decide that, when users blocked a search result, it was appropriate to remove all URLs from that site from future search results.
When users can’t provide what seem to be realistic answers when asked how they might use a product, that’s a serious red flag. Had the makers of the Segway® personal transporter done this, they would have realized early on that they actually had merely an interesting niche product—rather than one that was going to revolutionize transportation and change how cities were built, as its makers proclaimed it would. Breakthrough products are inherently risky, so they often do fail. Consequently, in some cases, the most valuable contribution UCD can make is to help kill ideas that aren’t likely to be viable in the marketplace, before companies have spent much time and money on them.
Give users something familiar to hang their hats on.
In its initial advertising campaign, TiVo® focused on its ability to pause and rewind live television broadcasts. Those of you who use TiVo know that’s a small part of what TiVo can actually do, but trying to explain its capabilities to people who are unfamiliar with the product is difficult. Pausing live TV was a “difference that made a difference”—something that people couldn’t easily do with VCRs and was useful enough to get people started using TiVo. Once they bought TiVo, they could discover all the other things it could do.
When designing a digital product, you may sometimes need to downplay the truly breakthrough aspects of your product, which may be harder for users to understand initially. Web sites, application programs, and other software products or features are somewhat at a disadvantage when compared to physical products, because breakthrough functionality in software products is seldom as obvious as it is in physical products.
During usability tests, it’s useful to ask people to describe your product “as if they were telling a friend about it”—not only to see whether they understand the product concept, but also to learn about bridging concepts that you can use to get people interested in using the product, even if they don’t fully grasp its potential.
Plan for flexibility.
As William Gibson once famously said, “The Street finds its own uses for things—uses the manufacturers never imagined.” It’s doubtful Tim Berners-Lee imagined the World Wide Web as it is today. In fact, many of the headaches Web developers have encountered with HTML were the result of their trying to use it for more than just electronically distributing papers among academic researchers.
So, as you’re gathering user feedback about a digital product, be sensitive to ways in which people might misunderstand or “misuse” what you’re building. Such applications of your product may actually make your product idea more marketable than your product team’s original concept. While user-centered design normally warns us against designing for early adopters and power users, these are exactly the people whose needs you want to meet when developing a breakthrough product. I’m not saying you should necessarily design just for them—even though they are likely to be the first customers and users of your product—but pay attention to the insights they can provide. It’s up to you to decide whether those insights are applicable to a wider audience.
Final Thoughts
Because evolutionary products are far more common than revolutionary products, UCD techniques have focused more on how to approach projects for which the problem space is fairly well understood—both by UX designers and by users. UCD techniques are best at helping us determine how to solve such problems—which is not to downplay the challenges of those sorts of projects. However, the situation is different for breakthrough products, where potential users often have difficulty imagining a solution to a problem. UCD techniques have some role to play, but often these sorts of projects require UX designers to make decisions more on the basis of their conceptual modeling skills and design experience than on direct user feedback. They must envision solutions that potential users can’t quite see for themselves yet. This is why breakthrough products are high-risk, but potentially also high-reward projects.
I’m sorry. I don’t agree at all. UCD techniques—at least how I define them—always apply.
If a human is going to be using technology, we can find out useful data at any time with any prototype—even a scribble on a napkin.
It seems you may be confusing UCD with marketing—or maybe you define UCD techniques as usability testing only.
Why would you ever ask a user directly if they would use something as opposed to observing what they do and assessing effectiveness, etcetera. The recruiting/screening process is where you assess whether they are targets or not—or in a survey/focus group.
Good article. And I guess just the last paragraphs point out why or when a new product or service is revolutionary: either you begin from a safe ground and plan to take little steps or you jump from nowhere to a grand vision.
Taking the little steps is safer and gets you where you want to go—although sometimes people and developers are just happy to go whereever the new requirements lead them. It takes longer, and it does not really surprise anybody, because they can see and evaluate the progress. “Hey, anyone can take such a baby step.”
Making a jump on the other hand is risky—who knows on what ground you will fall—and you are likely to be on your own—for the good and the bad. If the market or people accept your new position, they may begin to follow you and you become the leader. But they might well neglect you, too—a fate common to many innovations, real or false ones.
Great post, George—very pertinent for where the profession is today. A lot of our ethos still harks back to the psychology lab and so is essentially descriptive.
I suspect it is our mindset that is at fault, though, rather than our methods. Many of our techniques can be catalysts for new insights and innovation if we apply them correctly. I recommend you look at the IDEO Method Cards for examples of how that company deploys user research in the design of breakthrough products. They certainly inspired me.
George, I agree with Gordon. None of what you mention has to do with choosing between user-centered or other-centered design.
In fact, your first example of non-UCD starts with the very user-centered activity of field research.
I get the point. Kind of. Sometimes you need to tell everyone to sod off and then just come up with something brilliant. Instead of user-centered design is that me-centered design?
I’d love some clarification here. Maybe we’re hauling around different definitions for UCD?
Actually, Gordon, I’m not confusing UCD and marketing—I’m intentionally drawing on both. That’s because things have to be useful in addition to being usable. And evaluating whether something is useful isn’t something you can necessarily get from only watching people. Think of the Segway. We could perfect its usability, but that still doesn’t make it useful for most people when you get down to practicalities—especially at its price point, which is also an important consideration that UCD isn’t used to thinking about. And there’s always a price, even if it’s just the time users spend interacting with your product. From my experience, it’s very difficult to evaluate how people use things that don’t exist yet, particularly—again as in the case of the Segway—if they’re difficult to prototype, and/or you’re trying to be stealthy before going to market. A related problem is that often you need to get early feedback about whether to pursue an idea before you invest the time and effort in prototyping it. Which means using lo-fi methods in an artificial situation, which again makes strictly observing behavior of limited value, not only in assessing value, but even just assessing usability. It is a tough nut to crack.
Part of the inspiration for writing this article were precisely the problems I had when we did the design research for Yahoo! Search. I can’t really discuss the details—which includes stuff that never made it into a public release—without violating my NDA, but as I mentioned, just observing people using some prototypes was problematic, because it wasn’t clear if there were design flaws, or the users were having trouble because they were still wrapping their minds around the concept. This was no fault of the design researcher, who was excellent. It was a case of a technique reaching the limits of its appropriateness. That’s one reason we later ended up doing a longitudinal study in which people were able to try out the product for a few weeks—and presumably got past the learning curve of what it was all about. But we still had to ask users questions to understand what they thought about the product, including the key question of whether it had value to them. Again, it’s not all about usability. If a product doesn’t achieve an organization’s goals as well as its users’ goals, it’s not a success.
Asking people does have inherent problems, but all UCD techniques have pros and cons, and sometimes it’s quite valuable to understand what people are thinking. Even knowing that may not be how they’re acting. But knowing there’s a disconnect between thoughts and actions is also useful.
Brian, not being able to take baby steps is pretty much the defining feature of a breakthrough product. One can do personas and scenarios, etcetera, but these are often inherently speculative. One can see only the before state—and really breakthrough products change the world significantly enough that the before state may not be that closely related to the after state, because the product changes things so much. Imagine trying to envision and design for today’s Internet 30 years ago. At a conceptual level, a retail Web site isn’t that different from a catalog retailer, which is one reason why catalog companies like L.L. Bean and Crutchfield often have good sites. But in terms of actual impact—both for shoppers and for businesses—it’s a very different environment from the pre-Internet world. As mentioned, not even Tim Berners-Lee fully anticipated where things would go. Certainly he never initially thought of the World Wide Web being used for commerce. He was just looking for a way to distribute papers among academic researchers. So it’s sort of like trying to duplicate Columbus’ voyage by building a bridge across the ocean: It’s theoretically doable—although you often might not even be sure where or if there’s land on the other side—but not practical in terms of the time and effort needed to get there. But it’s also just a different type of problem, so the approach needs to change. Much like quantum mechanics was created to solve problems in situations where Newtonian physics broke down.
John, thanks for the recommendation of the IDEO Method Cards. I’ll need to check them out. I agree it’s less a matter of techniques not being appropriate, as much as our mindset. I’ve been interested in learning traditional—that is, offline—new product development, and one area in which it is weak in is figuring out what to build in the first place. The problem is what they aptly call the “fuzzy front-end,” and this is where I think UCD has a bit to teach those folks—just as we’ve got a bit to learn from them about how to think more about the broader picture.
I think this is a relevant article, not least because of the potential of throwing away good ideas if you stick too rigorously to following the results of user feedback and observation. Just because there are things they don’t like—or can’t use—now, when they’re experiencing something wholly new, doesn’t necessarily mean that you’ve got it wrong.
I don’t think anyone—at least I hope they wouldn’t—would advocate never getting users involved in the design of revolutionary products, but I think that sometimes you have to take their input with a pinch of salt and believe in your ability as a designer.
Hi George
In the offline world, where most of my work primarily is, most of the cult/ breakthrough objects came about without traditional or non-traditional market research of the type you mention at the outset. But they do a significant amount of testing via product labs with proof-of-concept prototypes before making the investment in expensive tooling and even more expensive branding and marketing—for example, the MotoRazr, the iPod. This is true even if they do say in hindsight that the user always was at the centre of the design process. ‘Thinking about the best interests of the user’ was—not what the user said.
Applying user feedback directly to products might be a safe way, but it would result in boring products. This must also be the reason why there are still no great Indian or Chinese brands.
Marla has more than 20 years of experience doing award-winning design work for a variety of companies—from dotcom startups to Hollywood studios such as Disney to Fortune 500 companies, including Nestle, Transamerica, and The Capital Group, and to Internet giants such as Yahoo!, where she was the interaction designer for Yahoo! Search. Marla heads her own User Experience consultancy. She has also taught at UCLA Extension, spoken at numerous conferences, and written articles about UX design. Back when Marla had a hands-on role in crafting Web sites, she co-founded The Web Standards Project, a grassroots coalition of Web developers who sought to ensure browser-makers fully supported HTML, CSS, and other Web standards that help make the Web accessible to all. She was also a co-founder of both Boxes and Arrows, a peer-written online journal about UX issues, and UXnet, a group seeking to make connections between people, resources, and UX organizations. Read More
