GR1: Project Proposal and Analysis
Group signup due 11:59 pm on Tuesday, February 20, 2018. Each group should sign up once using this form. Students who are not registered for credit are not permitted to participate in the group project. Students in 6.831D (for PhDs) need to form groups amongst themselves, however students in 6.831M and 6.813 may form groups together.
Presentation & draft report due in studio on Friday, March 2, 2018.
Final report and self-assessment (one per group member) due 11:59 pm on Sunday, March 4, 2018.
The heart of this course is a semester-long project, in which you will design, implement, and evaluate a user interface in HTML/JS. User interface design is an iterative process, so you will build your UI not just once, but three times, as successively higher-fidelity and more complete prototypes. In order to have time for these iterations, you need to get started on the project as early as possible.
Each project group should consist of 4 people. If you need help finding group members, see the Search for Teammates post at the top of Piazza. You will attend studio with your group, and all of you should be available for the same session times.
For students in 6.831D only, each group should consist of 2-3 students. In addition to the project topics described below, you may choose to do a topic related to an outside research project, or novel HCI research topics.
Your group will be assigned a TA and studio session after the signup deadline. If you have questions before you have an assigned TA, please post on Piazza.
Choosing a Problem
For your project, you will choose a problem faced by some user population, and then design and implement a user interface to address that problem. Note that the problem should come first; try to avoid having preconceived notions about the solution until you've at least understood the problem.
You have a lot of freedom in choosing your problem topic. However, you will learn the most from this project if you stretch yourselves into unfamiliar areas of the design space. So we require that you design for somebody else. Choose a problem faced by a user population that nobody in your group belongs to. If you design for somebody much different from you, you will have to learn more about your users and their problems, you will have to challenge your assumptions, and you will have to be more creative in your designs. Examples include people with different roles (diving coaches, singers, mothers), different capabilities (children, elderly, people with disabilities), and different contexts (windsurfers, rock climbers, buskers). Note that your chosen user population must be reasonably available to you -- you will have to interview and observe them for this assignment, and you will have to do user testing with them later in the semester.
Examples of previous projects that looked at interesting user populations include ElderConnect (for older people), CheckIn (for parents and kids), VoiceComposer (for composers), Musical Sketches (for music students).
If you are concerned that your chosen population is not enough of a stretch, contact your TA or post on Piazza.
User Observation and Analysis
In order to refine your understanding of the problem you have chosen, you will interview at least three users in your target population who face the problem you are tackling. Observe them dealing with the problem in their real environment, and take notes about what you observe. Ask the participants to perform their tasks as realistically as possible, while talking to you about it as appropriate. Afterwards, spend 10 minutes interviewing each participant about the activity that you observed.
Using your observations, and the results of your interviews, you should then refine your problem statement, and analyze your problem, by identifying user classes and goals. A user class is a subset of the user population that may be expected to use the system in a different way. Note that a single user may fall into two classes, if they play distinct roles at different times. Be aware that generic terms such as 'power users' and 'novices' are not usually helpful. The goals should be high-level tasks that are associated with the problem. You should identify at least three goals; if you cannot, your problem may be too small to serve as a good project, and you should rethink it.
Signup form. A draft of your problem statement should be included in your signup form submission. You are expected to refine this over the course of the interviews, and to include a more polished version in your report.
Google Doc Project Report. You will be keeping track of your team's work in a google doc, which you will update with each group assignment. By the end of the semester, your google doc will constitute the final report for your project. A link to your doc is accessible from the course web page.
Create a project page with the following sections:
- Group members. A list of your group members. Students who are not registered for credit are not permitted to participate in the group project. All members of your group must be registered for the class by the time this assignment is due.
- Problem statement. Briefly state the problem(s) that your project will seek to solve. Take the user's point of view. Consider what the user's goals are, and what obstacles lie in the way. Do not talk about any solutions here.
Then under "GR1 Analysis" section, complete the following:
- Observations & Interviews. Give a narrative of the three people that you observed and interviewed. Don't use their names. Don't identify the users by name, but do describe who they were. Each narrative should include a particularly interesting moment -- a breakdown or workaround that exhibits a feature of the problem you're aiming to solve.
- User Classes. Describe the user classes that you have identified, and their major characteristics.
- Goals. Describe the goals that you have identified, with reference to the observations you made.
- Studio Reflection. Describe the feedback you got in your studio sessions, and how you will incorporate it into your project.
As a side note, in years past teams have created wiki pages so if you look through past projects, you will find these. We decided to migrate to a more modern documentation infrastructure this year and are henceforth using Google Docs.
Studio presentation. You must prepare a Google Slides slideshow to present this work in studio. Send the link to your mentor by 12pm (noon) on Friday. Here are some sample slides. Each member of the team should participate in the presentation. Take notes during the discussion of your presentation and put the important ones in your wiki.
Self-assessment form. Remember to complete your individual self-assessment forms in advance of the deadline. The checklist is very similar to the TAs' grading rubric, and is intended to help you make sure your submission is complete and on target.