Design Project

What do we do?

This is a team-based, semester-long design project, in which you'll create an original social computing application on your own. You'll work in teams of four people. More information about each milestone will be added to this page. Here is the timeline and grading weights for each milestone:

• Team Formation (week 3): 0%
• Ideation (week 5): 20%
• Pitch (week 6): 15%
• Low-fi Prototype (week 7): 15%
• High-fi Prototype (week 12): 15%
• Final Presentation (week 15): 10%
• Final Paper & Video (week 16): 25%

Please note that all team members will receive the same grade for all the milestones.

Why do this?

Now that you've mastered the arts and skills of social computing, it's important that you apply what you learned to a problem you deeply care about. It's a great way to learn further, and potentially make impact.

Does my project idea qualify?

Projects are open-ended, so please be creative. But here are some requirements:

• Your project should involve a VOLUNTARY OR INTRINSICALLY MOTIVATED USERS, which means you cannot use paid crowds (e.g., MTurk, Upwork).
• Your project should have some user interface. I'm expecting most projects to be a novel crowdsourcing and social computing system that can be tested by others (e.g., a prototype website or a mobile app). Data mining or analysis focused projects are okay, but there needs to be some visualization or analytics dashboard component that is accessible by others to understand your results.
• Your prototype doesn't need to be a fully implemented platform, menaing that it needs to focus on the core crowdsourcing / social computing concept you're introducing, rather than to build all the database backend, login, etc.
• Connecting to your own research is encouraged, but please make sure to talk to course staff early about how to make it happen.

Examples

Here are the project gallery pages from the previous years:

• 2016
• 2017
• 2018
• 2019
• 2020
• 2020

How do we submit?

We'll create an assignment in KLMS for each milestone.

Late Policy

For each milestone deadline, all members of your team will lose 10% for each late day. Submissions will be accepted until three days after the deadline. After then you'll get 0 on that assignment. Please note that late submissions for midterm and final presentations are not allowed.

Milestone 0: Team Formation

Due: 11:59pm on 9/13 (Wed)

What do I do?

You'll need to find teammates to work on an exciting project this semester. Each team should have three people by default. There may need to be a small number of four-person teams.

How do I find teammates?

Here are three methods you can use:

• You can use Classum to post advertisements for finding teammates. Please use the "Team Formation" category when posting.
• We'll give 10 minutes at the end of two classes for in-person team formation.
• Use office hours to talk to us about project ideas so that we can make connections, and you can also run into other classmates.

Please try to have diversity in your own team: skillset, interest, and background.

How do I submit?

Please fill out the design project sign-up form.

Milestone 1: Ideation

What do we do?

In a team, you'll identify a problem that you'd like to tackle with your project, and brainstorm approaches to solving the problem.

Your report

In your report, please answer the following questions:

