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 prototypes 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 high fidelity prototypes he had completed. It left everyone at the meeting dreading our looming deadline and the realisation that we’d have to start right back at the drawing board (Pun unintended) and on an even tighter timeline. That experience made us quickly refine 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 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 sketching was 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 define the problem. The first thing they need to ask themselves is 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, novice UI designers completely misses the fundamental point of product design. Many university courses tend to concentrate more on aesthetics over true product design. Product design has more to do with problem-solving over 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:
- Emotional attachment: The amount of emotional attachment to a piece of work is directly proportional to the time spent on it. Now picture the time a designer takes to get a high fidelity prototype just right from the layout to the colors, the typography, shadows or raised buttons etc., in short, it’s no small effort. This is especially true if there isn’t already an existing design system in place which is usually the case at early product concept stages. The amount of effort sunk in creates a big emotional attachment to the design by the designer. 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 and even allows the rest of the product team to contribute.
- 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 a cross-functional team eliminates blind spots and bad ideas early besides serving as a great team building exercise where everyone feels involved and has a sense of ownership.
- 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?!