Project 2: MVP and Low-Fidelity Prototyping

Due Date

Tuesday, March 25, 11:59am EST

Overview

Learning Goals

By the end of this lab you will learn how to create and evaluate prototypes.

Requirements

Your mission this week is to refine the interface for your class project.

By the deadline, you should have:

1. Interviewed at least three potential users of your system.
2. Identified 15-20 functional requirements for your system, of which you will select a subset of 10 for your MVP and stretch goals.
3. Conducted a competitive analysis of three competeitors in your space.
4. Developed two personas that represent your target users.
5. Created two scenarios that describe how your personas will interact with your system.
6. Created a set of three low-fidelity prototypes of your system's user interface that correspond to three different tasks.

Your "Project 2" folder within your team's Google Drive folder should contain a Google Doc with all of your requirements and prioritized requirements, competitive analysis, personas, scenarios, and initial + final set of low-fidelity prototypes.

Part 1: Minimum Viable Product (MVP) and Stretch Goals

“A requirement is a statement about an intended product that specifies what it is expected to do or how it will perform.” — Helen Sharp, Yvonne Rogers, and Jennifer Preece, Interaction Design: Beyond Human-Computer Interaction

For this assignment, you will work with your team to derive requirements, personas, and scenarios for your project.

Need Finding and Requirements Gathering

First, you will gather data about the needs and requirements of your intended users in the context of your project. People often overestimate the degree to which other people will agree, think, and behave the way they do. This applies to designers, developers, and user experience researchers who are tasked with creating digital interfaces as well: we infer generalizations when we assume that others will perceive and understand the interface in the same way we do. The false-consensus effect can be found in the design process when there’s a lack of data on how the actual users respond to your designs.

To avoid the false-consensus effect, you will need to gather data about the needs and requirements of your intended users. Speak to at least three different people who are potential users of your system. These people should be representative of the intended users of your system. For example, if you are designing a system for students, you should speak to students.

When you speak to potential users, however, you shouldn't ask them what they want. Henry Ford quipped that people would have asked for faster horses, not automobiles. Steve Jobs also said, "It's not the customer's job to know what they want." Instead, your goal will be to understand the problem that they are facing and to identify their needs and requirements.

Here are some sample questions you could ask:

