How Can Paper Prototyping Help in Development?

Question

Possible Duplicates:
Do you feel that writing on paper helps you develop better?
What advantages does sketching a user interface on paper have?

drawing interfaces in paper, having huge piles of paper demonstrating the "flow" of the program, having to have a huge eraser in case of changes do not seem appealing to me.

Yet a lot of software practitioners actually recommend paper prototyping. I have seen books about it with really good reviews.

Has paper prototyping ever had huge benefits on your project?

Answer 1

In my opinion, the greatest value in these sorts of things is in making them rather than having them. The act of thinking about the system in terms that let you represent it on paper helps you to understand it in a more thorough way.

With that in mind, I try not to overdo it by producing unmanageable heaps of paper but rather doing this together with the team to better understand certain components on a detailed level as well as looking at more abstract models for the entire system.

I'd say that working together on a paper-prototype is a great way of building shared understanding of a system in the earlier design phases and it has proven very valuable for me in that regard.

Answer 2

I don't use paper but I always start with the white board. Small projects stay on the white board until they are realized. If there is enough on the white board to merit more thought or the consideration of other I begin using other tools. Its just part of how I code and design I can see why other wouldn't use it.

there have been several times I draw some stuff on the board and I show a user a sketch of what I think they want and I quickly realize I've designed a yougo.

Answer 3

I have only used it on one project and it helped a lot, but we only used it as a discussion tool. We used the paper prototypes for working sessions and idea generation. Then we through them out after transfering the ideas to other forms. But they were really handy for the tactile feedback they gave. People could reach over and move things around and really get a quick feel for the layout. They gave everyone a level playing field since you did not have to know any particular design tool in order to play with the layout.

But we did not keep them around. Once things seemed close to settled we moved on from the paper.

Answer 4

1. Sidestep problems before you write your code

2. You can get clear picture of what you are going to do.

3. Also it is good to fail on paper.

Best thing about paper prototyping is that everything works on paper.

Look here for good examples of paper prototypes.

Answer 5

I concur that having to simulate things through paper helps seeing things from a different perspective and spot issues (or at least some issues) before starting the actual design.

There is also another positive effect: if you prototype directly in HTML (for web applications) or your own RAD of choice the customer will tend to consider the whole product to be more or less completed: no matter how much you explain this point (at least to people who are not developers) seeing a working interface even if it is a mockup, makes people imagine that the back-end is just a trivial matter and the product will be done in a couple of days.

Answer 6

Prototyping is one thing.

When you encounter a true mess of a code and try to untangle it into something readable (in order to understand it, then rewrite it), a big sheet of paper is priceless.

Also, big data structures are way more readable in form of a set of crossreferencing boxes than as a typedef struct { ....(800 lines)....}

Answer 7

I was sure this was part of the Agile Manifesto, and I guess it's wrapped up in "Individuals and interactions over processes and tools", but not quite the same. Not sure where I read it now, and certainly not claiming it as my own, but it summarises why I like paper prototyping:

"We value the conversations we have over the documents we create."

When discussing software design, several bits of differently-sized paper can serve as really useful props in the discussion. I like them better than whiteboards because with a whiteboard I always find we're rubbing out and redrawing and scribbling all over the place when what you actually want to do is pop one form (bit of paper) on top of another one (different bit of paper) and drag a third (smaller bit of paper) over there to do this other really cool thing.

Once you've agreed it, then is the time to start putting it up on whiteboards or down in design documents or wherever you record design decisions for the project.

Answer 8

If you design a software that will be used by non-technicals, then you MUST start with paper.

Indeed, you have to test the UI from the very begining, and it always starts with interviews of about how random people feel in front of the first sketches.

More about that in the very good "don't make me think" from Steve Krug.

Good sketches are better than heavy specs for CRUD apps.

And there are very good side effects. For instance, you will have the data that has to be displayed on the design drafts, so it makes you think about your view and your model. It's much easier to code it after that.