Bookmate | IEP Collect | Memorable | Serendipity |
James Fogarty | Daniel Epstein | King Xia |
Instructor | Teaching Assistant | Teaching Assistant |
Contact: cse441-instr [at] cs.washington.edu
Class Times & Location: Tuesdays and Thursday, 10:00-11:50am, MGH 284
Individual Project Group Meetings: To be scheduled, primarily during Thursday class time.
Office Hours: Check the calendar. Scheduled Wednesdays 10:30-11:30am, CSE 666. Other meetings by appointment.
Students will work in groups of three or four on a single project that parallels the experience of delivering a high-fidelity interactive prototype within a company or with a customer.
Students are expected to already possess knowledge of appropriate HCI methods, and will focus on independently applying those methods in their work. There will therefore be little or no lecture material in this course. Course staff will instead work closely with students to critique and advise on their group project.
Prerequisite: CSE 440 or instructor’s permission.
Students will propose, design, and develop a high-fidelity interactive prototype. The definition of “high-fidelity interactive prototype” will be negotiated with each group according to the nature of their project. For example, a group delivering a mobile application or website will be expected to provide a complete interactive experience. But the prototype of that experience might be unlikely to scale in a large deployment, or might be limited in some other regard.
Project process will include:
It is appropriate, but not required, to choose to pitch proposals based on prior CSE 440 projects:
We welcome proposals based on any idea that has previously been explored and developed at a similar level of depth. But the demands of this course are too high for starting from scratch. You need an initial high-quality understanding of your problem and directions for your design.
The overall structure of the course is intended to facilitate rapid feedback on project progress:
Pitches will be presented in class on Tuesday, April 7. Each pitch should last 3 to 5 minutes. We will then have time for questions and discussion, before moving to the next pitch. After all pitches are presented, we will have free time for talking with classmates before bidding.
An effective pitch will address these points:
What is the problem?
What is the pain point you want to solve, or the new capability you want to enable.
What existing understanding of the problem has been developed?
This might be research you have done, it might be research prior students did, or it might be something you read. We are open to whatever background informs your pitch. Convey that you understand the problem well enough to create an effective design.
What is the unique design insight?
Given that existing understanding, what design insight makes this project compelling. Many problems have some familiar design solution available. Convey why this project will be fun and different in the context of this course.
What is the interesting interactive question?
Some projects are interesting, but primarily due to backend implementation challenges. Such a project is unlikely to surface compelling interactive questions in the context of this course. Convey why this project is a good fit for an HCI capstone.
What might the group plan to accomplish?
Given the above, what might a group plan to do in the context of this project?
If students choose to work on this project, they will need to define three milestones.
Convey initial thoughts on appropriate milestones that will allow a group to quickly get started
and ultimately make this an interesting and tractable project.
What might a group explicit decide to omit?
This class is about a high-fidelity prototype, not a full product launch. This class also happens on a very aggressive timeline. Given that, what aspects of the problem might a group choose to mock or otherwise omit from their prototype? For some projects, this might be a large piece of the overall vision. For other project, a full implementation might be easily in-scope. Either is potentially appropriate, but convey explicit thoughts regarding this.
For ease of in-class coordination, submit your presentation materials here:
https://catalyst.uw.edu/collectit/dropbox/jaf1978/35293
Bids will be collected in-class at the end of Tuesday, April 7. We expect to form teams the same day, or possibly on Wednesday April 8.
We ask that students be highly response to email in this time, for the sake of resolving any questions.
Proposals will be presented in class on Tuesday, April 14. Proposals should last 5 to 10 minutes. We will then have time for questions and discussion, before moving to the next proposal. This is the final opportunity for feedback before your written proposal. You plans should therefore be detailed enough for the staff and your classmates to understand your proposed project.
It is understood that later elements of your project may change in response to knowledge gained or barriers encountered in the early elements of your project. But you should put forward a concrete proposal against which any later revisions can be compared.
An effective presentation will address these points:
A project name.
A short, creative, and marketable title capturing the key idea. Projects that build upon a prior student project should seriously consider changing the name. It will of course be necessary to give appropriate attribution to the prior work but changing the name will also help in making a clear separation between the different project efforts.
What is the project?
Your pitch presented:
Now that you have assembled as a team, present a compact project description based on these points. Although your classmates already have some familiarity with your project, imagine presenting to a new audience.
Your overall goal is to effectively motivate:
What are your deliverables?
Describe what you will produce in the course of your project that will correspond to your efforts and results. Note that this includes more than just your final code. Your CSE 440 project deliverables included your contextual inquiries, your tasks, your design explorations, your paper prototypes, your usability testing, and your digital mockup.
By exclusion, you are also drawing bounds around what you will not aim to accomplish. Be appropriately explicit in this regard.
What are your milestones?
You will give milestone presentations to the class on April 28, May 12, and May 26.
Break your deliverables into a set of milestones, based on the course calendar. Describe how we will know you are making progress and on track in your project.
What are your success criteria, major risks, and risk mitigation plans?
Given the above, discuss how you will consider your project a success. Discuss any major risks in the project, and what you have done or will do to mitigate those risks.
For ease of in-class coordination, submit your presentation materials here:
https://catalyst.uw.edu/collectit/dropbox/jaf1978/35293
You will maintain a project website over the course of the quarter. This is where you will post all your project notebook and all of your project materials. We have created a placeholder project directory. By end-of-day Tuesday, submit a pull request that replaces the placeholder with a minimal project website.
For some examples of these sites, see those from prior offerings of CSE 477:
http://abstract.cs.washington.edu/~shwetak/classes/cse477/?Project_Pages
Based on the content of your proposal presentation and any feedback received, prepare a 1-page proposal document. This document should address the same points as your proposal presentation. It should be written so that a person unfamiliar with your project and this class can understand the proposal.
Post the proposal document to your project website.
Stand ups are an informal update to the class. They are intended to facilitate awareness within the class and support feedback to keep your project progressing. These do not need to be structured as a formal presentation.
Structure your update as a 3x3:
These are intended to support conversations, ideas, and feedback from the larger group. After each group updates, you will have the remainder of class for meeting with your group, seeking additional feedback from the staff, or following up on any points that were raised during the updates.
Milestone update presentations are a check on the trajectory of your project. They should convey the state of your project and your plans for the remainder of the quarter. This includes the same information as in your stand ups, but also higher-level reflection and planning. Presentation should last 5 to 10 minutes.
Structure your presentation to include:
For ease of in-class coordination, submit your presentation materials here:
https://catalyst.uw.edu/collectit/dropbox/jaf1978/35293
Prior presentations have focused on defining a project plan and receiving in-progress feedback. It is equally important to be able to effectively convey your design, the rationale behind it, alternatives considered, and the basis for your decisions.
Imagine you are presenting to somebody empowered to approve your project for more resources (e.g., a manager, a funder). They are motivated to understand and consider your design, but have not been involved in your work to date. Structure your presentation around effectively convincing your audience that your design is promising. This likely includes conveying:
Your process has included a variety of methods, but method is not the point here. Method is a powerful tool, but results and insight ultimately sell your design. So aim to use your process as support for your insight and your design, but remember you are selling the design itself.
You will present this content in three forms. The overall goal of these different presentation forms is the same. Your message will be therefore be largely the same, but delivered in a different format.
Presentation
Poster
Report
For ease of coordination, submit your presentation, poster, and report here:
https://catalyst.uw.edu/collectit/dropbox/jaf1978/35293
Grading will be based on the project process and individual contributions to that process:
These three criteria will be weighted approximately equally.
Your grade will thus reflect project work as evaluated by the staff, fellow students, and any mentor. Feedback will be provided throughout the class, such that groups and individuals understand their performance. If any problems emerge with group dynamics, it is the student responsibility to notify staff as soon as possible.
This course website is a GitHub Repository.
You can submit pull requests to update this website, including publishing your project websites.
We have provided instructions for how to contribute.