1. What is the problem your team is trying to solve? (one sentence)
   
   
2. How do you know this problem exists? Why is this problem important? Include both (1) external references (e.g., academic papers, news articles, or published surveys), as well as (2) internal investigation (e.g., results from making observations, personal experiences, or interviews with target requesters or workers). (maximum one paragraph)
   
   
3. Why use social computing for the problem? Why not use machines or individual experts? (maximum one paragraph)
   
   
4. How Might We (HMW) Questions: For the identified problem, discuss with your teammates what specific challenges exist. State these challenges as "How might we..." (HMW) questions. HMW questions serve as a bridge between the identified problem and solution ideas. They are short questions that should be broad enough to allow for open ideas yet narrow enough to set meaningful boundaries. Report at least 10 HMW questions for your team's problem, and pick top 3 HMW questions. The Design Thinking Bootcamp Bootleg by Stanford d.school (CC BY-NC-SA 3.0) should be a useful resource. For HMW questions, look at page 26.
   
   
5. Solution Ideas: Solution ideas are your attempts at solving the HMW questions. Report at least 5 solution ideas per each of the top 3 HMW questions, and pick top 3 solution ideas overall. Note that these 3 ideas should be distinct from one another, covering a wide solution space. The best ideas don't necessarily have to represent each HMW; multiple ideas can belong to a single HMW.
   
   
6. Storyboards: Create 3 storyboard sketches, one for each of the top 3 solution ideas. A storyboard is a set of comic-strip-like drawings that visually walks through a concrete scenario and a task that your persona experiences. Show the challenge the persona encounters, what environment the persona is surrounded by, what motivates the persona to use the solution idea you're suggesting, and how your solution idea actually addresses the challenge. The storyboard shouldn't be about specific system features or UI elements. You don't even need to show the detailed screen layout of your UI at this point. Focus on the concept and context, rather than pretty UIs or sophisticated system features.
   
   Make sure to hand-draw your storyboards, with a thick pen so that sketches are visible when digitally scanned and excessive details are not included. Using a pencil or a thin ball-point pen is not allowed. Here are some good examples (Verbivore and Let's Read), except for the fact that some of them are not drawn with a thick pen. Also, Amal Dar Aziz's guide to storyboarding is a highly recommended resource.

Your Report

• Final Team Name
• Problem statement
• Problem background
• Motivation (Why social computing?)
• HMW questions (at least 10)
• Top 3 HMW questions
• Solution ideas for your HMW questions (at least 5 x 3 HMWs)
• Top 3 solution ideas
• Storyboards (3)

Grading

• Problem (10%)
  • Clearly presented in a sentence?
  • Unique?
  • Non-trivial?
• Problem Background (15%)
  • Clearly presented in a paragraph?
  • Convincing evidence or references presented?
  • Importance of the problem highlighted?
• Motivation (15%)
  • Clearly presented in a paragraph?
  • Suitable for social computing?
  • Convincing reasons for using social computing presented?
• HMW (10%)
  • 10+ HMWs submitted?
  • Scope not too broad or narrow?
  • Distinct, broad, and creative?
  • Selection process clearly described?
• Solution Ideas (20%)
  • 5+ solution ideas submitted for each HMW?
  • Distinct, broad, and creative?
  • Selection process clearly described?
• Storyboards (30%)
  • 3 storyboards submitted?
  • Flow easy to follow and understand?
  • Easy to read (thick pen used)?
  • Not solution-driven but user- and scenario-driven?

How do we submit?

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). Storyboards 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 your team's report on KLMS.

Milestone 2: Pitch

What do I do?

Now that you've identified an interesting problem, a set of concrete tasks you want to support, and a set of possible solutions, it's time to turn these into a convincing pitch!

You'll have 5 minutes to do the following:

• Motivate the problem. Present convincing references and evidence.
• Present the identified tasks and explain why they matter. The tasks are what you identified in Milestone 1 as you made storyboards. Please feel free to revise your original tasks as your idea develops.
• State what your proposed solution is, and why it'll be able to solve the problem and support the tasks well.
• Share your plan: (1) In your team, who'll be responsible for what? (2) How will you find the crowd or users to use and test your system?

After the pitch, you'll have 2 minutes for Q and A.

Note #1: We'll enforce a strict 5-minute time limit by cutting off the presentation. Please plan and rehearse.

Note #2: Note that all team members should present at least once between the pitch and the final presentation. This means if your team decides to have only some members present in the pitch, the remaining members should definitely present in the final presentation.

Grading

• Organization (10%): Overall structure and flow of the presentation.
• Problem (20%): Well defined? Is it a real problem? What's the evidence?
• Solution (30%): Novel? Feasible? Quality control / aggregation / motivation... thought out?
• Plan (10%): Who does what and deployment plan.
• Visual aids (10%): Design and readability of the slides, use of effective visual aids and examples.
• Overall (20%): Delivery and clarity of the presentation. How engaging was the overall talk? Handling Q&A went smoothly?

Your report

You'll present in class and submit your slides after the class, which are due 11:59pm on the day of presentation.

How do I submit?

Your team's slides should be submitted as a PDF file, via KLMS.

Milestone 3: Low-Fi Prototype

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 first use a prototyping tool to implement the tasks and scenarios. Specifically, we recommend Figma, Marvel, InVision, or proto.io. You can also choose any prototyping tool of your choice.

Functionality does not need to be fully implemented. Please use hard-coded but realistic data 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: During the feedback meeting, we 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.

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: List the three core tasks you've decided to support in your prototype. Again, you can reuse or improve what you had earlier.
• 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?
  • 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.

Grading

• Problem Statement (5%)
  • Problem statement is clearly written?
  • Lists a problem not a solution?
  Tasks (15%)
  • Good usability? (e.g., learnable? efficient? safe?)
  • 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 (50%)
  • 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 (30%)
  • 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?

How do I submit?

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). We're going to publish your reports on the course website. Submit using KLMS.

Milestone 4: High-Fi Prototype

What do I do?

Now's the time for a fully functional and interactive prototype that is ready to be tested by your target users. You need to build a prototype that supports end-to-end scenarios captured in your earlier prototypes. 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. You may choose to reuse or revise the tasks and the UI you created in earlier stages. Make sure your tasks are centered around novel social interaction you intend to support. Other features (e.g., detailed my page design, complex login management) can be hard-coded or fed with fake data.

