Users don't know what they want - but they know something

How much, or little, should product designers and developers interact with potential users and customers of the products the designers and engineers are creating?

It seems like a simple question, but if you think about it some and recall some of the famous perspectives on customer input into product development you find that the answers to this question tend to land on one of two extremes.

On the one side, you have the Steve Jobs/Henry Ford take on customer needs and wants. Jobs more or less thought customers had no idea what they really wanted, and he (and Apple), had to create that want by building amazing products that met that need (that the users didn't know they had). Ford is famously quoted as saying that if he had asked customers what they wanted they would have replied 'faster horses', instead of reliable and affordable automobiles.Ford

The other extreme, and one seen traditionally in lots of workplace kinds of technologies, is for developers and designers to build just exactly what customers request. This approach is mostly an outgrowth and evolution of internal IT shop's tendency to build custom applications based on a list of documented requirements from the end users. If the feature was in the requirements doc, it made it into the product. If not, then the capability didn't get built in the delivered product. And the IT response to downstream complaints was always, 'Well, it wasn't in the requirements.' 

So what is the best, or most effective middle ground between Jobs/Ford (customers don't know anything) and the traditional IT (customers HAVE TO know exactly what they want) approaches?

Maybe the best approach is summed up in this recent piece from the O'Reilly Radar site, 7 User Research Myths and Mistakes:

The most common reason people give for not talking to users is that “users don’t know what they want.” While that’s sometimes true, it’s not a good reason for not talking to them. It’s just a good reason for not asking them to tell you exactly what they want.

Instead, ask people about their problems. Ask them to tell you stories about how they use other products and how they make buying decisions. Ask them when they use specific products. Is it on the train? In the car? At their desks? At work? Ask them about their lives.

Users might not be great at telling you what new product they’re definitely going to use, but they’re great at telling you about themselves, and that is a very good thing for you to understand if you’re making a product for them.

That seems right to me - describing that sweet spot or middle ground between not giving a rip about what users think and the other extreme of expecting the users to tell you exactly what you should build for them.

Keep this in mind the next time you sit down with some HR tech solution provider salesperson. How much do they ask you and your team about the problems you need to address? How much do they seem interested in what makes your organization work (and unique)?

And how much do they like to talk about exactly what their product does?

You are the user. You might not know everything. But you sure know something.

Comments

[Duncan from Vetter]

We totally agree with that approach outlined in the O' Reilly article. Laura Klein (the author) seems to write a lot of sense, here's another similar article by her: http://radar.oreilly.com/2014/02/building-the-right-thing-vs-building-the-thing-right.html