These are not the prototyping tools you are looking for

It’s almost inevitable for UX professionals to find themselves entangled in conversations about what are the best tools of the trade. There is a wide variety of design and prototyping tools for any taste. Everyone has their favorites and the ones they absolutely despise. Arguments?sometimes reach a point of dogmatic fanaticism. You might have seen dedicated technology meetups created around a single tool. Not a discipline, a profession or methodology, but a software tool.

The right stuff

As you might have guessed from the title, this article focuses on prototyping tools, rather than purely design tools. This refers to any tool that produces some form of digital interactive prototype, rather than static design work. But why do we need an interactive prototype and how is it going to be used?

There are three possible answers to this question:

• We need a prototype to assist communication with stakeholders, clients or the broader organisation.
• We need a prototype to assist collaboration and development within our team.
• We need a prototype to conduct usability testing with users.

In order to communicate design solutions to business stakeholders or to collaborate with other team members, you may as well use almost any design or prototyping tool in the market, as long as there is some sort of 'presentation view' or export functionality. So, let's dive a bit deeper into the third case...

Hindering validity

The main way in which a prototype’s fidelity, both in terms of functionality and interactivity affects usability testing, has to do with the internal validity of the study .

Simply put, during a usability test, we aim to simulate the circumstances under which users will engage with the product, as closely as possible.?Especially in later stages of the production cycle. We also aim to elicit honest responses and natural behaviours which users would generate, when interacting with the real product.

Our focus here is not the fidelity of the prototype, since we can achieve valid results with low fidelity paper prototypes, for example. What we aim to mitigate are external factors that impact user interactions in any way.

Any kind of aid or prompt external to the prototype itself (e.g. hotspot highlighting), which will not be included in the end-product, can bias participants or lead them towards completing a task. When in reality, without this external assistance, users would probably take more time to complete the task or even fail it completely. Thus, returning false results.

A good prototype does not impact the validity of our usability test. It allows us to reproduce the exact experience of the end-product in a way that mitigates any confounding parameters that affect our measurements. Therefore, we know that our results contain clean data?and the observed interactions are reliable.

Essential functionality

The following list of functions explains in detail what we have observed to be a minimum requirement for any prototyping tool, when it comes to using them for usability testing. This list of impeding cases has come up on many occassions and numerous rounds of usability tests, across different products, using with many popular tools including, but not limited to:?Axure RP , Invision , Marvel , Proto.io , Figma , Framer , Adobe XD , ProtoPie , Justinmind , Balsamiq .

Some tools have strengths in some areas and are weak in others. It’s totally up to you and your team to decide which are the most important function for your user research.?Let’s jump into it.

1. Create realistic interactions

If there was a single way to immediately identify whether an interactive prototyping tool is good or not for usability testing , this is probably the one. A tool needs to cover for all primary interactions a user might perform, such as tap, scroll, drag and most importantly type!

What we need is for users to freely type within an input field, as they would normally do. Auto-filling input fields with mock details won’t suffice. There is nothing useful to learn, by watching users click their way through a form with multiple fields in 5 seconds (auto-filling it with dummy data), where in reality they would take at least 3 minutes to complete it and encounter a few errors on the way as well!

2. Prevent hotspot highlighting

This feature allows users to highlight all the interactive areas of a prototype, by holding down a hotkey or clicking on any non-interactive area of the screen. This function is normally not carried out to the end product, but can be helpful when sharing a prototype with internal stakeholders, as it can draw their focus on the updates that have been applied.?

However, highlighted elements completely ruin the purpose of a usability test, by 'spoiling' potential interactions and navigation. They prompt users where to click next, causing a severe impact when measuring findability or discoverability in particular. A good prototyping tool allows the designer to toggle this functionality off. Bonus points for prototyping tools that also prevent users from turning it back on again.

3. Deactivate mouse-over state

Similar to the previous case is the hover status change of the mouse pointer. Contrary to hotspot highlighting, this is a useful visual queue that will (hopefully) exist in the final version of a product in order to enhance usability. The pitfall however, is that since a prototype is typically a work in progress, not all functionality will be in place from the beginning.

Take for example a case where only three out of five global navigation options may be active. Users will be able to discover which three options are active simply by hovering over them and see the pointer change. The prototype indicates the components that work and those that don't, impacting findability, time-on-task and task completion.?A good solution to that, is to be able to toggle-off mouse hovering in order to maintain consistency, until every single component that is supposed to be interactive, actually has some functionality built in.

