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.