Final Project

You'll DESIGN, BUILD, and TEST your own crowdsourcing system.

Tips & Info

What do I do?

This is a team-based, semester-long design project, in which you'll create an original crowdsourcing application on your own. You'll work in teams of 3-4 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-4): 0%
  • Idea (week 4): 10%
  • Story (week 6): 10%
  • Pitch (week 8): 20%
  • Prototype 1 (week 10): 10%
  • Prototype 2 (week 13): 10%
  • Final presentation (week 15): 20%
  • Final paper (week 16): 20%
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 crowdsourcing, 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 CROWD, which means you cannot use paid crowds (e.g., MTurk, Upwork).
  • Your project should include some quality control or aggregation component.
  • Your project should have some user interface. I'm expecting most projects to be a novel crowdsourcing 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.
  • Connecting to your own research is encouraged, but please make sure to talk to us early about how to make it happen.

How do I 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.

Team Formation

Milestone 0: Team Formation

Due: 11:59pm on 9/23 (Fri)

What do I do?

You'll need to find teammates to work on an exciting crowdsourcing project this semester. Each team should have 3-4 people.

How do I find teammates?

Here are three methods we provide:

  • You can use Piazza to post advertisements for finding teammates.
  • We'll give 5 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 crowd, in terms of skillset, interest, and background.

How do I submit?

Please email the course staff (me and TA) with a list of your team members, including name, student ID, and email.

Ideas

Milestone 1: Problem Identification and Ideas

Due: 11:59pm on 10/5 (Wed)

What do I do?

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

Dimensions

