Usability testing of prototypes

Best practices and expert tips for testing prototypes of websites and apps

RapidUsertests of prototypes work the same way as testing a finished website or app. Simply provide us with the prototype as a URL and create the test via our booking form.

We recommend running tests with prototypes as moderated tests. This way you can ask questions and if anything is not yet working in the prototype, you can better guide the testers.

There are a few unique aspects to testing with prototypes, especially from a technical point of view and in the writing of the test tasks.

But if you follow these tips, nothing can go wrong with testing your prototype:

Create the prototype and prepare it for testing

Use appropriate tools - From our experience, Sketch, Figma and Adobe XD work very well for creating the prototype. To make it accessible through a link, we recommend Invision. For RapidUsertests, however, it is only important that the prototype can be accessed via a URL. Which tools you use is up to you.

Align the prototype with the main use cases - To create a good basis for optimizing the prototype, it should cover the main use cases and be optimized for them. These must be reflected in the tasks of the usability test. In other words, not all links need to be clickable, but only those links that are important for the test.

Hide unnecessary elements - Some prototyping programs (Axure, InVision, Marvel App, Adobe XD) leave behind control elements in the prototype (comment function, screen overview, specification, etc.) that are intended for collaboration with one's own team, but are confusing and distracting for users in the usability test. These elements can be hidden in most programs, as can be seen in this screenshot of the InVision share function:

Hotspot hinting or not? - In many prototyping tools, "hotspots" are used to link elements. These light up - usually blue - to indicate which areas of a page are clickable. This is useful during the design development and discussion phase, but if you want to find out if users can find the call-to-action, for example, the blue hotspot flash gives it away, and therefore you won't see the user's natural behavior. By default, hotspots should therefore be hidden.
If you feel users might get too "lost" - despite a well-written test concept - consider a moderated remote test with RapidUsertests.

Compress screenshots - If you are using screenshots in your prototype, you should compress them with tools like compressor.io or tinypng.com so that testers don't have to endure long loading times.

Linking correctly within the prototype

Prototypes whose links lead to dead ends or lead outside the prototype cause users to lose their orientation or land on the wrong pages. Especially in unmoderated tests, these losses of orientation affect test results.

Set consistent and logical links - All links must be inherently logical and consistent to avoid confusing users. If the logo links to the home page on one page, it should do so on all other pages. In the same way, links in the navigation bar should always take users to the same page.

Do not link out of the prototype - Especially for usability tests that are not moderated (such as RapidUsertests), links should not lead out of the prototype, e.g. to an already finished web page. Otherwise, this bears the risk that users will not find their way back to the prototype.

Only use necessary links - In unmoderated usability tests, there is no one to guide users back to the right path if they get lost in the link structure. Therefore, for this type of testing, the prototype should ideally only include links that are actually needed for the test. Linking elements that do not yet work with overlays such as "Unfortunately, this function is not yet implemented" should be avoided, as it only leads to unnecessary frustration for the user.

Instruct the users properly

If applicable, point out technical limitations - Does the prototype only work on certain devices or with a certain browser or screen resolutions? (Invision does not support Microsoft Edge, for example.) If so, point this out to testers in the "Other interests or features" field.

Provide users with credentials - It's often useful to password-protect prototypes on the web. In the entry scenario, give testers credentials to access the prototype.

Example: Please write down these login credentials before starting recording: Username: XXX / Password: XXX

Ask what users would expect behind non-clickable links - Even if not all links are working yet in a prototype, you can ask users what they would expect behind those links. This way you test if the expectation/understanding matches your intent.

Point out unfinished website/app - Users should definitely be instructed at the beginning of the test that this is an unfinished website/app. The word 'prototype' might be too ambiguous in this regard. Without this hint, users will treat the website/app like a finished product.

Control user focus - Instruct users on what to pay attention to and what to disregard. For example, if the test is about navigation, testers should know that they should focus their attention on that and can still disregard the design.

Communicate loading times - If the prototype has longer loading times despite compressed images, point this out to the users so that they do not abort the test prematurely.

Example: This is an unfinished version of the website/app, i.e. the page may take longer to load and not everything may work or be clickable yet. Nevertheless, please always tell us where you suspect something and what you would have expected there (if the link does not work)!

Test prototypes of mobile websites and apps

Make it possible to use it on as many devices as possible - With RapidUsertests, users test from home on their own devices, which makes the tests particularly realistic. However, this also means that they are run on a variety of different devices. If your prototype only works on certain devices, please contact us beforehand.
The prototype should definitely work on widely used devices so as not to limit our panel too much.

Requirements for unpublished apps - Apps that are unpublished must be deployed for iOS via a testing platform (e.g. Testflight). For unpublished Android apps, it is sufficient to make the app available online. However, it should have a trusted file name to avoid making testers skeptical.

Add to home screen - You are testing a future app, but it is currently only accessible with a URL? To still make the testing situation as realistic as possible for the testers, they should add the link to their home screen.

Example: To be able to use the prototype, please add the accessed web page as a bookmark to your home screen. This usually works via the options of your mobile browser (e.g. "Add to home screen"). Open the page using this bookmark on your home screen and then go to the next task.

Usability testing with wireframes

Wireframes are better tested moderated - Wireframes are a very raw form of prototype. They often have little content and look very abstract without the design. As a result, they are often not self-explanatory and users are required to have a high sense of abstraction. It is therefore recommended to conduct a usability test with a moderator, who can intervene in case comprehension problems occur.

Wireframe tests with unmoderated tests - If you do decide to test a wireframe with unmoderated tests, the following should be considered:

• Self-explanatory design - The wireframe needs to be as self-explanatory as possible to guide users through the prototype without a moderator.
• Provide meaningful content - Users need actual content to help them navigate the prototype. Lorem Ipsum text and other placeholders should be avoided. 

Download our wireframing kit to create wireframes for your next usability test in no time: To the wireframing kit

Avoid usability tests with clickable PDFs

We do not recommend usability tests of clickable PDF prototypes for the following reasons:

• PDF prototypes are scrollable - This can impede user flow and makes the test lose realism.
• PDF prototypes are unpredictable - Links in PDF prototypes are more unpredictable than in other types of prototypes. For example, jumping to the middle of the linked page happens more often.

However, tests conducted by a trained moderator can also be conducted with clickable PDFs.

With our usability agency Userlutions, you can test clickable PDFs as well as prototypes in even earlier stages, such as paper prototypes. In addition, our UX experts will design the prototype or individual pages for you if needed.

Are you unsure if we can ensure confidentiality and secrecy in usability testing of sensitive prototypes? Find out more info here.

Find out what else you can test here.