A3: Prototyping Team submission

This is the first team assignment. Review and share the user needs you brainstormed. This week, your team will develop blueprints for your mobile web app by settling on a team point of view, storyboarding, and making paper prototypes.

Step 1: Make a Team Point of View

By now you should be a pro at writing a point of view! As a team, think about the user need you want to address and come up with a point of view that illustrates the need and your studio brief. Remember to look at the issue from a high-level; don't try to plan out all the functionality for your app or design a solution here. Refer to previous assignments on point of view for more guidance if needed.

Step 2: Create 3 Storyboards

Using your point of view and inspiration, generate three different design ideas that address/engage your point of view to address a user need. (Your call whether the different designs tackle the same scenario or diff't scenarios.) Your setting should assume access to current tools, such as the ones from your inspiration. Illustrate each of these ideas with a storyboard.

A storyboard is a comic-strip-like set of drawings about what your interface does and how it is used to accomplish tasks in a real usage scenario. Feeling stumped about how to show your ideas visually? Check out "Understanding Comics" by Scott McCloud, and Amal Dar Aziz's excellent Guide to Storyboarding. A good storyboard should clearly demonstrate who the user is, the usage situation, and the user's motivations for using the interface. It should show what the user can accomplish with your interface, but it needn't (and often shouldn't) show a specific user interface design. For a storyboard including an app screen, the details of the screen are not relevant, but what those screens enable you to accomplish is. Check out these lecture videos to learn more.

Each storyboard should fit on one (single-sided) 8.5" x 11" sheet of paper and comprise 6-8 panels. Use a thick pen like a Sharpie---ballpoint pen or pencil is not acceptable. A thick pen is a good reminder to focus on the high-level and not sweat the details at this point. (Don't worry, in a few weeks you'll have plenty of time to sweat the details.)

Remember that the three storyboards should diverge, meaning that they each represent different design ideas that address the same point of view. As an example, the following two storyboards both address the point of view "Through time budgeting and tracking, you can be your most productive self:" Storyboard 1, depicts a way to reduce the time of unproductive activities; Storyboard 2, depicts a way to manage your productive time.

Step 3: Build 2 Paper Parallel Prototypes

For this step, lay out your storyboards. Take some time to think about the different ideas you've had. Make sure you think out the strengths and weaknesses of each design, and how well they achieve the goals set out by your point of view. Buy-in and ownership are critical here.

Working as a group, make two paper prototypes. Each should clearly connect to your point of view, but in a completely different way. (Can you see we really value enumerating alternatives?) Each prototype will instantiate one of your storyboards (pick your two best storyboards). These sketch-level prototypes should show all of the important UI elements in approximate locations. They should not show fonts, colors, or pixel-level details. Paper prototypes must be hand-drawn. No digital devices are allowed. Again, it helps focus on the concepts, and saves you from wasting hours twiddling pixels. It also forces you to focus on the hard conceptual work of figuring out information architecture and functionality now. Years after taking this course, students often come back and tell us that paper prototyping was their favorite part of the class because of its effectiveness for rapid ideation.

The prototypes should be complete enough understand the "gist" of the app and to "run" a new user through each task. Small details that aren't very important for designing and do not affect the task (such as the copyright policy on Piazza) do not need to be included in the prototype. When you're done, everyone on your team should sign the prototypes. Your prototype interface should enable people to navigate, recover from errors, and change their mind. Check out the Hanmail video for an awesome example and inspiration.

Student Examples

Examples are a great way to learn, but they are not a gold standard for this class, especially as it evolves over the years. Use these examples as a reference, see where they succeeed/breakdown, and make sure your final submissions adhere to the rubric items.

  • Example 1 - This example shows two prototypes that are too similar, and a disjointed link between POV and storyboards.
  • Example 2 - This example has markedly distinct prototypes that each address the POV in their own way.

What’s this for? A UX agency perspective

by Mike Davison, UX Project Manager

Agencies use storyboards to convey to clients potential solutions to a given problem....problems discovered during needfinding. Doing it this way allows you to tell a story and explain how a user will interact with your design, without the need to draw a single pixel or code a single line. Storyboards are generally used during the discovery phase of a project, or during pitching activities when we are trying to dazzle a client with our creative thinking!

Team Submission

For this assignment, ONE person will submit the assignment for their team, listing every group member's student ID number in the assignment submission. Individual submissions will not be accepted. Meaning you must have joined a team by this time. Remember to bring your storyboards to class.

Your write-up will contain the following in one pdf:

  • Point of view that is the core motivation behind your app.
  • A comprehensive set of digital photos or scans of your three different storyboards.
  • A comprehensive set of digital photos or scans of both of your paper prototypes.
Submit your formatted pdf here

Evaluation Rubric

Note: if you are a rare group of 2: pursue a dev plan that meets the rubric with a reasonable workload. If you are unable, you may propose an accommodation to this on Piazza; include a link to your dev plan.

Team POV

  1. Presents team’s 1-2 sentence point of view on a user need. Point-of-view does not offer a specific solution or violate a taboo.

Storyboard

  1. Three different storyboards engage the point of view and studio brief in different ways.
  2. Storyboards are drawn with a sharpie or thick marker to focus on high-level design.
  3. Storyboards’ sequences are easy to follow. Someone else could come up with a distinct prototype that would correspond with the point of view just from looking at the storyboard.
  4. Storyboard 1 shows at least 5 panels, begins with a specific user need, and ends with satisfaction addressing it.
  5. Storyboard 2 shows at least 5 panels, begins with a specific user need, and ends with satisfaction addressing it.
  6. Storyboard 3 shows at least 5 panels, begins with a specific user need, and ends with satisfaction addressing it.

Paper Prototype

  1. Paper prototype 1 sketches an interface that accomplishes the design's major functionality.
  2. Paper prototype 1 has enough detail that the user can see all of the interactions, understand how they work, and a programmer could use the prototype to create a functional application with a defined flow.
  3. Paper prototype 1 connects to the point of view and a storyboard.
  4. Paper prototype 2 sketches an interface that accomplishes the design's major functionality.
  5. Paper prototype 2 has enough detail that the user can see all of the interactions, understand how they work, and a programmer could use the prototype to create a functional application with a defined flow.
  6. Paper prototype 2 connects to the point of view and a storyboard.
  7. Bring your team paper prototypes to studio.

Self Assessment


During studio, click here to assess your group's work as a collective unit.
During studio, click here to assess your own work and each of your team member's work.