You can't change the game if you don't understand the players

That hot post on the Fast Company Design blog, User-Led Innovation Can't Create Breakthroughs; Just Ask Apple and Ikea, is both wonderfully true and dangerously wrong. I want to both make it required reading for all my clients, and also bury it underground where it will never again see the light of day.

It is deeply and importantly true that you should not build what your users ask for (or put another way, you should not ask your users what to build). At Cooper we call that “automating the misery.” One commenter on the original post reminds us of the Henry Ford quote:

“If I'd asked customers what they wanted, they would have said 'a faster horse.'“

If Ford had listened to his users, he would have bred faster horses and made better saddles, and he wouldn’t have put out a game-changing product. Many of our clients come to us with a history of producing bad user interfaces, and they can’t understand why when they have included every popular feature request from their users.

The reason for this is very simple: users are not designers or visionaries. We should no sooner ask them to design a product than we would ask them to write the code.

Where this article gets it very, very wrong is in the implication that being user-centered, talking to users, or understanding them at a deep level is not important or even antithetical to creating a game-changing product. Apple and Ikea are held up as the prime example of this. But both of these companies make products for consumers. Their target market is not too dissimilar from the designers themselves. They can get away with not talking to users because they already understand them at a deep level.

But what if you’re designing a product for a user very different from yourself? What if your user is a heart surgeon? An architect? An investment banker? In these situations designers can’t draw on their own personal experience for inspiration, and shouldn’t. (Though honestly it might be funny to see Apple’s take on a heart surgery interface.) As I talked about in my blog post on expertise, you can’t use your brain to design for a very different brain.

Users can only tell you what they think they want to achieve their goals. It’s our job to listen to what they say, detangle it, and design something that they love. To be in a position to do what you do well—design visionary products—for someone not like yourself, you have to understand your users. Once you truly understand your users’ goals, only then can you create game-changing products to help them achieve those goals.


