Menu Search
Jump to the content X X
SmashingConf London Avatar

We use ad-blockers as well, you know. We gotta keep those servers running though. Did you know that we publish useful books and run friendly conferences — crafted for pros like yourself? E.g. our upcoming SmashingConf London, dedicated to all things web performance.

Design Better And Faster With Rapid Prototyping

The old adage, “a picture speaks a thousand words” captures what user interface prototyping is all about: using visuals to describe thousands of words’ worth of design and development specifications that detail how a system should behave and look. In an iterative approach to user interface design, rapid prototyping is the process of quickly mocking up the future state of a system, be it a website or application, and validating it with a broader team of users, stakeholders, developers and designers. [Links checked & repaired March/06/2017]

Doing this rapidly and iteratively generates feedback early and often in the process, improving the final design and reducing the need for changes during development.

Further Reading on SmashingMag: Link

Prototypes range from rough paper sketches to interactive simulations that look and function like the final product. The keys to successful rapid prototyping are revising quickly based on feedback and using the appropriate prototyping approach. Rapid prototyping helps teams experiment with multiple approaches and ideas, it facilitates discussion through visuals instead of words, it ensures that everyone shares a common understanding, and it reduces risk and avoids missed requirements, leading to a better design faster.

The Rapid Prototyping Process Link

Rapid prototyping involves multiple iterations of a three-step process:

  1. Prototype
    Convert the users’ description of the solution into mock-ups, factoring in user experience standards and best practices.
  2. Review
    Share the prototype with users and evaluate whether it meets their needs and expectations.
  3. Refine
    Based on feedback, identify areas that need to be refined or further defined and clarified.

rapid prototyping

The prototype usually starts small, with a few key areas mocked up, and grows in breadth and depth over multiple iterations as required areas are built out, until the prototype is finalized and handed off for development of the final product. The rapidness of the process is most evident in the iterations, which range from real-time changes to iteration cycles of a few days, depending on the scope of the prototype.

Scoping A Prototype Link

The word prototype often conjures images of a coded, fully functioning version of an application or interface. Rapid prototypes are not intended to evolve into fully functional solutions, but are meant to help users visualize and craft the user experience of the final product. With that in mind, when scoping a prototype, decide on a few key issues before beginning any prototyping work.

What Needs to Be Prototyped? Link

Good candidates for prototyping include complex interactions, new functionality and changes in workflow, technology or design. For example, prototyping search results is useful when you want to depart significantly from the standard search experience; say, to introduce faceted search or the ability to preview a document without leaving the search results.

How Much Should Be Prototyped? Link

A good rule of thumb is to focus on the 20% of the functionality that will be used 80% of the time; i.e. key functionality that will be used most often. Remember, the point of rapid prototyping is to showcase how something will work or, in later stages, what the design will look like, without prototyping the entire product.

Find the Story Link

After identifying the areas to be prototyped, weave them together into one or more scenarios: identify the coherent paths through the user experience that the prototype simulates. For a website that sells shoes, one scenario could be “Boring Joe” buying the exact same Nike running shoes that he bought six months ago, while another scenario could be “Exploring Sam” browsing through size 10s to find a pair of Oxfords and pair of loafers that interest him.

Plan Your Iterations Link

The entire prototype is usually not built in a single iteration but rather piece by piece. A good approach is to start prototyping broadly and widely and then dive deep into selected areas of the solution. For a website, this would mean building out the home page and landing pages for the main sections in the first iteration (sometimes referred to as a horizontal prototype) and then reviewing and revising that framework. Subsequent iterations could drill down into one or more sections of the website (a vertical prototype); for a media download website, this could be the steps a user would take to find a video and to download it, or how they would manage the media in their online library.

Choose the Appropriate Fidelity Link

Key Dimensions of Fidelity

