Essays on Design

Creating Software Prototypes

Prototypes: Why Bother?
    Perhaps some of you have read various arguments for or against the need to build prototypes as part of the software design process.  Over the years I’ve been able to form my own opinions on the subject.  I am a prototype protagonist.

    The common argument against prototypes always has to do with the time required to build them.  “Every version is a prototype for the next version”  is another common frame for this debate.  We get a finger-wagging from these while-wasting watchdogs: “Time is Money!”

    It does take time to create prototypes.  Design requires time.  On the other hand, industrial manufacturers build prototypes in order to prove (& improve) designs and save time and money.  And when a production model is considered a prototype for the next version, be aware:  The lack of intentional design process in a prior version will often kill the whole product.  A product with a bad reputation is very hard to sell, even after improvements have been made.  And the release of a single poor product can haunt the parent company’s standing for years.  I remember a software company that kept releasing poorly designed versions of an icon editor, one after another.  I would never consider using any of this company’s products ever again.  Never.  Free downloads notwithstanding.

    In order to build something that will have enduring utility and appeal, designers will model the creation or build a prototype before beginning production.  Why would software be an exception to this rule?  Alan Cooper says this in About Face 3.0: The Essentials of Interaction Design:

When we think about complex mechanical devices, we take for granted that they have been carefully designed for use, in addition to being engineered. Most manufactured objects are quite simple, and even complex mechanical products are quite simple when compared to most software and software-enabled products that can be compiled from over one million lines of code (compare this to a mechanical artifact of overwhelming complexity such as the space shuttle, which has 250,000 parts, only a small percentage of which are moving parts). Yet most software has never undergone a rigorous design process from a user-centered perspective.

    Yes, prototypes take time, but most of us would rather spend our lives creating a single work of enduring worth and beauty than be party to more trashware:  Inhuman, unusable, untestable, unlearnable, undesirable muck that is unworthy of a blank CD or even the time to download it for free.

•

The Big Easy?
    A generation after Visual Basic gave everyone access to GUI development, many are realizing that software does not design itself.  Being able to drag and drop controls onto forms gave us all the power to become visual and interaction designers, but … [insert your favorite gui horror story here].

    Still, design is not rocket science.  Genius designers certainly stand out from the rest of us and I am inspired by them, but most of us get the job done by working at it.  It’s probably hard work for the geniuses too.  Prototypes are part of the required effort.  Prototyping is where many small mysteries of innovation often occur.  It is sacred territory.  If time is short, then we must prototype quickly.  And sometimes I wonder if innovation might be facilitated by tight deadlines; so many of my own ideas have come only as the clock was running out.

•

The Proper Business of Design
    In order to test the usability of a design, a prototype of some sort is essential.  Paper prototyping can be valuable.  Building a functional prototype is better.  On their own, prototypes do not guarantee that the final design will not simply be a reflection of the designer’s own prejudices, but when it follows proper preparation: user research, defining requirements, persona development, key path definition, etc., it is vital. Prototyping is part of the proper business of design.  It is precisely where a lot of important design work occurs.

(continued at top of next column)

(continued from left column)

A Special Kind of Development
    Building a prototype should not  be done with the hope of using this code in production software.  Prototypes should look and act well enough to evaluate the design concept.  They should be completely fake and held together with baling wire and twine.  Output should appear genuine, but does not necessarily need to be accurate.  UI details are important, but internal functioning is not. 

    If you know a developer who simply cannot bring himself to violate the rules of object-oriented programming, keep him as a valuable resource for the production team.  If you have nothing else for Mr. OOP to do right now, send him to Disneyland for a break.  You are looking for a coding cowboy who can obsess over small ui details and do whatever it takes to quickly get the fine points in the ui done correctly.

    If you are an expert  programmer yourself, you might consider creating the prototypes on your own, but there are some dangers with this.  It is important for you to remain a designer.  It is very difficult to be an interaction designer and write the code.  The danger is that your designs will be tainted by your closer association with how the software actually works.  You will begin to think about the processes in terms of how the software functions instead of how the user mentally relates to the functionality.  If you are involved in the details of how the software actually works, you will have a much more difficult job innovating as an advocate for the user. 

I recently researched the invention of the upside-down ketchup bottle.  I’ll summarize: It was not  invented on the factory floor where folks were concerned with getting the ketchup into the bottle and keeping it there.  You can visit the factory floor, but don’t bend your design to their requirements.  You, the designer, are the architect.

Note: Microsoft Expression Blend™ and XAML may allow you to remain a designer while you construct good prototypes, provided you only  play in the presentation layer.  As mentioned, use shams and simulations to produce faux output where required.  Liars and goof-offs excel in this arena I think.

•

Okay, Now What?
    Building the prototypes is an important part of the process.  But studying each prototype is also important.  As part of the process that precedes prototype building, a good interaction designer will have created a set of key path scenarios which define the steps that target users will follow in order to execute core functionality.  Use these key path scenarios and walk through the paths using the prototypes.  Quite often key path analysis across multiple prototypes can resolve outstanding issues. 

    But some design problems defy key path analysis.  Submitting prototypes to formal, recorded usability testing can be a good way to resolve difficult problems.  Usability studies are usually intense learning experiences.  It is always a revelation to see a user’s reactions to screens that have burned themselves into your author’s eye.  A sense of humor can help you cope.

•

Put Them Away!
    When you are done with the prototypes, preserve them to a safe place.  Do not use any part for production.  For your redline specification, create new screens with your favorite screen design tool. 

 - Dave Walker