Design Project 3: Low-fidelity Prototyping

What do we do?

Let's start giving your design idea a digital life by creating a low-fidelity digital prototype. Rather than use HTML and JavaScript, you'll use a prototyping tool to implement the tasks and scenarios. You can also choose any digital prototyping tool of your choice. Our recommended tools include Figma, InVision, Marvel, and proto.io.

Functionlity does not need to be fully implemented. Please use hard-coded but realistic data, Wizard-of-Oz, and fake results, so that you can focus on the essential: the user's task, scenario, and UI components to support them rather than the underlying implementation. You need to build a prototype that supports end-to-end scenarios captured in your paper prototype. Your prototype needs to support at least three distinct tasks. This does not mean you need to build three separate prototypes, but rather this means you need to build one complete prototype that is flexible enough to support the three tasks.

Task examples for a shopping app could be: “Put more than 6 items into a shopping cart and finish the purchase.”, “Put two items into a shopping cart, remove both, and add a new item.”, and “Cancel your purchase in the middle of a payment process.”. But avoid functionality-focused examples such as “Use the 'add' button and put 6 items into a shopping cart”. After building your digital prototype, find at least three participants to test it. Make sure they are not friends who know about your project already, or classmates. Preferably, try to find participants who are close to your target user group or persona.

Your Report

Your report should include:

• POV: Re-state the POV of your project. Based on what you've learned so far, you can revise your POV.
• Tasks: List the three core tasks you've decided to support in your prototype. Again, you can reuse or improve what you had in DP2.
• Prototype:
  • Link to your prototype
  • Prototyping tool: Which tool did you choose? Why? What worked well with the tool? What didn't?
  • Design choices: What did you intentionally choose NOT to implement (e.g., fake or hard-coded data, manual algorithm, etc.), and why not?
  • Representative screenshots: Include a few most important screenshots that showcase the uniqueness of your application.
  • Instructions: Your prototype needs to be accessible and executable by anyone with the link. Please include instructions for running your prototype in detail, if needed.
• Observations: Briefly describe your participants: how many you had, (very brief) background information that is related to your prototype. List at least 10 usability problems you discovered. Organize them by high-level task or theme, not by each participant or time. But mention which participant ran into the problem by referring to them as P1, P2, ... (e.g., search results did not show the price information (P1, P3)). For each problem, indicate how critical the problem is: high, medium, and low. Finally, show how you plan to address each of the problems in the later stage of your design process.
  • Note that observations should not be about the implementation limitations of your prototype. Avoid reporting issues about features that are not programmed to work.

Grading

• POV & Tasks (15%)
  • POV is clearly written?
  • Tasks align with the POV?
  • Three or more tasks?
  • Are the tasks distinct from each other?
  • Are the tasks described concretely and clearly?
  • User-level description not functionality description?
• Prototype (40%)
  • Good usability? (e.g., learnable? efficient? safe?)
  • Tool description and justfication are clear?
  • Design choices are justified?
  • Design choices mention what's not selected by the team?
  • Screenshots are added?
  • Screenshots capture representative moments of the prototype?
  • The prototype captures the three tasks?
  • The prototype is complete in that it supports an end-to-end scenario?
  • The prototype is accessible and executable?
  • Instructions for running the prototype are clear?
• Observations (25%)
  • Participant information provided with clarity?
  • 10+ submitted?
  • Are the usability issues described concretely and clearly?
  • Organized by high-level task or theme?
  • Level of criticality included?
  • Is the plan for improvements reasonable and sound?
• Studio Reflections (10%)
  • Is feedback well summarized?
  • Is feedback addressed, or is the plan for addressing feedback concrete?
• Studio Presentation (10%)
  • Preparation and organization?
  • Articulation and clear delivery?
  • Effective use of visual aids?
  • Time management?

Deliverables

Studio Presentation: In studio, your team will present your main findings for 7 minutes, with 5 minutes for Q&A and feedback. You need to prepare a Google Slides presentation, by editing the template slides in your team folder. The slides should be ready by 2:30pm on Wednesday before the studio begins. Every team member needs to participate in the presentation. Write down the questions and feedback you receive during your presentation, and reflect on them in your report.

Team Report: One report per team. Your report should be submitted as a zip file. The main report should be written in Markdown (please use the .md extension). Name the file with your team name, and submit it by the submission link provided. You can submit multiple times until the deadline, and we'll use the most recent version for grading.