UX Prototypes: Low Fidelity vs. High Fidelity - NN/G

Introducing NN/G Membership | Access all self-paced courses for $249 per year | Join by Jan. 26, 2027 |
Find the training option that fits your learning style.
December 18, 2016 2016-12-18
A user interface prototype is a hypothesis — a candidate design solution that you consider for a specific design problem. The most straightforward way to test this hypothesis is to watch users work with it.
There are many types of prototypes, ranging anywhere between any of these pairs of extremes:
The choice of prototype will vary greatly depending on goals of the testing, completeness of the design, tools used to create the prototype, and resources available to help before and during the usability tests. But, whatever prototype you may use, testing it will help you learn about users' interactions and reactions, so you can improve the design.
Ripping up code is very expensive. Ripping up a prototype is not, especially if it’s just a piece of paper.
Let’s first consider common arguments for not testing a prototype. These are:
These arguments may seem good at first glance. But in reality, testing final products is uninformed and risky. Enlightened teams create prototypes, have users test them, and iterate the design until it’s good enough. (Note: We also test final products to benchmark the usability at the end of a project or at the beginning of a new one, to assess ROI, to run competitive studies, and to do a final check and make small tweaks.)
Work needs to be done to bring a prototype to life for usability testing. To make it respond to user actions, we can spend time implementing the interaction before the test or we can “fake” the interaction during the test. Both methods have benefits and drawbacks.
With interactive prototypes, the designer must set a response for each possible user action before the test happens. Even with the right tool, building an interactive prototype can be time consuming: you have to get all the click targets right, and make the system respond only when the user interacts with a clickable target.
With static prototypes, the responses to users’ actions are given in real-time during the test by a person who is familiar with the design. There are several methods that can be used with static prototypes:
Wizard of Oz testing is particularly useful for testing AI-based systems before you have implemented the artificial intelligence. The human who controls the computer can simulate the AI responses based on natural intelligence.
Criteria to help you decide which type of prototype is right for your project:
The fidelity of the prototype refers to how closely it matches the look-and-feel of the final system. Fidelity can vary in the areas of:
A prototype may have high or low fidelity in all or some of the above 3 areas. The table below explains what high and low fidelity mean in each of these areas.
Yes: Many or all are clickable.
No: Targets do not work.
Yes: Links in the prototype are made to work via a prototyping tool (e.g., InVision, PowerPoint).
No: Screens are presented to the user in real time by a person playing “the computer.”
Yes: Graphics, spacing, and layout look like a live system would look (even if the prototype is presented on paper).
No: Only some or none of the visual attributes of the final live system are captured (e.g., a black-and-white sketch or wireframe, schematic representation of images and graphics, single sheet of paper for several screenfuls of information). Spacing and element prioritization may or may not be preserved.
Yes: The prototype includes all the content that would appear in the final design (e.g., full articles, product-description text and images).
No: The prototype includes only a summary of the content or a stand-in for product images.
A delay also gives users extra time to study the current page. So, with a slow prototype, usability-test participants may notice more design details or absorb more content than they normally would with a live system.
TIP: If the page supposed to appear next is hard to find in a paper prototype or slow to load in a clickable prototype, take away the current screen the user is looking at, so she is instead looking at a blank page or area. When the next page is ready, first display the previous page for a few moments again so the user can get her bearings, then replace that screen with the next one. The test facilitator can help this process by saying just a few words to help the user recover the context — for example, “Just a recap, you clicked About Us.”
In prototype tests, facilitators often talk a bit more with participants than they do in tests of live systems, mainly for the following good reasons:
Even with the above necessary interactions between the test facilitator and the user, the test facilitator’s ultimate goal should be to quietly observe the person interacting with the design, not to have a conversation with the participant.
Note that “computer” errors can seriously impact the test. As screens appear, users form a mental model of how the system and the research method work. If the wrong page appears, don’t assume that you can make users forget what they just saw. (Brain wipes only work in Star Trek.) Even if you take the screen away or try to explain the error, users may infer that the wrong screen is related to the task or get some more knowledge from your explanation, and may be later influenced by that information. Seeing the wrong page also breaks the users’ flow, and can confuse them. Finally, later in the test, if a screen appears that is unexpected, they might think the prototype is just malfunctioning again. This impacts the users’ expectations, trust in the research method, and ability to form a consistent mental model.
Since computer errors can negatively impact the study, take the time to pilot test and fix issues with the prototype before any sessions occur.
Make no mistake: You cannot afford to not test prototypes. Your design will be tested, whether you plan for it or not. Once y