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. A widely used tool for digital prototyping is Figma, but if you are more familiar with a different digital prototyping tool you should check with the course staff to see if it’s okay to use that instead. See Figma tutorials here and here.

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.

Note: In our feedback, we have strongly encouraged you to narrow down the scope of the idea and focus on the core social computing aspect of the idea. Supporting three tasks should also be thought as a way to focus, not diverge. You should define concrete tasks that are connected to the core idea, not three completely disjoint tasks that make it work like three separate systems.

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. You should use a think-aloud protocol to test your prototypes. See a basic guide to think-aloud protocols here, and examples here and here.

You will 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.

Your Report

Your report should include:

  • Problem Statement: Re-state the problem you’re tackling in your project. Based on what you’ve learned so far, you can revise your problem statement.
  • Tasks (3): List the three (or more) core tasks you’ve decided to support in your prototype. Again, you can reuse or improve what you had earlier.
    • Describe the tasks clearly from the user’s perspective.
  • Prototype:
    • A concise summary description of your tool and a brief justification of how this tool will help users with the problem you described above. (No more than 1 paragraph)
    • Link to your prototype: 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 from User-testing: 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.

Grading

  • Problem Statement (5%)
    • Problem statement is clearly written?
    • Lists a problem not a solution?
  • Task Descriptions (15%)
    • Tasks align with the problem statement?
    • 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%)
    • 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 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 (20%)
    • Participant information for 3 or more participants provided with clarity?
    • 10+ observations submitted?
    • The usability issues are described concretely and clearly?
    • Organized by high-level task or theme?
    • Level of criticality included?
    • Plan for improvements is reasonable and sound?
  • Studio Presentation (10%)
    • Preparation and organization?
    • Articulation and clear delivery?
    • Effective use of visual aids?
    • Time management?
  • Team Feedback Form (10%) – Graded for each team member separately.
    • Complete and submitted on time.

Deliverables

Studio Presentation: In studio, your team will present your low fidelity prototype for 7 minutes, with 10 minutes for Q&A and feedback. The format of this presentation is more flexible – there will not be a Google Slides template – but you will probably be presenting directly from Figma with some additional explanation. Every team member needs to participate in the presentation.

Team Report: One report per team, which will be due the day after the studio by 11:59PM. Your report should be submitted as a zip file. The main report should be written in Markdown (please use the .md extension). Any images accompanying your report should be scanned in png or jpg, and need to be in a directory called images. We’re going to publish your reports on the course website. Submit a .zip file containing your markdown file and image folder to this form. Please double check to make sure that everything is included in your submission!

Peer and Self Feedback Form: Each person needs to individually submit the peer and self feedback form. This will be emailed to you separately shortly before the studio. This is mandatory for all team members, and is 10% of each team member’s grade for this DPM. This form should only take about ten minutes to complete. Note that you are not grading your teammates directly – you are just helping the course staff understand if there are any team issues that need to be addressed.