What do we do?

Let’s start giving your design idea a digital life by creating a low-fidelity digital prototype. This is a low-fidelity version of your prototype, meaning you should not put too much effort into making it pretty or polishing every detail. Focus on the essential interactions and functions of your design. Rather than use HTML and JavaScript, you’ll use a prototyping tool to implement the tasks and scenarios. You should use Figma for digital prototyping until the end of this semester. We’ll give you a quick tutorial in class.

Functionality 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. 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.

In your prototype, a task is a user action to support the solution, aiming to meet user needs. 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”.

You must do a live demo of your prototype during the studio presentation. A live demo must focus on explaining how tasks are supported rather than functional features. Try to capture the end-to-end scenario.

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. If they are not your target user, please explain how they still provide valuable feedback for your prototype.

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.
  • Updates from DP2: If your team revisited ideation (e.g., HMWs, solutions) and made updates to your ideation results, briefly describe what has been changed.
  • Tasks (3): List the three core tasks you’ve decided to support in your prototype. Again, you can reuse or improve what you had in DP2.
    • Connection with DP2 HMWs & Solutions: How each task is linked to HMWs and solutions in DP2. If your HMWs and solutions have changed since the DP2 report, please use the final version and explain it in Updates from DP2.
  • Prototype:
    • Link to your prototype (1): Your prototype needs to be accessible and executable by anyone with the link.
    • 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. Please do not put every single page of your prototype, but only the representative ones.
    • Instructions: Please include instructions for running your prototype in detail. It should tell us what kind of actions should be done to proceed with each task.
  • Observations:
    • Briefly describe your participants: how many you had, (very brief) background information that is related to your prototype.
      • If your participants are not your target user, please explain how they still provide valuable feedback for 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?)
    • 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 all of the feedback received during the studio accurately captured in the summary?
    • Is the summary of feedback well structured (e.g., according to high-level themes and/or criticality)?
  • 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 10:29am on Tuesday 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.