By Request: In Praise of Paper

NOTE: This article originally appeared in Interactivity Magazine, June 1998.  I am posting it in honor of http://www.mobilesketchbook.com ... a very useful tool for iPhone designers.

In Praise of Paper - William Volk

     Let me tell you a little secret.  The best way to build a great "high tech" interactive title is to start with paper.  I know it sounds "retro", but in designing for a visual medium paper works best.  A room filled with your creative, technical, and yes ... marketing types ... with at least one person who can draw blazingly fast ... is the best way to come up with great designs.

    It doesn't matter if it's a video game, educational title, or corporate presentation.  The ability to view what the thing is going to look like, right then and there, can make the difference between success and failure.  Rapid visualization allows you to explore the possibilities, come to consensus, and most importantly have a actual clue as to what the product is going to look like.  All the verbiage and flow diagrams in the world can't take the place of a talented artist's quick sketch at what you're talking about.

    At this recent Interactivity Roundtable, I bought this concept up for discussion.  Unfortunately it degraded into a debate on why a computer based input system can’t be as good as paper.  I suppose I could have called this article “In Praise of Ultra High Resolution Flat Panel Displays Mounted Horizontally with Pressure Sensitive Drawing Surfaces”, as this advanced technology is slowly becoming available (Disney is rumored to be using it as a replacement for traditional paper and pencil animation stands).  However for most of us the computer display and drawing technology (monitors and mouse) isn’t as immediate as paper or a white board.  I’ll concede that the “paper-less office” is a possibility, as I suppose the “paper-less bathroom” is also a possibility …. but for most of us … I doubt it.

    The main point is that rapid (within seconds) visualization of design concepts is a necessary first step in creating great designs.  I also think the nature of the initial design meeting needs to be open and inclusive.  Having representatives from all areas of product development from the “get-go” allows for a consensus on what the title will look like.  All ideas in this “creative room” need to be considered.  There will be plenty of time to whittle the design down to the practical and producible.

    Drawing can and should play a role as the design is refined.  To start with the drawing serves to center discussion on what a particular section or game will look like.  In educational software (see dCamera) there is often a question of the fit of the on-screen elements.  Text must be readable and the images should be identifiable.  Drawing is a fast and inexpensive way to look at several possibilities and to arrive at the ever important design consensus.

    I view the process of starting off with a general concept and a few sketches and finishing with a complete description of the title in a design document/database as “turning the wheel.”  You review ever smaller sections of the title in ever greater detail, refining at every turn.  Drawings eliminate much of the “how did we end up with this?” nonsense that can lead to re-work and blown budgets.  In the example (dCharge) notations are made about the use of the screen and the placement of text and numbers.

     I’m not against the use of computer based tools.  In fact I believe that the final design should be reflected in a production database.  This can be a relational database that contains the description of all production elements and their use in the product.  I think the next step will be to have this information available to the entire development team in the from of a browser accessible intra-net database.  Programmers, managers, artists, and testers should be able to access a common design “document” that details the operation of the title.

    Just as drawings representing the appearance of the title enable the visualization of the various “interactive scenes”, other styles of drawings can be used to convey operation of a title.  Flow diagrams can be used to link the earlier sketches into a diagram of how a user will navigate the title (see dPKMain).  Action can be represented in a series of drawings, otherwise known as a storyboard.  

    One justification for this visual emphasis is the mere fact that part of the audience for a design document are “visual learners.”   It may be a generalization to say that the programmers tend to be more comfortable with written descriptions than your art staff, but it’s not far off the mark.  I learned this by trial and error.  At Lightspan we started with a very detailed text document that described our titles in detail.  What we found was that we needed the text description … and we also needed visualization.

    Having reams of written description of the title and it’s production elements was not sufficient to insure production of a design in a timely and accurate manner.  The visualizations of the scenes and of the flow of action provided the “forest” that helped to provide a context to the “trees” of the individual production elements.  You can see how the final game screens (Charge and Camera) reflect the design intent. 

    This may all sound obvious, but it easy to get caught up in the world of “high technology” and forget just how natural the processes of drawing on paper and design can work together.  Find some who can quickly come up with rough visualizations (the best do it in mere seconds) and your design meetings will have a focus that mere words cannot provide.  

Comments

[bikingbill]

I agree with you. Never meant to imply that final design should be 'paper.' On the iPhone particularly ... prototyping is a must.

My point is that starting with drawings makes sense.

Thank you.

[Jan Halfar]

I do agree that (UI) design starts with paper-pencil sketches. It helps one to sort ideas. It helps to state clearly what is the purpose, audience expercations, possibilites, solutions.

I can't agree that final design \ prototype decisions should be done on paper. This would be possible for creating some standard, boring, static menus selection for PC game.

Here we are working with iPhone. GUI thats dynamic and fluid in its nature and users expect that kind of feel from every app, let alone game.

I see only one way for creating fluid and highely user fiendly interface. Interactive prototyping \ whiteboxing.
And tweaking, tweaking, tweaking.. ;)