Usability Testing your Prototypes? Avoid these Common Mistakes
Testing with wireframes is a fast and easy way of discovering usability issues during the early stages of the design process.
Wireframes are a low fidelity version of the real thing, meaning they have lots of limitations that can affect the results of your usability study — or even completely ruin it — if you don’t take some precautions. For the context of this article, a wireframe will include: those drawn on paper, clickable wireframes created in prototyping tools such as Marvel, InVision or Axure, or coded wireframes (e.g. in HTML).
I’ve put together a some advice for running great usability studies with wireframes and prototypes, and help you avoid some the most frequent mistakes.
Don’t suggest a correct path
Your wireframes may have limited functionalities, so probably will not allow your users to do any more than the few tasks you’ve set up for testing.
Because of this, you have to ensure that the limitations of the prototype don’t suggest a correct path (or answers) to your participants, or your usability test will become inaccurate. We can avoid this problem by showing the user as many options as possible, and making the entire prototype seem interactive, even when it’s not.
Make your prototype appear interactive
Every interface element that is clickable must appear and be clickable, even if it is not linked to anything. Otherwise, users will be able to understand where to navigate, and that will ruin user testing.
Every interface element that is clickable must appear and be clickable
For example, if you only add links to elements you want the user to click, they are likely to be lead along the path you want to test. That’s because they’ll be drawn to what they perceive as clickable, such as text decoration of a link, or, in the case of higher fidelity wireframes, by the mouse cursor changing as they move across the interface.
The difference is highlighted in the following image:
- On the left, people are more likely to click on ‘Madrid’ as it is highlighted.
- The screen on the right provides multiple paths for a user to take, by making every option appear clickable.
Making everything an option to the user doesn’t mean you have to create a wireframe for each page of the interface — you’ll only need to add an anchor link to each of the navigation options of your page, pointing nowhere.
If you are testing an InVision prototype, make sure you enable the prevent hotspot hinting option.
Record your user’s navigation
If your user clicks on any of the ‘dummy links’ outlined above, you can simply prompt the participant to try another option, stating the prototype is not yet a fully functioning. Depending on the context, this can be done in a number of simple ways:
- If you’re in the same room, you can simply tell participants to try a different option.
- If you’re running an unmoderated remote test, you should consider linking to a standard target page with a similar message, so that your users will not think that the site is broken and won’t leave the test (BTW, don’t forget to place a “back” button in the target page).
This may seem pointless, but it gives you a better idea of where users would like to navigate, had they been given a full choice. Also, in the case of remote testing, that ‘dummy page’ set up to prompt users can also be used to record and keep track of the user’s navigation — a tool that can help you do this is UserZoom:
By tracking your users’ navigation with tools such as this, you’ll be able to discover how many errors there are in your prototype, by counting the number of times your ‘dummy page’ was shown.
Double check browser compatibility
In the case of coded wireframes and prototypes, it can be beneficial to double check them in the same browser you will use during the usability study.
When you are testing a live website, you can be pretty confident that the page will be displayed well in any browser. HTML prototypes, on the other hand, are usually not fully developed, and may not be optimized for all browsers.
Therefore, before running any test sessions:
- Make sure the prototype works well in the browser you will be using during your testing sessions.
- If you are testing remotely, ensure that it works with all major browsers
- Alternatively, ask your participants to use the browser which is fully compatible with your prototype.
This advice is especially important when testing a mobile prototype, since it may look great when you open it in a PC, but completely different in the devices used by your participants.
Careful with A/B testing
A/B testing enables us to compare two or more versions of the same prototype, in order to find out which performs better.
If you are carrying out A/B tests during prototyping, it can be important to make sure every variation allows your users to do the same things, and access the same information.
Consider your prototype fidelity
A/B testing with wireframes and prototypes, where each variation of your prototype may differ in level of fidelity can be dangerous, as it can provide you with partial and misleading results.
For instance, if your A/B test involves comparing a live website with a new version created through an HTML prototype, information is likely to be missing on the HTML prototype which is available on the live website.
Therefore, in this situation, you should consider creating a quick prototyped version of the live website too, so that two variations can be tested in equality of condition.
Test at every stage
The good thing about user testing with wireframes is that you can do it without the need of a full functioning interface, and in nearly every step of the web design process.
Changes are nearly inexpensive, so each usability issue discovered can be amended quickly and with little effort.
Think about what you want to test
Testing wireframes at different stages means that you can use more or less detailed wireframes, depending on when you are testing and what you are testing for.
For example, in the earlier stages, you’re likely to be more focused on the concept rather than the details, so in these cases, you can afford to carry out testing with less information (maybe some “lorem ipsum” here and there).
On the contrary, if you are testing a final design, your aim might be to find as many usability issues as possible before going live. At this stage, it would be a better time to provide actual content to your participants, to get more detailed feedback.
Information must match prototype fidelity
Confusing, or poor information are two of the most common issues I have observed when testing with users. If you are in the latter stages of your design, and test a higher fidelity prototype without real content, lots of usability problems can be missed.
Originally published at www.somethingaboutux.com on June 29, 2015.
