Let\u2019s explore how you can whittle down requirements into a clear product vision.<\/p>\n
1. List all your user stories<\/h2>\n
Let\u2019s say you\u2019re building a mobile app that allows users to print their phone pictures in a photo book. For this type of app, here are some of the primary user stories:<\/p>\n
- \n
- As a user I can create a new account<\/li>\n
- As a user I can select pictures from my phone gallery<\/li>\n
- As a user I can select my photo book size<\/li>\n
- As a user I can apply visual effects to my pictures<\/li>\n
- As a user I can pay for my book with a credit card<\/li>\n
- As a user I can access my order history<\/li>\n
- As a user I can access the Terms & Conditions and Privacy Policy<\/li>\n<\/ul>\n
As explained in Prototyping for Product Managers<\/a>, don\u2019t worry about the fine details of each user story. List the user actions so that you can identify any gaps.<\/p>\n
2. Prioritize user stories by risk<\/h2>\n
Little benefit comes from prototyping a user story like this one:<\/p>\n
As a user I can access the Terms & Conditions and Privacy Policy<\/em><\/p>\n
This is a very low-risk user story because the screens involved are static and read-only.<\/p>\n
For prototyping, prioritize user stories involving user-submitted data and processing of user-submitted data. This is where the most risk often lies and clear user experience is most required.<\/p>\n
For the photo book example, let\u2019s examine the potential risks of each user story.<\/p>\n
![\"prototyping](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/Screen-Shot-2016-08-09-at-9.38.17-PM.png\")
<\/p>\n3. Prototype the riskiest user stories<\/h2>\n
Now that you\u2019ve identified the high risk user stories, it\u2019s time to visualize them through your prototype.<\/p>\n
When prototyping requirements, use low or medium fidelity. You want designers and developers to better understand how the specs might manifest themselves as interaction models and content structures. Don\u2019t get ahead of yourself by prescribing branding and visual design.<\/p>\n
Let\u2019s take a look at the prototypes for user stories 1, 2, 3 and 4. I\u2019ll demonstrate with UXPin<\/a> since I use it most often as a product manager. The advice, however, applies to whatever tool you prefer.<\/p>\n
User Story 1: As a user I can create a new account<\/strong><\/p>\n
![\"new](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/image07-1.png\")
<\/p>\nThe 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 to the technical team because it immediately clarifies the type of data stored in the backend:<\/p>\n
- \n
- Name (will contain only letters)<\/li>\n
- Email (will contain letters and numbers)<\/li>\n
- Password (may contain letters and numbers, depending on the organization\u2019s security rules)<\/li>\n<\/ul>\n
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?<\/p>\n
By presenting a prototype, you can discuss the best rules for secure passwords. Without a prototype, developers wouldn\u2019t know the type of information stored and visual designers wouldn\u2019t have any guidelines about the quantity of displayed information.<\/p>\n
User Story 2: As a user, I can select pictures from my phone gallery<\/strong><\/p>\n
![\"uploading](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/image04-4.png\")
![\"select](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/image06-1.png\")
<\/p>\nThe prototype for User Story 2 involves two screens that must appear in a particular order:<\/p>\n
- \n
- User presses the camera icon in the first screen<\/li>\n
- The second screen displays all the images stored in the user\u2019s phone<\/li>\n<\/ul>\n
The prototype also ensures users can easily see their selected images. This functional need is represented by the checkboxes placed in the top, right corner of each image.<\/p>\n
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 color of each image border could change to indicate that it is selected. Luckily, you can now quickly discuss and refine these items.<\/p>\n
The technical team also benefits because they can now see the rough number of images that need to be instantly uploaded from local storage into the app.<\/p>\n
User Story 3: As a user, I can select my photo book size<\/strong><\/p>\n
![\"select](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/image05-2.png\")
<\/p>\nWe prototyped User Story 3, even though it\u2019s a Medium Risk story.<\/p>\n
While you should always prioritize High-Risk stories when prototyping, you will run into situations where it makes sense to prototype a Medium or Low-Risk screen.<\/p>\n
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\u2019t avoid any missteps in such a key moment when users are selecting the product.<\/p>\n
While it\u2019s nowhere near perfect, we\u2019ve at least created a tangible reference for designers, developers, and marketers. The team can now all discuss:<\/p>\n
- \n
- How might book dimensions, price and short descriptions accompany images of the photo books?<\/li>\n
- How might we help users preview their selected images in the final photo book size?<\/li>\n
- Should the book print the photos in the book in the order they were uploaded? Or do we allow users to reorder the pages?<\/li>\n
- 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?<\/li>\n<\/ul>\n
User Story 4: As a user, I can pay for my book with a credit card<\/strong><\/p>\n
![\"pay](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/image00-8.png\")
<\/p>\nThe 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:<\/p>\n
- \n
- 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.<\/li>\n
- Should we consider adding Paypal as a payment option? If so, how do we prioritize that integration for developers in upcoming sprints?<\/li>\n
- When fields are left empty or invalid data is submitted, how does the system respond?<\/li>\n<\/ul>\n
This prototype also highlights a very important functional requirement: saving the user\u2019s payment information for future use.<\/p>\n
While this is just one little checkbox in the UI, the technical implications are quite serious. We\u2019ll need to research legal requirements for storing personal information. The technical team must also consider what might happen if servers suffer an attack or virus. Would customer data become publicly available?<\/p>\n
By using built-in components like buttons, icons, image placeholders, and phone frames, you create a user-friendly prototype that helps everyone visualize the final product and associated risks.<\/p>\n
Now that we\u2019re done building all the screens, we would add interactions to all the key content:<\/p>\n
- \n
- Calls to action leading to new screens<\/li>\n
- Icons and images that expand or open new screens<\/li>\n
- Form fields that react to user input<\/li>\n<\/ul>\n
![\"share](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/image01-6.png\")
<\/p>\nNext, we\u2019ll annotate and share our interactive prototype for feedback.<\/p>\n
4. Add comments and questions to your prototype<\/h2>\n
As you build your prototypes, you\u2019ll likely have open questions for developers, designers, or management stakeholders.<\/p>\n
![\"add](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/image02-6.png\")
<\/p>\nIt helps to annotate:<\/p>\n
- \n
- Regional restrictions:<\/strong> For example, prices in the U.S. use a period (.) to separate the whole number and decimal portions. For example, $25.00. However, in the Euro zone it\u2019s common to use a comma instead. For example, \u20ac25,00.<\/li>\n
- Nice-to-have functionality:<\/strong> In the Photo Book App, the option to save the user\u2019s payment information isn\u2019t a must-have for the first release. You\u2019ll need more time to work on implementing the correct data encryption and security to support that functionality.<\/li>\n
- Potentially expensive items: <\/strong>Adapt your final requirements based on the feedback you receive.<\/li>\n<\/ul>\n
5. Share the prototype for consolidated feedback<\/h2>\n
When it comes to reviewing feedback, you can set up a group meeting with all stakeholders and present the screens.<\/p>\n
However, a better option is to provide some lead time during which all stakeholders can review the screens in your absence.<\/p>\n
When using UXPin<\/a>, I share a prototype link so that:<\/p>\n
- \n
- Stakeholders can interact and evaluate the prototypes without feeling rushed. The feedback is less knee-jerk.<\/li>\n
- 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.<\/li>\n
- 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. You can leave questions regarding the legal and technical requirements for this functionality.<\/li>\n<\/ul>\n
For a more complex project, try reviewing feedback in a group setting.<\/p>\n
6. Analyze feedback, update prototypes and user stories<\/h2>\n
Once you\u2019ve analyzed all your consolidated feedback, update the prototype and user stories.<\/p>\n
For our Photo Book App example, the review process brought up an important question we missed in the original user stories: the need to send confirmation emails when an order is placed and after it\u2019s shipped.<\/p>\n
![\"analyze](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/image08-1.png\")
<\/p>\nFor any e-commerce platform, transactional emails are essential for reassuring customers that their order is on its way. Therefore, we need to update our user stories.<\/p>\n
As a user I will receive an email when I submit my order.<\/em><\/p>\n
As a user I will receive an email when my order has been shipped.<\/em><\/p>\n
In this case, we also need to prototype an email to account for all legal requirements for receipts and invoices. We would, therefore, consider this new user story as High Risk.<\/p>\n
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<\/a>.<\/p>\n
Conclusion<\/h2>\n
Prototypes should always be part of the specification process. In my past projects, they\u2019ve made it much easier to notice gaps and redundancies in the user flow.<\/p>\n
A prototype opens everyone\u2019s 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.<\/p>\n
If you found this post useful, learn more by downloading the free e-bookPrototyping for Product Managers<\/a>.<\/em><\/p>\n
- Nice-to-have functionality:<\/strong> In the Photo Book App, the option to save the user\u2019s payment information isn\u2019t a must-have for the first release. You\u2019ll need more time to work on implementing the correct data encryption and security to support that functionality.<\/li>\n
- Regional restrictions:<\/strong> For example, prices in the U.S. use a period (.) to separate the whole number and decimal portions. For example, $25.00. However, in the Euro zone it\u2019s common to use a comma instead. For example, \u20ac25,00.<\/li>\n
![\"free](\"https:\/\/www.uxpin.com\/studio\/wp-content\/uploads\/2016\/08\/fb-promo.png\")
<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"