Paper Prototyping Best Practices

Ok, before we really get into the finer points of paper prototyping, let me be clear. I will actually recommend groups do this, for the best usability they can get, and so that their design process goes smoothly. But, this is a practice I catch myself almost never using. Well, this isn’t because I’m opposed to it, it’s because it does inherently have a problem. Paper prototyping uses paper. Tree Hugger: What? No hold on. Well yeah the less trees that have to be cut down is scientifically better for the world but that’s neither here nor there. Paper is just so obsolete and inconvenient going forward from 2008. Modern SaaS-powered global online business entities are not nearly as focused around people in a central physical location anymore. Using paper kind of requires line of sight, given paper is physical and analog. However, the concept behind this form of prototyping? Maybe Just Not Paper: The thing I just want to get people to let go of is the literal paper aspect. Why don’t more people embrace the software designed for this kind of prototyping? Software like Visio, Flash, Balsamiq and so on, which are made for graphs, charts, flows, mockups and even floor plans and the like. Ok, but How Do I Prototype “Good”: Well, now that we’ve covered the elimination of literal paper we can touch on some good practices. These apply to paper or these programs mostly, so if you’re in an office together and have scratch paper that’s genuinely more convenient at the moment, then go for it on paper. #1 – Agree on Representations You’ll use different designs, label schemes and the like to represent different things in an early prototype. Unless you’re using Balsamiq, which maybe is not ideal for first prototype, then you’re going to come up with your own standard. Well fine. Try to be logical in your choices. And more than that, make sure you’re all on the same page on those ideas! #2 – Simplicity Trying to represent too much in a given “frame” results in webs of tangles mess that’re impossible to really follow. Make multiple states as their own documents. #3 – Save Iterations On top of all that, each iteration of prototype you do shouldn’t be discarded until alpha stage of development, because back reference is just something you randomly need, trust me. #4 – Too Many Chefs Finally, while it’s a great idea for everyone to contribute ideas and input all around, make sure there’s a funnel and filter to it before it gets put to a serious prototype, or you again get this inscrutable mess that’s impossible to untangle. Conclusion: Ok, above all, I really recommend not being literal about the paper aspect of paper prototyping. That said, as I pointed out, there may for now still be times when paper itself is convenient so alright. Either way, the problems I discussed above, and how you handle them to ensure smooth design, stands. Just look at the first part of this as pointing out that you have options to in fact get way more out of this prototyping mindset if you actually look past the inherent terminology it understandably has.