A guide to building prototypes for UX research
Prototypes are essential in UX Research. However, there are prototype pitfalls you should avoid. This article describes some of those pitfalls and how to avoid them. These are thirteen lessons I learned the hard way, from real research (and very real mistakes!).
By following this guide you can help to ensure that you produce consistent, logical and functional prototypes that serve your research (and do not seriously confuse your participants!).
Avoiding prototype pitfalls is especially important in unmoderated user tests where you can’t intervene if your prototype behaves in an unintended way or if your participant misinterprets an aspect of your prototype.
Make Sure Users Can Access Your Prototype
Yeah, this one seems obvious, but you’d be surprised how easy it is to overlook… until you’re watching your poor participant locked out of your lovely prototype. For example, make sure your participants do not need to log in to access your prototype. If they must log in, provide them with very simple, clear log in instructions.
Tip: Pilot test your prototype link in an incognito window.
Build The Prototype To Work On Small/Low Resolution Screens
You may be building your prototype on your lovely big monitor, but your participant may be viewing your prototype on a much smaller or lower resolution screen. This means they may miss critical parts of your prototype (this has happened to me in my user tests in the past, causing those tests to fail).
One Prototype To Rule Them All!
Use as few prototypes in each test as possible. If possible, build all the interactions required for your research on a single prototype. This is more reflective of real life anyway. The problems with using multiple prototypes in a test include:
- Changing prototypes disrupts the smooth flow of the test
- The change from one prototype to another can be confusing and distracting to your participants, especially if your prototype is of the same page that the participant was just on. This is because it may not be obvious to the participant whether or why the change occurred. In this case, it can be helpful to explicitly state in the test task that they are, indeed, on the same page as before.
- Each new prototype can take a long time to load
The exception is when your participant must start a task on a particular page and their previous task could leave them on a different page (if, for example, they took an unanticipated route through your prototype in an earlier task)
For example, you might ask your participant in their first task to add three items in an online shop to their shopping cart. Inadvertently the participant selects a wrong item and gets lost trying to correct their mistake, ending up on a page about shipping and returns. So they start their next task on the shipping page, when you expected them to still be on the online shop page at the start of this task. In this case, for the sake of making sure your participant is in the right place at the start of their task, it may be worthwhile adding a starting link to the online shop for that next task.
Never Display Prototype Tool UI Elements
Make sure you switch off any InVision, Figma or other UI elements not related to your prototype. These must not be visible to your participant at any point during their test. These include: comments toggles, grid button, clickable area highlights etc. This is to avoid confusing your participants, who may interact with these elements during their test, with unexpected consequences.
Don’t Leave Clues In The Prototype
If a test task requires your participant to select an item, make sure that item is not already selected in the prototype e.g. double-check that the item is not highlighted in a different colour, toggled or whatever method you used to indicate selection. If you leave unintentional clues this will skew your research findings. Similarly, switch off any clickable area highlighting such as the blue InVision highlights that appear on all clickable elements on a page.
Another inadvertent clue can be the words you use in your prototype and in your test tasks. Generally you’ll design your test tasks to avoid the use of words used in your prototype or words similar to the words used in your prototype. For example, if you want to test an ‘Announcements’ section in your prototype, you might ask your participant to find out about the latest news rather than the latest announcements (where ‘Announcements’ is the term used in the interface).
Make Your Prototype Work for All Possible Task Flows
Your participant should be able to carry out all the tasks that you set them during their test on your prototype, in every possible way those tasks can be carried out. For example, if you ask your participant to post a comment in your test and there are three ways to post a comment, then all three ways should work in your prototype.
Be Logical
The prototype must be logical, Captain! For example:
- If there are numbered sections in your prototype, make sure they are numbered sequentially (1, 2, 3, etc.) unless there is an obvious reason why they should not be.
- If your prototype includes a progress bar and shows completed tasks, make sure the number of tasks shown as complete at least approximately matches the progress indicated in the progress bar e.g. if the task contains 40 sub-tasks and your prototype indicated that the participant has completed 4 sub-tasks, don’t have your progress bar indicate that the task is 80% complete!
Be Consistent
The prototype must be consistent. For example, if a section of your prototype is labelled ‘Let’s Get Started’ on one page of your prototype, it should be named ‘Let’s Get Started’ on all pages of your prototype.
If your participant is testing multiple prototypes that are supposed to be displaying the same content, make sure the content (e.g. titles, images, progress indicators, etc.) are exactly the same in each prototype. This ensures that any comparisons are solely based on differences in the interface and not differences within the content.
Provide Clear System Feedback
If you ask your participant to take an action that would be expected to produce a change in the interface, then provide an obvious change so the user receives some realistic system feedback. For example, if asking your participant to switch from one image to another, make it very, very obvious when they switch that a change in image has occurred.
If you are using a limited functionality prototype where the full task flow you are asking your participant to complete is not functional, give your participant a confirmation page when they complete the task. Make the confirmation message on the final step you want them to take in the task really explicit, for example, ‘You have completed this task correctly. Thank you. Please move on to the next task.’
For example, you want a participant to share an image from a gallery page on your prototype. You just want them to find the correct button and click on it. You have not provided prototype pages beyond the gallery page. Here, when your participant clicks the correct button they are brought to a page that says “You completed this task correctly. Thank you.” This ensures the participant is certain they completed what you wanted them to do and as far as you wanted them to do it.
Avoid Distractions
- Don’t include content (text and images) that may distract and is not key to the research, especially if that content could be related to the research question e.g images with numbers when you are asking your participant to identify quantities.
- Avoid using content that contains words that are also in the UI or are contained in your test questions.
- Conversely, avoid using content that is unrepresentative of real content that may skew the test e.g. using a very plain image which makes gallery navigation tools more easily discoverable than they would be on a more typical image (which is more likely to distract from or obscure navigation tools).
- Use neutral, generic content (text, images, etc. ) that are not misleading or open to misinterpretation.
Include The Standard UI Features Users Expect
Include features participants would expect to see in the type of site you are prototyping e.g. if they are supposed to be logged into an account, include a profile section, even if this is not central to your test. This helps add credibility to your prototype.
Pilot Test Your Prototype
Even with the best efforts, you might still overlook something in your prototype that may become a problem for your participants. For peace of mind, if time and resources allow, pilot your test before launching it so that you can identify and resolve any problems. This is especially important if you are testing with difficult-to-recruit participants (you really don’t want to mess up your tests because of a silly prototype problem!).
Do Not Change Your Prototype Once Research Has Started
Once research has started the prototype must not be changed, altered or amended until the research is complete. For clarity, this means you shouldn’t make changes to the prototype from launch until after the research report has been delivered. This is to ensure that each participant is testing the same experience in exactly the same prototype, so you’re comparing apples with apples.
The exception is when you are using the RITE Method (Rapid Iterative Testing and Evaluation) where you modify the prototype based on the findings of each test. For more information about the RITE method you may find these articles helpful:
- Ten Things To Know About The Rite Method, by Jim Lewis, PhD and Jeff Sauro, PhD, 31 March 2020
- The RITE Way to Prototype, by by Jenny Shirey, Ann Charng, Quynh Nguyen, 19 March 2013
- The Rite Approach To Product Design, by Paula Desmond, 15 June 2011
So there you have it, some prototype pitfalls and how you can avoid them in your research. What challenges and pitfalls have you encountered using prototypes in your research? How did you resolve them?
