On this page... (hide)
- 1. Overview
- 2. Teams
- 3. Portfolio
- 4. Project Ideas
- 5. Project Components
- 6. Frequently Asked Questions
1. Overview
The project is a hands-on opportunity to try the methods and ideas that we cover and discuss in class -- in particular, to engage in a user-centered design process. The two main lessons to be learned here is that: (a) designers do not rely on their intuition, but instead rely on real user research, and that (b) design is really about a process. This is a process that you can apply as a software developer in the real world.
You will choose a project idea to work from, and use that project idea for every component. The project has four main components. The first component asks you to consider real users in the context of real activities, and understand their real needs. The second component is about the process of brainstorming and iteratively developing and building on ideas quickly and cheaply, asking you to identify the most important aspects of your system. The third component is about actually building the system in code, and then evaluating the interface/system that you have built using heuristics. In the final component, you provide a brief report, and presentation about the entire scope of your project.
2. Teams
The project is to be completed in teams of three, where all members are from the same tutorial section.
The idea here is to work as a deep dive group to generate a wide breadth of alternate and varied design ideas -- just as you would in the real world.
This may seem pedantic, but here are Randy Pausch's Rules for Working in Teams. I cannot emphasize this enough: those tips are probably some of the most important lessons you will get from this class.
3. Portfolio
Your team needs a binder that is 1 1/2" thick. All of your project components will be handed in to the TAs in a binder. The idea is to compile all of your project materials in one place, making it easy for us (when we mark your materials) to see the evolution of your project and work.
You should have section separators for each of the components of the project, a cover sheet (with your names on outside cover), and name/contact information on the first page of the binder.
Print off the Grading Sheets, and put these at the front of the appropriate section.
4. Project Ideas
You may choose from any of the following project ideas. Most will need some narrowing (i.e. focus) to make it tractable. My suggestion: pick a project that speaks to you (i.e. you find/found it an issue).
- System for people new to the city
- Personal fitness tracker: able bodied or physiotherapy
- Cross-family communication system
- Communication system for video gamers
- Paying the bill with a group
- Ordering system at a restaurant/bar
- Electronic course registration system
- Trip planning for public transit
- Buying movie tickets online (seat selection, etc.)
- System for navigating course material and communicating with other students
5. Project Components
5.1 Overview and Deadlines
| Component | Value | Due |
| P1: User Research. Conduct three different IDEO methods to learn about your users in their environment. | 7.5% | 10/15 |
| P2: Ideation and Lo-Fi Prototypes. Brainstorm and sketch a variety of possible interfaces for your system, identifying important aspects of a user's flow. | 10% | 10/29 |
| P3: Hi-Fi Prototypes and Heuristic Evaluation. Implement important features of your interface and system, and conduct a heuristic evaluation on its major features. | 15% | 11/23 |
| P4: Final Report and Presentation. Provide a report on your work, and present the work to your classmates. | 7.5% | 12/7 |
5.2 Component P1: User Research
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 three methods from the IDEO methods, such as contextual inquiry, surveys, interviews, focus groups, observations, etc. It is important to choose appropriate methods that complement one another -- for example, interviews could be complemented with observation. After collecting the data here, you will analyze it to develop design requirements for your system that you will use in later components.
Major Activities
- Identify your project idea. Succinctly describe the nature of the project, how you expect your system to be used, by whom, and the context under which you expect it to be used.
- Identify stakeholders and users. Figure out who is impacted (in one way or another) by this system -- these are stakeholders. Note that stakeholders and users overlap, but are not always the same. For example, the primary users of self-checkout at a grocery store are customers, but cashiers still make use of the system, and the owner of a grocery store (who is likely paying for its installation) is someone who cares about the system, too. Create a list of these stakeholders, and describe them (particularly the users) in terms of: how much training/experience they might have, their background knowledge, etc.
- Conduct three user research methods. Select three user research methods from the methods we covered in class (or are in the IDEO cards) that complement one another. Justify your choice of each of these research methods in terms of why they are appropriate for your context. Conduct the methods with potential users and/or stakeholders. Make notes about your experience conducting these methods: 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 from each of these methods.
Since this is a class project, you need not to necessarily interview as many users as suggested in the literature; instead, focus on selecting good techniques, and learning something from their application. If you're not sure, talk to me long before the deadline.
- 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?
Deliverable
- Turn in a written summary document in your portoflio binder (along with the appropriate grading sheet on top). This should be a single spaced, double sided, 12 pt Times Roman document with 1" margins. Sections should be clearly labeled for each activity in this project component. This should be handed in at the beginning of the class on the day it is due. As with assignments, you have a 10 minute window from the start of class -- handing it in after this 10 minute window will result in a grade of 0.
- Provide the following: (a) a succinct description of your project idea, how you expect your system to be used, by whom, and the context under which you expect it to be used; (b) provide a list of stakeholders, and describe them as they relate to the design of the system; (c) discuss the user research methods you used, provide justification for them, and provide a summary of your findings from each of these methods, and (d) define the basic design requirements for your system.
- As a rough guideline, this assignment should result in a 4-6 page document. The maximum is 8 pages.
- You should also provide an appendix of any materials used in your user research to serve as proof that you conducted the research methods. Note that these do not count against your page count, and do not need to be formatted nicely. Examples could include (but are not limited to): interview questions, raw notes from observations, photos from ethnography, survey questions, etc.
Grading Sheet
- Ensure that your grading sheet is placed in front of the section of this component.
Resources
More insight into how to conduct certain methods
- 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
5.3 Component P2: Ideation and Lo-fi Prototypes
Overview
Now that you understand your users and their problem, your job is to brainstorm designs for them. As I said in class, the best way to come up with a good idea is to have lots of them, and narrow down. In this component, you will brainstorm many designs, and then use some basic criteria to filter and select the best ideas. You will then polish these ideas, and create a storyboard for at least one to show the entire scope of the interaction.
The goal of this component is to show you that if you have an open mind, your first idea is (unlikely) to be your best idea. Instead, the process of brainstorming, discussing and affinity diagramming (particularly with a deep dive group) can help you find good ideas that you had not considered before.
Major Activities
- Brainstorm session. With your deep dive group, schedule a mutual time that you can get together and work for at least an hour together. Brainstorm and sketch ideas -- one each on a single sheet of paper. The goal here is to sketch as many distinct ideas as you can -- you should aim for at least -- at least -- four sketches a person (at least 12 sketches). Anything goes: crazy or boring, whole system or even just a small piece of the system. You are aiming here for variance: the ideas should be different from one another. You are allowed to build off of one another's ideas, but make sure that they're different. If you end up with a bunch of sketches that are essentially variations on the exact same idea, try again, because you didn't do it right.
Time permitting, I will make time available for you to do this session during tutorial time.
- Affinity diagramming session. This can be part of your brainstorming session, or a different one altogether. As a group, go through each of the sketches one by one, discussing the main idea of the sketch. Construct an affinity diagram with these sketches, or with ideas extracted from the sketches. At the end of this, you will have several different groups (say 3-5 groups). Discuss each of these groups in relation to the design requirements you identified in P1, their weaknesses, strengths, feasibility and originality.
- Select and polish ideas. From your affinity diagramming session, select the three most promising ideas, and re-sketch the idea on a sheet of paper neatly. Add annotations and/or provide descriptions where appropriate.
- Refine ideas and create storyboard. Select one of the three promising ideas, and construct a storyboard that illustrates its context of use, how it would be used. This should depict some of the interface, and how a user would interact with it.
Deliverable
- Turn in a written document in your portfolio binder.
- Provide a summary of the brainstorming process and affinity diagramming process, articulating: (a) the range of ideas that were explored, (b) what major conceptual groupings you came up with in your affinity diagramming process (likely 3-5). Describe these conceptual groupings, and how they relate to the design requirements you specified in P1 and what you learned from your user research: are users likely to find these ideas palatable?
- Provide polished versions of the three sketches that you selected as having the most potential. Provide a paragraph describing the idea, then provide another paragraph justification as to why this sketch is appropriate given user needs, constraints, and/or the design requirements you specified in P1. Each of these sketches should comprise one page.
- Provide a polished storyboard for at least one of these designs. The storyboard should illustrate a usage scenario, and depict how the interface functions in the context of that scenario. You want to provide some detail here. You should aim to have between 6 to 12 slates (no more than 24).
- As a general guideline, you should expect to have roughly 6-9 pages of content (no more than 12).
- You should provide evidence of your brainstorming session mainly as an appendix (e.g. a photo of the assorted sketches, or the raw sketches themselves). Again, the appendix does not count toward your page count.
Grading Sheet
- Ensure that your grading sheet is placed in front of the section of this component.
5.4 Component P3: Hi-fi Prototypes and Heuristic Evaluation
Overview
In P2, you developed a wide space of ideas, and focused on developing a number of sketches, polishing a limited set. In real life, you would use these polished sketches, along with your storyboard to get feedback from potential users. In practice, you would go through several iterations of this, where you develop ideas, gather feedback, and continue to develop more ideas.
At some point, your customers are going to want to see a more tangible prototype. In tutorial, you learned a number of ways to prototype, using paper, video, and pictures. These are ways that you can develop prototypes to not only understand what the resulting system may look like, but also what it feels like to interact with. Using these prototypes, you could easily evaluate your interface with users, understanding what aspects of the interaction works well, and what doesn't. These "quick and dirty" prototyping methods allow you to get that idea without expending the major effort that is required to develop a prototype using code. Due to time constraints, we unfortunately need to skip this middle step.
For this project component, you will actually develop a prototype of your system in C#. You should develop a deep vertical prototype that addresses all the "must have" requirements you identified in P1, and refined in P2. Your prototype should follow the design ideas you identified and storyboarded in P2, but only to the extent that it makes sense. If you discover that an alternate idea/design works better, feel free to implement this; however, you will need to be clear about this modification, and justify it for both P3 and P4.
In practice, you could now demo the system and conduct usability or feedback sessions with potential users. This is often time consuming and expensive, so you may need a method to evaluate the usability of your interface that gets you results without having to involve users. One of these methods is to conduct a Heuristic Evaluation. Your job is to conduct a heuristic evaluation, and report on the main findings.
Major Activities
- Build a vertical prototype. Using C#, build a vertical prototype that addresses all of the "must have" design requirements you identified in P1, following the selected idea and storyboard you made in P2. This prototype should be functional: not only in that the interface appears correct, but that the core functionality (in terms of interaction) actually works the way that it is intended. The goal, remember, is to allow someone to understand how it would feel to interact with the system.
- Demo your system. You will demo your system to your TA and your fellow classmates in your tutorial section. Think carefully about how to demo the interaction of your system. You have 10 minutes to do your demo, and will need to answer questions from the class and your TA for 5 minutes.
- Conduct a heuristic analysis. You will conduct an heuristic evaluation of your system as outlined in class. Each member of your deep dive team will use the heuristics, and individually make his/her way through the interface, identifying when some aspect of the interface violates one of the heuristics. It is important that this step is conducted independently. You will then meet as a team, and again walk through the interface, discussing each of the problems that you all identified. Your goal is to identify major problem areas of your interface through this method, what heuristic(s) have been violated to cause these problems, the severity of the problem, and to make recommendations on how to address them.
Deliverable
- There are two deliverables: an in-tutorial demo to your TA, and a written component.
- The in-tutorial demo will be scheduled by your TA. You will have 10 minutes to say what your project is, and to demo the core features of your system (consider using your storyboards as a guide). You will then need to respond to 5 minutes of questions.
- On the due date for this project component, you will hand in your portfolio binder in lecture with a written report about your prototype and the results of your heuristic analysis. This written report should address:
- In about two pages, how the prototype was built, and the major features that are exposed in the interface. This should include small screenshots of the interface where appropriate. These major features should align with the design requirements that you specified in P1, and explored in P2. Where there is variance from these original ideas, point them out, and justify the design changes.
- The results of your heuristic analysis should be written in 3-4 pages (maximum 6 pages). Identify a small set of major problems that must be fixed, and summarize these. Then, describe the issues that were identified, along with which heuristics were violated, and finally, how you would address them in another iteration. You can sort these in terms of severity, in terms of functional/conceptual area (i.e. in a way that makes sense with respect to your system), or in terms of each heuristic. Justify your choice for presentation, and make it clear that sort is being done in the written presentation. You may not have enough space for everything: this is fine, put the remainder in an appendix.
- Include as an appendix the raw notes from your heuristic evaluation.
Grading Sheet
- Ensure that your grading sheet is placed in front of the section of this component.
- Bring a copy of the grading sheet to your demo with your names and email addresses filled in. Your TA will use this grading sheet to evaluate your demo.
Resources
5.5 Component P4: Final Report and Presentation
Overview
At this point, you now need to wrap up this project, and deliver it to whomever gave you the project to begin with (normally your boss, but in this case, your instructor and TAs). A normal "real life" process here would involve a professional presentation and project report.
Your presentation should present ideas at a very high level, and should cover the following topics:
- Who is this presentation/project report for?
- What is the design problem being addressed here?
- Who are you designing for, and what is the context of their activities?
- What are the main things you discovered in your user research?
- What were the major design decisions that you made? (i.e. what did you decide were must haves vs. should haves; how did you arrive at the final design ideas?)
- How do you justify your design decisions?
- What did you discover from your heuristic evaluation?
- How would you address these in the next iteration of the design?
Word provides several paragraph styles that will help with the professional look of your final report. I would suggest using styles such as "Title", "Heading 1", "Heading 2", "Normal", "Block Quote" and "Caption". You should organize your final report with the following headings (roughly):
- Executive Summary
- Introduction
- Design Problem
- User Research and Findings
- Design and Justification
- Heuristic Evaluation and Findings
- Recommendations for Next Iteration of Design
- Conclusions
Deliverable
- Final in-tutorial presentation. This is a 10 minute presentation where you are to construct a powerpoint slide deck. Make sure that you use the pictures and images/scans of your sketches/ideas liberally. Do not go over time. At 11 minutes, your TA will abruptly end your presentation. You will also answer questions from your TA and labmates for 5 minutes.
- Final report. This document should essentially be a summary of the major components from the previous steps of your project, but the point is to present it professionally and succinctly. You will be given eight pages to compile this report. You have a limit of 12 pages.
Grading Sheet
- Ensure that your grading sheet is placed in front of the section of this component.
- Make sure that you bring your portfolio binder to the demo.