As a product manager I’m sure you will have found that prototypes can be hugely useful for visualising requirements and revealing hidden risks.
Lengthy, 50-page requirements are 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.
But prototypes expand each user story into a tangible part of a system, in my experience. If user stories express task-level goals, then prototypes can help us see the horizontal feature set (breadth) and vertical feature set (depth) required to fulfil each story.
I’ve found the following methodology very useful in my work as a product manager:
- Prioritise your user stories for prototyping
- Start prototyping the user stories
- Annotate prototypes to get the right feedback
This is my approach to whittling down a list of requirements into a clear product vision, which I hope others will find useful.
List all your user stories
Let’s say you’re building a mobile app that allows users to print their phone pictures in a photo book. Below are some of the primary user stories for this type of app:
- As a user I can create a new account
- As a user I can select pictures from my phone gallery
- As a user I can select my photo book size
- As a user I can apply visual effects to my pictures
- As a user I can pay for my book with a credit card
- As a user I can access my order history
- As a user I can access the Terms & Conditions and Privacy Policy
You don’t need to worry about the fine details of each user story. You simply want to list the user actions so that you can map out the user flow and identify any gaps.
Prioritise user stories by risk
I’ve found that there’s little benefit from prototyping a user story like this one below:
As a user I can access the Terms & Conditions and Privacy Policy
It’s a low-risk user story because the screens involved are static and read-only.
For prototyping, I always prioritise user stories involving user-submitted data and processing of user submitted data because this is where the most risk often lies and a clear user experience is most required.
Let’s examine the potential risks of each user story for the photo book example.
| ID | User Story | Comments | Risk Level |
| 1. | As a user I can create a new account | Accounts are necessary to keep each user’s data separate and private | High |
| 2. | As a user I can select pictures from my phone gallery | Since this is a mobile app, it’s essential that users can connect to and access the phone’s image gallery | High |
| 3. | As a user I can select my photo book size | The book size selected on this screen should be the same book size used at the printer. There’s a chance that book size codes could get mixed up, resulting in the customer receiving the wrong size | Medium |
| 4. | As a user I can pay for my book with a credit card | Users will be inputting personal and banking information. We need to decide if the info is stored for future use. If so, then technical implementation will need to address security and data encryption needs. | High |
| 5. | As a user I can access my order history | This is a read-only screen.
Only potential risk is errors related to order cost or book type. |
Medium |
| 6. | As a user I can access the Terms & Conditions and Privacy Policy for the app | No user data is being received or manipulated in these screens. Read only content. | Low |
Prototype the riskiest user stories
Once you’ve identified the high risk user stories, you can visualise them through your prototype.
When prototyping requirements, I use low or medium fidelity because I want designers and developers to better understand how the specs might manifest themselves as interaction models and content structures. There’s no point getting ahead of yourself by prescribing branding and visual design.
Let’s take a look at the prototypes for user stories 1, 2, 3 and 4. I’ve chosen demonstrate this with UXPin since it’s the tool I’ve used most often as a product manager, but my advice applies to whatever tool you prefer.
User Story 1: As a user I can create a new account
The first screen for the Photo Book App highlights the information that users must provide in order to create an account. This is a simple but critical screen for the technical team because it immediately clarifies the type of data stored in the back-end:
- Name (will contain only letters)
- Email (will contain letters and numbers)
- Password (may contain letters and numbers, depending on the organisation’s security rules)
Based on the above requirements, stakeholders will likely ask about the rules for passwords. For example, should they contain only letters, letters and numbers, letters and special characters?
By presenting a prototype, you can discuss the best rules for secure passwords. Without a prototype, developers wouldn’t know the type of information stored and visual designers wouldn’t have any guidelines about the quantity of displayed information.
User Story 2: As a user I can select pictures from my phone gallery
The prototype for User Story 2 involves two screens that must appear in a particular order:
- User presses the camera icon in the first screen
- The second screen displays all the images stored in the user’s phone
In addition, the prototype showcases another important aspect of the user experience: ensuring users can easily see the their selected images. In the prototype, this functional need is represented by the checkboxes placed in the top, right corner of each image.
It’s important to note that the app must provide feedback to users about selected images. While the prototype uses a checkbox, the visual designer may choose another option that works better for the screen size, brand, and overall user flow. For example, a transparent overlay could be placed over each selected image, or the colour of each image border could change to indicate that it is selected. Using a prototype you can now quickly discuss and refine these items.
The technical team also benefits from this prototype because they can now see the rough number of images that need to be instantly uploaded from local storage into the app.
User Story 3: As a user I can select my photo book size
We prototyped User Story 3, even though it’s a Medium Risk story. Whilst I think you should always prioritise High Risk stories when prototyping, there are cases where it makes sense to prototype a Medium or Low Risk screen.
For our Photo Book App, once users select their photos, the above screen for User Story 2 acts as the transition point towards checkout. We can’t avoid any mis-steps in such a key moment when users are selecting the product.
While it’s nowhere near perfect, we’ve at least created a tangible reference for designers, developers, and marketers. The team can now discuss:
- How might book dimensions, price and short descriptions accompany images of the photo books?
- How might we help users preview their selected images in the final photo book size?
- Should the book print the photos in the book in the order they were uploaded? Or do we allow users to reorder the pages?
- Do we include an additional step that allows users to select a cover image? Or do we randomly assign one from the images they uploaded?
User Story 4: As a user I can pay for my book with a credit card
The prototype for User Story 4 showcases the basic payment information we need to collect. This allows everyone to discuss the rules for each field. For example:
- How many numbers can the user enter in the credit card field? Do we accept all card types (Visa, Mastercard, American Express)? American Express cards have 15 numbers while Visa and Mastercard have 16 numbers. We must account for these variances.
- Should we consider adding PayPal as a payment option? If so, how do we prioritise that integration for developers in upcoming sprints?
- When fields are left empty or invalid data is submitted, how does the system respond?
This prototype also highlights a very important functional requirement: saving the user’s payment information for future use.
While this is just one little checkbox in the UI, the technical implications are quite serious. We’ll need to research legal requirements for storing personal information. In addition, the technical team must consider what might happen if servers suffer an attack or virus. Would customer data become publicly available?
At each step of your prototyping exercise, I think it’s important to focus on creating screens that clearly communicate the desired functionality and actions. By using built-in components like buttons, icons, image placeholders and phone frames, you can create a user-friendly prototype that will help everyone visualise the final product and associated risks.
Once you’re done building all the screens, you can add interactions to all the key content:
- Calls to action leading to new screens
- Icons and images that expand or open new screens
- Form fields that react to user input
Next, you can annotate and share the interactive prototype for feedback.
4. Add comments and questions to your prototype
As you build prototypes, you’ll likely have open questions for developers, designers, or management stakeholders.
Usually, I’ve found it helps to annotate:
- Regional restrictions: For example, prices in the US use a period (.) to separate the whole number and decimal portions. For example, $25.00. However, in the Euro zone it’s common to use a comma (,) instead. For example, €25,00. I would annotate these types of nuances so that it’s clear to the technical team that this is non-negotiable.
- Nice-to-have functionality: If some requirements can be added on in a subsequent version, point this out in your prototype. In the Photo Book App, the option to save the user’s payment information isn’t a must-have for the initial release. It’s a convenience that can be added later once you’ve released the product. You’ll need more time to work on implementing the correct data encryption and security to support that functionality.
- Items that might be costly: If you’re worried about a particularly functionality being too costly to implement, then immediately highlight your concern in the prototype. Use the prototype as an opportunity to discuss the effort needed to implement the items that you find most worrisome. Then, you can adapt your final requirements based on the feedback you receive.
5. Share the prototype for consolidated feedback
When it comes to reviewing feedback, you can set up a group meeting with all stakeholders and present the screens.
I think however that a better option is to provide some lead time during which all stakeholders can review the screens in your absence.
Sharing a link to your prototype provides the following benefits:
- Stakeholders can interact and evaluate the prototypes without feeling rushed. The feedback is less knee-jerk.
- Stakeholders can evaluate the prototypes with minimal bias. In a group meeting, the PM will usually set the context for the screens. However, outside of the confines of a meeting, the screens must speak for themselves. If the basic functionality is not clear as presented on the prototype, this quickly becomes evident to the stakeholders.
- When you share the link to a prototype, stakeholders can review all the comments and questions. Stakeholders can hover over any pin to view its details as shown below. For example, user story 4, which deals with storing payment information. You can leave questions regarding the legal and technical requirements for this functionality.
For a more complex project, it’s a good idea to review feedback in a group setting. This is an opportunity to focus on the feedback that requires buy-in from other stakeholders.
Here are a few of my tips for actionable feedback:
- When you send your team the design, ask for feedback regarding these items: product vision, feature completeness, and flow between pages. Explain that they shouldn’t obsess over the UI design since that may change completely later.
- When responding to comments, ask why. I’ve found it helps if you can the question in useful and non-condescending ways. Try something like: “That’s an interesting perspective. Have you seen any data that brought you to that conclusion or is it more of a gut instinct?” If someone says it’s a gut instinct, reframe their situation from a user’s perspective: “While that makes sense, as a user, if I wanted to accomplish [user story], I’d most likely need [actions] to happen because of [user and market research].”
- Tease out the core problem behind the feedback with the 3 question rule.
6. Analyse feedback, update prototypes and user stories
After you’ve analysed all your feedback, update the prototype and user stories.
For our Photo Book App example, the review process brought up an important question that we missed in the original user stories: the need to send confirmation emails when an order is placed and after it’s shipped.
For any ecommerce platform, transactional emails are essential for reassuring customers that their order is on its way. Without this, the user experience for the Photo Book App is seriously degraded. Therefore, we need to update our user stories.
As a user I will receive an email when I submit my order.
As a user I will receive an email when my order has been shipped.
In this case, a prototype of the email is also warranted to ensure we account for all legal requirements for receipts and invoices. Failure to respect legal requirements for receipts can lead to serious consequences for the business down the road. We would therefore consider this new user story as High Risk.
Overall, the Photo Book App example we explored is fairly simple. But you can imagine how the more complex your product, the more user stories you might otherwise miss unless you prototype.
Each time you update the prototype, reshare it with stakeholders to validate the changes are satisfactory. After the first revision, designers and developers should see enough of your vision to create the first formal build to test with users.
And as we all know, the earlier we revise and validate the vision, the less costs and risk we accumulate.
Conclusion
Prototypes should always be part of the specification process. In my past projects, they’ve made it much easier to notice gaps and redundancies in the user flow. Furthermore, prototypes are a great time-saver for product teams. You no longer need to rely on lengthy specifications documents to get your point across. You can build a quick prototype, annotate it, and share it with your team members to get feedback.
As part of an agile process, prototyping helps everyone unpack and prioritise requirements before each sprint. A prototype opens everyone’s eyes. The laundry list dissolves, and the product comes into focus. The consequences of additional features become immediately real for everyone from a junior designer to a product VP.
