CS5340 Human-Computer Interaction

Assignment #

Due Date

Description

T1

1/24, by 6pm

The heart of this course is a semester-long project, in which you will design, implement, and evaluate a user interface. User interface design is an iterative process, so you will build your UI not just once, but multiple times, as successively higher-fidelity and more complete prototypes. In order to have time for these iterations, we need to get started on the project as early as possible.

Project teams may consist of 3-4 people. Teams will primarily be formed based on the results on the first brainstorming exercise and in-class discussion. A directory of all students in the class will be posted to help you with informal networking to find teammates. At least two people on your team should have solid programming skills in the same programming language or platform that your team decides to use. One member of the team should set up a team web page on which you will post the results of team assignments. Ensure the names and email addresses of the team members are at the top of the page and post it to a server. Organize the page so the instructor and TA can quickly find your assignments each week. Email the names of the team members, a name for your team, and a URL to the instructor and TA with "[CS5340]" in the subject line.

Here are some guidelines to help you develop your project proposal. Your project must

• Have a substantial user interface. A health screening system that simply administers a questionnaire is not enough.
• Be interactive. A patient education system that simply displays a page of text or sequences through a series of pages would not be acceptable.
• Work robustly. You will need to fully build what you propose. Ideas are not enough. Your project should be fully implementable by the end of the semester, although we will consider larger projects in which you primarily develop the interface and leave some implementation details for later.
• Contribute to health or health research.
• Solve a real-world problem.
• Support use and interaction amongst 2 or more users (it must be a social application).

Your project should

• Be creative.
• Be original.
• Be non-obvious.
• Have a "wow" factor.
• Allow you, at the end of this course, to have an amazing system to add to your design/programming portfolio.

Group projects must focus on a health-related problem. Over the course of the semester, you will design a system that promotes health and wellness through social interaction between users. One way to figure out if your ideas is creative, original, and non-obvious is to do a lot of searching and reading on your own of research papers in the HCI literature to figure out what really is a new idea. The instructor will tell you when an idea does not meet these criteria, but it will be left to you to figure out why and propose alternatives. Coming up with a good idea, and knowing when and having the courage to switch ideas when you discover one is not good, is one of the biggest challenges in this course.

Some ideas for potential types of systems that you could design (not an exhaustive list):

