By putting designs in front of users and watching them work, teams can identify key requirements that users may not even have mentioned. They also see that different users respond differently to the same interface, giving them a better understanding of who the users are and what they need to accomplish. When we first started prototyping with paper, we didn't realize it would be so different from other prototyping techniques we'd used. We thought we would produce the prototype from a specification, try it with a few users, make and document changes to the specs, and then put the prototype aside as we started development. But we've learned that the prototype itself is more than a disposable instrument to gather design changes.
Teams increasingly use paper prototypes to help generate requirements.
Every time they test a design, they uncover new requirements. By having real users do real work with the prototype, they end up with more accurate requirements than any other process would give them. It can be labor-intensive to create a paper prototype, especially the first one. Paper prototyping is sometimes easier with a larger team, because the work can be shared. With only one or two developers, it's necessary to block out more time to create the initial prototype.