Contact  |  Login  Volunteer

Rapid Prototyping

The creation of low-cost representations of the user interface to a system as a method of brainstorming, creating, testing and communicating ideas about the system being developed.

A prototype is a model of something to be further developed. The higher the fidelity the more representative is the prototype. Rapid prototyping implies that there is a short time between conceiving an initial notion and modeling it in physical form and between successive iterations. A popular method is to use paper to create the prototype (Snyder 2003) which can be done without programming skills and which has the look of work in progress thus encouraging users to comment on it. Software prototypes can then be developed when the ideas have been thought through and tested on paper. These can then be used for usability testing.


Related Links


Low fidelity prototyping seems to have been advocated around 1990 by authors such as Jakob Nielsen, Bob Virzi and Tom Tullis. A few high-tech companies were using the technique during the 1980s as described by Robin Kinkead.

Authoritative References

Kavanaugh, R. and Soety, J. (2000) Prototyping using Visio, Usability Interface<, 7(1).

Leone, P., Gillihan, D. and Rauch, T. (2000) Web-based prototyping for user sessions: Medium fidelity prototyping. Proceedings of the Society for Technical Communications 44th Annual Conference, pp231-234. Toronto, Canada: STC.

Nielsen, J. (1993) Usability engineering<, Morgan Kaufman: Academic Press.Contains a number of general references to prototyping as part of a general usability engineering process.

Rudd, J., Stern, K., and Isensee, S. (1996) Low vs. high-fidelity prototyping debate. Interactions, January: pp76-85.

Snyder, C. (2003) Paper prototyping, The fast and easy way to design and refine user interfaces, Elsevier Science.A comprehensive source for understanding a simple but powerful technique.

Tullis, T.S. (1990) High-fidelity prototyping throughout the design process. Proceedings of the Human Factors and Ergonomics Society, 34th Annual Meeting, p266, Santa Monica, CA: HFES.

Uceta, F. A., Dixon, M. A. and Resnik, M. L., (1998) Adding interactivity to paper prototypes, Proceedings of the Human Factors and Ergonomics Society, 42nd Annual Meeting (Chicago), pp506-511. Santa Monica , CA: HFES.

Published Studies

See Snyder (2003) and Tullis (1990) for example case studies.

Related Subjects

  • Paper prototyping: The user may be asked to interact with a paper prototype comprising a series of paper elements representing different parts of the interface and controlled by the evaluator or assistant. The user may point to interaction elements of the prototype or speak their inputs, which are then manipulated accordingly by the evaluator. The paper prototype provides enough detail to perform an evaluation relating to the function and flow of the interface, but not the look.
  • Wizard of Oz: A user interacts with a computer system that is actually operated by a hidden developer - referred to as the 'wizard'. The wizard processes inputs from the user and responds with simulated system output. The approach is particularly suited to exploring design possibilities which are demanding to implement such as intelligent interfaces possibly featuring agents or advisors, and/or natural language processing.
  • Video prototyping: Here a prototype is developed and it is videoed with an end user interacting with it. The video is then shown to end users to obtain feedback.
  • Storyboard: A storyboard is a series of illustrations that represent a process, such as the steps of interacting with a computer or website. Storyboards can be used for checking that the steps of a process make sense to the user once the details are sketched.

Detailed description

Rapid prototyping can be used for a number of purposes:

  • To be creative: the prototype can be developed in a workshop setting as part of the creative process in developing system ideas, functions and user interfaces.
  • As a basis for evaluation: the developed prototype (on paper or in software) can be tested for usability or usefulness with real users.
  • For communication: the prototype can be used promote a design idea or to support a request for a design requirement.

Outcomes and Deliverables

Representation of the system in a prototype form which has been in some way accepted by user representatives. (This will follow an iterative design process in which several prototypes have been produced.)

Benefits, Advantages and Disadvantages


Rapid prototyping gives users (especially non-technical users such as the general public) a tangible demonstration of what the system is about. The use of pencil and paper and simple software development tools allows the prototype to be quickly replaced or changed in line with design feedback.

  • Permits the swift development of interactive software prototypes.
  • The prototypes created under this method support metric-based evaluations.


  • Allows design team to identify major navigation and usability problems before your company spends a lot of time and money developing and coding user interfaces.
  • If the prototype is sufficiently well developed it can be used to support metric-based evaluations.
  • The prototype can help to communicate the details of the user interface to the whole design team as well as to users. It can also be used as an awareness training tool with users.


  • Rushing in to develop a prototype may exclude other design ideas.
  • Design features may be limited by the scope of the prototyping tool.

