What not to do while making an interactive prototype?
How to make a more usable prototype…
The Buzzfeed Tasty App (redesigned only for learning and practice purposes), gives you a wide range of simple and attractive recipes to choose from. Although it is already an amazing App, there are some things, I felt, that could be improved in terms of the experience people have with it. More details on this can be found in my case study.
When I created static wireframes/prototypes and discussed it with people, my ideas for changes seemed reasonable and helped me gather constructive feedback. But to my astonishment, as soon as I switched over to an interactive prototype, I observed people having troubles understanding the functionality of the App. This is when I realized that the problem was not with the ideas or the functionality, but with the prototype itself. So, I made some changes to the prototype to make it less limiting, and more helpful to test the functionality. Here is what I think you can avoid while creating interactive prototypes. Hope this saves you some time, by creating a more usable prototype, and prevents you from telling the users again and again, that it is just a ‘prototype’ :).
Testing too many screens or too much functionality at once
An interactive prototype is mostly images representing different states of an application along with pre-planned interactions to simulate the actual functionality of an application. If we try to test too much or too many screens in a single test, it makes it very hard or sometimes impossible to cover all the possible scenarios of how users can interact with the application. As a result, there is a good chance of missing out on crucial interactions and states of the prototypes, which could confuse and limit the users, instead of taking them forward.
In case of the Tasty App, I realized that I tried to test the whole application in a single test, making the users switch between many screens, many times. Some people managed to go along smoothly, but others found it hard to follow through, as not all states, which they expected, showed up or got persisted. But, can you blame them? No!
A good way to solve this could be to iteratively modify and test prototypes, gradually adding interactions. By having tests focused on some part(s) of the application, one can create more screens and more detailed interactions and cover more scenarios for interactions.
Different behaviors for the same element in different places
One of the most annoying things in a prototype can be varied behaviors for similar-looking elements (such as buttons, icons, hyperlinks etc.). This behavior trait can surprise and/or disappoint users and easily digress their focus from the main functionality they are actually testing.
In the Tasty App, the list of recipes is presented in the form of clickable image buttons. One thing that I did wrong was to allow a recipe to be opened only from the main page and not from anywhere else. So, when the users wanted to access the recipe from another screen, they just kept clicking and nothing happened. This lead to major disappointment in many cases.
An easy way to fix this would be to create uniform interactions across the application. As designers, we can’t predict all the behaviors and moves of all the users, so it is good to try to be as precise as possible.
Limited possibilities for interactions
It is nearly impossible or even unnecessary to enable users to interact with every element in a prototype. But, at the same time, it is also not possible to predict which elements would the users try to interact with. Some prototyping tools highlight the elements which have interactions attached to them, making it easier for people testing the prototypes, to understand where to click. But, this is not always helpful.
For example, in case of the Tasty App, I created a detailed recipe page for one of the recipes and provided a link to it from the image button in the list. But, the users who were testing the App had a hard time finding which recipe was really accessible, as they kept trying to open the recipes which they preferred. Even though the prototyping tool was highlighting the recipe which had an associated recipe, it was hardly noticeable to most people. This left people annoyed and prevented them from performing the actual tasks.
An interesting way to solve this problem could be to link the same recipe to all the image buttons, to provide some kind of feedback to the users. I believe it would have been much easier and more pleasant for people to realize the limitations of a prototype this way, and not by feeling limited or stuck at some point.
Expecting people to behave in a certain manner
Every person is different which is why they think differently. Creating a prototype to behave a certain way could be limiting for many people. In other words, to assume that people would only do something in a particular sequence of actions is not correct.
In the Tasty App, I wanted people to try out some filters to get a specific list of recipes. I made the prototype in a way that they could only click filters in a certain order. For instance, first ‘easy’, then ‘healthy’, and then ‘Chinese’. But, as this was a long screen, most people did not read everything as they scrolled, and did not manage to apply any filters.
A good way out of that could be to create more combinations of images and interactions, making it flexible for people to choose whatever they saw first. Also, some pre-selected filters could have helped cover up the shortcomings of prototypes.
So, here are some very simple points, which might take you a long way. I hope this article helps you to create better and more usable interactive prototypes. I look forward to your comments and suggestions and some 👏🏼👏🏼👏🏼.