Fidelity refers to how closely a prototype resembles the final solution. There are multiple dimensions of fidelity, and prototypes can lie anywhere on the spectrum for each of these dimensions. Depending on the stage of the design process and the goals of the prototype, select the appropriate fidelity for each of the following:

  • Visual fidelity (sketched ↔ styled)
    Look and feel are the most noticeable dimension of a prototype’s fidelity and, if not properly selected, can sidetrack prototype reviews. Go hi-fi too soon and users will focus on visual design, which is not appropriate in early stages. From a visual standpoint, prototypes do not have to be pixel perfect but should be proportional; for example, if the left navigation area has to occupy one-fifth of a 1024-pixel screen, it does not need to be exactly 204 pixels wide, as long as it is proportionally depicted in the prototype. As prototyping progresses through the design cycle, increase visual fidelity as needed by introducing elements of style, color, branding and graphics.
  • Functional fidelity (static ↔ interactive)
    Does the prototype reveal how the solution will work (static) or does it appear to be fully functional and respond to user input (interactive)? This dimension is less of a distraction to users, but adding interactivity in subsequent iterations increases functional fidelity and allows the prototype to be used for usability testing and training and communications.
  • Content fidelity (lorem ipsum ↔ real content)
    Another dimension that often distracts users is the content that is displayed in the prototype. Squiggly lines and dummy text like lorem ipsum are useful to avoid in early stages of prototyping. But as the prototype is refined, evaluate the need to replace dummy text with real content to get a feel for how it affects the overall design.

The Prototyping Spectrum Link

Low Fidelity Link

The quickest way to start prototyping is also the easiest: putting pen(cil) to paper. Sketching on paper is a low-fidelity approach that anyone can do; no special tools or experience required. Most often used during the early stages of a design cycle, sketching is a quick way to create rough mock-ups of design approaches and concepts and to get feedback from users. Paper prototyping is ideal during brainstorming and conceptualization and can be done alone in a cubicle with a sketchbook or in a group with a flip chart (or whiteboard) and markers.

Examples of low fidelity prototypes

Lying at the low-fidelity end of the prototyping spectrum, paper prototypes are static and usually have low visual and content fidelity. This forces users to focus on how they will use the system instead of what it will look like, and it makes designers more open to changes based on user feedback.

Low-fidelity prototyping lends itself to rapid prototyping. It has no learning curve but lets you make changes easily and quickly.

Medium Fidelity Link

As we start using computer-based tools such as Visio and Omnigraffle to prototype, the fidelity increases on most fronts, yielding medium-fidelity prototypes. Wireframes, task flows and scenarios that are created with these tools take more time and effort but look more formal and refined. While visual elements of branding, colors and style can be introduced, prototypers often stay away from them, focusing instead on demonstrating the behavior of the application. Interactivity can be simulated by linking pages or screens, but functional fidelity here is medium at best. These prototypes are best suited to determining whether user needs are met and whether the user experience is optimal.

Examples of medium fidelity prototypes

There are two reasons why one might intentionally make a medium-fidelity prototype not look like a medium-fidelity prototype:

  • The first is that, by using Balsamiq or sketchy Visio stencils to make the prototype look low fidelity, you force users to view it as a draft or work in progress, rather than a polished and finished product.
  • The second is that, by giving the prototype a high visual fidelity (for instance, in a comprehensive layout done in Photoshop), you get the user to focus on the visual design and look and feel, including color, fonts, layout, logo and images.

The speed of medium-fidelity prototyping is achieved with templates, stencils and reusable widgets and elements. It gets faster as you become more proficient with your tools of choice.

High Fidelity Link

High-fidelity prototypes are the most realistic and are often mistaken for the final product, but they are usually time-intensive. A few years ago, the only way to create high-fidelity prototypes was to actually code using a programming language, which often required the designer and developer to work together. These days, however, application-simulation tools allow non-technical users to drag and drop UI widgets to create high-fidelity prototypes that simulate the functionality of the final product, even for business logic and database interactions. Axure and iRise are some examples of application-simulation tools that can be used to create high-fidelity prototypes.