Cost-Effectiveness (ROI)

Experience shows that the method is very cost effective in highlighting the main problems with a product or system after a small number of iterations and user tests. More formal user tests of a software prototype which generate metrics (needed to "prove" usability) will take more preparation and may require more detailed video analysis to generate the metrics which normally takes longer. It is not easy to measure ROI, as this rapid prototyping would typically be used early in the design process.


How To


  1. Hold brainstorm session: A team of designers and users is assembled to discuss general ideas for functions and the user interface to the system.
  2. Develop paper prototypes: A small group of designers then refine the ideas and develop a paper prototype. This is tested in a step by step manner against a series of test tasks. A user may also be invited to try the paper prototype and perform the tasks. They can then provide feedback which can lead to changes to the paper prototype.
  3. Develop software prototype: When the paper prototype has been sufficiently developed and receives a favorable response from the user subjects, a software prototype is developed using a rapid prototyping tool. This should also be tested with users and iterated until it reaches a level of acceptability
  4. Feed into design specification: The advanced prototype is reviewed and feeds into the development of the design specification. The prototype can sit alongside the specification as a representation of the proposed look and feel of the system.

Participants and Other Stakeholders

  • Human factors staff
  • Design team members
  • Graphics design staff
  • Prototyping tool specialist)
  • Representative users

Materials Needed

  • Paper prototyping: paper, pencil, adhesive notes, card, scissors, etc.
  • Room to test prototypes
  • Prototyping software e.g. PowerPoint, Visio, WYSIWYG web development tool, visual basic or C.

Who Can Facilitate

The usability or human factors specialist is in a good position to facilitate the prototyping activity. They may be assisted by a task domain expert.

Common Problems

  • Sometimes users focus on the wrong things in a prototype which has too much detail (e.g. this button is too big).
  • Users may get intimidated by an over developed prototype and not feel able to comment on it. (This is where paper prototypes can be more useful than software prototypes).
  • Minor details in the prototype that are wrong may be copied into the final design e.g. tab order.
  • The push to develop a usable prototype may push accessibility issues into the background.
  • A prototype may be developed more and more and eventually become a sub-optimal final system.
  • Paper prototyping won&rsquo;t simulate identify some interactions features e.g. interaction with long documents, scrolling on web pages, rolling and cascading menus, response times. These should be covered by software prototyping.

Data Analysis Approach

If the prototype has been tested with end users, then typically the facilitator instructs the user to work through the allocated tasks, interacting with, and responding to, the system as appropriate. The user is then observed and their interactions may be recorded. Additional information can be obtained by interviewing users following their use of the prototype.

As a developmental method, rapid prototyping will identify good and bad points about the design. The themes and severity of the problems will be identified. One rule of thumb may be that if 3 users experience the same problem in a sample of 8 to 10, then it should be addressed in the revised prototype with high priority in the revised design.

Next Steps

Extract the design implications and recommendations for improvements and feed those back to design team. Video recordings can support this. Where necessary the prototype is refined and re-assessed until it seen as meeting usability goals.

Special Considerations

Costs and Scalability

People and Equipment

Paper prototyping can be carried out by human factors or usability specialists with the support of domain experts and users. No special equipment is required.

Software prototyping also requires someone with knowledge of the prototyping tool being used.


Paper prototyping can be done very rapidly and a simple prototype can be developed in a matter of hours. If the paper prototype is to be tested with end users and iterated several times then a period of 2-4 days should be allowed. The development and testing of a software prototype will normally take about 2-3 weeks for development and small scale testing, although for a small system this could be carried out in a period of 1-2 weeks.

Accessibility Considerations

Special consideration should be given to accessibility of the system when the prototype is developed e.g. flexibility in choosing text size, font and color, good layout, operation with a screen reader. Accessibility should be planned for at the early prototyping stage even if implementation comes later.

Ethical and Legal Considerations

Users outside of the design team are normally required to sign a consent form before they participate in a prototype evaluation session e.g. that they have been informed of the true purpose of the text, that the data recorded will be kept confidential and that they may withdraw at any time.

Political Issues

If a well developed prototype is only presented formally to users they may be reluctant to comment on it especially in the presence of management staff.


Sources and contributors: 
Nigel Bevan, Chauncey Wilson.
Released: 2005-10
© 2010 Usability Professionals Association