At a product design presentation a few years ago, I remember listening to our UI designer as he went about articulating his high fidelity prototype design before it went to dev. It wasn’t long before we realised something didn’t seem quite right. The UI looked great, but when it was tested against use cases, simply couldn’t stack up against obvious pain points it was meant to solve. It got worse as the meeting progressed. As was expected in meetings of this nature, more prodding from different team members followed and there was little the UI designer could conjure to back up the world he had done. It left everyone in the room dreading our looming deadline and the realisation that we’d have to start right back at the drawing board (Pun unintended) on an even tighter timeline. We quickly refined our approach to our product design processes after a quick retrospective.

The experience gave me a strong sense of deja vu. I had very similar experiences to the designer in my previous life as a UI designer. My beliefs at the time were very similar to his. Take the brief, head down into my basement, work in isolation, drink coffee while researching Dribble for cool UI ideas and finally emerge out the other end with a perfect Hi fidelity prototype design that was intended to wow the stakeholders. I remember just as he did, struggling to articulate to stakeholders how this seemingly perfect glitzy UI was the answer to their problems.

Truth be told, at the time I was young and eager to prove myself as most UI designers are. My need for validation from peers seemed to take precedence over good sense. I had substituted problem-solving over the craving to be viewed as a unique artistic voice with a Dribble worthy portfolio, a reality most early UI designers still struggle with. I skipped past the need to validate the solution I was designing for through sketching and wireframing, steps that would have checked most of my assumptions way before I got down to the hi-fidelity prototyping stage. I had held a belief at the time that sketches were for amateurs who didn’t have a good grasp of UI design. The more I self-evaluated the more I began to realise the flaws in my approach.

What I did and what many amateur designers still do today is put mouse-to-computer way before they can answer the question. What is the problem and what am I attempting to solve? I use the word amateur and intentionally so because in attempting to create a hi-fidelity prototype, a novice UI designer completely misses the fundamental point of product design. Product design in its essence has more to do with problem-solving and fixing a users pain point than aesthetics. It’s borne on the back of plenty research that precedes the UI. In a tiny sentence, product design is NOT graphic design.

Why starting with high fidelity prototypes is a bad idea

There are several reasons why I believe starting with hi-fidelity prototypes in product design is set for failure:

  1. Emotional attachment: The amount of emotional attachment to a piece of work is directly proportional to the time spent on it. Now imagine all the time a designer has spent on a high fidelity prototype. The effort needed to put together a good visual hierarchy and flow even with a preexisting design system in place is huge. Without a design system in place, the effort is exponentially an order of a magnitude greater. This is usually always true at early product conceptual stages. The amount of effort sunk in creates a big emotional attachment to the design by the designer. Then at a product review meetings, you come along in your product management magnanimity and start to poke holes in a work that has been carefully crafted over days and weeks. Good luck with that meeting! Contrast this with starting with a sketch. Sketching an idea on paper ensures you invest little time and have little emotional attachment to the sketch you created. It allows you to reframe your thinking that these are just stepping stones on your way to solve a problem. This allows you to get through multiple bad ideas and iterations quickly without having anyone in the product team have a meltdown.
  2. Limited choices: The analysis and brainstorming stages of product design requires iterating through multiple choices before synthesis and settling with the one that works best. No matter how good you are at creating UIs, you can never get through all the permutations that you can get from just sketching. Which is why I’m a big fan of a GV sprint that forces you to wade through multiple iterations and picking from the best ones of the lot. What’s even better, having multiple sketches from different people actually ends up as a great team building exercise where everyone feels involved and has a sense of ownership.
  3. It becomes an unnecessary distraction: The team, even stakeholders can potentially go off tangent and start discussing aesthetics that have little to do with the problem a design is intended to solve. I once witnessed a stakeholder who was fixated on the colour scheme while the real problem was the design didn’t address customer pain points that needed to be solved in the first place. The colour scheme was probably the least of our problems and belonged at the bottom of a pile. Having a lower fidelity prototype ensures time is not spent focusing on the wrong problem.

High fidelity prototypes, for conceptual work, is a big risk. It’s best used in an environment when the changes are iterative and clearly not when trying to address a fundamental problem. However, even in these cases sketching still can yield better results.

Maybe, it’s time to get back to the humble paper and pen because that’s what really helps us answer the real question: What is our problem and what are we trying to solve?!