“Designers have developed a number of techniques to avoid being captured by too facile a solution. They take the original problem as a suggestion, not as a final statement, then think broadly about what the real issues underlying this problem statement might really be (for example by using the "Five Whys" approach to get at root causes). Most important of all, is that the process is iterative and expansive. Designers resist the temptation to jump immediately to a solution to the stated problem. Instead, they first spend time determining what the basic, fundamental (root) issue is that needs to be addressed. They don't try to search for a solution until they have determined the real problem, and even then, instead of solving that problem, they stop to consider a wide range of potential solutions. Only then will they finally converge upon their proposal. This process is called "Design Thinking.”—
Don Norman rethinks his position about “Design Thinking”. Het wrote the book “The Design of Everyday Things” when I was 7. A book I read in my early twenties and really influenced how I looked at objects and interaction
I think designers have a complementary set of skills that really helps in solving challenges. Especially in a time where we need more disrupting innovation instead of incremental.
Solving For A Use Case vs. Solving For Surprise
I want to offer an alternative view to Don Norman’s article “Technology First, Needs Last” where he argues that “design research is great when it comes to improving existing product categories, but essentially useless when it comes to new, innovative breakthroughs” and that those breakthroughs are largely technological ones.
This blog entry got long. Great writers are concise. As I am a mediocre writer, I’m leaving it longer than I’d like it to be. Try not to yawn out loud.
The limitation of a local maximum (background)
When user-centered design is implemented, it usually goes something like this: NonInnovation, Inc., an operations-oriented product firm realizes that they need to make a big advance in a product. They hire BouncyBallChair Inc, an innovation company which offices in a loft space where the walls are pastels and everyone has nurf guns. Oh, and all of their employees wear Warby-Parker glasses.
So BouncyBallChair Inc goes through the user-centered design process, working with NonInnovation to study the target customer or consumer, identify the core problem or need, and create a super-cool product to solve that problem. All throughout, they’re using User-Centered Design. The product is released…it’s the best new product in that category.
But what did we really create? It’s a beautifully designed shopping cart with removable boxes, each a different primary color. If the Google logo were a shopping cart, this is what it would look like. So we have solved the problem of how to make the best possible shopping cart. Local maximum.
Now let’s take a real life company, Twilio. They didn’t have some major technology breakthrough. They used Asterisk, an existing open-source platform, and turned it into a SaaS product. I don’t know anyone at that company, but I imagine at some point in the company’s formation, someone had this conversation: “how cool would it be if we could text a website…or if a website could call a phone…with, like, one line of code.” They would be correct, that’s really cool.
Now, to be fair, I’m sure they had specific use cases in mind, but really what they were doing was creating a platform for an infinite number of uses.
To illustrate this coolness, their pitch in front of a large audience at the New York Tech Meetup went something like this: “Look, with one line of php code, I can create this phone number that you can now call and hear a message.” The presenter had people call the number. Cool. But what was mind blowing was that he had a second webpage, which looped through all the numbers that had called in, and one by one, people’s phones started to ring in the audience. It was visceral. It was surprising. A computer shouldn’t be able to do this. Certainly not with a couple of lines of PHP code.
The underlying issue is that user-centered design can produce breakthroughs, but it’s how it’s being used andto some degree who is using it which prevent it from doing so. I believe the underlying difference is that you’re solving for two different problems: One I will call Solving for a use case and the other Solving for surprise.
Solving For A Use Case vs. Solving For Surprise, Part 2: Single Use Cases vs. Surprise
When we contrast the two examples from part 1 (the shopping cart vs. the grocery store), the key differentiator for me is that user-centered design tends to focus on solving a single problem – a single use case. However, the most exciting and innovative products do something surprising. Something that shouldn’t be possible. As a result, designers, programmers, and everyone else can immediately think of their own use cases for these products. In some sense, this is the difference between a product and a platform.
This is not to say that those innovations don’t solve problems – they absolutely do. But they solve problems beyond a single use case or two. At their best, they are infinitely scalable.
So if you agree that the most innovative products will be surprising, potentially solving hundreds of use cases, whereas user-centered design solves specific problems, sometimes using these innovations, two questions remain. First, must these innovations be massive leaps forward in technology, only invented by mad scientists or criminal masterminds? Second, can user-centered design be used to identify these types of innovations?
Do these innovations have to be massive leaps forward in technology?
Twilio is a technology company, but they did not make the underlying technology, it just made it super-easy to use. Very few of the truly innovative products right now are technological breakthrous — not Twitter, not Facebook (especially at first), certainly not Groupon or AirBnB or Birchbox.
Can user-centered design still be used to identify and create these types of innovations?
Yes, of course! The most entrepreneurs I know in the tech space observe a problem people have through some sort of formal or informal user-centered design. The difference is that they then go out and look for other use cases. We need two design constraints in our normal user-centered design process. First, a criterion must be added: is my solution surprising? I don’t mean “oh, that’s clever” I mean “woah, I (almost) can’t believe that’s even possible.” Not “why didn’t I think of that” but “I never would have thought of that.”
Second, we must ask ourselves “okay, so this is a surprisingly great solution for this one use-case, is it generalizable to potential other use cases?” Or, more likely “what are the characteristics of this solution’s applicability to this use case that might make it a good fit for other use cases? What are the charactaristics that make Facebook great for distributing images? Is it that I know my friends, but not strangers, will automatically see pictures they might find interesting? What else might I want to distribute that way? My location (Foursquare)? Invitations to private games (Farmville)?
The Point solved a specific problem for social action that was so generalizable that it cnot only encompassed multiple social actions, but it also included the Groupon use case. Groupon itself is infinitely scalable. If it solved a problem for a local Pizza place (which I believe was their first use case), what other places have that similar problem? Stores that have high lifetime customer values and high loyalty rates are willing to pay to acquire new customers, in this case by offering deep discounts for a first customer’s visit. Clearly that scales across lots of different types of retail, but as it grew, it had its own value proposition — get your company’s name in front of millions of people and only pay if people buy the coupon. This is a second use case of the product that increases the pool of retailers to whom the service is appealing.
Who’s funding the designing matters
It may be the case that it’s difficult to be massively innovative using user-centered design on someone else’s behalf (i.e., as a consultant). Imagine if in the course of doing consumer research for a shopping cart manufacturer, you (correctly) identify the need for Grocery Subscriptions, a truly innovative concept. It is unlikely that a shopping cart manufacturer can/should take on something that far out of their core competency.
Uber identified a market need and had no constraints as to how to implement it. They basically created NetJets for private drivers. Should they buy our own cars? Pool together existing limo services? Distribute on the iPhone? No constraints = the ability to make it work. Had a taxi company hired a design consulting firm to identify new consumer needs, even if the firm identified a need for Uber, I doubt the taxi company would have been in a position to create this type of service.
Despite these doubts, we’ve proven that innovation at the margins is by definition a failure of user-centered design, but rather a failure of the focus of it being on only solving a specific use case, rather than finding a surprising solution which can be applied to the use case and generalized to an infinite number of other use cases.