When Prototyping Isn’t the Solution
As a product person, the pressure comes from every direction. It always screams and shouts the same things: move faster and build more…
As a product person, the pressure comes from every direction. It always screams and shouts the same things: move faster and build more. Like a bureaucracy, the set of unbuilt and important features only ever grows. For a well defined market and a well defined situation, I couldn’t agree more that velocity and quality are key. However, in the early phases of a product or feature, prototyping with code is more often the enemy. In this brief post, I’ll explore why I believe that’s the case and a hypothesis for why we end up making the incorrect tradeoff even when we know it’s wrong.
Now, I’m not trying to rewrite the product playbook in this post; putting prototypes in front of users is very effective, but why do we get to that stage so quickly when development time is so expensive, when the opportunity costs of using that time are so high, and when uncertainty is so pervasive in these early phases? We know that user research, surveys, and market research can help us start our development with the best possible, knowable guess, so why does it so frequently get short changed? Why do we so often skip this step altogether?
First, it’s because research doesn’t translate well into progress. Product and engineering teams understand its utility, but stakeholders do not. All that time spent “preparing” or “researching” or “estimating” or “spiking something out,” to stakeholders doesn’t feel like progress. Unfortunately, working code does feel like progress, so step one is to push back hard on the concept that the prep work doesn’t matter and to learn to sell what the organization is learning so that product and engineering get the breathing room necessary to choose the right first thing to prototype.
The second reason is our own brains. If there’s one omnipresent truism in cognitive psychology, it’s that we do what’s easy and we do not do what is hard. The reality is, for most anyone in a product team except a UX researcher, the primary thing you do most days is not pure, speculative UX research. Sure you may meet with uses all the time, but most of those interactions relate to existing work not brand new innovations in a new or novel workflow. You also know how to meet with engineers and get things done. Great, that’s easy for you. For engineers, you know how to architect and build, so you architect and build. Doing fresh user research on a new problem requires a different mindset and even fresh creativity — who would be the target users and how can we get access to them to discuss their needs? That’s more cognitively difficult, so it gets short changed.
Finally, per the first point, it’s easier to reply to the people who depend on your output with clear, concrete progress, so that’s what we do more of. My entreaty to the reader today is to first stop. Do you really know enough about the problem space you’re about to tackle to start to build? If so, great, go make something beautiful and impactful. If not, scratch the record, message the approach, and then go sit with people and learn more about their world.