You might have noticed, if you don't have much more important things to be doing with your time, that the whole 'is paper prototyping a valid use of time' thing kicked off on #DesignTwitter recently - sparked as far as I can tell by the below tweet which shows someone using paper prototypes to teach kids about design. Innocuous enough, you'd assume.
https://twitter.com/londrareale/status/1459199660548149254?s=20
However, there were some (now deleted as far as I can tell) comments from one account in particular arguing that low fidelity prototyping approaches (such as paper prototyping shown in the image) are a waste of time, becuase a higher fidelity prototype would gather more accurate usability results, citing aesthetic-usability effect as their part of their reason.
I don't normally dive in on twitter storms (especially over the weekend when I'm with the kids...) but the comments got me thinking. I find how and why we prototype fascinating, so wanted to collate a bit more than a snarky twitter response to lay out some of my thoughts, which are based on both my own experience and academic research done by other people.
For now - lets leave aside that the fact that the comments are confusing 'what should professional designers do to make the best products' with 'how can designers communicate process in an engaging way to school children' and just pick up the question of whether its worth using paper prototyping and other similar lo-fidelity approaches in general.
The argument I saw levelled against paper prototyping was that it would get less accurate usability testing results.
Don't forget that testing with users is only one of many reasons you might create a prototype.
Prototypes are a fundamental part of any design process and the specifics of how any what you prototype should be dictated by what you want to use the prototype for. Prototypes are learning tools, that learning can take the form of usability testing with representative users, or learning what is or isn't technically feasible with whoever's building the design. Prototypes are also communication tools, they are ways of building consensus across teams each with a different skillset, understanding of the solution and different priorities. A quote I think that sums this up well is commonly attributed to the Kelley brothers:
"If a picture is worth a thousand words, a prototype is worth a thousand meetings" - Tom and David Kelley
I'm not the only one who sees it this way. One of my favourite discoveries through researching prototyping in academic literature is this model proposed by a team of researchers looking at how prototyping is used within product manufacturing.
What they found was that effective design teams used prototypes in different ways at different parts of the process. They classified them as reflective, or affirmative tools, which are used internally or with external users. These are all valid parts of a design process (see model below - illustration mine)
You can read the whole paper on core.ac.uk, if you get the chance (and don't find yourself pulling your hair out at the structure of academic literature) I'd recommend reading it all. Its a nice summary of how prototypes are so much more than a testing tool, but in fact enable teams to externalise, communicate and socialise design ideas, all with the purpose of achieving effective design outcomes. The fact that its focused on the automotive industry means that I think the details of how each of the 4 categories are described could do with tweaking to better apply to e.g. digital product development, but the model still stands. Maybe one day I'll get around to writing up my thinking on how it should change...
This is all to say that even if a prototyping method might not get you the most accurate usability testing results possible, there is still potential value in it, if used in the right way. Prototypes are as much about internally reflecting and communicating effectively as they are for testing with users.
For us as designers, it may be that if we took the time to build paper prototypes collaboratively with stakeholders/users etc before launching straight into polished Figma files we might actually design the right thing, then can usability test the hi-fi thing to design to right.
Or maybe if we built a paper prototype and passed it around the table at that meeting, we could have surfaced everyone's feedback on the concept as opposed to whether the buttons were the right colour, got alignment on direction and then ultimately ship the thing.