Project Component II - User Requirements
Overview
You now have a project space, but exactly what are the problems/issues that people encounter in this context? And, how can technology help to address this problem?
This project component focuses on employing methods for understanding your potential users in the context of your project. You may choose any method from the methods discussed in class, such as contextual inquiry, surveys, interviews, focus groups, observations, etc. Usually, it is important to choose several appropriate methods that complement one another -- for example, interviews could be complemented with observation. As this is a class project you are only required to use one method. After collecting the data, you will analyze it to develop design requirements for your system that you will use in later components.
Your Mission
1. Conduct a user research method
Conduct a user research method. Select one user research method from the methods we covered in class (or if you know another method you would like to use - get it approved from the instructor). Justify your choice for the research method in terms of why it is appropriate for your context. Conduct the method with potential users and/or stakeholders. Make notes about your experience conducting the method: what are your users' problems, what is their context of use, what would they like to do, etc.? Consider issues of what the use context will be (e.g. typical situations). Summarize your method, and your findings.
You will receive extra credit if you conduct more than one method and describe how the method complements the first one you chose.
2. Define design requirements
As you collect your data, look at your data together with your teammates, and compile a list of requirements for your system. Order them in terms of importance: what is absolutely important to have (must have), what should the system be able to do (should have), and what could be left for "version 2" (could have)? Identify major insights, such as where there could be major breakdowns, places where this would be used. This should be in the form of a bulleted list, labeled with the "must have"/"should have"/"could have".
When describing these requirements, describe them concretely: how often will these be done, and by whom?
Additional Information on how to conduct user research
- http://www.interaction-design.org/encyclopedia/
- Sharp, H., Rogers, Y., and Preece, J. Interaction Design. (2002).
- Moggridge, B. (2007) Designing Interactions. Cambridge, MA: The M.I.T. Press
Deliverable
- Turn in a written summary document for your portoflio binder at the beginning of the lab on February 4. The binder will be handed back to you at the beginning of class. The summary document must list the names of all team members either on the grading sheet or on the summary itself.
- Add this grading sheet as the first page of your report.
Handing-in Instructions
The binder is to be handed in at the beginning of the tutorial on February 4th.
Late Policy
For project deliverables we will deduct 10% for each day (including weekends) the deliverable is late.
Plagiarism Policy
Deliverables should consist primarily of your original work, building off of others' work--including 3rd party libraries, public source code examples, and design ideas--is acceptable and in most cases encouraged. However, failure to cite such sources will result in score deductions proportional to the severity of the oversight.