• Can you tell me how you currently (perform a task related to your project topic)?
• What are the biggest challenges you face when you (perform a task related to your project topic)?
• What are your goals when you (perform a task related to your project topic)?
• What motivates you to (perform a task related to your project topic)?
• What tools or resources do you currently use to help you with (your project topic)?
• What do you like about these tools or resources? What could be better? (Note: we aren't asking about what features to implement, but rather challenges with functionality, usability, etc. Form should follow function.)

Apart from speaking to users, you can supplement your data gathering with other sources of information, such as scholarly articles, news articles, social media posts, etc.

From your data gathering, you should identify 15-20 different functional requirements. These requirements should be specific and actionable. For example, “The system should be easy to use” is not a functional requirement because it is not specific or actionable. Instead, a functional requirement for a social meetup applcation might be “The system should show users people who they are friends with that are planning to attend the meetup or are on the fence"; "Users should be able to see the location of the meetup on a map"; "Only verified users should be able to RSVP to a meetup."

Select a set of 10 requirements that will be the focus of your design for the next part of this assignment, the prototype. These requirements should be the most important requirements for your system. You will use these requirements to guide the design of prototype.

Order these requirements from highest to lowest priority, and identify which requirements are for your MVP (minimum viable product) and which are stretch goals. MVP requirements are the minimum set of requirements that your system must have to be considered complete. Stretch goals are requirements that are nice to have but are not necessary for the system to be considered complete.

Competitive Analysis

A competitive analysis involves identifying your direct and indirect competitors using research to reveal their strengths and weaknesses in relation to your own. Direct competitors market the same product to the same audience as you, while indirect competitors market the same product to a different audience.

Conduct a competitive analysis of at least three competitors in your space. Create a table that lists the competitors, their strengths, and their weaknesses across at least three different dimensions. For example, if you are designing a social media application, you might compare competitors based on which users they target, what features they offer, and how well they perform.

Personas

A persona is a fictional, yet realistic, description of a typical or target user of the product. A persona is an archetype instead of an actual living human, but personas should be described as if they were real people. Personas work because designers and developers have the same tendency as all other people to be captivated more by concrete instances than by abstractions and generalizations.

Personas will help you to make user-focused design decisions and to shape the overall direction of the product. You can (and should) always ask yourself: What would Persona X need or want here? What would be their preference? What would help them the most?

At the same time, personas make it easier to communicate and share your user research findings with others (especially those outside of the design team). Anyone can glance at your personas and immediately understand who you’re designing for and why — making it easier to justify your design decisions and get buy-in from key stakeholders.

Create two personas by synthesizing data gathered with your functional requirements. Personas need to represent realistic users, not ideal or perfect ones. Each persona should be unique and represent a user with particular motivations and behaviors.

This blogpost providess some good examples of a persona. Keep in mind that the template personas are often designed for a particular context, which may not adequately match your project. For example, including a section on favorite brands is unlikely to be relevant to most projects. Include content that helps describe a potential user and their motivations and goals.

Scenarios

Personas are useful for describing characteristics of users, but they don't provide a way to describe how users will interact with your system. Scenarios are a way to describe how a user might interact with your system to achieve a goal.

A scenario is a short story or visual narrative (e.g., write-up, comic strip) that describes the activities of a particular user or set of users. Your scenario should depict the activities of a persona user(s) within the context of your proposed interactive experience. Describe the circumstances leading up to the interaction in question. Scenarios are usually centered around one task that is key to your product and includes 5 elements: (1) an actor, (2) a motivator, (3) an intention or intent, (4) an action, and (5) a resolution.

When writing a scenario, use a specific persona as the actor carrying out the scenario. Doing so provides additional context and insight about how that particular user segment might perform the task. For example, below is a possible scenario for a hotel booking website:

Detailed Debbie is going on a business trip. She needs to book a hotel room that’s affordable and has good reviews. Debbie browses the site to find a hotel for her upcoming trip. She looks closely at the various hotels to find one that meets her needs. She considers price and user ratings heavily as she shops. Debbie selects a hotel and books a room.

Come up with two scenarios, one for each persona. A scenario can be a series of short, hand-drawn sketches or a paragraph of text.

Part 2: Low Fidelity Prototypes

“A prototype is one manifestation of a design that allows stakeholders to interact with it and to explore its suitability. It is limited in that a prototype will usually emphasize one set of product characteristics and de-emphasize others.” — Helen Sharp, Yvonne Rogers, and Jennifer Preece, Interaction Design: Beyond Human-Computer Interaction.

For Part 2 of this assignment, you will work with your team to create three low-fidelity prototypes that represent major portions the user interface for your system. Low-fidelity prototypes are quick and easy to create and modify. I recommend paper (or... iPad) prototyping because it is quick and easy to create and modify. They are used to explore different design ideas and to get feedback from users. Low-fidelity prototypes are not meant to be polished or complete. They are meant to be rough sketches that can be easily modified, and users are more willing to provide honest feedback on rough sketches over polished final products.

Select at least three requirements from Part 1 to be the focus of your prototype. Brainstorm ideas for how to design an interface to address each of these requirements. Derive a set of tasks that a target user would need to perform in order to meet a selected requirement. For example, if a requirement states that a user should be able to easily access and edit to their contact list, then the task should involve creating, updating, and accessing their contact list. Consider your scenarios when deriving tasks.

Create three sets of low-fidelity prototypes that address the three tasks. Pages 9–11 in this document are a good example of a low-fidelity prototype.

For paper-based prototypes, sketch out interface elements and content on paper, a notebook, or your iPad. You should be able simulate an interactive experiences by adding and removing paper elements or changing cards. Here's a resource from the Interaction Design Foundation for more information about paper prototyping.

Iterate on your prototypes within your team and submit all versions that your team works on. Make sure to indicate which is your final set of prototypes.

Submission

Create a new folder within your Google Drive folder that you shared with me named "Project 2" that contains the files described above in the Requirements section.

Rubric

Category/Value	Needs Improvement	Good	Excellent
Requirements	Requirements are unclear or too few in number. The prioritization does not appear well-justified.	Requirements are mostly clear but there may not be 15-20. Requirements are not prioritized appropriately.	There are 15-20 requirements that are well-articulated and prioritized in a reasonable manner.
Personas	Personas are shallow or low-effort.	Personas are described in detail but not appropriate or some additional information is missing.	Personas are relevant and described in sufficient detail.
Scenarios	Scenarios are shallow or low-effort.	Scenarios are described in detail but not appropriate or some additional information is missing.	Scenarios are relevant and described in sufficient detail.
Prototypes	Prototypes are low-effort or hard to decipher.	There are three sets of prototypes, but may not describe all user interactions or missing some details. The relationship between prototypes and tasks/requirements is not clear.	Prototypes are clear and describe a complete set of user interactions that map onto tasks and requirements.