Design Tidbits

back Tidbits Overview

Tools for Design and Visualization


Interaction Design

Screen Design


Visual Design

Design Process

Web, Web Applications, Web Design





Using Prototypes

By Gerd Waloszek and Joelle Carignan, SAP User Experience, SAP AG – Updated: May 7, 2004

Prototypes can help to evaluate design alternatives at any stage of the development process. Here three approaches are introduced: storyboards, paper prototyping, and HTML prototyping. A listing of pros and cons is given for the prototyping approaches in order to facilitate the decision of which is best for your requirements.

Note: This article has been moved from the Resources section to the Design Tidbits.



Prototypes can be a valuable tool for designing applications. They can help to evaluate design alternatives at any stage of the development process. During the conceptual phase the basic design elements can be explored and tested with users. When designing the actual screens the layout and more detailed interaction issues can be evaluated and tested. Later "high-fidelity" mockups can be used to provide a "preview" of the final application. In addition, storyboards can be used for basic usability inspection.

Prototyping can be done in many ways. Currently, paper prototypes are promoted by a number of authors. But electronic prototypes like HTML prototypes have their uses as well. HTML prototypes are especially suited for Web applications or if just screen sequences are explored. However, any other familiar tool (VB, PowerPoint, ...) may also be used.

Creating paper prototypes is a team effort

Figure 1: Creating paper prototypes is a team effort; here the team is split into three groups that create alternative prototypes

Group members present paper prototypes

Figure 2: Having finished the prototypes, a member of each group presents the group's prototype to the team; then the pros and cons of each prototype are evaluated



Storyboards, also called sketches, are a good supplement to prototypes and can be used for basic usability inspection. Typical questions that you can answer with this approach are:

  • Is the dialog simple?
  • What is the reading patterns or workflow?
  • Are related elements grouped together?
  • Are there too many or too little elements on the screen?

Figure 3: A storyboard

Storyboards can be also be realized as wireframe models and later be used as final specifications. They are mostly used as a technique for Websites and learning applications, that is, for content-driven products.

Figure 4: Section of a wireframe model implemented with Microsoft PowerPoint (each view is a slide) (click image for larger view)


Paper Prototypes


Figure 5: A simple paper prototype

Paper prototypes can be implemented in a number of ways depending on personal experience or preferences. Typical materials used for paper prototypes are:

  • Cardboard – for the screen
  • PostIt's for menus, dialog boxes or other screen elements
  • Transparent slides for temporary items or user inputs
  • Masking tape or other tape for user inputs
  • Pens and markers (erasable markers for user inputs or temporary messages)
  • Water for erasing inputs
  • ...

Paper prototype

Figure 6: Example of a more complex paper prototype


  • The Technology barrier vanishes
  • Less invested effort to defend
  • Less time wasted in arguments
  • Conveys product “feel” quite well
  • Faster than Visual Basic or HTML prototyping
  • Rapid improvements before investing effort in code
  • Not expensive
  • Created fast and easily (from less than an hour to a couple of hours)
  • Can be created by a group – this helps to gain a common understanding of the design
  • Everybody can take part in the design of paper prototypes – there is no special "tool" knowledge needed
  • Users can co-design the prototype during or after a test session
  • The focus of paper prototype discussions with users is the structure of the application and the suitability to the task
  • Discussions about "taste" matters or graphic design can be avoided
  • No barrier for users to criticize the prototype, because it is obviously of temporary nature


  • Limited interaction – not all interaction issues can be tested sufficiently (for example, certain features like mouse-over events that give feedback to users cannot be simulated)
  • Can't evaluate response times
  • Have to fake data available in real system
  • Can't assess the visuals
    • Icons
    • Screen real estate issues
  • Lots of fiddling with paper
  • At least one person is needed to play the "computer" when the prototype is tested
  • Unsuitable for presentations with more than 3 people


HTML Prototypes

Low Fidelity Prototypes

Low fidelity prototypes can be created with minimal effort to demonstrate the basic interaction, for example, static HTML. They can be used for a walk-through with users and asking them the following questions:

  • Describe the system and each object
  • Where would you find [each function]?

HTML prototype

Figure 7: A low fidelity HTML prototype can be created from simple HTML elements if modeling interaction issues is the focus

High Fidelity Prototypes

High fidelity prototypes can be used for presentations to the board or colleagues because they convey many features of the final application, for example, the visual design. They are also suited to formal usability testing:

  • Give users written tasks to accomplish with required data
  • Users are asked to think aloud
  • Test facilitator guides user through the test
  • Test recorder notes usability problems
  • Rest of team silently observes, preferably in a different room
  • A satisfaction questionnaire may be used at the end

HTML prototypes can show the dynamics of an application

Figure 8: HTML prototypes are better suited to check the dynamics of a design than paper prototypes; here the "high fidelity" HTML prototype already includes some elements of the future graphic design


  • WYSIWYG HTML editor (or any other editor of your choice – however a WYSIWYG is faster)
  • One or more Web browsers for testing the prototype
  • Graphic tools
  • A library of design elements (helps creating consistent look and makes development faster once the library is established)
  • A library of graphical or other screen elements (helps among other things to reuse screen elements of the target platform)
  • ...


  • Better interaction, especially useful for evaluating screen changes (but usually someone is needed who plays the "computer")
  • Useful for presentations of the application design or of design alternatives
  • Still time to make changes between days of testing and final coding
  • No hassle with paper


  • Creation takes much time (usually one or more days)
  • Barrier to discard the prototype and start over
  • Not as flexible to test new ideas or alternatives
  • Providing realistic scenarios and fake data is time-consuming
  • Analyzing, editing tapes, creating reports delays change implementation
  • Often discussions on implementation issues ("taste") dominate content discussions
  • Users cannot CO-design the prototypes, they can only make suggestions (which cannot be checked immediately)
  • HTML and/or programming knowledge needed (usually created by one person only - the designer may also tend to create a "perfect" prototype)


  • Explore design alternatives and test them with users using scenarios or tasks.
  • Use the prototypes to add features and test them with users.
  • Prototyping is especially easy for designing simple applications with a limited number of views and user interface elements.
  • Prototypes for larger and more complex applications can be split into several prototypes that explore different aspects of the application in order to keep the prototypes simple.


To top top