Do not overtake anyone in a blind curve aka testing a prototype

In one of my previous blog posts, I talked about the necessity of prototyping and about how you cannot skip a single step in a properly and methodically conducted UX process. It could be said that this process follows the same principles as a game of hopscotch, where the player must jump through each space in order to successfully reach the end as otherwise, they will not have followed the rules of the game.

One of the most important steps in this process is testing the prototype – an activity that literally helps to see the new solutions from the end user’s perspective. Testing must be done in an informed manner and at the right time since sooner or later, it will be put to the test anyway, whether you want it or not.

A prototype can be tested in various ways during different stages of the process. For example, you could test either the paper, the low-fidelity (interactive, no design), or the high-fidelity (very similar to the actual final product) prototype or you could test them all – it all depends on the project’s budget and needs.

You could test two different versions of the solution on the prototype, i.e. conduct a comparative test, or you could test out different scenarios using the same solution. The important thing is to make sure that you definitely conduct the testing and do so prior to the development stage as each process is different and testing helps to uncover any mistakes during the stage when it is much faster and cheaper to fix them.

Testing has become much easier to do over time – a lot of in-depth interactive tools have been introduced to the market (e.g. Morae or SilverBack), which enable tracking whatever or whoever is being tested. For example, you can track and later analyse eye movements, audio-visual imagery, keystrokes on the keyboard, and mouse movements.

The more information is gathered, the easier it will be for the tester to analyse the data later, and to make any necessary changes based on the results. For example, if the data shows that there was repeated scrolling back and forth on a particular form, then that could indicate logic errors in the solution, a deep and audible sigh from the person who was tested could indicate that something is unnecessarily complicated, and excessive clicking through various submenus could indicate that the implemented navigation model is incorrect.

It is important to ensure that the testing task follows real-world scenarios and is done by actual end-users, and that the test itself is conducted properly. The tester absolutely must not interfere in any way during the test nor try to guide the test subject.

As a rule, I write the task out on a sheet of paper, which I then give to the test subject and then I step away from the test – in addition to reducing the risk of external interference, it also reduces the amount of pressure the test subject feels in having to solve the task.

For testing and prototyping, I would recommend using the tools created for this purpose. In the words of the UX guru Stephen Hay, “Photoshop is the most effective way to show your client what their site will never look like.”

The Morae testing window after testing a high-fidelity prototype. Morae also displays the audio-visual imagery of the test subject. The red line indicates mouse movements.

Why should you test a prototype?

• It helps to avoid the need to make changes during the development stage
• It helps to save money and time as mistakes can be identified during an earlier stage of the project (before developers start working on it)
• It is easy to do

Nevertheless, you should keep in mind that testing is not enough to eliminate all possible issues – the perfect solution that works equally perfectly for all users does not exist. It is also important to understand that the purpose of testing is to uncover and identify mistakes, not to prove that there are none. In other words, do not overtake anyone in a blind curve – instead, always make sure to test your prototype first!