Back your prototypes with science — 8 methods explained
Being a designer of any sort requires you to deliver some artifacts of your work. For UX designers, a prototype is a very frequent deliverable to produce.
Prototype however is a very broad term, describing handful of items. What are the differences then? Is it always worth going for a hi-fi mockup? Why a rough sketch may bring you more honest answers?
Welcome to a prototyping guide backed by science.
What a prototype actually is?
A prototype is an early sample, model, or release of a product built to test a concept or process — Blackwell, A. H.; Manar, E.
This explanation probably sums it all up, but did you pay attention to one little detail?
The word ‘early’ is critical for understanding the main purpose of prototyping — cutting costs of the development process.
Testing early and often requires prototypes to appear… early and often!
With that cleared, let’s see what those early prototypes can be, and what are their advantages.
1. Napkin sketches
Often when working on a completely new service, product, or feature, ideas come at unexpected moments. Or maybe we just want to generate as many of them as possible. So-called ‘napkin sketches’ are a great way to grasp those ideas in the form of a memo for us, so we can develop them later.
Simultaneously the same sketches can be good enough to share ideas with someone and trash the worst ones.
I can’t explain this idea to anyone, since only I can make sense of it as of now. — you may say.
If you can’t explain the main idea behind a design, while having some supporting visuals, better abandon it.
What are the benefits of using rough, napkin sketches compared to hi-fi mockups? If you are at the beginning of the creation process, there are plenty.
- Simple sketches have fewer elements users need to focus on when trying to understand your idea. Our short term memory is capable of storing 7 +/- 2 elements (Miller, 1956), so the fewer, the better.
- Humans are more likely to focus on visual rather than auditory stimuli (Witten & Knudsen, 2005), so if you want people to listen to your idea, focus on talking, not showing.
- When seeking early opinions, you probably talk to your teammates, or relatives first. They naturally will try to avoid hurting your feelings during a design review. A way to minimize the impact of that bias is a rough sketch because it looks like you didn’t put much effort into it (even if you did). It is easier to criticize an idea you’ve been working on for 3 min, rather than 3 weeks.
2. Content maps
I don’t have any better name for those, but I’d describe it as a site map, enhanced with a basic screen layout.
Content maps have a benefit of explaining complicated interactions between not only screens but pieces of content on all pages. As an analytical mind, I like to map-out the complexity of the system early on, thinking only about that will appear on each page, and ignoring a visual aspect of it.
Benefits of such a tool?
- Because you see how many screens, and interactions there are, it is easier to estimate the time you need to complete the next steps.
- You minimize the chances of forgetting about smaller features that may significantly delay your process later on.
- It is difficult to perform any tests on such design, however it opens-up conversations with developers, analysts, and business owners. As (usually) analytical minds, they can clearly see the depth of the project and quickly highlight any missing pieces. We all know how painful it is to incorporate a sudden additional branch of pages into a hi-fi mockup — avoid it with a content map.
3. Low fidelity prototypes for digital products
When you know which direction your project should follow, a low-fi prototype/design is usually a way to go. Those can be made digitally, hand-drawn, or made out of anything that works for you (more on non-digital prototypes later).
Their simplicity gives us a chance to experiment, build multiple versions of the layout and do it quickly.
So what is the difference between low-fi and sketch designs? Why choose the first, over the latter?
- I use low-fi designs to plan-out my content on the page. Using digital tools like Sketch, Figma or Xd makes it really simple and more precise than pen and paper. Not feeling confident enough? Clean looking paper prototypes will do the trick too!
- Low-fi are also good enough for the first usability tests (NN Group). Black and white screens can carry enough information for participants to ask them to navigate, or what particular screen represents. Testing this early has the best learnings to cost ratio.
- The fewer resources we spend on a prototype, the easier it will be to abandon it when needed. This principle is called sunken cost fallacy (Arkes & Blumer, 1985), so test your ideas early, before you become invested. Time and psychology is against you ;)
- When a flow of the product is a complicated and important matter, wiring low-fi screens together can result in a quick wire flow, showing a whole sequence of screens together. Particularly useful when working with a business or other non-designers, to show them the bigger picture.
4. Medium fidelity prototypes
There is probably no clear description of what a mid-fi prototype is. For me, it means basic interactivity, real content, and usage of colors.
Such prototype shouldn’t require any external explanation to make sense to a user.
When and why to test using this type of deliverable?
- Color plays a great role in capturing attention and carrying information (MacDonald, 2007), so using it brings a lot more data to the table. Color gives you an opportunity to better guide the user’s attention. Mood and feel of your solution get much richer too.
- More testing methods, like unmoderated remote testing, can be utilized when working with a mid-fi prototype. From my experience, it works best with colorful designs, and actual, real content on screen. Black and white screens leave more room for the confusion we can’t address remotely.
If you aim at doing remote testing (especially unmoderated), mid-fi is the right moment to go for it.
5. High fidelity prototypes
Probably the most popular deliverable we output. Probably the most satisfying one, since you see all your hard work (crafted in blood, sweat, and tears) in full glory.
At this point, a prototype should be an accurate representation of ‘a real thing’, and feel like it’s a functional product.
How real it should be, what functions it should represent depends only on you, and a purpose it will serve.
- If the main goal is to showcase the business what we’re aiming for, maybe just one happy path click-through is enough.
- If you’re planning on showcasing your UI skills in the first place, static mockups can do the trick.
- Doing some usability testing? Collaborate with a researcher/research team/anyone who can help to determine what the research scenario will be. Preparing only relevant screens for a test will save you a ton of time.
Hi-fi prototypes have a lot of benefits, but some drawbacks too, so when to reconsider making them?
- If your main goal is to focus on functionality, flow, or information architecture, keep your prototype simple. The Aesthetic-Usability Effect coined by NN Group makes users more tolerant towards minor usability flaws when an interface is visually appealing. The pretty visual design may cover-up flaws, that otherwise would be apparent, so don’t push it too far for initial research iterations.
- Flashy animations, pictures (with human faces particularly) and colors are great at catching attention (Northdurft, 2000). In the research scenario, however, we may not want to direct participants' attention away from things like flow, or information architecture. If you don’t want user’s opinion on photos or animations just yet, don’t make them stand out in your design
- Be careful when designing, and later analyzing research results! My own experience backed with the theory of planned behavior (Azjen, 1985) says, the more effort you put into a design, the more effort participant puts in testing it.
It’s a subconscious belief they are interacting with a real thing, so they act this way. Once they stumble upon a bug or an inactive link, this belief goes away for some time, and a participant may become more forgiving realizing “it’s just a prototype”. We don’t quite want that.
Other methods of prototyping
The majority of us work on digital products and don’t have many opportunities to experiment with alternative methods of prototyping. If you seek new fun (and effective) ways of improving your product, the below examples are for you!
6. Cardboard prototypes
Prototypes made of cardboard, foam or other product are fantastic when designing physical products. Can they be useful when working in digital? Sure!
Going this path is beneficial at the early stages of a design process when input from other stakeholders is needed, or co-design activities are being undertaken.
Cardboard, pens and paper are democratic in a sense everyone can draw “something” and comment right on the design itself. It’s also much easier to gather around a table and talk freely when design in question is available to everyone, not only to those who have laptops with adequate software installed.
Having a paper equivalent of a digital prototype for a testing session is also a good idea. I often used them towards the end of an interview, to summarize all findings and mark them right on the design itself.
7. Video prototype
Video prototype can be a great way to show how your whole solution is intended to work and impact your user, but not only that:
- Business and marketing are gonna love it! Videos showing the product in use are very popular online and can serve a marketing purpose if done correctly. It should be also naturally easy to understand by them.
- It’s a great tool for iterative prototyping since video amplifies all odd behaviors. If you feel something just feels off when recording, it’s a sign to re-think this area of a product. Video obviously doesn’t have to be perfect for such usage, so don’t be ashamed of just recording with your phone.
- Actors double as test participants. Because they actually have to use your product (or pretend to do so) they are the first to spot when something causes issues.
8. Wizard of Oz (UX narrative)
Wizard of Oz is a prototyping method with numerous interpretations, but I’d like to focus on the one, that changed the way I approach designing user flows for good.
All you need is one partner and enough imagination to become the system you are designing. Now simply answer every query your user has in a rather robotic, interface like manner. Say out loud every form label, every checkbox, every basket summary, every CTA button.
You’ll be amazed how many insights you’ll gather, and how clear the user’s needs become after just a few minutes.
Definitely try it out before sketching any future user flow or form!
8.5. *Re-enactment
Not so much a prototype, but rather a technique you can use to test your ideas at any moment of the process.
It’s as simple as just trying to use your product. It’s not ready yet? Play with some cardboard to simulate missing parts, or use labeled post-it notes to turn for ex. a plate into a steering wheel.
Working with a digital product? I bet the majority of tests happen in a lab, or while sitting behind a desk. Go ahead and try to navigate your app when standing in a crowded bus, or type an address in while holding an umbrella above your head! It’s an eye-opening exercise, that exposes you to real-world usability, or functional issues, that may go unnoticed otherwise.
It all sounds familiar already? It’s just like video prototyping, but you can skip planning, writing script, and a chore of recording. Just pure knowledge!
