Musings from The Software Underground

A List Apart just posted something on Paper Prototyping, and if you ever have to design complicated software with complicated user interfaces, this is a GREAT place to start. I've used this process many times in the past, both for design and for usability studies and I can highly recommend it, it's in my standard bag of UI design and usability tools. Granted, it's really more geared towards the corporate environment, where there are usually more people involved, than the indie one, but I can attest to it's usefulness.

I cannot emphasize enough how important the inclusive quality of paper can be. Though some people shy away from paper prototypes because they feel they will not be taken seriously, I argue that many people are intimidated by a formal, highly technical design process and that the less "professional" nature of paper prototyping is a great way to lighten the mood and engage a more diverse group. Just offer plenty of paper, pens, scissors, and other materials for anyone to grab and use. If anyone feels nervous, let them eat the paste.

It's true. It's SO low tech, it's almost silly, but at the same time, people's "fear" of software can seem to disappear. It's only paper and processes, right?

Paper prototyping can also help improve the final product: the prototyping stage is the right time to catch design flaws and change directions, and the flexibility and disposability of paper encourages experimentation and speedy iteration. Instead of "deleting" hours worth of layout code you've used to position a column in the right place, you can draw a prototype, throw away the ideas that don't work, and move on.

Not to mention the fact that in many corporate environments, people often get WAY too hung up on the look and feel of prototypes done in software. They are just too close in their minds to working software, at least in look, and this leads to frequent problems where too much time is wasted debating the exact layout, colors, and fine points of the design. Paper avoids all of this. A sketched table is just that, it's an abstract table, and people have no way to get into the exact column names, icons, graphics, etc.

At any rate, I like to write on software design here and point out things I've read from time to time, and this article is a great intro to the idea of paper mockups. It's a worthwhile read.