The design fidelity conundrum

What level of design fidelity is most appropriate when seeking user feedback?

Low-, mid-, and hi-fi designs for a UI dashboard widget.

No product is ever designed and perfected in the same step. It just doesn’t happen. When greatness is achieved, it is typically the result of an idea having been tried, tested, refined, and iterated upon over time.

That’s why at IBM Design we have the loop as one of our core principles:

The IBM Design Thinking “loop” — a visual reminder that good design work is not linear

We seek to apply this mindset to all that we do. So whether it’s a project workshop activity, a team meeting, or a new piece of design work, we:

• observe (learn about the people involved: their context, goals, habits, etc. and test out our ideas)
• reflect (build understanding and form intent)
• make (explore ideas and prototype possibilities)

Then repeat. And repeat. And repeat.

Our designers are encouraged to “work in the open” — that is, to seek feedback early and often, and to view everything as a prototype. In essence, we want and expect people to fail fast, to learn from the feedback they receive, and then to iterate over their ideas until more and more of the design decisions have been validated.

So when it comes to critiquing designs and getting user feedback, we are very clear that quick and early trumps slow and late. After all, the reason we seek feedback is so we can use the insights gained to further inform and improve our designs. (And if you wait until the thing is essentially designed and built before seeking feedback, the chances are it’ll then be too late and too costly to act on the feedback you receive.)

Some very early lo-fi wireframes, exploring one possible task flow. This kind of early lo-fi design artifact lends itself to quick and honest feedback.

Another positive thing about using lo-fi design artifacts when seeking user feedback is that people tend to feel freer about providing their true thoughts and feelings, as they can see that you are still at the early ideas stage. By contrast, if you show people a high fidelity design artifact, they will likely assume that a lot of detailed work has already gone into the design, and as a result, might well not feel as free to share any criticisms they might have of it, for fear of offending you. Similarly, they might limit their feedback to just certain aspects such as the text, the colors, the icons, etc., assuming that the broader design approach is set in stone and not to be critiqued.

So, using lo-fi design artifacts can be a great way of soliciting early, quick, and honest user feedback.

So far so good.

Some early hand-drawn design explorations by IBM Visual Designer, @NatalieCaudell

However, you might also have heard people tell you that if you’re wanting to test how someone will respond in a specific scenario, the closer the “test” or “model” corresponds to the reality that it is simulating, the more confident you can be that their behavior in the test scenario will be truly representative of how they would react in the real scenario.

So, what’s a designer to do?

Should we show users early, lo-fi design ideas even though they are quite clearly a long way from what the final product will be like? Or wait until we can show more fully realized, hi-fi designs or prototypes?

My point of view:

Seek feedback on your lo-fi explorations, your hi-fi prototypes, and everything in between.

In short, this is not an either/or situation. In nearly all cases, it makes sense to actively seek feedback on your designs at multiple stages throughout a project lifecycle. As you progress from first design to second to third to ninth to fifteenth, more and more pieces of the puzzle will have been tested, refined, and finalized.

An example

IBM Cloud Event Management is a relatively recent service available on IBM Cloud, which helps DevOps teams monitor events, identify incidents, and capture knowledge and tested procedures in operator “runbooks”, so that future incidents can be avoided or resolved more quickly.

The following images show how the Cloud Event Management team created designs at different levels of fidelity as they worked on the UI that users would ultimately use when creating a new runbook. At each stage, user and stakeholder reviews were carried out, which provided the design team with valuable feedback, which they used to inform their next round of designs.

Design artifacts from the IBM Cloud Event Management design team, showing how they progressed their designs through different levels of fidelity.

• First image: One of the design team’s early hand-drawn sketches, exploring some of the key concepts of the runbook editor.
• Second image: A mid-fi wireframe, focused primarily on the editor itself. Here the team started exploring using different colors to represent parameters, commands, and go-to links.
• Third image: The final hi-fi design, which includes not only the core editor (with each step visually separated) but also separate area for tags, parameters, commands, etc. associated with the particular runbook.

Pick the design fidelity level most suitable for the type of feedback you are seeking

Each project is different, but as a rough guide, each of the following stages can provide a good opportunity to receive helpful user feedback:

• initial user and market research
• validation of core project ideas, concepts, metaphors, etc. (i.e. even before pen has been put to paper, you can start “testing” your ideas as you discuss, dissect, and refine them verbally with others)
• early low-fidelity designs (e.g. paper sketches showing the high-level UI)
• mid-fidelity designs (e.g. wireframes that show approximate page layout, more meaningful text, actual UI controls, etc. to test the proposed flow through a single user task)
• higher-fidelity designs (including color, iconography, precise layout, etc.)
• a prototype that users can interact with (note that prototypes themselves can be low-, mid-, and high-fidelity artifacts)
• a coded prototype of some aspect of the product (e.g. to show key functionality or micro-interactions in the UI, etc.)
• an early demo (no need to wait until all intended features are complete)
• a product beta
• the released product

A depiction of how different levels of design fidelity can be used at different stages of a product lifecycle. (Image originally published in an article by Tracy Lepore here to explain “The Sketch to Design Continuum”.)

The key is to think through what specific aspect of your design work you are needing to validate and to then ensure the design or prototype you share is of a suitable level of fidelity. For example, if you are wanting to validate your site navigation structure, a very lo-fi mockup of the UI with different navigation models shown might suffice, but if you’re wanting to validate the user experience of one particular workflow, a mid- to high-fidelity clickable prototype might be most suitable.

Conclusion

When it comes to choosing a suitable fidelity level to use in testing your designs, there is no one-size-fits-all “correct” answer; it will always depend on context. Think through what you are wanting to test and then choose the fidelity level that seems most appropriate.

And bear in mind the following points:

• Carrying out some user research is always better than carrying out no user research.
• Build on top of your previous prototypes, reviewing and refining them based on the feedback that you receive. Remember: the design’s in the details!
• However, it’s best not to rely solely on user testing lo-fi designs, as these — by necessity — contain various “gaps” and are really just approximations of what the final product might be, based on what is known at the time.
• But equally, don’t wait until you have a fully-coded prototype before getting any feedback, as making changes based on the feedback received will be more costly than it would have been earlier on.
• And remember that high-fidelity doesn’t always mean high-effort. You can quickly create clickable UI prototypes with tools like Marvel, without anyone having to write any code.
• And speaking of code, sometimes a quick CodePen demo might be all you need to get some initial user feedback on a particular UI component.
• For further information about using different types of prototype (static vs. interactive, etc.) and different levels of fidelity, see this Nielsen Norman Group article.
• Finally, if you are temped to think that all this user testing seems time-consuming and expensive, remember this:

Whatever the product, each aspect of your design will ultimately be tested (think about it). The real question is: do you want that testing to happen before or after you still have time to incorporate the feedback you receive?

Arin Bhowmick (@arinbhowmick) is Vice President, Design at IBM based in San Francisco, California. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.