Your report

Your report should include:

• Project Summary (maximum three sentences): (1) the problem you're addressing, (2) what your solution is, (3) what unique approach you're taking in your solution (how it's different from other similar solutions). This summary will be used as a blurb on the project gallery.
• Instruction: Give a quick tour of the interface, and also show off some of the highlights of the interface. Note that this should not cover all features you have; focus on the most exciting and important parts. Use screenshots and callouts.
• URL of your prototype: A live version of the prototype for evalation. Note: the URL must work at least until your assignment is graded. Course staff will run your prototype to do a heuristic evaluation for grading. If the link doesn't work, your team will be penalized. If there are specific requirements (e.g., browser or device settings), include them as well.
• URL of your Git repository: Make sure to add a README file that briefly describes the code, e.g., main JavaScript file, or where main feature implementations are, etc. Several lines are enough.
• Libraries and frameworks: List any external dependencies you used for your implementation (e.g., Bootstrap, Semantic UI, etc.).
• Individual Reflections: Each member should write this part on their own, reflecting on their own experience. Merge all members' mini-reports in the final report. Answer the following questions:
  • Which part of the system did you directly contribute to?
  • What were some of the difficulties you faced?
  • List one useful skill you learned while working on the high-fi prototype.

Grading

• Project Summary (10%)
  • Clear description of the problem?
  • Clear description of the solution?
  • Clear description of the approach?
• Instruction (20%)
  • Screenshots are added?
  • Is the instruction clear and easy-to-follow?
  • Screenshots capture representative features of the prototype?
• Prototype (40%)
  • The prototype is complete in that it supports an end-to-end scenario?
  • Heuristic evaluation results: how usable is it?
• Implementation Notes (15%)
  • Prototype URL is accessible and works properly?
  • Repository URL is accessible and contains README?
  • Libraries and frameworks used are listed?
• Individual Reflections (15%) -- graded individually
  • Individual contribution clearly specified?
  • Difficulty discussion has enough depth and insight?
  • Non-trivial implementation skill added?

How do I submit?

One report per team. Your report should be submitted as a zip file. The instructions should be written in Markdown (please use the .md extension). Submit using KLMS.

Milestone 5: Project Showcase

What do I do?

Now that you have an awesome prototype that is (hopefully) getting a lot of excitement from your users, it's time to tell us about what you built and what you learned from having real users use the system. In the project showcase session, each team will give a 7-minute presentation of their project and do a live demo + interactive Q&A.

Part 1. Presentation:

You'll have 7 minutes to do the following:

• Motivate the problem.
• List the main tasks you're trying to support.
• What is your solution? How is it different from existing systems? Why is it better?
• Walk through your interface. You can use video or screenshots, or even do a live demo. But be careful with live demos, because they require a lot of practice and include many moving parts.
• Show us how your deployment went. How many users did you attract? What are some exciting results that suggest your application served the tasks well? What did you learn from designing social interactions?
• Limitations, implications, and possible improvements.

Note #1: We'll enforce a strict 7-minute time limit by cutting off the presentation. Please plan and rehearse.

Note #2: Note that all team members should present at least once between the pitch and the final presentation. This means if your team had only some members present for the pitch, the remaining members should definitely present for the final presentation.

After the pitch, you'll have two minutes for Q and A.

Part 2. Demo: After the presentations, each team will be given 30 minutes to show an interactive demo. In your assigned table, be ready to show a demo of your working prototype to the class. People will freely walk by the tables and try any demo they would like.

After the pitches and the demo session, we'll hand out a few awards based on different categories, such as "most human-centered", "best prototype", and "people's choice".

Grading

• Problem (10%): Well defined? Is it a real problem? What's the evidence?
• Solution (30%): Does the application deliver its initial promises? Is it novel? Feasible? Are important design factors such as quality control, social interaction, aggregation, motivation, etc. well thought out?
• Results (30%): What did you learn from the deployment? What are the qualitative and quantitative results from users? Insightful lessons?
• Discussion (10%): Depth in discussion of limitations, implications, and possible improvements.
• Delivery (10%): Is it well-organized? Is the story clear? Flow and clarity of the presentation.
• Visual aids (10%): Design and readability of the slides, use of effective visual aids and examples.
• Demo: Is the demo working well, engaging, and are people able to try it out? Is it a well-designed system that supports or enables meaningful social interaction?

How do I submit?

Your team's slides should be submitted as a PDF file, via KLMS.

Milestone 6: Final Report

What do I do?

Now that you have deployed your system for a couple weeks, seen your crowd use the system, and collected useful data, it's time to wrap it all up! You'll write a short report and make an engaging video that showcases your system.

Report

• Representative screenshots: Include a few most important screenshots that showcase the uniqueness of your application. Add callouts, annotations, or captions.
• Quality arguments (max. 500 words): Make convincing arguments for what makes your interface "great" and why the expected social interaction is successfully supported. Add comments from users, UI screenshots, etc. that could support your arguments. Depending on your interface, you may focus on different aspects: neat features, visual design, usability, novel UI components you designed, hardcore implementation, etc. This is your chance to convince us that what you created is a high quality user interface.
• Evaluation (max. 500 words): How did your deployment go? Report the number of users, results, analysis, etc. Use visual aids (e.g., charts, tables, graphs) to effectively communicate the results. NOTE: Please do not include results generated by your own team!!
• Discussion (max. 500 words): Connect the lessons from the project to important aspects of social computing covered in class: incentives for participation, quality control, supporting social interaction (communication, collaboration, networking...), privacy, ethics, etc. What worked well and what didn't? Why? What would you have done differently?
• Individual reflection (max. 500 words per person): Each member should write this part on their own, reflecting on their personal experience. Merge all members' mini-reports in the final report. Please answer the following questions:
  • What part of the implementation did you contribute to? Be concrete and honest, please.
  • What worked well and not in your team? How did you overcome any hurdle in teamwork? What lesson about teamwork did you learn that you might apply to your next team project?
  • Through the team-based design project experience, what did you learn about social computing and web-based GUI implementation?

Video

Record a 2-minute video that captures the user context and the killer features of your UI. Be creative in how you plan, structure, and record the video! Check out last year's project gallery for inspiration. Revisit your storyboards, as they capture the rich usage context. You need to set the stage by starting with users and their problem. Avoid using slides and try to capture realistic context, and don't hesitate to "act". Do not show the UI from the beginning. You need to show parts of your final prototype to demonstrate how the user might perform the task using your system. Rather than describe all the features you implemented, focus on the flow of the task.

NOTE: Make sure to connect the user scenario and the solution. A common antipattern is to make the UI description too generic, not about solving the particular user problem captured earlier in the video.

Grading

Here's how your report will be graded.

Part 1: Report (10% toward your project grade)

• Quality Arguments (25%)
  • Convincing arguments with supporting evidence?
  • Is it overall a high quality interface? We will look at a variety of aspects such as completeness, novelty, feasibility, UI-level contribution, etc.
  • 500 words or less?
• Evaluation (25%)
  • The evaluation is complete and shows if and how the system worked as expected?
  • Results are reported and communicated clearly?
  • 500 words or less?
• Discussion (25%)
  • Discussion touches upon important aspects of social interaction supported by the team's application?
  • Discussion has enough depth and insight?
  • 500 words or less?
• Individual Reflections (25%) - graded individually
  • Individual contribution clearly specified?
  • Teamwork discussion includes both the good and the bad?
  • Teamwork discussion has enough depth and insight?
  • Design process discussion has enough depth and insight?
  • 500 words or less?

Part 2: Video (10% toward your project grade)

• 2 minutes or under?
• Overall organization and flow of the story?
• Quality and variety of shots and rhythm?
• User needs well captured?
• UI introduced convincingly but not as dry list of features?
• Engaging and creative?

Deliverables

• 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). Also include your original video MP4 file in the zip file as well. Submit via KLMS.
• Video: (guidelines adopted from CHI 2017 Video Showcase, which also has links to many inspiring videos)
  • Encoded as an MP4 using the H.264 codec. No exceptions!
  • You'll upload your video file on YouTube. Include the URL of your posted video in your final report.
  • All spoken dialog must be closed captioned (subtitled) to improve accessibility.
  • Resolution of at least 1280px x 720px.
  • The 16:9 aspect ratio is recommended.

Extra Credit #1: Cool Video

Up to +10% on the final milestone

We'll reward 1-2 teams with most engaging videos. We'll announce the winner(s) and explain why they deserve the "Cool Video" title.

Extra Credit #2: Best Crowdsourcer

Up to +10% on the final milestone

Teams that successfully engage active users deserve some credit! We'll reward 1-2 teams that most successfully showed the power of the crowd. This does not just mean the most number of users, but includes the overall participation, quality of data, and your analysis of the data. We'll announce the winner(s) and explain why they deserve the "Best Crowdsourcer" title.