A2: Prototyping – DUE Friday, Oct. 19 @ 12:30am
Review and share the user needs you brainstormed for A1: Needfinding. This week, your team will develop blueprints for your web app, fleshing out your design ideas by creating a point of view, seeking inspiration, storyboarding, and making paper prototypes.
Step 1: Refine your point-of-view if necessary
Revisit your point-of-view from A1 with your team after reading this entire assignment's directions, and refine it if necessary, in the spirit of repeated iteration. (If you feel that your A1 point-of-view is fine, then you can keep it for A2.)
Based off the user needs you found from A1, write a Point of View (one or a few sentences) that describes a core problem in relation to the class's design theme. It should address a deep user need and your personal take on a high-level design strategy, but without offering any concrete solutions yet. (You can resubmit what you had from A1 if you feel that was adequate.)
Refer to this document for a point-of-view about writing a Point of View (these may not match this year's design theme, though). 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.
Step 2: Create 3 Storyboards
Next, use your point of view and inspiration to come up with three different design ideas that address/engage your point of view to address a user need. 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, along with the lecture notes for prototyping/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 should not 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. In sum, every storyboard should start with a user need and end showing how that need is satisfied (i.e., a "satisfaction that addresses the need").
Each storyboard should comprise 4 to 8 panels and fit on one 8.5" x 11" sheet of paper. (It's OK to use more than one sheet per storyboard if you really need the space, but try to stay within one sheet.) 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 clever scheduling, homework doesn't have to be a time-consuming and dreaded process:" Storyboard 1, depicts a way to prioritize tasks; Storyboard 2, depicts a way to factor in breaks. (Don't worry if yours isn't drawn as nicely; you don't need to be an artist to create good storyboards. Just focus on conveying the ideas clearly.)
Step 3: Build 2 Paper 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 team, make two paper prototypes. Each should clearly connect to your point of view, but in a completely different way. (Can you see by now that we really value generating and considering diverse alternatives?) Each prototype will instantiate one of your storyboards (pick your two best storyboards). A paper prototype concretely shows all the essential elements of a user interface, except that it's implemented with pen and paper, as opposed to pixels and code. Paper prototypes must be hand-drawn. No computers and printers 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 course because of its effectiveness for rapid ideation.
Your paper prototypes should be complete enough for your TA to understand the "gist" of the app and to "run" a new user through each task. Small details that aren't important for designing and do not affect the task (such as the copyright policy page on the Piazza web app) do not need to be included in the prototype. Your prototype interface should enable people to navigate, recover from errors, and change their minds. It's a good idea to write captions explaining the high-level flow of each 'screen' of your paper prototype so that people understand how it flows. Do not simply turn in a bunch of pictures with no captions or explanations, since your TA will not understand how to use your prototype.
Check out the Hanmail video for an awesome example and inspiration.
Submit a single well-formatted PDF file for your entire team with the following items concatenated within it:
Submit your single formatted PDF in Gradescope to the bin for your studio section. Only one team member needs to submit on behalf of the entire team.
Due In Studio: Bring Your Storyboards for Feedback
Remember to bring your storyboards to studio to get feedback on them.
Due In Studio: Teammate Assessment
Evaluation criteria & Grading rubric
The rubric below contains criteria that are worth one point each and will be graded independently and in a binary fashion.
Frequently Asked Questions
Q: Should our paper prototypes target a mobile or desktop web app?
A: It's up to you; depends on your needfinding and storyboards. Some kinds of tasks would be better served by mobile apps since people can use it anywhere, but other tasks might require the larger screen space of a desktop setup.
Q: Do I have to use thick Sharpie markers for my paper prototypes as well?
A: We encourage you to do so to focus on the big picture, but it's not required.
Q: Should paper prototypes be in black&white or color?
A: We discourage color since we don't want you to focus on visual design aesthetics at this early stage. But if color is integral to your design idea, then go for it.
Q: Should our paper prototypes simply be drawings of full webpage screens, or should it also contain cut-outs of individual UI elements?
A: You will probably need both: entire screens are useful to show the initial state; cutouts are usually more appropriate for dynamic UI elements like dialog boxes, menus, etc. In both cases, make sure that the interaction flow is explicitly indicated.
Q: In our paper prototypes, do we have to show pages/screens/elements that are not directly related to our storyboard?
A: Yes, there will be pages in an app that go beyond the scope of any one storyboard. Another way to think about it is that any realistic app has more than a single piece of functionality, but storyboards usually illustrate only one feature.