As we did in Assignment #2, We'll use the following seven dimensions, which were top-rated in our own crowdsourcing effort to rank the dimensions that matter the most in analyzing a crowdsourcing system.
  • Motivation - why would a crowd worker do this?
  • Aggregation - how are results from multiple workers combined?
  • Crowd pool - you are required to use a VOLUNTARY OR INTRINSICALLY MOTIVATED CROWD, but please be more specific.
  • Quality control - how to ensure valid results?
  • Human skill - what kind of human skill is required to complete a task?
  • Process order - in what order is the work processed between computer, worker, and requester?
  • Goal visibility - how much of the overall goal of the system is visible to an individual crowd worker?

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 we 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). (one paragraph maximum)
  3. Why use crowdsourcing for the problem? Why not use machines or a small group of experts?
  4. For the identified problem, discuss with your teammates what specific challenges exist. State these challenges as "How might we..." questions. For example, for the ESP game, questions might include "How might we make the game fun so that people play multiple sessions?", "How might we ensure that there is always a partner for any player at any given time?", and "How might we encourage players to type in accurate labels?". List at least 10 "How might we..." questions for your problem based on the team brainstorming.
    NOTE: Refer to Stanford's d.school guide on "How might we" questions.
  5. In your team, discuss how you might address these questions with crowdsourcing. Then pick the three most promising solutions overall. These solutions need to be rough and diverse at this point. For each idea, answer the following:
    • What is the one-sentence summary of the idea?
    • Describe a scenario from the requester's point of view. Think how an imaginary requester might use the system. How do they create a task? How do they review results and successfully end the task?
      NOTE: "A scenario is a concrete, realistic story that sets up a situation involving a user with a goal to satisfy, and then follows the user through the tasks they do to satisfy that goal." (from MIT's 6.813 description)
    • Describe a scenario from the worker's point of view. Think how an imaginary crowd worker might use the system. How do they come into the system? What is the task experience like? What motivates them to keep contributing?
      NOTE: You can merge the earlier question and this one if you want to design an organic workflow, in which there's no clear distinction between requesters and workers.
    • Analyze the idea using the seven dimensions above. Make sure your team's three ideas have clear differences in some dimensions.

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

Story

Milestone 2: Tasks, Sketches, and Video

Due: 11:59pm on 10/13 (Thu)

What do I do?

Your team will now further develop the ideas that you came up with in Milestone #1. You'll create three types of artifacts that will capture your design process. Please follow the order presented below.

  • Tasks: Based on the three solution ideas your team came up with, brainstorm three major tasks your solution wants to support. Tasks represent what the user (crowd workers or requesters) wants to achieve, rather than specific system features or UI elements. For each task, list three requirements or design goals that a solution should support. Some tips:
    • Make sure the three tasks are distinct from one another and cover different levels of complexity.
    • Be specific, and include details and context. "The user wants to learn math." is way too broad. Think about a particular user with their likely demographic, constraints, and motivation: "Seung Hyun, a 20-year old college student, wants to learn Chinese in his spare time. While he doesn't have time to take classes or get a private tutor, he wants to use his commute time to learn useful words and phrases."
  • Sketches: For each of the three tasks you identified, turn them into storyboard sketches. The storyboard should walk through a concrete scenario and a task, and again, shouldn't be about specific system features or UI elements. Of course you'll need to describe the solution, but focus on the concept and context, rather than pretty UIs or sophisticated system features. Some tips:
    • Before you jump to your sketch, watch the first 6 minutes of this video by Scott Klemmer, talking about storyboards. Optionally, you can also read this paper on storyboarding.
    • Here are some examples.
    • Make sure to use a thick pen in your final version so that sketches are visible when digitally scanned. But it's a good idea to use a pencil in your first draft.
    • When brainstorming what solution to include for each story, go back to the three solution ideas from Milestone #1. Join forces and think about what best elements to combine and keep, while removing some of the less promising ideas.
  • Video: Now turn your three storyboards into a concept video that illustrates the three tasks. Some tips:
    • You need to set the stage: Start with a user and their context and problem. Do not show the UI sketches from the beginning.
    • You can include rough UI sketches to demonstrate how the user might perform the task using your system, but they need to be rough and in low fidelity.
    • Some examples here.

Your report

Your report should include the three components: storyboard sketches, a concept video, and an abstract.

  • Tasks: Description of three tasks, each about a paragraph long. For each task, include three requirements or design goals, and explain why they matter.
  • Sketches: Three storyboards, hand-drawn.
  • Video: A video clip, maximum three minutes long.

How do I submit?

One report per team. Your report should be submitted as a zip file.

  • Tasks: In Markdown (please use the .md extension)
  • Sketches: Scan in png or jpg. Images need to be in a directory called images.
  • Video (guidelines adopted from CHI 2017 Video Showcase)
    • 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 abstract document. Also upload the original mp4 file on KLMS.
    • 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.
We're going to publish your reports on the course website. Submit your team's report on KLMS.

Pitch

Milestone 3: Pitch

Due: in class (1:30-3:30pm) on 10/20 (Thu)

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 10 minutes to do the following:

  • Motivate the problem
  • Present the identified tasks and explain why they matter
  • 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 to use and test your system?

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

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

Grading

Here's how your pitches will be graded.

  • 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.
  • Articulation (10%): Delivery and clarity of the presentation.
  • Visual aids (10%): Design and readability of the slides, use of effective visual aids and examples.
  • Overall (10%): How engaging was the overall talk?

Your report

You'll present in class and submit your slides after the class.

How do I submit?

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

Low-Fi Prototype

Milestone 4: Low-Fi Prototype

Due: 11:59pm on 11/10 (Thu)

What do I do?

Now you have a clear idea and concrete tasks and scenarios to support in your crowdsourcing application. Let's start prototyping the idea!

Before making something that's fully functional with a server backend and a visually pleasing interface, it's more important to first "implement" the tasks and scenarios into a prototype.

Rather than use HTML and Javascript, you'll first use a prototyping tool to implement the tasks and scenarios. Specifically, we recommend Marvel, InVision, or proto.io. You can also choose any prototyping tool of your choice.

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 UI and the crowd workflow rather than the underlying implementation.

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 core tasks (one to three, at least two recommended) you've decided to support in your application. Again, you can make improvements from the initial report.
  • 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. Later, peer students will actually use this prototype to give you feedback.
  • User feedback: Show your prototype to THREE people (hopefully target users) outside your team. Ask them to think aloud. Write down any usability issues and comments. List at least 10 distinct comments you received in your report. Your submitted prototype doesn't need to reflect these comments, although we encourage you to make these changes for your next iteration.

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). Submit using KLMS.

Mid-Fi Prototype

Milestone 5: Mid-Fi Prototype

Due: 11:59pm on 11/22 (Tue)

What do I do?

Finally, the tasks and scenarios you want to support need to be available in an interactive prototype.

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 UI and the crowd workflow rather than the underlying implementation.

Your report

Your report should include:

  • Instruction: Include any information for someone who doesn't know about the project to be able to try the prototype and offer feedback (e.g., what tasks to try, what's working and not working now).
  • Prototype: It should be either (1) a URL to your prototype, or (2) files (e.g., HTML, CSS, Javascript) that can be run locally.

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.

Hi-Fi Prototype

Milestone 6: Hi-Fi Prototype

