Conundrums about design fidelity
When seeking user feedback, what design fidelity is most appropriate?
A low-fidelity, mid-fidelity, and high-fidelity interface design for a Dashboard widget.
No product is designed and perfected in one step. That kind of thing just doesn't happen. A great design is usually the result of an idea being tried, tested, improved, and iterated over time. That's why at the IBM Design Center we have "Loop" as one of our core principles:
IBM Design Thinking “Loop” – This visual image demonstrates that good design work is non-linear.
We try to apply this kind of thinking to all the designs we do. So whether it's a project workshop event, a team meeting or a new design job, we:
Observation (get to know the people involved: their backgrounds, goals, habits, etc., and test our ideas)
Reflection (building b2b data understanding and forming intent)
Create (explore the possibilities of ideas and prototypes)
Then cycle back and forth.
Our designers are encouraged to “work in an open environment”—that is, to seek feedback as early and as often as possible, and to treat any output as a prototype. Essentially, we want and even expect people to fail fast, learn from the feedback they receive, and then iterate on their ideas until more and more design decisions are validated.
So we know very well that when it comes to evaluating designs and getting user feedback, getting feedback quickly and as early as possible is far better than being slow or procrastinating. After all, the reason we seek feedback is to use the information we get to further improve our designs. (If you wait until a thing is basically designed and built before asking for feedback, there's a good chance that changes to that feedback will either be too late or have to be expensive.)
Some very early lo-fi wireframes exploring a possible task flow. This early lo-fi design output helps get quick and realistic feedback.
Another benefit of using low-fidelity design drafts when seeking user feedback is that respondents can see that you are still in the early stages of thinking and tend to be more free to provide their real thoughts and feelings. By contrast, if you show respondents a high-fidelity design, they are likely to think that a lot of detail has already been considered in the previous design, so they are likely to be reluctant to share any criticism so as not to offend you . Similarly, they may think that the general design direction is already established, and will only provide feedback on a few specific aspects, such as text, colors, icons, and so on.
Therefore, using low-fidelity design drafts can be a great way to get early, quick and real user feedback.
Looks good so far.
Early hand-drawn design explorations by IBM's visual designer @NatalieCaudell.
However, you may also hear someone tell you that if you want to test someone's reaction in a particular scenario, the closer the "test" or "model" is to the real situation it simulates, the more confident they are in the test scenario behavior will truly represent how they would react in a real scenario.
So, what should a designer do?
Although the low-fidelity design draft is far from the final product, should we show the low-fidelity design idea to the user as soon as possible? Or should we wait until we can show more high-fidelity designs or prototypes?
My point is this: Whether using low-fidelity idea exploration, high-fidelity prototyping, or anything in between, you should actively seek user feedback.
In short, this is not an either-or situation. In almost all cases, it makes sense to actively seek design feedback at multiple stages of the project life cycle. As you design from the first edition to the second, third, ninth, and fifteenth editions, more and more parts will be tested, refined, and refined.
an example
IBM Cloud Event Management is a relatively new service on IBM Cloud that helps DevOps teams monitor events, identify conflicts, and gather knowledge and tested step-by-step guidance for an operator's "playbook" so they can be faster avoid or resolve future conflicts.
The images below show different fidelity designs drawn by the Cloud Event Management team while exploring the Code of Practice creation page. At each stage, users and stakeholders participated in the review, which provided the design team with valuable feedback to guide their next round of design optimization.
Design drafts from the IBM Cloud Event Management design team, showing how they use different levels of fidelity to advance the design.
First image : One of the early hand-drawn sketches by the design team, exploring some key concepts of the Code of Practice Editor.
Second image : A medium-fidelity wireframe draft, mostly focused on the editor itself. Here the team started exploring the use of different colors to represent parameters, commands, and jump links.
Third image : The final high-fidelity design, which includes not only the core editor (each step is visually distinct), but also separate areas for markers, parameters, commands, etc. related to a specific code of practice.
Choose the design fidelity that best matches the type of feedback you seek
Every project is different, but as a general guide, each of the following stages can provide a great opportunity to receive useful user feedback:
Initial user and market research.
Validate project core ideas, concepts, metaphors, etc. (for example, by verbally discussing, dissecting, and improving them with others, you can start "testing" your ideas before you even start writing them).
Early low-fidelity designs (such as paper sketches showing the main user interface).
Medium fidelity designs (such as wireframes showing rough page layouts, more meaningful text, and actual interface controls, etc., to test the flow of an envisioned single-user task).
High-fidelity design (including colors, logos, precise layouts, and more).
A prototype that users can interact with (note that the prototype itself can be a low, medium, or high fidelity design).
Code prototypes for some parts of the product (such as showing key features or micro-interactions in the user interface, etc.).
Early demo version (no need to wait until all expected features are complete).
Beta product.
The official release version of the product.