Nina Mehta
Jenea, I completely agree. As designers, we cannot completely draw on our experiences and knowledge. We cannot possibly know everything, but then again, neither can our users. I wrote a similar post about this yesterday and one of my commenters succinctly said, "design is generative, not deductive." He makes a great point. There is no fixed formula; design is not always logical--in the mathematical sense. Your post also brings up a great opportunity to discuss user-centered and self-centered design. Is it valuable to hire people on a team who are likely to be users of the products, people who intimately understand the needs, wants and nuances of a product? Or, is there power in bringing in people who are defamiliarized (re: Shklovsky, Geneve Bell) to the problem space and project to broaden the scope exploration and solutions? I'm not sure, but I think it's a good question. I suppose it depends on the project, problems and design goals--as always. Thanks for sharing your thoughts. Here are mine:
Graham sear
Hi Jenea, completely agree. I do think the Henry Ford quote can be used to both support and negate the need for user research. On one hand people have said a 'horse' so you focus on improving their horse-riding experience. However, if you focus on the word 'faster' then you get insight into what people actually want. Something faster. They would only say horse because they have no concept of anything else. That is what a good designer will do with user research and interviews. Highlight the underlying need.
Tim Allan
The oft used Ford quote, I always find, rather misleading. As a call to action to "follow your instincts and never let detractors voices get in the way", I think it's great. However, it misses the point in that people actually didn't want faster horses. What they wanted a more convenient mode of transport. One that didn't get tired. One that was consistent in its output (ie could govern its speed), and one that didn't need much upkeep (it costs a lot to keep a horse). All the attributes a mechanical system could deliver. Obviously, using this wouldn't have lead to such a punchy quote so you can understand why he expressed it that way. Consumer insight, led by rigourous understanding of peoples needs is only one part of the equation and I agree with the general thrust of your post. What Ford may have also understood was the changing environment his new products would live in. Cars are only as good as the infrastructure they live on, so a very deep insight into the growing road network (which was also suitable) to run his cars on provided an ideal catalyst to solidify his ideas on newer transport systems. This no doubt would have been fed by the long standing developments in the rail network, and before that, the canal system in the UK around the time of the industrial revolution. This is a bit of guesswork on my part with regards to exactly what Ford's thinking was but the point being that user led insight should only make up part of the reservoir you draw from for ideas for innovation. Ford may well have looked far and wide and used burgeoning consumer demand (user insight) fed with a startling insight into the development of other transport systems in the past. As well as lending an ear to what they say, you need to focus and eye and concentrate a brain on the things around the product, i.e. its landscape. (I believe architects call this 'site' ) as a way to help drive innovation. In a way to think thats what the Fast Company article was trying to get at.
Bob MacNeal
I like the reminder "Users can only tell you what they think they want..." Please note you have a typo in that sentence (change the first "want" in that sentence to "what"). I'm a developer who works on apps where IxD is not (formally) considered. IxD is, at best, an after thought for most of the non-public-facing apps I'm contracted to build. I'm usually the lone user advocate on the team. While an advocate, I'm not a doormat. I know users need my advice & guidance. User led insight is always considered (part of the reservoir), but rarely implemented verbatim. On good days, I build software that users won't hate.
Nick Myers
Hi Bob, Thanks for catching the typo. Fixed.
Jenea Hayes
@Nina: Fascinating questions! I think about those issues a lot because I'm fascinated by the way that experience changes our brains. I think you gave the most responsible answer already ("It depends"), but I'll add two comments to that. The first is that it can be extremely helpful to have a subject matter expert on the team (or on call, at least) who has "been there, done that," but you have to keep in mind that their experience as part of a product team will ultimately transform them into an alien who is no longer like the user. I think 18 months is a good rule of thumb for how long that process takes. After that, their insight is still valuable of course, but perhaps not as valuable as a current user untainted by product development experience. I can tell you that former users are often the most skeptical of the results of user research in my experience! As for the naive perspective, I really think this can be valuable. Often it's the naive point of view that can get at the disruptive solution: A fresh brain approaching the problem without the baggage of learned helplessness and "this is how it's always done" is perhaps best suited to break through the log jam of old thinking. (Of course, I *would* say that, as a consultant who is always naive coming on to a project!) @Graham: I'm not sure I would say "negate." Instead, as you say, it emphasizes how important it is to not take what users say at face value. *Why* they say what they say is key, and unpacking user requests for the underlying goals and motivations is the job of the designer. @Tim: I think we are in vehement agreement. The quote strikes home on many levels and all are worth exploring. It does have the benefit of being pithy! I agree that the FastCo. article was ultimately making your point, but what got me all ramped up was the tone of "Apple doesn't talk to users, and they make great products! You shouldn't listen to users, either!" It scares me to think of hordes of busy executives skimming that article and taking that to heart, without all the other insights and caveats that I and many other designers have been talking about. "We don't need no stinkin' user research!" @Bob: keep fighting the good fight!
Marty Nelson
Nice post. I used a quote from it to help describe a major shift in technology development for which I am advocating ( The traditional focus has been on the functional aspect of technology, yet there exists a second type of feature that is a demonstrable confirmation that the expected value was realized and this happens after the functional aspect has been exercised. I propose that our top priority should be engage users by asking what will they be shown that proves the satisfaction of their desires. It seems the design community knows this to be true. I think the missing piece has been the continued attempt to boil design down into a functional requirement, whereas we want to keep users the majority of the time in a state of enjoying the value of the system. Most functional mechanisms are really necessary evils and our focus should be to minimize those.
I agree with Tim Allen's comment. You should ask what users want, but you should ask further and find out WHY they want it. If people ask for a faster hourse, ask them why they want it, what it would mean for their business and how this would change the way they work. This way you should end up with a functional requirement and that is where the designers come in. They should translate this requirement in the best possible solution and check back with the customer to see if this solution would serve the customers needs. So, don't blindly follow the customer question, but don't ignore the customers whishes either. PS. there still is a market for faster horses ;-)
Alok Jethanandani
"The true sign of intelligence is not knowledge but imagination." - Einstein This situation you described is often referred to as the inventors paradox. If all great thinkers resorted to the status quo, then they wouldn't be great ideas. Look at all the paradigm shifts in history: Copernicus, Kepler, Galileo, Newton, Einstein, Tesla, Edison, and ofcourse as you mentioned Henry Ford. Here is a more recent Henry Ford: It’s really hard to design prod­ucts by focus groups. A lot of times, peo­ple don’t know what they want until you show it to them. – Steve Jobs
how are you?wannaWatch the funny video on "Oh Funny Tv" funnyman

Post a comment

We’re trying to advance the conversation, and we trust that you will, too. We’d rather not moderate, but we will remove any comments that are blatantly inflammatory or inappropriate. Let it fly, but keep it clean. Thanks.

Post this comment