As a writer with over 10 years of experience in product management, Germaine loves to share resources that help agile PMs. Check out her recent ebook Prototyping for Product Managers.
If a picture is worth a thousand words, then a prototype must be worth a hundred thousand pages of a requirements document. While a requirements document describes how a product works, a prototype is how a product works.
Prototypes bring your user stories to life. They allow product managers to quickly communicate and validate functionality. Because they are visual, they are also easily understood by all stakeholders and agile teams. Seeing is believing.
Here’s how I’ve found prototyping most useful in my own work as an enterprise product manager.
1. Less risk of confusion
Lengthy, 50-page requirements are simply not reliable ways of conveying all the subtleties of a digital product. In my experience, readers quickly get bored and even worse, misinterpret what is written.
Prototypes, on the other hand, expand each user story into a tangible part of a system. If user stories express task-level goals, then prototypes help us see the horizontal feature set (breadth) and vertical feature set (depth) required to fulfill each story.
2. Flexibility and usability
If you’ve ever created a formal requirements document, you know how much patience and imagination is required.
And beyond writing, validating a requirements document eats up even more time. If you want accurate feedback, everyone needs to review every inch of it. And if changes are requested, updating the document becomes even more tedious. The cycle of documentation just downright expensive.
Prototypes, on the other hand, are much easier to create. Instead of reading requirements, people are experiencing them. Content is easier to navigate, and the taxonomies are crystal clear. If changes are required, the reviewer can comment directly on the affected part of the UI. It’s far more efficient than wading through documentation that requires serious analysis.
3. Improves the quality of technical decisions
UX decisions are only as good as their implementation. And if you look deep enough, and you’ll see that poor implementation is most often caused by miscommunication.
If developers and designers both speak the common language of systems interactions, why not communicate requirements in that medium?
Even a lo-fi prototype can help developers quickly see dependencies between elements and interaction models. An early evaluation might even prompt developers to suggest better solutions the designers never even considered. All before anyone ever opens Photoshop, Sketch, or a code editor.
One way to improve communication is by outlining your core requirements in the requirements document, and then linking to external sources for more information. For instance, at Autodesk documentation is treated as a knowledge hub rather than a paper trail:
Simple requirements portal created by Autodesk
Annotated user story flow created by Autodesk.
4. Better stakeholder buy-in
Stakeholder buy-in is often tricky. With a focus on the bigger picture, user needs can easily fade into the background of a decision-maker’s mind. And requirements can easily be seen as a laundry list of tasks – why not add another feature or two if it makes the product more robust?
Prototypes help ground expectations and clarify product direction for all involved. When everyone, from a junior designer to a VP of Product can experience the product for themselves, both user needs and the workload of the team come into sharp focus. Prototypes help create a shared understanding and bring empathy into the process.
In sum
Agile development requires a great deal of flexibility from all team members. Even with the use of agile user stories, it’s not easy to dive into the fine details around design and UX.
When you prototype, documentation becomes a complementary rather than supplementary activity. Your design becomes the documentation.
As a result, the designs remain truer to the user stories. Your team also delivers with greater velocity since you aren’t spending hours on encyclopedic PRDs. You finally start to find that tricky balance between user-centered design and agile delivery.
Like this post? You might love our resources at The Agile Product Manager, our collection of articles for agile PMs on everything from product roadmaps, to NPS, customer feedback, and more!