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.
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.
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.
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.
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.
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.
George has more than 10 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 he was the interaction designer for Yahoo! Search. For the past two years, George has headed his own user experience consultancy. He has also taught at UCLA Extension, spoken at numerous conferences, and written articles about user experience design. Back when George had a hands-on role in crafting Web sites, he 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. He was also a co-founder of both Boxes and Arrows, a peer-written online journal about user experience issues, and UXnet, a group seeking to make connections between people, resources, and UX organizations. Recently, DevSource™ featured George in its series of video interviews with experts in the field of software and Web development, “Great Minds in Development.” Read More