Prototyping
A prototype is an early sample of a solution used to get feedback and make rapid experiments with new ideas.
The goal of a prototype is to enable testing of products and ideas before investing lots of time and money into development.
The form and fidelity of the prototype should always reflect the hypothesis that you want to test with the prototype.
In a nutshell
Time
1 – 2 hours
Participants
– Project team
Materials
– Pen and paper (lo-fi prototype)
– Balsamiq (mid-fi prototype)
– Adobe XD (hi-fi prototype)
Learning materials
UX Fundamentals (internal training)
Create powerful prototypes with Adobe XD (internal training)
Prototypes: Low fidelity vs. High fidelity (article) – Nielsen Norman Group
Paper prototyping 101 (video) – Nielsen Norman Group
PREPARE
Clearly defined purpose. As you don’t want to use any unnecessary time to build prototypes, you should start by clarifying what questions you need to find answers with your prototype.
Also, it is sometimes better to create different prototypes for different purposes than trying to create too wide / deep prototypes to test everything with.
Schedule tests early. To keep the pace, you want to recruit and schedule the test users already when you start to create the prototype. This saves time and also gives you good “soft deadlines” to keep. You should plan for multiple test sessions so you can iterate based on feedback between each session.
DURING
Keep it simple. Depending on what kind of prototype you are creating, choose the best way to work. Remember to build ONLY what is necessary to carry out the tests and get those answers, nothing extra.
Be realistic. Make the test sessions as realistic as possible. For example, if you have a clickable prototype of a mobile application where the scenario is to scan receipts and complete an expense claim, do the test after the user gets out of a car (“taxi”) with some luggage in their hands while trying to use the phone and get the receipt straight.
Record. Use some sort of recording method to capture the test sessions so that you can share the findings more realistically with the project team. Sometimes they need to see what happened to believe it happened!