4. Restrict ‘slideshow’ navigation

Some prototype functionalities are created with internal team collaboration in mind. One of them allows users to navigate across all 'screens' or sections of the prototype freely, like watching a PowerPoint deck. This is typically enabled by using interface elements that sit outside the actual prototype or by using the arrow keys on the keyboard.

As a general rule, users should not be able to browse the prototype content with any means outside the prototype itself, exactly as it would happen with the end-product. Toggling the feature off?is mandatory, especially in unmoderated testing, where it can allow users to ‘cheat’ their way to completion. Bonus points for prototyping tools that utilise browser or device navigation elements properly (e.g. browser 'back')

5. Export unique URLs

It is advised that each page or section of the prototype should bear it's own unique URL within the prototype. A single URL across all prototype sections won't suffice, as it prevents referring, directing or pointing out a particular page to the users.

Think of the simple scenario where you present two tasks for users to complete on a commercial website, each initiating from a different starting point of that website. This cannot be achieved if the whole prototype is generated through a single url. Let’s say you need to measure findability on the first task and purchase completion on the second. Some users might fail the first task, but you can still measure the performance of the second task. This way you can share with participants the 'success' screen URL for the first task, so they can continue on the second task regardless.

6. Prevent design editor access

By ‘design editor’, we refer to the actual design or prototype creation aspect of the tool, where the interactions are set up by the designers. This is more critical with tools that don't have a 'true' prototype function, but only a 'presentation view' of sorts.?

Any access to the prototype editor should be hidden from users, as it allows them to see, edit or download the full list of designs. This not only helps with study validity, but it saves your team from a huge headache with NDA infringement as well. In most cases, this requires a user account to access, which mitigates the risk. But keep an eye for it.

7. Allow account-free access

Speaking of accounts, users should not be prompted by any means to create an account, register or download anything from the prototype software service in order to see and interact with the prototype.?Prototypes should?be?independent shareable links. If an account creation or a plug-in is required to be installed, before anyone can access the prototype, it may cause users to abandon the test before they even begin.

8. Hide design editor notifications

It is an absolute disaster when a non-intended error message, triggered from the design editor (not the prototype itself), pops up during a user session. The reason might be that some fonts are missing from the participant's browser or an image is not loading properly. These incomprehensive error messages that have nothing to do with the prototype, are anything but helpful for the users.

Things get even tougher during unmoderated sessions, without any means to help participants recover from these errors. True story! Controlling how error messages and notifications appear, can prevent this. Testing your prototype in different devices before sharing it, should be a standard process as well.

9. Add password protection

This is a good-to-have option that provides the facilitator with some flexibility and control. Having a password protected prototype is ideal in cases where NDAs are involved. Regardless if this option exists, it's a good practice to generate a new URL for the prototype for each participant or usability round and revoke them afterwards, just to keep things safe.

10. Add interaction logic

Last, but not least comes logic between interactions. Most of the things we actually want to test with users when using an interactive prototype boil down to a series of choices and inputs, rather than a simple tap and scroll. All these choices come together with the use of some logic: User picks option A then X happens. If they pick B instead, then Y happens.

A quick and dirty way to identify how optimal the use of logic is in a prototyping tool, is to test a simple form page where the form submission is unavailable (i.e. inactive Submit button) until all required fields are filled.

A more complex check for logic, is a page that contains two dropdowns with two available options each. Let's say that each drop down selection affects a small portion of the content in some other part of the page. If you need to completely design the whole page four times, in order to display each of the different possible selection cases, you're probably using the wrong tool.

Move along...move along...

We could potentially put all ten items above in a matrix, showcasing which functionality exists in each tool. However, these features change every day and the companies that make these tools adapt to the needs product teams have. Prototyping tools become obsolete and new ones get released every year. A tool that works for you today, may probably feel inadequate in a few years. There is no reason to overcommit on using a specific solution and passionately defend it to the grave. The real premise here is to use the tool that covers most of the issues above. At the end of the day,?a tool is just a tool. Our process and the way we work is what we bring to the table as professionals.

Feel free to share in the comments your thoughts on this list or any other potential tips and functionalities that work for you and help you maintain validity in your research...