Builder’s Perspective vs User’s Perspective
There’s a natural tension in the act of building a product. We have our projection of who we’re building it for (usually ourselves and not anyone else), what we want to build, what it will do, and how it will be used, etc.
Users have their own projection of what they want us to build, who we’re building it for, what it will do for them, how they will use it, etc.
Who you think you’re building for doesn’t end up being the only, or many times even your biggest, constituentWhat you want to build is rarely exactly what’s wanted by usersHow you think it will be used is only a subset of how people actually use it in real life
Our imaginations, as builders, are surprisingly small and the number of “corner cases” large — less like corners and more like whole edges we just don’t conceive of.
Communication vs Broadcasting
Getting the calibration right is a matter of communication, bi-directionally, between us and our users. It’s a conversation.
But instead, usually what we’re doing broadcasting things that serve our purposes as builders-and-sellers:
Stating who we think the user and buyer is, so people can rule themselves in/outStating what we think the value is, so people can be convinced they’ll be better offStating what we think the product/solution is, so people can compare the thing to other things and categorize itStating what the technology is, so people can be bamboozled by buzzwords or impressed by our engineering chopsStating what we think the use cases are, so people know how they will experience the valueStating what the pricing or buying process is, so people know how they will consume it
The problem with communication is the illusion that it has occurred. —
What we tend not to do is communicate expectations:
How do I expect you’re going to use the product?What’s the range of inputs I expect?What’s range of outputs you should expect?What have I imagined you doing?What have I imagined you not doing?Where are the cracks and fissures in the product, in the experience?What should you not be surprised by?How should you interpret the expected and unexpected outputs?How do you think you’re going to use the product?What do you expect it to do when you use it?What don’t you expect?What do you think the value is?
We can’t manage expectations we don’t communicate
Without communicating expectations to, and consuming expectations from, users — we can’t manage them. I’ve found this to be one of the central causes of friction and poor user experience.