Project 2: MVP, Prototyping, and Front-End UI

Due Dates

• MVP and Prototype Deadline: Wednesday, November 5, 11:59am EST
• Front-End UI Deadline: Wednesday, November 12, 11:59am EST

Overview

Learning Goals

By the end of this lab you will learn how to create and evaluate prototypes, a well as plan a large-scale project and develop the front-end UI for your project.

Requirements

Part 1: MVP and Prototypes

By the MVP and Prototype deadline (Nov 5), you should have:

• Conducted a competitive analysis of three competeitors in your space.
• Identified 15-20 functional requirements for your system, of which you will select a subset of 8 for your MVP and the rest for your stretch goals.
• Created a timeline that maps onto your MVP requirements for the next five weeks and should include a list of tasks (pertaining to a requirement), a time estimate for completing the tasks (each person should budget 4-6 hours/week), the person responsible for each task, and the due date for each task.
• Developed two personas that represent your target users.
• Created a set of three low-fidelity prototypes of your system's user interface that correspond to three different tasks.

Part 2: Front-End UI Implementation

By the Front-end UI deadline (Nov 12), you should have:

• A codebase that contains:
  • A README.md file that describes the project, lists team members, and provides exact instructions for how to set up and run your application.
• The first iteration of your front-end UI for your MVP requirements (apart from account creation/login/logout pages). The pages you create should have a consistent look and feel, but do not need to be functional — we are only concerned about form at this stage. You do not need to write any JavaScript at this point.

Note: If you are developing an application using something other than HTML/JS/CSS/NodeJS, please let me know. Your intstructions need to be explicit on how to install all of the requirements to your application.

Instructions for Part 1: MVP and Prototypes

Part 1A: 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 conduct a competitive analysis, derive requirements, and create personas for your project.

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.

Need Finding and Requirements Gathering

Second, 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 through a competitive anaylsis, 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 8 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.

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.

Part 1B: 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 1B 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 key 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.

You must iterate on your prototypes at least onece and submit both versions that your team works on. Make sure to indicate which is your final set of prototypes. A final prototype should be detailed enough that a software engineer could implement the design based on the prototype.

Instructions for Part 2: Front-End UI Implementation

Set up your virtual environment.

Create a python virtual environment:

$ git clone <repo>
$ cd <directory> 
$ pwd 
$ <directory>
$ virtualenv venv

Activate your virtual environment. You’ll need to do this every time you want to access your node project.

$ source venv/bin/activate

To deactivate it:

(venv) $ deactivate
$ 

Install nodeenv and create a node environment inside your python virtual environment:

$ pip install nodeenv
$ nodeenv -p

Install node.js modules

$ npm install 

Run your node server with nodemon

$ npm run dev

Create front-end templates

You can now create your front-end templates. Feel free to use the EJS templating language to minimize redundancy between pages (e.g., have common base_header and base_footer files). You can also use CSS libraries for your styling (e.g., Bootstrap, UIKit).

You will need to set up URL routes in your server.js file to serve each of your front-end pages. For example, if you have a home.ejs file, you will need to set up a route for /home that serves the home.ejs file.

Submission

• By the end of the lab session, discuss your timeline with me.
• By the MVP and prototype deadline, updated your Google Drive Project 2 document with your final submission.
• By the Front-End UI deadline, pushed your code to GitHub.

Rubric

Part 1: MVP and Prototypes (40 points)

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.

Part 2: Front-End UI Implementation (60 points)

Category	Needs Improvement	Good	Excellent
MVP Requirements Met	Several front-end requirements are not met or non-functional.	Most front-end requirements are met, but some minor aspects are missing or incomplete.	All front-end requirements are fully implemented and functional.
User Interface Quality	UI is inconsistent across pages, or deviates significantly from prototypes.	UI is mostly consistent across pages and follows what is specified in the prototypes, but could use additional refinement.	UI follows prototypes almost exactly, and has a consistent layout and styling.
Code Quality	Code lacks informative comments, is unorganized, or is difficult to read.	Code is functional but may have inconsistent formatting or have overly verbose comments.	Code is well-structured, readable, and well-commented, including concise function descriptions, appropriate function, and variable names.