What do we do?

Let’s start giving your design idea life by creating a low-fidelity paper 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.

Functionality does not need to be fully prototyped. Please use fake 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 paper 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 show a demo video of your paper prototype being used during the studio presentation. The video must focus on explaining how tasks are supported rather than functional features. Try to capture the end-to-end scenario. Here (Hanmail) is an example of a demo video.

After building your 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 as close as possible 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:
    • Thorough images of your prototype clearly showing the flow of all three tasks.
    • Design choices: What aspects of the usage process did you intentionally choose NOT to include in your prototype, and why?
    • Instructions: Please include instructions for using your prototype in detail. It should tell us what kind of actions should be done to proceed with each task.
    • Please make sure that the prototype you submit for photos and videos is in English. You may test the prototype in other languages closer to your target users (e.g., Korean, Urdu) for the observations.
  • 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 the limits of the paper format.

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? (i.e., the task should describe what the user does, not what the system does)
  • Prototype (40%)
    • Good usability? (e.g., learnable? efficient? safe?)
    • Design choices are justified?
    • Design choices mention what’s not selected by the team?
    • The prototype captures the three tasks?
    • The prototype is complete in that it supports an end-to-end scenario?
    • Photos are added?
    • Photos showcase the flow of all three tasks?
    • Video of the prototype usage is included and is clearly understandable?
    • Instructions for using the prototype are clear?
    • The prototype is clearly readable and visually understandable?
  • Observations (25%)
    • Participant information provided with clarity?
    • 10+ issues 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 8 minutes, with 10 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:29pm on Thursday 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 in KLMS.