A lightning talk about paper prototyping, delivered at Service Design in Government: http://govservicedesign.net/ Won't make as much sense if you just look at the slides: the notes view should help...
A bit more like these ones maybe...
I evangelise for paper prototyping as a technique for getting feedback on an interface concept very early in a project.
We were looking around for a way of co-design back in 2007, while working on a project for Channel 4 Education. The project was aimed at teenagers, and we knew we weren't teenagers. What we wanted was some way of testing an interface concept before coding it.
And from that exploration, we returned with mystic knowledge...
What we found was this book. And the concept of paper prototyping. Building an interface from elements made of paper, and sharpies, and blutac and tape. Showing that to real people, with one of us playing the part of the “computer” and moving elements in an out of the interface, in response to our tester's finger, acting as the mouse.
And this is an early paper prototype – annotated later for some reason that escapes me.You can see different elements are made of separate bits of card, ready to be moved around in response how our tester interacts with them.We ask people to think out loud, and gain valuable, early, qualitative feedback that validates our assumptions. Or challenges them.
And this is the final development outcome. You'll see it's got some changes from the paper prototype: that's in response to testing of the digital alpha. For us, paper prototypes are the star of an agile process, not the beginning of waterfall development.
I come like Moses with the 3 laws of paper prototyping. Presented, with a certain amount of tongue in cheek, as follows...
1. It has to be paper
(Malleable, tactile, tangible, rough, lo-fi, unfinished. Obviously so. Paper prototyping isn't hard. It's quick and easy, cheap and accessible.. )
2. It has to be a prototype
(At the beginning of the process, with people in a position to make change. Probably best for small teams, with product ownership... Geeks and normal people working together.)
Test your paper prototype with real users, and have your other folk there. Maybe 2, so they bounce off each other. Lab tests can put users under scrutiny so they can feel the software failures' are their failures – make sure this doesn't happen.)
3. It has to -ing
(An active process. Involving, democratising, doing. Changing one thing using scissors during your testing. Validates involvement, can become co-design.
The prototype has to function, to work, or it's a wireframe. It's for examining process, user journeys, flows. Not design, only partly layout. Empower users by saying it's all our fault - it's us not you who are wrong.
It's that beginning stage of a project, when you are working out what to do that it's most useful.
We keep the test environment casual, and listen to the feedback we get.However, we don't simply make every change we're asked to. This is “people-centered”, not “do what people say”, and there's still a role for a designer.
Sometimes paper prototyping isn't right for a project – the best I've been able to articulate this is that it's for projects where the key problem about interaction, not information architecture.You can make some interactions seem more onerous than they actually are. ie: scrolling interfaces. It can be tricky to prototype some sorts of interactions in paper ie. pinch/zoom is pretty tough...
It doesn't replace accessibility testing, particularly not for some visual impairments.
Mind of My Own v0.1 100gsm. Black on white.This is used as a co-design process for the Mind Of My Own app – there's more about the project at http://mindofmyown.org.uk/about/ and more about how the project team felt about paper prototyping at: http://mindofmyown.org.uk/magic-paper-prototyping/
A beta – again, you'll see some changes from the paper prototype.
It's awesome.(Image from the Lego Movie http://www.imdb.com/title/tt1490017/)