Discussions

News: Article: Six Signs That You Should Use Paper Prototyping

  1. Carolyn Snyder tells us to collect the wrapping paper that is all around, and put it to good use. Carolyn's article discusses six signs which let you know that you may have a use for paper prototyping, and then goes on to show you "how".

    The Six Signs

    Sign 1. There are many different ideas about the design.
    Sign 2. You find yourself defending a particular design.
    Sign 3. There are parts of the design you're unsure about.
    Sign 4. You're changing the way that the users perform a task.
    Sign 5. The concepts or terminology are new to the users.
    Sign 6. You're feeling uncreative.

    Sometimes it feels good to go back to basics doesn't it? When do we use technology versus something simple like pencil and paper?

    Which of these do you jump to?

    - A UML Tool
    - Use the source
    - Paper

    Read Six Signs That You Should Use Paper Prototyping

    Threaded Messages (20)

  2. Which of these do you jump to?
     - A UML Tool
     - Use the source
     - Paper


    None of the above: the white board. But only because my coworkers haven't embraced a CASE tool. I find UML a great way to capture and share ideas from the very beginning. I've worked in an environment of code generation accompanied by total model governance, which forces folks to embrace CASE, and the benefit of immediate digital sketching was amazing. No one ever complained about a feature being discussed and then forgotten. Feature capture was always in sync with our office chatter. Paper sketches are ambiguous and easily lost. Paperless is the way to go. Spontaneous art lives on with diagraming tools and white boards, but the proverbial "napkin sketch" is a thing of the past. I once used a white board that could print a hard copy of its analog contents. I imagine the benefit of a smart white board with a mouse and computer to act as a collaborative digital tool.
  3. sounds good except for the paper[ Go to top ]

    I'd agree with most of the article except the "paper" part.

    The reason is that it is trivial to find a good straight HTML building tool to create the "mockup" in. And the time it takes to build the prototype in this fashion is generally not much more (and sometimes less) than it takes to do it on paper.

    The advantages to this are significant:
    - it is trivial to distribute electronically as a zip file
    - your users can actually click through the pages to navigate (it is very difficult to convey site navigation on paper)
    - when you get some signoff, you have some boilerplate HTML code to drop into your coding environment rather than starting from a blank page
    - because of the lack of "cut and paste", paper mockups tend to "abbreviate" things that are repeated on pages even though they might actually be slightly different per page...with an HTML mockup you can cut and paste and address these issues
    - similarly, for form fields, a paper mockup tends to not enumerate each and every field that is needed (usually some form of elipses are used at some point). With an HTML mockup it is trivial to add fields so these things can be captured.
    - with a laptop projector, you can actually walk through the interface with your users to get feedback
    - it is much easier to revise a detailed HTML screen mockup than to revise a detailed paper mockup
    - screenshots can be cut and pasted into other supporting documentation (e.g. design, sitemaps, etc)
    - the HTML mockup can be used to "demo" the application to users while the real implementation is being developed

    The downsides are:
    - not as easy to print out to distribute (pretty much need to manually convert to PDF if you want a simple way for users to print all the pages)
    - doesn't work as well if the prototyper isn't skilled in HTML (but then I'd argue why it is they are doing a paper prototype if they can't ensure it can be implemented...)
  4. Why Paper is Better[ Go to top ]

    The point of prototyping pages is to focus on general content and flow. As soon as you put something too 'real' into place users very quickly begin to focus on colors, positioning, details. Furthermore, once users see something which appears to be 'real' they often tend to be hesitant to offer out of the box ideas.

    Paper has the power of being very low tech leading users to be very comfortable suggesting to throw it out and start from scratch. Users also are encouraged to focus on flow and general content rather than look and feel since a paper sketch does not contain much look and feel.

    Paper is not necessary, but the prototype should have the sketchy look of paper rather than of a finished html page.

    This of course is in my humble opinion and only applies if you are trying to flesh out the general content and flow of your application rather than the final details of an already conceptualized view.

    A very cool idea of a product for doing this type of work is DENIM (http://guir.berkeley.edu/projects/denim/)
  5. Similar Discussion[ Go to top ]

    I originally was referred to Denim via a similar discussion about when to use paper prototyping and how to evolve a feature list for the ui portion of a project. Here is the link to the thread : http://www.featuredrivendevelopment.com/node/view/550#159
  6. Why Paper is Better[ Go to top ]

    Paper has the power of being very low tech leading users to be very comfortable suggesting to throw it out and start from scratch.

    Quite the opposite: digital content is disposable and biomass isn't.
  7. that assumes HTML of course[ Go to top ]

    But if you are building with Swing or some other technology, there are probably good prototyping tools out there whereby the same approach applies.

    And then there is Visio or some other drawing tool if none of the above apply (still better than pen and paper for the long term).
  8. sounds good except for the paper[ Go to top ]

    The reason is that it is trivial to find a good straight HTML building tool to create the "mockup" in. And the time it takes to build the prototype in this fashion is generally not much more (and sometimes less) than it takes to do it on paper.


    That is just partially true. There is a technology called "wiki" which ideally
    suits the needs of mockup creation. Have a look at osafoundation wiki page:
    http://wiki.osafoundation.org. Design of Chandler application is done using this
    approach, and it seems quite effective.

    What about the paper, well, it sounds quite obsolete...
  9. Advantages of Paper[ Go to top ]

    Some good points here about problems with paper and benefits of HTML. But I've seen too much time wasted tweaking HTML mockups of pages that never even make it to production. At an early stage, paper has several advantages:

    - Paper is faster to create and update.
      It might *seem* faster to write HTML, but watch what actually happens: developers spend too long on the detail, even though the overall scheme is still undecided. Work happens quickly when you don't have to align tables, tweak colour schemes, deal with Javascript.

    - Paper lets people focus on information architecture, i.e. general content, page flow, suitability for users' tasks.
      These are the important things to establish early on, but once you add a green background, the first comment you'll hear is why green does not meet corporate style guide standards. The page may not even be required, but we're now beginning a lengthy discussion on its colour and layout.

    - Paper can be generated by non-HTML developers.
      As long as someone understands the basic capabilities of an HTML UI, they do not have to be an HTML "programmer" in order to generate high-level prototypes.

    - Users can change paper prototypes.
      The great thing about paper is its familiarity --- it invites a two-way collaboration exercise because users can cross things out, add labels, and so on, as easily as developers.

    - Paper prototypes can be truly dynamic.
      HTML can be made a little dynamic via some ugly javascript. Tools such as index cards or sticky ("Post-It") notes can augment paper prototypes to help teams explore scenarios.

    - Developers are less committed to paper prototypes.
      Because paper prototypes can be whipped up quickly, developers do not feel particularly committed and are open to suggestions. In contrast, developers who have spent a long time working on a sophisticated HTML prototype often experience cognitive dissonance, and become resistant to criticism.

    There are some disadvantages of paper prototypes as you point out, but they are usually not too serious. For instance, how important is it to retain an electronic version of an early prototype? Even if required (eg for emailing), there are workarounds such as scanners and digital photos.

    Detailed look-and-feel issues *do* matter, just not at the early stages when paper prototypes are more suitable. By the time it is necessary to work on these, it may be quite easy to tweak the code directly rather than build an HTML prototype at all. This assumes the system is well engineered enough to make those changes quite simple.
  10. - Users can change paper prototypes.

    > The great thing about paper is its familiarity --- it invites a two-way
    > collaboration exercise because users can cross things out, add labels, and so
    > on, as easily as developers.

      Michael, I hope you realize that if you use lets say XUL to protoype/mock up your UIs you can still use paper. All you need to do is print out your web page. How hard is that? And than you can go on and write on it and post sticky notes on it and so on. The world isn't all 0 and 1. Black and white. Red pill and blue pill or whatever.

      - Gerald
  11. Use XUL To Prototype Your UIs[ Go to top ]

    Evidently, Carolyn has missed the XUL revolution.

    If you want to prototype/mock up your UI why not use XUL (XML UI Language)? XUL lets you build dialogs or wizards using nothing more than a bunch of XML tags and attributes. No need to get stressed out over learning loops, packages, classes and other hard-core Java stuff.

     - Gerald

    PS: If you're new to XUL you might wonna check out the Xul Alliance Linkopdia online @ http://xul.sourceforge.net/links.html

    PPS: More and more XUL forms designers are forthcoming that let you build UIs the clicky-clicky way. Check out Theodore for an example online @ http://www.carlsbadcubes.com/theodore
  12. Use XUL To Prototype Your UIs[ Go to top ]

    Evidently, Carolyn has missed the XUL revolution.


    Along with about everyone else in the IT world.
  13. I'm a bit worried..[ Go to top ]

    .. if this is Sun's official prototyping solution it's no wonder that developers describe VS.NET as superior design environment.

    Wake up SUN!
  14. I am wondering how many people here who are slamming the author have actually compared digital versus paper prototyping. I think the author makes an exceptional point that a lot of people here are missing completely.

    I don't believe that this issue once states that HTML screen mockups, XUL, Swing models, etc. should not be used. I think she's saying that Step 1 of a project could be doing a paper prototype and I would defend that choice. I know that when I've built digital prototypes, one of two things happen. I design it with the exact layout and graphics that I plan to use for the final version and we argue about color and font with the users because they think they are seeing the final application. If I leave out the colors and screen layout, then they turn their nose up at my application because it lacks the pretty colors. Unfortunately, our user base doesn't think like us technical folk do.

    On my last application, I did what the auther suggests and we were able to have a rational discussion about the interface instead why I chose Verdana 12 point rather than Verdana 10 point bold.

    Let's cut the author some slack. I don't think that it's evident that the author has missed any revolution, nor do I think it evident that throwing another technology (with its associated learning) curve at a project is the best answer. (Gasp! Yes, I know.)

    I think that what she merely highlighted an important design step, not the ONLY design step.
  15. I totally agree. Is paper prototyping this controversial or revolutionary an idea? I swear people will argue over anything.

    As technical people I think we too often go for the most gee-whiz approach first. Digital whiteboard, XUL, HTML mockups etc. I don't know a user, client, or manager who can use these tools as easily as they can a piece of paper and a pencil. Starting with paper (or analog whiteboard :-) is often a great way to draw non-tech folks into a discussion about requirements and design. Of course, this is only one tool in the box but it still useful and will be around longer than most of the other technologies discussed.


    > I am wondering how many people here who are slamming the author have actually compared digital versus paper prototyping. I think the author makes an exceptional point that a lot of people here are missing completely.
    >
    > I don't believe that this issue once states that HTML screen mockups, XUL, Swing models, etc. should not be used. I think she's saying that Step 1 of a project could be doing a paper prototype and I would defend that choice. I know that when I've built digital prototypes, one of two things happen. I design it with the exact layout and graphics that I plan to use for the final version and we argue about color and font with the users because they think they are seeing the final application. If I leave out the colors and screen layout, then they turn their nose up at my application because it lacks the pretty colors. Unfortunately, our user base doesn't think like us technical folk do.
    >
    > On my last application, I did what the auther suggests and we were able to have a rational discussion about the interface instead why I chose Verdana 12 point rather than Verdana 10 point bold.
    >
    > Let's cut the author some slack. I don't think that it's evident that the author has missed any revolution, nor do I think it evident that throwing another technology (with its associated learning) curve at a project is the best answer. (Gasp! Yes, I know.)
    >
    > I think that what she merely highlighted an important design step, not the ONLY design step.
  16. Low Tech is High Tech![ Go to top ]

    Personally I think a low tech solution is a great way to precede a high tech process. If you want to use paper, chalk, white boards, or whatever, it has a wonderful advantage of being a totally abstract representation. You can visually see and interact with the items. If you are doing page layout or site architcture, there is no learning curve for non-techies to assist, and you aren't bottlenecked while clicking and typing around on the keyboard. Multiple people can work and collaborate in a totally understandable medium.

    Sure.. I can go type up XML or HTML or whatever.. heck, I could go have a graphics designer mock up pages and all of that.. if I'm using sticky notes Its trivial for different people to step right in and be involved.

    Now that said.. later in the design process.. sure you want to move to some tool for capturing and distributing the information. The point is.. its an early design process with no technical overhead.. no imput contention.. no learning curve.
  17. the problems of paper continued[ Go to top ]

    Here's the problem with a low tech paper solution based on my most recent project:

    I came into a project after the team spent 4-5 weeks interviewing the users and creating paper mockups of what the application should do.

    When actually tasked with translating these mockups into HTML, the team was unable to effectively do so, and it was impossible to create an effective estimate of the work effort. The reason is that the paper mockups skipped over an enormous amount of detail and were chock full of "and a miracle happens here" panels.

    I worked with the team spending 3 weeks literally splattering this chicken scratch into HTML mockups and presented them to the users (the emphasis was on content and not "presentation". In doing so, what was originally a mockup of about 70 screens turned into 350 screens over a period of about 3 more weeks reviewing the mockups with the customers and creating additional screens.

    The paper was clearly ineffective at conveying the full scope of the application. (To be fair, a better job could have been done on the paper mockups, but I wasn't involved at that time).

    With regard to mucking with fonts/colors/etc, it was very easy to lead the discussion away from those topics by emphasizing that the intent of the mockup was to capture the general flow and functionality of the application.

    The side effect of this effort was that we now have an artifact that is being used by the training staff to write documentation, being used to demonstrate the concept of the application to user groups, etc. And if any of these folks ask if they can "test drive" it for themself, we just fire off an email with a zip containing the content. Meanwhile the team has taken the page content as the starting point for each of the pages (although we have since done quite a bit of refactoring of the table layout crud from Dreamweaver into CSS and just generally cleaning up the presentation).

    For future phases of the project, the mockup will be reused and additional functionality "plugged in" to the mockup.

    My fundamental argument is that paper is an inherently flawed medium for mockups because most people use far too much shorthand when doing so and don't capture anywhere near enough detail. It is more efficient to iteratively go from whiteboard to mockup, back to whiteboard, back to mockup, etc.

    If you have a pressing need to lower the "tech curve", you could use Visio or Powerpoint as the source of your mockups (where again the miracle of cut and paste will significantly boost productivity). The downside to these approaches though is that it is more difficult to "test drive" the flow of the application.
  18. all the Signs we have meet and fixed it well.

    there are many advantages when you use Paper Protype for your requirement-analyzer.such as let customer feedback more detail according to the paper , let art design has a overviews of the whole project , etc.

    you should not make it complex , just KISS. because we all know that is just a Prototype.We can beautify it any time after the requirement is ensured.

    and in the process of Business Model Design , designers can make the work flow of Paper Propotype more clear for coder or others who need:)
  19. the problems of paper continued[ Go to top ]

    Maybe you could look at this as a success of the paper prototype:

    This is obviously a large project and a lot of time was spent with the users. You gathered a lot of information on your paper prototypes and that allowed you to take the next logical step and come up with a functional prototype. You spent 5 weeks gathering "paper requirements" and then it took 3 weeks to translate them into a draft functional prototype. Then 3 more weeks to fully flesh out the prototype into 350 screens.

    Look at it this way: If it only took you 13 weeks to have a functional and acurate prototype of 350 screens, what are you complaining about? That is almost 30 screens a week progress. Seems like it was time well spent by your team.

    My guess too is that by going back to your users multiple times allowed them to think more and more about what was actually needed of the system. Do you really think the users could have come up with all 350 on the first pass no matter what technology you used?

    Anyway, wouldn't you like it if I was your Project Manager? I'd be taking your team out to lunch for productivity!





    > Here's the problem with a low tech paper solution based on my most recent project:
    >
    > I came into a project after the team spent 4-5 weeks interviewing the users and creating paper mockups of what the application should do.
    >
    ....
  20. See also ..[ Go to top ]

    Carlos Villela on Paper Prototyping

    Peace,

    Cameron Purdy
    Tangosol, Inc.
    Coherence: Clustered JCache for Grid Computing!
  21. See also ..[ Go to top ]

    Hey, thanks for the blogref ;)