Testing prototypes require more than just getting screens in front of people. I have had horror stories when I put prototypes in front of users but they just couldn’t understand the content to even test. Eventually, I learned that it is more than just the fidelity of the design. It is also about the fidelity of the data and how it connects with users. Based off of my experiences and experiments with prototypes, here are five must-haves for testing prototypes.
1. Screen for the right users for testing prototypes
Nothing is worse than sitting a person down in front of your prototype and then hearing, “I don’t know if I can really help you because I don’t really do this stuff.” Avoid wasting everyone’s time. Screen for the right participants. In a lot of my work, the product is for developers. That is a start, but I need to narrow down the focus to find developers who need a solution for ‘x’ and tend to work in environments for ‘y’.
Talk with your product team to see how far you can narrow down the focus on the test. This will help surface what problems the work is supposed to solve and what assumptions the team has.
Here is a good article on screening for participants.
2. Prepare tasks to complete
You are testing your screens and workflow, but the participant will not give you feedback on whether or not your colors are right or if the layout is helping conversion. They use software to complete tasks. When you test, you should set up the session with a series of tasks the participant needs to complete. Those tasks should resonate with the participant’s day-to-day struggles.
When you request your participant to “imagine this is your environment,” you have already tainted the session
3. Show relevant and realistic data
Putting a prototype in front of a user means taking as much guesswork out of the session as possible. It may not be possible to code a working prototype. Nonetheless, the screens should be as relevant and realistic as possible. No lorem ipsum. No boxes with X’s on them to represent images. All of the content and data should simulate an experience that makes sense to the participant.
When you request your participant to “imagine this is your environment,” you have already tainted the session.
4. Make sure people can access and use your prototype
Prototyping software like Invision run on the cloud. Their default state requires an Internet connection. Think about when and where you will conduct the session, will you and your participant have access to the Internet? What are other ways to get the prototype to your participant if the Internet is not reliable?
Test your links. Make sure you get a feeling for what the participant will see on their computer. If you craft your screens and prototypes on a large monitor but test on a small 13” or 15” laptop, your screens will be off. The participant may have to struggle with the prototype rather than testing your work.
5. Capture the session to review later
Remote session via WebEx or Zoom offers the ability to record. You can also record video and audio on with Quicktime screen capture (for Mac). Find some way to get video and audio, so that you can experience the session again. You will need time to process the session afterward. Also, it is always a good idea to keep this artifact for stakeholders who want to audit your data.
Prototypes are only useful if you show something that makes sense to your users. They are not judging your designs. They are judging if you can help them complete the tasks they need to do. Getting the right data on the prototype is key.
Read more about making prototypes in Framer.