Due: 11:59pm on 12/6 (Tue)

What do I do?

Now you're finally building a fully functional prototype, with live user interactions. Please make sure users can complete the tasks you initially outlined in the earlier milestones.

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 information will also go into the project gallery.
  • Instruction: Give a quick tour of the interface, and also show off some of the highlights of the interface.
  • Technical Description: What frameworks / libraries / technical stack have been used for both the frontend and the backend.
  • Prototype URL: A link pointing to your prototype, where the system can be tested live.
  • Prototype Code: A link to a Github repo.

How do I submit?

One report per team. Your report should be submitted as Markdown (please use the .md extension). Submit using KLMS.

Final Presentation

Milestone 7: Final Presentation

Due: in class (1:30-3:30pm) on 12/15 (Thu)

What do I do?

Now that have an awesome prototype that should be getting a lot of excitement from your crowds, it's time to tell us about what you built and what you learned from having real crowds use the system.

You'll have 10 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 move parts.
  • Show us how your deployment went. How many users did you attract? What are some collected results suggesting that your application serves the task well? What did you learn from talking to users?
  • Limitations, implications, and possible improvements.

After the presentation, you'll have three minutes for Q and A.

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

Grading

Here's how your pitches will be graded.

  • Organization (10%): Overall structure and flow of the presentation.
  • Problem (10%): Well defined? Is it a real problem? What's the evidence?
  • Solution (20%): Does the application deliver its initial promises? Is it novel? Feasible? Quality control / aggregation / motivation... well thought out?
  • Results (20%): What did you learn from the deployment? What are the qualitative and quantitative results from users?
  • Discussion (10%): Depth of disccusing limitations, implications, and possible improvements.
  • Articulation (10%): Delivery and clarity of the presentation.
  • Visual aids (10%): Design and readability of the slides, use of effective visual aids and examples.
  • Overall (10%): How engaging was the overall talk?

Your report

You'll present in class and submit your slides after the class.

How do I submit?

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

Final Report

Milestone 8: Final Report

Due: 11:59pm on 12/22 (Thu)

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 write it all up! You've already read and written responses to 30+ crowdsourcing papers, so let's write one on your project.

Suggested Outline

Find a model paper that your team really likes or is inspired by, and use it as a template. Here's a suggested outline:

  • Abstract: One paragraph summary of the project. This is the most important part of the paper. After reading it, a reader should understand the problem you're tacking, the approach you're taking, and the results of your evaluation.
  • Introduction: What is the state of the world? What's the burning problem? What's your solution? What's the summary of results?
  • Background and Related Work: What backgrond knowledge do you want your readers to have to better understand your motivation? What existing techniques or ideas are you inspired by? How does your approach differ from them?
  • System: What are the major tasks you're supporting, and how does your system support them? Report on the unique aspect of the interface and the crowdsourcing techniques. Include screenshots of important interactions.
  • Evaluation: How did your deployment go? Report the number of users, results, analysis, etc. Use visual aids to communicate the results effectively. NOTE: Please do not include results generated by your own team!!
  • Discussion: What lessons did you learn? Specifically, discuss what you learned about designing a system for a VOLUNTARY OR INTRINSICALLY MOTIVATED CROWD. Also discuss limitations, design implications, and possible improvements.
  • Conclusion: Not necessary.
  • References: List of references.

Grading

Here's how your paper will be graded.

  • Idea (20%): Motivation, problem identification, and approach are clearly and convincingly presented.
  • Background / Related Work (10%): Covers relevant background information and research.
  • Execution (20%): The system delivers its initial promises. It's technically strong and robust, and involves crowdsourcing in a non-trivial manner.
  • Evidence (20%): The evaluation is complete, and shows if and how the system worked as expected. Results are presented in an academically sound manner.
  • Discussion (20%): Discussion touches upon important design dimensions and shows reflective thinking.
  • Presentation (10%): It is overall well-written. Images, tables, and charts effectively communicating the message.

Your report

You need to submit a maximum 4-page paper in the CHI Proceedings Format.

How do I submit?

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

Extra Credit #1: Cool Video

Up to +10% on the final report

Video is a great way to demonstrate the awesomeness of your application. Follow the guidelines from the concept video to create an updated version of your video, which should feature the final interface design. Add the video link in your final report.

Extra Credit #2: Best Crowdsourcer

Up to +10% on the final report

A group that recruits the most active crowd deserves some credit! We'll reward one group 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 and explain why they deserve the "Best Crowdsourcer" title.