• A health-related application that can be installed/used in a public space (e.g., library, clinic waiting room, commmunity center, grocery store, gym, etc.)
• A "serious game" that supports play between 2 or more users (consider different game types, e.g., exergames, augmented reality, casual, strategy see this list.)
• A health-related application for mobile devices (phones, tablets, etc. -- your final solution needs to go beyond what's currently available in app stores)
• A health-related application that meets guidelines for an available software competition (e.g., see this example) (with the caveat that this option must be approved by the instructor and there are important restrictions with respect to deadlines, scope, etc. )

An important note: Your technology must run robustly on standard Mac & Windows-based PCs or Android phones/tablets. Students without substantial mobile experience are strongly encouraged to simulate their interfaces on PCs in a language they already know well to reduce the complexity of project implementation.

What to Post

You must post a project proposal (about 2-3 pages long, double-spaced, 1 inch margins, 12 point font, PDF format), that includes the following parts [20 points possible]:

1. Problem. In this assignment, your team will identify a general problem area to focus on. Describe the problem you chose and how a new, innovative system could help someone towards improved health and wellness. Include a description of why this is a challenging issue to address, and why technology might uniquely help address it. Also include a brief overview of what has been done previously to address this issue (commercially and in the research world). [10 points]
2. Target users. Characterize the user population. What population have you chosen to focus on and why? You might choose to constrain your population by age, marital status, occupation, living context (e.g., apartment), children, occupation, etc. You must indicate how this target population differs from yourself, as a goal of this project is helping you learn how to design interfaces that are not simply what you would like to use. [8 points]
3. A couple sentences describing each team member's contribution to this assignment. [2 points]

T2

2/7, by 6pm

In this assignment, each team member will conduct ethnographic observations to explore the problem area you identified in T1. Note that each team member must hand in a report and will be graded on their individual report. While you will collectively decide which areas the observations will be conducted in, the observations should be done independently, and the reports should be created independently.

Based upon your project topic (and the feedback you receive on T1), your team will identify settings that will allow you to obtain formative insights into your topic area. Make sure you choose a location that will allow you to observe your target demographic. Each team member should, independently (do not go in groups), conduct 2.5 hours of observation in the setting of your choosing. The goal is to collect real-world observations that can help you think up new opportunities for design.

Tasks

(detailed in the class slides ... please review them for the full information!)

• Select a place where you will spend 2.5 hours observing and interviewing people engaged in an activity related to the health problem your team is focused on.
• Prior to heading out for your observation, talk as a team about what it is you expect to see, what you might be suprised to see. This will help you articulate your biases upfront, and better prime you to notice unexpected happenings. Also discuss what you hope to learn from your observations. Finally, as a team, develop five questions that you can use to informally interview people. Each team member should have the same 5 questions. These questions should help you get insight into your team's project topic.
• Arrive at the location and check in with someone and let them know that you are working on a class project and are hoping that you will be able to sit and observe for a while and perhaps talk with some people in the location. If anyone tells you that you cannot do so, you need to thank them and leave immediately. It is critical that you be respectful at all times.
• "Jottings": Make notes about what you see. Pull ideas about how to do this from the readings. It's normal to feel that what you're writing down is mundane! Still, write down what you are seeing. Some observations will not seem meaningful until you start to see them occurring over and over again - it's then that you start to uncover taken for granted, yet important parts of human behavior & interaction. Write down things you're observing that might impact UI design: people, objects, timing, relationships, exchange of information, documents, emotional reactions, the environment in which people ar acting, etc. Your goal is to observe carefully and thoughtfully and try to understand the behavior, activity, and environment that you see. Remember that your ultimate goal will be to design a social application, so keep an eye out for interesting ways in which people interact with others. In your notes, do not identify people by their real names in your report - give them a pseudonym.
• After you've observed for a while, spend at least 30 minutes trying to interview at least one and optimally 2-3 people about what they are doing in the location that you chose. Again, your goal is to observe and listen, and to learn what some of the activities or challenges are for the people. This should help you come up with (or refine) project ideas.
• If you already have a project idea in mind, you can approach this exercise from that perspective. However, you need to keep an open mind. Your primarily goal is to learn what the really important issues are ... not those that you think might be important.
• In total, spend 2.5 hours in a single block of time observing, listening, and thinking. For some of this time you may feel like you are not seeing much. But look around! Use your keen senses. You will see things you did not expect if you do this exercise properly.
• Please do not bring your phone or computer or any other device that could distract you. You need to be completely focused on the environment for the 2.5 hours.
• Create Complete Field Notes. Immediately after your observation, convert your "jottings" into more complete fieldnotes d iscussing the trends you saw, supported by specific and detailed examples (this will serve as the basis for item 5 in your report, below). This will involve expanding the quick notes you took in the field into prose as you reflect upon what you saw. Spend some time reviewing your notes and organizing them. In particular, I'd like you to focus on what you saw people actually doing, how the environment and others impacted their activities and how that provides information about the tasks they may most care about or need help with.
• Implications for Design: Conclude by making a concise (2 sentences per point) bullet point list of 5 of your most important observations and how what you've seen or heard might impact how you design a new system.

What to Post

Each team member should write (independently) and submit a report that include [45 points possible]:

1. Your name and your team name at the top.
2. A copy of the notes ("jottings") you made while doing the observation (if they are messy that is ok).[10 points]
3. A one-paragraph summary of why you picked this particular setting to focus on and what questions you sought to answer in this investigation.[5 points]
4. The 5 interview questions that your team developed. [5 points]
5. Your complete field notes (see above). Here you want to provide a summary of the setting and activities you observed, the kinds of people you observed engaging in the activities, a description of any artifacts they used, any variations or consistencies you observed, and what you found out in your interviews. You should try to include a few quotes from people that support your conclusions. (See the ethnography research readings for examples of how to write your report.) You can include sketches in your report but no photographs. [15 points]
6. Implications for Design (see above). [10 points]
7. Total report length (not including the raw jottings) should be about 3 pages (double spaced, 1inch margins, 12pt font, PDF format).

T3

2/21, by 6pm

In this assignment, you will build upon the ethnographic observations that you did in T2 through requirements identification and design ideation. Each team member should read other team members' T2 assignments. You should then meet as a team to discuss what you feel are the most interesting and consistent insights that you gained. Based upon these insights, derive a set of requirements that will guide your design ideation. Specifically:

• Stakeholder analysis. Based upon your ethnographic work (T2), identify the characteristics of your user population, as we discussed in lecture. If you have multiple user classes, identify each one. Identify all stakeholders in your application (primary, secondary, tertiary, facilitating). Be sure to note how this analysis is based on your findings from T2.
• Task analysis. Based upon your ethnographic work (T2), identify 6 tasks that your stakeholder population engages in. These tasks should be relevant to the health-related problem you are solving and the system you will design. Analyze each task's characteristics, and answer the general questions about tasks we asked in lecture. Think about other questions you should ask that might be relevant to your particular domain. If you can't think of 6 tasks, try drilling down to more specific tasks, and consider exceptional and emergency tasks. For each task, describe the goal, preconditions (what needs to happen/be in place before the task can be executed). and exceptions (what can go wrong). In addition, use heirarchical decomposition to specifify each task's subtasks and plans for executing these tasks/subtasks. Be sure to note how this analysis is based on your findings from T2.
• Functional Requirements. Describe what the system should be able to do (what tasks it should support). Note that this description should be platform and implementation-independent. Discuss 6 such functional requirements and how they were derived from your ethnographic work (T2) and task/stakeholder analysis. (Refer to readings and lecture slides.)
• Non-Functional Requirements. Describe the environmental context in which the system will operate and any constraints that will be placed on your design. Discuss 6 such non-functional requirements and how they were derived from your ethnographic work (T2) and task/stakeholder analysis. (Refer to readings and lecture slides.)
• Brainstorm 3 system concepts. As a team, collaboratively brainstorm 3 possible systems that could help address your problem and your requirements. Note: Do not simply describe the system concepts you came up with in the initial stage of this project. Your ideas should have evolved based upon T2, your requirements analysis, and what you've learned in this class. Each concept should be significantly different from the others. Do not just suggest 3 systems where only one or two features is slightly different. The goal here is to think creatively and broadly. Ideally you will brainstorm many more than 3 concepts, and then choose the final 3 candidates to write up for this assignment. For each of your 3 concepts, briefly describe:
  1. How the system would address your chosen problem. Think outside of the box. The system may directly support users in completing the tasks you've identified, or it may help build skills that would then enable them to complete those tasks. This is especially true for those designing a game. For example, through game play, users might develop health-related knowledge that then makes them better equipped to live a healthy lifestyle.
  2. What the system enables users to do and how it addresses the functional & non-functional requirements that you've identified.
  3. How the system differs from currently available systems and why you think your concept is innovative.
  4. Come up with and describe an interaction metaphor for each of your concepts, following the examples in the lecture. Here the goal is to think more specifically about how your users will actually navigate and use your proposed systems.
  5. List 3 potential unintended consequences of the system, that is, things that could go wrong as its used.
• Storyboard. Create one storyboard for each of your three system concepts that shows the operation of the proposed interface. These storyboards should provide a high level depiction of how the systems would work. Do not get caught up in details! Provide very short (1 sentence) captions for each illustration to help set the context and describe the scenario. Remember that the storyboard is different from screenshots because it shows more context about what the user is doing. It tell's a story of the use of the app and the problem(s) being solved with it.

What to Post

Your report should not exceed 15 pages, not including the storyboards (double spaced, 1inch margins, 12pt font, PDF format). Include the following parts:

• Title. Give your project a title, if you haven't already.
• Problem. Clearly and briefly, restate the overall idea for your project and the problem(s)/challenge(s) your proposed systems will solve (1 paragraph).
• Stakeholder Analysis. Describe your user population as discused above.
• Task Analysis. Describe the 6 tasks you have identified as discussed above.
• Requirements. Describe the functional and non-functional requirements you've identified, and how you came to generate these requirements. That is, what insights from your ethnographic work led to identifying these requirements?
• Design Concepts. Describe in detail each of the 3 design concepts you have arrived at.
• Storyboards. Post one storyboard for each of your 3 concepts.
• A few sentences describing each team member's contribution to this assignment.

T4

2/28, by 6pm

In this team assignment, you will continue the design of your term project by choosing a design concept to pursue.

• Functional Requirements. Based on the functional requirements identified in T3, choose the 3 most important (and most feasible to implement) that you will focus on for the remainder of the semester. Describe why you have chosen these to focus on these.
• Concept selection. In this assignment, you will choose one of the design concepts you generated in T3. This is the concept you will pursue for the remainder of the semester. Choose what you believe to be the most innovative concept. Describe what was lacking in your other 2 design concepts, and how the one you've chosen seems to be superior. Also discuss how you've refined your design concept since T3 (how you've improved upon it and fleshed it out), including how your system addresses the 3 requirements you've settled on, and the specific strategies/concepts from class and the readings that you have used to refine the design concept. Remember, focus on the high level functionality here; putting too much time into low-level details (font, widget placement, etc.) is pointless at this stage as your design concept is still in flux.
• Storyboard. Revise your storyboard for your chosen design concept. The storyboard should depict users engaging with the 3 functions identified above. This should be more detailed than what you turned in last week, as you more fully flesh out the design concept. Do not just have the storyboard describe the simplest case. Your goal is to have the storyboard show how your design would work well in the more complex situations (where lesser interface designs might fail). The storyboard should clearly indicate what things about the design are going to make it successful in a social use context. Keep in mind that someone who knows nothing about your idea should be able to look at your storyboard and understand the problem(s) you are solving and see evidence that the interface is going to actually have the ability to do address your problem. Remember to provide very short (1 sentence) captions for each illustration to help set the context and describe the scenario.

What to Post

Your report should contain the following:

• Problem. Briefly (1 paragraph) restate the overall idea for your project and the problem(s) your system will solve.
• Functional Requirements Selection. Describe the 3 functional requirements you've chosen to focus on (as discussed above).
• Concept Selection. Describe which concept you've chosen to pursue and why, as described above.
• Storyboard. Post a copy of your storyboard.
• A few sentences describing each team member's contribution to this assignment.

T5

2/28, by 6pm

In this team assignment, you will create a full paper prototype of your interface.

• Develop a paper prototyping kit. Focus on the metaphor you're trying to communicate to the user, and think about the requirements you've identified, as well as your task analysis (T3): what does the user need to do and how will your system help them do it? Practice using your kit on at least one friend who is not in the class. One or more teams will be selected to do paper prototyping with a volunteer in class. We will critique the team's prototype and also the paper prototyping session. Follow the suggestions mentioned in class and the suggestions in the Rettig paper. Remember that you are creating paper tools that allow you to manipulate the interface as a tester "uses" it. You are not just handing in screenshots. More specific instructions on building your paper prototype:
  • Draw the static background, menus, and other windows. Decide how to implement the dynamic parts of your interface. Very neat hand-sketching is preferred. Use the tips and tricks in the readings and discussed in class. Make sure your prototype addresses the 3 functional requirements identified in T4, as well as all major functionality you propose to build.
  • Prepare a briefing for test users. This should be at most a page of information about the purpose of your application and any background information about the domain that may be needed by your test users to understand it. These are your notes for the briefing, so make them short, simple and clear, not dense wordy paragraphs. You will read this to your test users in T6. This is not a manual or quick-reference card. It should absolutely not describe how to use the interface.
  • Develop 3 tasks that your target users will engage in (this is what you will ask users to do in T6). Just write the concrete goal of the task (e.g. "buy milk, tomatoes, and bread"). Don't write the specific steps to follow, since that's for your users to figure out. Some tasks may be brief (5 minutes), but others are likely to take longer. Your tasks should not be trivial; in fact, your tasks should be some of the most complex that someone might have to do with your interface. You will read these tasks to your test users. Come up with a short list of questions that you are hoping to answer through this evaluation. To develop these questions, think about which aspects of the interface are you unsure of. These questions will help you be attentive to important aspects of users' interaction with your prototype.
  • Prepare debriefing questions. Develop a short list of questions (3-5) that you will ask users at the end of the session, related to their experience using your prototype.
  • As a team, rehearse going through your evaluation plan (briefing, tasks, prototype, questions asked). Each team member must play a role: one person must play the computer and one should play the facilitator. The other team members will be observers (although they may ask questions during the test if necessary). Each team member should practice playing the computer, learning the steps involved in making the prototype functional, such as rearranging pieces and writing responses. It isn't important to be fast, just competent and confident.
  • Once you have rehearsed, assign a role to each team members for your evaluation. It may be useful for you to swap roles after every user, so that each of you gets a chance to try each role, but decide how you'll do it in advance.

What to Post.

Include the following:

• Create a PDF (post to blackboard, and bring a copy to class) with: the paper prototyping brief, tasks, and questions you're hoping to answer (during the evaluation and during the debrief).
• Paper prototype materials. Bring a photocopy of your paper prototyping materials to class in a large, sealable envelope labeled with your team member names and emails. You will hand these in after class so please keep the original copies for your team (your next assignment will also involve paper prototyping). Include a concise description of how the protoype works. Be sure to label the different interface pieces so that the instructor and TA are able to easily understand how to navigate the prototype.
• A few sentences describing each team member's contribution to this assignment.

T6

3/14, by 6pm

Team Project Assignment #6 - Paper Prototype Evaluation (2 weeks)

In this team assignment, you will revise the prototype you developed in T5 based on the issues you identify in a pilot test and the insights gained in our in-class lectures and exercises. You will also evaluate your paper prototype with at least 3 users.

Pilot Test

Practice running your paper prototype with at least 2 family members/friends (using the briefing, tasks, and questions developed in T5). Conclude by asking them to share any thoughts and reactions they have. A few trials are enough, here you are making sure that your prototype is robust and easy to use. Keep an eye out for any aspects of the prototype that are unclear, and make sure that the tasks you are giving participants and the questions you ask them are yielding useful insight. If any area of your protocol is lacking (tasks, prototype, questions asked), revise it.

User Testing

After you have updated your prototype as discussed above, evaluate your prototype with at least 3 users from your target population (one at a time). You will lead them through at least three tasks in your interface. With each user, you should do the following:

• Brief the user. Use the briefing you wrote up in T5 (revised as needed) to describe orally the purpose of the application and background information about the domain. Don't waste too much time on this: 1 minute should be enough.
• Ask initial questions to obtain some relevant background information about the user (this should not last more than a couple minutes).
• Present one task. Hand the index card describing the task to the user, read it, and let them read it. Make sure they understand the task.
• Watch the user do the task. Take notes of your observations. You may ask brief questions to probe how they are reacting to the interface (refer to questions you developed in T5).
• Repeat with the other tasks. Run as many tasks on the user as you have time for (at least 3). Bring extra materials. Having extra blank Post-it notes, correction tape, and index cards on hand will help you improvise if a user does something unexpected, or help you make small fixes to your prototype between users. Use the tips discussed in class and in Rettig.
• Conclude by asking them any remaining questions you have and giving them the chance to share any thoughts and reactions they have.
• Videotape one session. You must ask the user permission to videotape the session - if they are not comfortable with it, do not video tape them. Let them know that the video is just for your class project. Do not include the user in the video, just their use of the prototype.

What to Post

Post a report with the following parts:

• Pilot Evaluation Report. Include:
  • a short bullet point description of any issues that arose in your pilot test of the paper prototype (e.g., aspects of the paper prototype that did not work as expected)
  • a description of changes you made to your prototype, user test questions, etc. based upon the pilot and team discussions
  • a description of how many people you pilot tested your prototype with and their characteristics (e.g., gender, age - are they representative of your target population or not? It's ok if they're not but this should be stated.)
• User Test Report. Include:
  • a brief description (couple paragraphs) of each person you tested with and where you found them (no names, please).
  • the briefing you used
  • the tasks you gave to users--exactly as you wrote them on the cards
  • questions you asked participants (pre-test, during test, post-test)
  • a bullet list of usability problems you discovered from the testing sessions, and your proposed solutions
• A few sentences describing each team member's contribution to this assignment.
• A video of one session.

T7

3/28, by 6pm

Team Project Assignment #7 - Medium Fidelity Prototype

In this group assignment, you will do the first computer-based implementation of your term project.

Your computer prototype should be:

• High fidelity in look. Use this prototype to explore the graphic design of your final implementation. Lay out screens as you want them to appear in your final implementation. Make choices about colors, fonts, alignment, icons, and white space. Your prototype need not be pixel-for-pixel identical to your final implementation, however. In fact, it shouldn't be the same since you will iterate on the design one more time based on the feedback you receive in the in-class heuristic evaluation.
• Medium fidelity in feel. Your prototype may not support some advanced interactions with high fidelity, such as drag & drop. That's OK. You can simulate these interactions with a little animation, or at least with a popup that describes in English what would happen.
• Medium fidelity in breadth. Your prototype should include features that correspond to the 3 functional requirements you chose to focus on in T4 (or a revised set of 3 functional requirements). In addition, your prototype should include every major screen or dialog you e xpect to have in your final implementation.
• Low fidelity in depth. Don't implement any back end. Where system responses are needed, make them canned (i.e., always the same) or random. Write minimal code.

Here are some issues you should not worry about in this prototype:

• Window resizing.
• Platform independence.

After you hand in your prototype, it will be evaluated by your classmates in a class exercise. You must make it easy for other people in the class to be able to run your prototype. If your prototype requires special hardware, you need to bring whatever is required to run your software to this class session. You can require evaluators to use a particular web browser and platform to ensure the correct appearance and operation of your prototype, as long as the browser/platform is commonly available.

What to Post

Post the following in a PDF to blackboard. Also put this same information on your webpage for your evaluators.

• A link to your prototype (your prototype must remain frozen and accessible at this location for the remainder of the course, warts and all).
• Startup instructions on installing/running whatever software is required to run your prototype (this MUST be easy). Specify the platform and browser requirements for your prototype. Give any special instructions for starting it up.
• System Overview. This must be neatly organized, concise and easy to understand. Describe the purpose of your application (i.e., the problem(s) it solves or helps with) and background information about the problem you are focused on (no more than 1 page).
• Team Credits: A couple sentences describing each team member's contribution to the interface.
• Software Credits: Describe all code, graphics, etc. that your prototype utilizes that you did not create yourselves (i.e., stuff you got from the web or other sources).
• Finally, post the following in your blackboard report ONLY: A 1 page (max!) bullet point description of how you updated your design based on what you learned in your paper prototype evaluation (T6). A 1 page (max!) bullet point description of the usability and graphic design principles that you followed in creating this UI. A 1 page (max!) bullet point description of your functional requirements, what features you've designed to address them, and how these features address your requirements.

This must be posted by the beginning of class on March 28, because other students will be testing your interface during class.

Hint: You should also think about getting a start on the final project report at this point, see T10 below.

T8

4/18, by 6pm

Team Project Assignment #8 - Prototype Revision & User Testing

In this group assignment, you will revise your interface based upon the feedback in the heuristic evaluation and conduct user testing of your interface. It is up to you to find at least 3 people in your target user group to test with.

Redesign

After you receive the heuristic evaluation of your T7 assignment, group problems by severity rating (cosmetic, minor, major, catastrophic), and brainstorm possible solutions for these problems. Revise your interface, addressing as many of the problems found as possible (in priority order).

Your system should be more functional than what was turned in for T7. However, you may simulate most of your system's backend. Your goal is to focus your main energy on the user interface design, and providing enough functionality to allow you to carry out a productive user test. At least some of the backend should be functional to allow users to provide you with useful feedback. Where the backend is not functional, you should simulate or have popups that tell the user what would happen if the system was fully functional.

A note on social features of your system: you may use a Wizard-of-oz approach to simulate multi-user interaction in the system, or implement this functionality fully. I expect that most students will use a wizard-of-oz approach, given the time constraints of the class.

A this point, the expectation is that you have a robust, well-designed, and creative user interface that solves a real problem. It should reflect a great deal of progress from prior versions. Keep in mind what is being assessed is not only the idea, but evidence of major improvements in the design from prior assignments.

User Testing

Your goal in the user test is to identify how well your system meets your team's functional and non-functional requirements (e.g., are users able to easily recover from errors? Does the system support the need you identified?). You will design a user test and carry it out with at least 3 users.

You will carry out this portion of the assignment in 3 steps:

1. Step 1: Develop Evaluation Plan
2. Step 2: Evaluate with (at least) 3 users.

Step 1: Develop Evaluation Plan.
Choose an evaluation method from those covered in this course to date. Develop a rationale for why you are choosing this method(s) (you will provide a discussion of the following items in T10, but you need to develop your answers now to conduct a good evaluation):

1. To start, review and list your team's functional & non-functional requirements. Choose at least 3 to assess in your user test. Your goal is to test how well your system meets your requirements.
2. Next, identify metrics for success, that is, through your evaluation, how will you know if your system is meeting your requirements? For example, if one of your requirements is that your system will help users engage in Task X, how will you know if your system is doing this adequately? How are you defining "adequate"?
3. You will conduct a Think Aloud evaluation of your system. Prepare for your test as follows:
   • Develop a briefing for test users. This should be at most a page of information about the purpose of your application and any background information about the domain that may be needed by your test users to understand it. These are your notes for the briefing, so make them short, simple and clear, not dense wordy paragraphs. You will read this to your test users during the user test. This is not a manual or quick-reference card. It should absolutely not describe how to use the interface.
   • Develop a set of task scenarios that you will present to users. These tasks should be such that as users complete them, you will be able to gather data relevant to the requirements you are evaluating. That is, your tasks should allow you to assess how well your system is meeting your requirements. Just write the concrete goal of the task (e.g. "buy milk, tomatoes, and bread"). Don't write the specific steps to follow, since that's for your users to figure out. Some tasks may be brief (5 minutes), but others are likely to take longer. Your tasks should not be trivial. You can read these tasks to your test users or give them written tasks to read themselves (see Rubin Ch9).
   • Come up with a short list of questions that you are hoping to answer through this evaluation. These questions should help you evaluate to what extent your system is meeting your requirements.
   • Debriefing: develop a short list of questions (3-5) that you will ask users at the end of the session, related to their experience using your prototype. Again, these questions should help you assess whether your system is meeting your requirements. Remember, your last question should always be, "is there anything else you would like to say that you haven't had a chance to?"
   • As a team, rehearse going through your evaluation plan (briefing, tasks, prototype, questions asked). One person should be the facilitator (guides the test and asks questions) and the other team members will act as observers and note takers. Each team member should practice being the facilitator.

Step 2: Evaluate with (at least) 3 users.
Use your evaluation plan to evaluate your software prototype with at least 3 users. Take copious notes on note cards about what you see users doing, and what they say during the user test. Write down information that will help you assess how well your system is meeting your requirements. In addition, if you observe or hear additional information that is more generally useful in helping you evaluate the usability, utility, or user experience of your system, then write this information down as well. Then, use the affinity diagramming method to organize these observations into themes. You will write a description of your findings in your T10 report, and discuss them during your T9 presentation.

What to Post

• On your team webpage, post a link to your interface.
• On Blackboard, post a PDF file that contains the following information:
  • Startup instructions on installing/running whatever software is required to run your prototype (this MUST be easy). Specify the platform and browser requirements for your prototype. Give any special instructions for starting it up.
  • Team Credits: A couple sentences describing each team member's contribution to the developnment of the interface.
  • Software Credits: Describe all code, graphics, etc. that your prototype utilizes that you did not create yourselves (i.e., stuff you got from the web or other sources).

Note: You will describe your redesign, evaluation method, and results in your final report and presentation (see T9 & T10). As such, you will be graded for the work you do in this assignment through the grades given for T9 and T10.

T9

4/18, by 6pm

Team Project Assignment #9 - Final Presentation

Final Presentation Instructions

On the last class (April 18), each team will make a final presentation on their project and important lessons the team learned during the development process.

The presentation must follow the format described in this template: template for team final project presentations. No exceptions.

Each presentation will be followed by a few minutes of Q&A during which time the next team will set up their computer.

You should be comortable with this presentation style from the paper presentations, but re-read those instructions for more detail.

The presentation is part of the team's final project grade.

What to Post

• The Powerpoint file for your final project presentation

T10

4/20, by 7am

Team Project Assignment #10 - Final Report

Your final project report is due at 7am on April 20 and should contain the following:

• Introduction. Here you should summarize the following. What health-related problem were you trying to solve? Why did you think a social application might potentially address this problem? Who were your target users? What challenges do they face that technology might be able to help with? Be sure to include proper inline citations that reference related work regarding the problem you are addressing, as well as other existing technologies that address your health problem.
• Design. Describe the final design of your interface including the purpose of the application and the features that it supports. Discuss how your system meets all your functional and non-functional requirements. Also discuss how your design has evolved over the semester. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluation phases (rqeuirements gathering, paper prototyping, and heuristic evaluation). Spend much of this section discussing how you modified your design following the heuristic evaluation. In particular:
  • Document how you modified your system to correct the problems identified during the heuristic evaluation. Describe how you addressed as many of the problems as possible (in priority order). If you do not address a concern, then justify why.
  Illustrate your design with carefully selected screen shots.
• Implementation. Describe the internals of your implementation, but keep the discussion at a high level. Discuss important design decisions you made in the implementation. Also discuss how implementation problems may have affected the usability of your interface.
• Evaluation Method. Describe how you conducted your user test. In particular:
  • Describe the evaluation plan that you developed in T8 - be sure your report addresses points 1-3 in Step 1
  • the number of users tested and a basic description of them (justify that they are representative of your target demographic based on the characteristics of your primary user group)
  • recruitment approach (how you found these users)
  • Describe in a paragraph your analysis process. Include a photo of your affinity diagram.
• Evaluation Results. Describe the results of your user testing:
  • Describe the results of your affinity diagramming analysis, including to what extent your results show that your system has met your functional/non-functional requirements. It is fine if you find that your system has failed to meet some requirements. Either way, clearly illustrate the success and/or failures of your system.
  • In your discussion, list all of your top level "green label" categories, and use the "pink" and "blue" labels to elaborate on at least 3 of these categories. You do not need to discuss all of your pink and blue categories. Instead, focus on the most important ones, making sure to provide concrete examples from your "affinity notes" to illustrate your points. Your goal here is to convince us that your findings are valid, by providing sufficient evidence from your affinity diagram analysis.
  • For each usability problem you discovered, brainstorm why you think these problems occurred and possible solutions for fixing the problems.
  • If the particiant agrees, post a video of one of the sessions to your team website.
• Reflection. Discuss what you learned over the course of the iterative design process. If you did it again, what would you have done differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: what features to prototype, what prototype techniques to use, and how to evaluate the results.
• A few sentences describing each team member's contribution to this paper.

Your report (including references and figures) MUST be no more than 10 pages long (anything over 10 pages will not be graded), following the CHI long paper format. Remember that you should make explicit references to course readings and/or lecture topics to show that you are able to apply those concepts. Also remember to carefully proofread your submission: Clarity, grammar, & spelling will be assessed. In addition, you must carefully organize your paper so that it is blatantly obvious how you are addressing all required component.

What to Post

• A PDF of your report. As an appendix, include the briefing given to participants (see T8).