These prototypes are appropriate when high visual and functional fidelity is required; for example, when introducing a new technology (say, when moving from a mainframe application—yes, they still exist!—to a Web-based solution. Most of these prototypes cannot be converted to usable code, but they serve as an excellent reference for developers. These are also useful for conducting usability testing and training users.

Examples of high fidelity prototypes

High-fidelity prototyping is relatively rapid, considering the level of interactivity and fidelity involved, and it can be accelerated by using drag-and-drop simulation tools. In addition, some of these tools facilitate the gathering of user feedback and documenting of requirements, further speeding up the design process. Even though you do not need to learn a new programming language, these tools do have a learning curve.

Selecting a Fidelity Level Link

In choosing the prototype fidelity, there is no one correct approach. Most designs of new products are best started with sketches, then moving to either medium- or high-fidelity prototypes, depending on the complexity of the system and the requirements of the dimensions of fidelity.

In working with one particular client in the pharmaceutical industry, we went from whiteboards to interactive prototypes that had high functional and content fidelity but low visual fidelity. They cared less about the look and feel than about adhering to corporate guidelines.

For another client, this one in retail, our interactive prototype had to have high visual and functional fidelity. The content fidelity did not matter because they would be reusing content and were already familiar with it. To them, the look and feel and interactive experience mattered more because this was their first implementation of SharePoint, and they wanted to make the portal look “non-SharePointy”!

Selecting Tools Link

Depending on your approach, you have a wide variety of tools to choose from. Dan Harrelson has compiled a list of popular prototyping tools on the Adaptive Path blog.

Each tool has its own feature set and strengths. Based on your needs and the requirements of the projects you work on, evaluate which tool would be most appropriate. Here are some questions to consider when evaluating tools:

  • How easy is it to learn and use the tool?
  • Is it flexible to support prototypes for Web, packaged and custom software applications, as well as desktop and mobile applications?
  • Is there a repository of reusable stencils, templates or widgets available?
  • How easy is it to share the prototype with others for review? Can their feedback be captured using the tool?
  • How easy is it to make changes on the fly or to incorporate feedback?
  • Does it have any collaboration features, such as allowing multiple people to work on it at the same time?
  • What are the licensing terms and costs?

Dos And Don’ts Link

As you get started, here are a few points about effective rapid prototyping to keep in mind:

Do… Link

  • Work collaboratively with users, business and IT stakeholders while rapid prototyping. Apart from giving valuable feedback, they also gain a sense of ownership of the final product.
  • Avoid “prototype creep” by setting expectations for the process, including ones affecting the purpose, fidelity, scope and duration. Remind everyone, including yourself, that rapid prototyping is a means to an end, not an end in itself.
  • When creating interactive high-fidelity prototypes and simulations, build in realistic delays (for instance, for screen refreshing or moving through steps of a transaction), so that users do not expect instant response times from the final product.
  • Reuse, reuse, reuse. For computer-based prototyping, this means saving reusable templates, stencils, patterns and widgets for future projects.
  • Most importantly, begin every prototype review session with the disclaimer that this is just a prototype, a mock-up, not the actual solution. This reminds users that this is a work in progress, it encourages feedback, and in the case of high-fidelity prototypes, it prevents users from mistaking it for a working solution.

Don’t… Link

  • Don’t prototype features or functionality that cannot be implemented—often an issue with software package implementations. When in doubt, confirm with developers before starting.
  • Don’t take every change or request that comes out of a prototype review as a new requirement. Rapid prototyping helps capture missed requirements, but these new requirements should be evaluated carefully. Some may be implemented, while others are pushed to a future release.
  • Don’t begin prototype review sessions without clear guidelines for feedback. Be very specific about the type of feedback you are looking for. (Are the steps logically arranged? Is the navigation clear and intuitive?) If not, be prepared for, “I don’t like the blue in the header,” or “Can’t we use this font instead?” or “Can you make this bigger, bolder, in red and flashing?”
  • Don’t be a perfectionist. In most cases, rapid prototyping does not have to be 100% perfect, just good enough to give everyone a common understanding.
  • Don’t prototype everything. Most of the time, you shouldn’t have to.

Further Resources Link


Footnotes Link

  1. 1
  2. 2
  3. 3
  4. 4
  5. 5
  6. 6
  7. 7
  8. 8
  9. 9
  10. 10
  11. 11
  12. 12

↑ Back to top Tweet itShare on Facebook

Lyndon Cerejo is a certified user experience strategist in Capgemini's Rapid Design & Visualization practice, with a successful track record with clients including Allstate, American Express, Coca-Cola, General Motors, Merrill Lynch, and Wal-Mart. His key areas of expertise are user experience analysis, information architecture, rapid prototyping, usability testing, online strategy & marketing. He is the co-author of - a book about marketing adaptations on the Internet.

  1. 1

    Daniel White

    June 16, 2010 6:41 am

    We usually start at the high. We used to start at the low, then work towards the high, but they kept changing the high, which they should have done at the low, and they generally only ever want to see the high, so the low is usually stayed internal until a variety of highs are presented.

    Then… after presenting 2 or 3 beautiful highs, they want a little bit out of each, in order to create thier own high, but the combination of the highs they want, would never work in either low, meduim or high and force us to create a whole new kind of high which they feel they did themselves, and we can’t put in own portfolio which is just low….

  2. 2

    You won’t design better! Less thought will go into your models creating more waste in the process.

    It’s time people got back to the way things used to be made, manual.

  3. 3

    Frans Gerber

    June 16, 2010 5:56 am

    Great Article – like the various fidelity levels, we usually start with a medium working our way towards high, if the budget allows of course.

  4. 5

    Leandro Puca

    June 16, 2010 6:04 am

    Great article, i like and i use sketchying when i have to design some iphone app.
    I’ll insert this article on my blog:

  5. 6

    great article! I think it definitely depends on the client and the website when deciding the best “fidelity” to start at.

    On my site,, you can see a wide variety of different styles and programs used to make wireframes during this prototyping stage.

    I realize there is a “no link dropping” rule, so I’ll understand if my comment gets edited or not approved. I think some people might enjoy the content as it relates to this article though.

  6. 7

    Estoy un poco en desacuerdo con la parte de no bocetar funcionalidad que no puede ser implementada. Un problema que tengo con algunos diseñadores de mi equipo es que no se atreven a bocetar nuevas funcionalidades por miedo a no poder desarrolarlas. Algunas veces no hay tiempo de sentarse a analizar con los desarroladores las posibilidades de usar algo nuevo. Esto hace imposible mejorar o inovar nuestras herramientas. Yo le pido a mi equipo que si tienen la oportunidad se atrevan a bocetar funcionalidades nuevas no importa si los desarrolladores las rechazan. Esto no significa que trabajaremos doble, simplemente, debemos tenere en cuenta que necesitamos poder resolver el problema con un metodo probado anteriormente.

    (Sorry for the abd english)

  7. 8

    I am a bit at odds with the non-sketching functionality that can not be implemented. A problem I have with some designers on my team is that they do not dare to sketch new features for fear of not being able to developers. Sometimes there is no time to sit down with the developers to analyze the possibilities of using something new. This makes it impossible to improve or innovate our tools. I ask my team if given the chance to dare to sketch new features it does not matter if developers avoid them. This does not mean double work, simply, we must note that we need to solve the problem with a previously tested method.

    • 9

      Valid point, Norke. This is why I think any interactive designer should have at least some development experience so that they can know the limitations of implementation. It’s such a waste of time to have to run to a developer or development team to find out if something is technically feasible.

  8. 10

    Andrés Ayala

    June 16, 2010 8:48 am

    Excellent !

  9. 11

    Great article, I can really benefit from this because it helps break down the “Webdesign” process. If webdesign involves “look and feel” and “functionality”, look and feel would be the icing and functionality would be the cake. I only wish I worked in a place where there weren’t so many chef’s in the kitchen ;-) This article will certainly help break it down and simplify our work process. Thanks!

  10. 12

    Christian Broadbent

    June 16, 2010 9:30 am

    This was a good article to read, although i’ve been an avid believer in suppling sketched mock-ups to my clients for a long time. Since graphic design has become 99% about the computer, it’s great to bust out the pencil and sketch book as a method of brainstorming ever once and a while.

  11. 13

    This may sound trite, but:

    Dos and Don’ts


    • 14

      Lyndon Cerejo

      June 16, 2010 10:45 am

      Shane – yes, thanks – made the correction.

      • 15

        Lyndon – I was a bit rude there – I actually enjoyed the article, but didn’t say thanks!

        Thanks :)

  12. 16

    OMG. Thank you SO much for writing this! This’ll be helpful to show to clients too.

    I’ve been having so much trouble with concept sketches; it appears so clearly in my head but my client doesn’t see the full impact when they see the sketch. Even when I explain to them to focus on the CONCEPT and not the form, they still reject certain ideas because the concepts don’t seem solid on paper.

  13. 17

    “Can you make this bigger, bolder, in red and flashing?”
    I don’t get it…is that not a good technique? lmao

  14. 18

    Fitim Blaku

    June 16, 2010 1:06 pm

    Fantastic article. My design firm uses the same system… splitting people into small groups makes rapid prototyping so much easier for everyone because time is well spent thinking about the user’s experience and focusing on the overall vision, not on people management issues.

  15. 19

    Adam Fuller

    June 16, 2010 4:29 pm

    Awesome article!!

  16. 20

    Nicely done. Love your resources–both Dan & Carolyn’s books are spot on.

    I would heartily recommend that you also include Todd Zaki Warfel’s excellent book, “Prototyping: A Practitioner’s Guide” ( It goes into detail about why you should prototype, what the benefits are, five types of prototypes, eight guiding principles, and a hands-on overview of several tools: Paper, presentation software, Visio, Fireworks, Axure, and HTML.

  17. 21

    Thanks Lyndon,

    This is a great article for me and i got a clear picture about prototyping.

    Now, i am clear about all the three types of prototyping. Really this is a very clear info.

    Thanks again to Smashing Magazine & Lyndon Cerejo.

    Elumalai J.

  18. 22

    Very very good. Prototyping should be the first step in every plan: sketches, schemes, basic drawings, etc.

    Cool article

  19. 23

    Mohammad Ashour

    June 17, 2010 1:27 am

    Really like the subject of this article. Thought the bit about focusing on “20% of the functionality that will be used 80% of the time” was on point! I do disagree about reusing code developed during a prototype. Prototyping is usually done rapidly, as the article’s heading suggests. This means that the usual design > implement > test cycle isn’t tight like in regular development. So code made by prototyping won’t be as robust or well designed. Actually that’s part of the fun of prototyping, just doing it quick and dirty. There’s a lot of lessons learned from prototyping, but I leave it at that.

  20. 24

    Very helpful… claeared many thing, many thought clouds which were there about prototyping.

  21. 25

    Great article!

  22. 26

    how about using a different terminology. rapid prototyping has been used since the mid 90’s for prototyping real parts quickly, not websites. This will only cause for confusion calling this rapid prototyping

  23. 27

    Finally a timeless article that doesn’t fluff anyone’s feathers.

    Personally Low Fidelity is the way to go….Medium already requires attention to detail and is ‘time wasted’ while High will only trigger discussions about designs,colors the looks and not the features.

  24. 28

    Great article – we employ these techniques on ‘every job’ we touch. Now if only we could get some clients to sketch up what’s in their head, we’ll be off and running.

  25. 29

    Andrea at ProtoShare

    June 17, 2010 3:39 pm

    Lyndon, this is one of the best prototyping articles I have come across. Very informative on the process, dos and don’ts, and how to select the best tool for you and/or your project. Thank you for sharing this resource!

    Some highlights for me:

    “Rapid prototyping helps teams experiment with multiple approaches and ideas, it facilitates discussion through visuals instead of words, it ensures that everyone shares a common understanding, and it reduces risk and avoids missed requirements, leading to a better design faster.”

    “Do…Work collaboratively with users, business and IT stakeholders while rapidly prototyping. Apart from giving valuable feedback, they also gain a sense of ownership of the final product.”

    We are strong proponents of facilitating the collaborative and iterative process – define, share, and refine – to save headaches later on. And depending on the needs of a project, being able to use a single tool to evolve from grey box wireframes to high-fidelity prototypes also saves time and headaches.

    These sentiments are what our company has built our product on, so it’s nice to see them continue to spread throughout the industry.


  26. 30


  27. 31

    Awesome… thank you for the great article, and of course i click the ads too :)

  28. 32

    You can’t believe how relevant this article is for me right now. Thank you so much! Incredibly informative.

  29. 33

    Pete Kinser

    June 18, 2010 1:38 pm

    RP is a great practice if done correctly and shared with informed stakeholders. Otherwise – this can quickly become design by committee – aka – a designer’s nightmare.

    ** Educate your stakeholders before committing to this method**

    Great detail of the process. Thanks for sharing.

  30. 34

    Very, very useful article! I don’t have a habit to prototype, but when I did – I’ve finished a project twice faster than usually. Cheers!

  31. 35

    This article has open my eyes to the usefulness of prototypes. Now i just need to make the time to put into practice the lessons learnt!

  32. 36

    Eric Azares

    June 21, 2010 8:10 am

    I think every web design professional should bookmark this article and read it again every week.

    I think that there’s a temptation for smaller scale sites to shrink(or even cut) the iteration process for the sake of ‘saving time’. However, I feel that in the long run, PLANNING and PROTOTYPING actually SAVES time.

    It’s 10x harder to change code that is already in production. With prototyping, iterations are as easy as pressing delete or erasing a pencil line.

    Prototype early! Prototype often!

  33. 37

    Very useful article.
    Thank you!

  34. 38

    Sharad Kapoor

    June 21, 2010 11:17 pm

    can you please share some real time examples of prototyping .. may be prototyping process of smashing magazine.

    it would really great with examples along with this article

  35. 39

    Justin Davies

    June 22, 2010 3:04 am

    Great article and well explained in how to use it. I’ve prototyped using graph paper, balsamiq and omnigraffle – as well as keynote, and html mockups – however the key point that you make is really valid – understand the purpose of the prototype and go from there. Many thanks for sharing the ideas…


  36. 40

    Great article!

    We are developing a new prototyping and design app called ANTETYPE ( that makes it easier and faster to create interactive hi- and lo-fi prototypes. Just have a look at our overview video. We plan a private beta test in August, so please register for our newsletter if you are interested.


  37. 41


    June 23, 2010 1:08 am

    A great well explained article on prototypes,

  38. 42

    Thanks you guys, as always very informative and useful!

  39. 43

    Great article Lyndon! My colleagues and I will find this very useful. We have been using Balsamiq and begun using iRise. I look forward to your articles in the future. Thanks!

  40. 44

    Here’s another tool you might use – webbased JustProto

  41. 45

    I think a happy medium is finding a balance between static and interactive elements. Having too many interactive elements may interfere with a site being fully optimized for SEO and digital marketing

  42. 46

    Why is the thumbnail for this post a picture of Peter Cech?

  43. 47

    Lisa Pierson

    March 7, 2014 8:25 pm

    Good artilce, but the link for Adaptive Path’s blog for Selecting Tools is not working.

  44. 48

    very Good nice and useful article.Thanks for sharing

  45. 49

    I also agree


↑ Back to top