So, it seems I’m inspired to do most of my writing around--or as a result of--some dumb user experience or annoyance I experience at work or in the real world. And….so….well, here is another.
On the heels of a pretty-darned successful, highly visible project in which user research activities were very prominently integrated and featured (and just when I think we are getting past the point of having to explain what we do), I am blind-sided by yet another opportunity to educate people whom you’d think would know better. So, here we go.
There seem to be some misconceptions about user research:
• It is at odds with innovation
• It does not impact the decision about a solution
• It hinders iterative design and development
• It’s not needed for iPad apps, because they’re innately brilliant
Two common ideas keep fueling these misconceptions, generally from managers who read books that managers read. “Steve Jobs didn’t talk to users,” and “Henry Ford said that if you ask people what they want, they’ll ask for a faster horse.” These are well-known examples from peerless visionaries who drove innovation in their companies. And they are--indisputably--excellent, inspirational quotes to foster innovation thinking.
Here’s the rub: The realization of the products they envisioned, and all the ways people use them, did not happen solely due to one person envisioning it. I know—that sounds obvious, but here’s what I mean: Steve Jobs may not have talked to users, but Apple has some of the best, most well-respected user research groups in the world. So do many respected design leaders, including Sony, Microsoft, HP, Google, and my all-time favorite example of excellent user experience work, TurboTax. TurboTax is not great solely because some brilliant guy sat in an office and designed it, and neither is the iPad. It is great because of its design, yes, but also because of how application designers have understood the domain and usage scenarios of the users of the devices. Without that understanding, the device would be a beautiful, useless object. User research and innovation are not at odds; they go hand in hand. A product will not be successful with only one of those in place. They are partners.
I agree that, in general, users should not drive the vision for the products we design and build. But if we are not providing an opportunity for our users, or solving a problem they have, it will not fly. We don’t talk to users to ask them for permission or ask if something might be useful. We talk to users to understand their world, to walk in their shoes. We talk to users so we can ensure our design effectively either addresses an unmet need, or opens the door to an unimagined opportunity, in a way that supports or improves what they do. That does not prevent us from being innovative and creative, but it helps us to get inside their heads to support and validate our innovative vision.
Innovation and user research work in concert to create some of the most innovative and user-friendly devices known to man. A single person, even the most brilliant mind, cannot possibly anticipate every use case for a product. (And we’ve all seen very poorly-designed apps on the Apple Store and Android Market, now haven't we?)
User research does not hinder iterative design and development (or any design and development, for that matter). In fact, it’s quite the opposite. As a colleague of mine says, “You pay now, or you pay later!” Well-timed and appropriate user research can make design and development more effective, and reduce cost of user acceptance testing, future enhancements, deployment, training and support costs. You know the old adage, “Measure twice; cut once”? Too often we don't even measure once.
When we draw a conclusion without knowing what problem we are solving, we risk traveling down a “path of very expensive return”. 15 years ago, everyone said, “We need a web site!” but I rarely heard anything about who we were serving, what problem or opportunity was being met, or why. Now, the chorus is, “We need an iPad app!” But the same questions still apply. Why do we insist on providing a solution without a problem? An answer without a question? We need to understand what we are trying to accomplish before we build.
One of the reasons I like iterative design and development is that you can bite off chunks of the problem and validate the solution with less investment (potentially down the drain, if you find you’re on the wrong path). You can also course-correct more effectively. Big reveal: User research enables the same thing! You can find out early on if your vision is on track or just blowing smoke.
Let's read beyond the sound bytes in our management books. There's no one prescription for designing and developing a solution will be successful, but using proven practices is a great place to start.
