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 -- once started you cannot change project problem. 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. You are to form your own groups and email the professor with the details, BEFORE FRIDAY SEPT 13. If you do not you will be randomly placed into a group and notified.

The idea here is to work as a group to generate a wide breadth of alternate and varied design ideas -- just as you would in the real world.

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.

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
• netflix-like movie browsing
• photo sorter

5.  Project Components

5.1  Overview and Deadlines

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?

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 for this component. Seriously.
• 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. Be detailed AND succint - a hard combination to achieve.
• 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 group) can help you find good ideas that you had not considered before.

5.4  Major Activities

• Brainstorm session. With your 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 -- six sketches a person (at least 18 sketches totak). 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.
• Affinity diagramming session. This should be a second session after the brainstorming session. 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 storyboardw. 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.5  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.

Major Activities

• Build a vertical prototype. Using client-side web technologies, build a vertical prototype that addresses all of the 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 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.
• Conduct a heuristic analysis. You will conduct an heuristic evaluation of your system as outlined in class. Each member of your 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. Make sure to document your discussions and progress

Deliverable

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.

Resources

• Heuristic Evaluations
• How to Conduct an Heuristic Evaluation
• Nielsen's 10 Usability Heuristics

5.6  Component P4: Final Report and Presentation

Overview

At this point, you now need to wrap up this project, polish you prototype, and deliver it to whomever gave you the project to begin with (normally your boss, but in this case, your instructor). 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. This is a comprehensive report spanning the entire project. This below list is not necessarily the order of your presentation, but points that must be covered.

• 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). A large component here is to highlight the full process that you undertook to make this system.

• Executive Summary
• Introduction
• Design Problem
• User Research and Findings
• Design and Justification
• Heuristic Evaluation and Findings
• Recommendations for Next Iteration of Design
• Conclusions

The bulk of your implementation should have been done with P3. With P4, your job is to basically polish the prototype

• finish the horizontal layer of the prototype, that is, all major screens and navigation should be intact, even if they don't work functionally.
• ensure all the must-have requirements are met, and decide if you want to add any easy should-haves.
• polish and improve your vertical prototypes. Be meticulous here. Validate input if necessary, handle exceptions (e.g., doing something invalid), try to make the navigation and interaction more robust.
• you are not expected to solve all of your issues identified in P3, as this would take much too much time. If you do improve on any points raised, document this in your write-up.

Deliverable

• Final in-class presentation (to be scheduled). 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 instructor will abruptly end your presentation. You will also answer questions from your instructor and classmates 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. Feel free to re-use any perfect text you had in prior components (this is not cheating), but it is extremely unlikely that simply copy-pasting would be sufficient.

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.

6.  Technical Tutorials

(hint, click "next chapter" to move on within each)

1. HTML - complete HOME through XHTML
2. CSS - complete HOME through CSS Summary, and, CSS Selectors
3. JavaScript - complete HOME through JS JQuery. this is a long tutorial, save time for it.
4. jQuery - complete HOME through jQuery filtering
5. recommended but not quizzed - HTML 5 tutorials

general recommendations and requirements

• your work will be tested on google chrome version 29.x. If you want to use another browser for a good reason (e.g., cutting edge functionality) send me a petition.

debugging and dev environment tips

• investigate chrome's built-in developer tools. will save you a bunch of time, particularly the JS console.
• do not use tables for layout -- they will constrain you and it's not what they are meant for
• DO NOT USE A PRE-PACKAGED WEB TOOL LIKE OFFICE, DREAMWEAVER, ETC -- not only will you have a terrible time working with it, your final result will likely be not interesting or innovative (which can quickly turn into a marks issue)
  • find a clean, simple text editor. I like notepad++.
• while you will not be marked on valid CSS/HTML, I strongly recommend regularly using HTML and CSS validators that ensure you are following standards. a great way to avoid bugs before they start