Bridging the Gap Between Products and People
As a product designer, I’m often alarmed at how different my perspective can be than that of my customers. I create a flexible system of semantic, consistently-styled, reusable user interface components, piece them together into a series of views that support complex workflows and tasks, and… people get stuck during usability tests and tell me, “I don’t know what to do now,” or, “That’s not what I expected.”
When customers react this way, it illustrates the gap between my own thinking and the realities of their world. It’s like two archaeologists looking at the same fossil and drawing completely different conclusions.
As Samuel Hulick points out in his article Features vs. Benefits, “People don’t buy products; they buy better versions of themselves.” I think this is insightful. Whereas my tendency is to fixate on the product itself, customers will evaluate it on the basis of whether it adequately solves their problem.
I must constantly remind myself of the following:
Real solutions, to real problems, for real people.
If I were to say, “I have this idea for an app that makes processing email into a game,” I’m describing a solution. There’s nothing wrong with this, as long as I don’t stop there. I must identify some underlying problem that explains why my solution is needed. (Hint: The problem is not that “people need an app that makes processing email into a game.” That’s simply rephrasing my solution.)
“People feel overwhelmed and unproductive when they have to spend time sorting through emails.” That is a description of a problem, but I’m not ready to solve it because I haven’t gotten specific about whose problem it is yet.
In this example, it would be helpful to spend some time thinking about who would most likely have these problems with emails, those who receive very few, or those who receive dozens or hundreds each day? Okay, that’s fairly obvious, but I should get even more specific. Do these people receive large amounts of personal emails or are they predominantly business emails? The answer may make a dramatic difference in my product. It will certainly impact my marketing. Are they processing email as a function of their job (e.g. personal assistants), or is it a distasteful add-on to their real job (e.g. programmers)?
By identifying who I’m going to target, I increase the chance of making a product that matters for real people. I can talk to these very people to see if I’m on track. Sadly, there are plenty of products that spring from a hopeful solution to a speculative problem for an imaginary audience. The app store is chock full of them.
When people use something I’ve designed, I want them to feel as though I had them in mind, as though I knew exactly what they needed. As Steve Jobs famously said, I want the things I design to “just work.”
