CS 5340 – Human-Computer Interaction

 

 

[Syllabus] [Schedule] [Homework] [Projects] [Bibliography] [Resources] [Directory] [Acks]

 

Project (Team Assignments)

 

The following assignments are to be completed by teams and posted to your team web page by the start of class on the week due.

 

T1

Team Project Assignment #1 – Find a Team, Find a Project (3 weeks)

 

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 four 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 2-4 people. Teams will primarily be formed based on the results on the first brainstorming exercise and in-class discussion. You can also use the Directory or informal networking to find teammates. Ensure that at least one person on your team has solid programming skills, preferably in Java. 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 instructors can quickly find your assignments each week. Email the names of the team members, a name for your team and a URL to the team web page to cs5340@ccs.neu.edu.

 

Group projects will involve the design of health education interfaces for older adults users, to be deployed on a touch screen kiosk in the GAP waiting room. We will provide a group of older adults who will be available for testing your interface at the end of the semester.

 

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.

• The user interface must be interactive. A patient education system that simply displays a page of text or sequences through a series of pages would not be acceptable.

• Creative, original projects are preferred (within the constraints provided). Scan the bibliography of HCI for older adults and the list of research papers for ideas.

 

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. You can implement your interface in any language you like using any UI toolkit you like (including none), but it must run on garden variety PCs and the teaching staff may not be able to help you if you pick something too esoteric. 

  

What to Post

Your proposal should be about a page long, and include the following parts:

1. Problem. Describe the problem you chose and how the system will help users. 

2. Target users. Characterize the user population.

3. Solution. Describe a possible solution to the problem --- i.e., the interface that you envision, and how it will address the problem. You aren't absolutely committed to your solution, since you may find after building and evaluating some prototypes that a wholly different solution will work better.

 

T2

Team Project Assignment #2 – Task Analysis (1 week)

 

In this team assignment, you will start the design of your term project by doing the following:

 

User analysis. 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.

 

Task analysis. Determine the tasks of the problem you've chosen, analyze their 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. You should find and analyze at least 6 tasks. If you can't find that many tasks in your problem, try drilling down to more specific tasks, and consider exceptional and emergency tasks.

 

What to Post. Your report should be around 4 pages long. Include the following parts:

  • Title. Give your project a title, if you haven't already.
  • Problem. Briefly restate your problem.
  • Users. Describe each of your user classes and other stakeholders.
  • Tasks. Describe the 6 (or more) tasks you have identified. Every task should have a goal, preconditions, subtasks (if any), and exceptions (what can go wrong). Also include a paragraph describing other relevant features of the task, such as time constraints or frequency of use.
  • Problem Scenarios. For the 3 most important tasks in your task analysis, write a paragraph-length problem scenario: a concrete, realistic example of the task, following the examples in Rosson & Carroll Ch 2 (Fig 2.13).

 

T3

Team Project Assignment #3 – Activity Design (1 week)

 

In this team assignment, you will continue the design of your term project by exploring possible interaction metaphors.

 

Metaphors  Make a list of possible interaction metaphors for your interface, following the examples in Rosson & Carroll Ch 3, Tables 3.1 and 3.2. For each of your scenarios list at least two options for interaction metaphors and some of their implications.

 

Activity Design Scenarios  Transform each of your problem scenarios into an activity design scenario, documenting analyses of design features, following the examples in Rosson & Carroll Ch 3, Figures 3.4 and 3.5, and Table 3.3.

 

What to Post. Your report should include three detailed activity scenarios and a pro/con analysis of at least six design features.

 

T4

Team Project Assignment #4 – Design Sketches (1 week)

 

In this team assignment, you will continue the design of your term project by exploring possible design options.

 

Interaction Scenarios  Expand each of your activity design scenarios into full interaction scenarios, indicating what the user perceives and the actions he/she performs at each major step in the scenario, following the methods outlined in Rosson & Carroll Ch 4 & 5. Identify and document at least two special considerations for older adults (e.g., citing Hawthorne).

 

Preliminary interface design. Refine your interaction scenarios into a preliminary design. A preliminary design consists of one or more sketched windows or dialog boxes, along with the menus and controls that the user manipulates.

 

Storyboards. For each of your scenarios, describe how your preliminary interface would be used to perform the task. Use rough sketches to illustrate how the interface would look at important points in the task.

 

Take a little time now to brainstorm a variety of different interface designs, sketching them by hand on paper or a whiteboard. Then choose one that seems the most promising, or a combination of them, to hand in. When you draw your sketches, don't get bogged down in details like wording, icon appearance, or layout. Keep things simple. Focus on the model you're trying to communicate to the user, and think about your task analysis: what the user needs to do and how they can do it. Putting too much time into low-level details is pointless if big things have to change on the next design iteration. Hand-drawn sketches are encouraged.

 

What to Post. Include the following parts in your report:

  • Interaction Scenarios. Provide the detailed narrative text for each of your scenarios.
  • Overall design. Describe your preliminary design by presenting sketches of important windows, dialog boxes, and menu trees, and briefly explaining the function of each item.
  • Scenario storyboards. Present each of your scenarios in story form, including sketches to illustrate how your interface would look at important points in the task.

 

T5

Team Project Assignment #5 – Paper Prototyping (1 week)

 

In this team assignment, you will do your first implementation of your term project, which will be a paper prototype. Your paper prototype should be able to handle at least 3 scenarios. These scenarios may be the scenarios you described in T4; alternatively, you may want to choose different scenarios that explore the riskiest parts of your interface, which are the ones that will provide the most payoff from prototyping. You will test your paper prototypes on at least 3 users, TBD.

 

What to Prepare  Before testing your prototype, you should:

  • Build your prototype. Draw the static background, menus, dialog boxes, and other windows. Decide how to implement the dynamic parts of your interface. Hand-sketching is preferred.
  • 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. This is not a manual or quick-reference card. It should not describe how to use the interface. You will read this to your test users.
  • Write your 3 scenario tasks on separate index cards. 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. The tasks should be brief, roughly 5 minutes to run. You will also read these to your test users.
  • Choose roles for your team members. One person must play the computer and one should play the faciliatator. The other team members (if any) will be observers (although they may ask questions during the test if necessary). 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.
  • Practice running your paper prototype. Every 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. A few trials are enough. Make sure your prototype can handle the 3 scenario tasks you chose.

 

Testing Users  When you run your prototype on a user, you should do the following things:

  • Brief the user. Use the briefing you wrote up 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.
  • Present one task. Hand the index card 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.
  • Repeat with the other tasks. Run as many tasks on the user as you have time for. 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.

 

What to Post  You should post a report with the following parts:

  • Prototype photos. Digital photos of the pieces of your prototype. Try to show the prototype in an interesting state, not just a blank window.
  • Briefing. The briefing you gave to users.
  • Scenario tasks. The tasks you gave to users, exactly as you wrote them on the cards.
  • Observations. Usability problems you discovered from the testing, and possible solutions. Describe what users did, but don't record users' names. You must test at least 3 users. 

 

T6

Team Project Assignment #6 – Computer Prototyping (2 weeks)

 

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.
  • Medium fidelity in feel. This prototype will run on a desktop computer with a mouse and a keyboard. Also, 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 be able to handle at least the 3 scenarios you described in your task analysis. In addition, your prototype should include every major screen or dialog you expect to have in your final implementation.
  • Low fidelity in depth. Don't implement any backend. 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. Focus on Windoze for now.
  • Printing. You might pop up a window showing a mock up of what might be printed in a given situation.

 

After you hand in your prototype, it will be distributed to at least two of your classmates, who will do heuristic evaluations of it for individual homework I8 and give their reports back to you. Since your evaluators must be able to view and interact with your prototype, this puts some constraints on how you implement your prototype. If at all possible, implement your prototype as a Java applet that can be deployed off of your project web page. 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 is commonly available in one of the CCIS labs. If your prototype is unable to work under these constraints, talk to the instructor.

 

What to Post  You should create a separate web page for your evaluators (linked to your project web page, of course) with the following information on it:

  • A link to your prototype (your prototype must remain frozen and accessible at this location for two weeks after the due date).
  • Startup instructions. Specify the platform and browser requirements for your prototype. Give any special instructions for starting it up.
  • Briefing (from T5). The briefing you gave to users of your paper prototype describing the purpose of your application and background information about the domain.
  • User analysis, task analysis, and scenarios (from T2). 

 

Hint: You might think about getting a start on the project report at this point, see T9 below.

 

T7

Team Project Assignment #7 – Heuristic Evaluation & Prototype Revision #1 (2 weeks)

 

At this point you will have approximately one week before you receive heuristic evaluations from your classmates. During this time you can continue implementing the “back end” of your system, but should not make any major changes to the UI. After you receive the heuristic evaluations you should assign each of these problems a severity rating (cosmetic, minor, major, catastrophic), and brainstorm possible solutions for it. Modify your system to correct as many of the problems found as possible (in priority order), documenting how you do this.

 

What to Post   A link to your updated prototype and the report describing how you responded to the heuristic evaluations.

T8

Team Project Assignment #8 – User Testing & Prototype Revision #2 (1 week)

 

In this final group assignment, you will complete enough of the implementation to support user testing, conduct a user test of your interface, and write up the final results of the project.

 

User Testing  You will conduct user testing of your system. Prepare a briefing and three tasks. These may be the same ones that you used in paper prototyping, but you may want to improve them based on feedback from the paper prototyping. You may, if you wish, also prepare a short demo of your interface that you can use to show your users the purpose of the system. The demo should be scripted, so that you do and say the same things for each user. It should use a concrete example task, but the example task should be sufficiently different from the test tasks to avoid bias. The demo option is offered because some interfaces are learned primarily by watching someone else use the interface. Think carefully about whether your interface is in this category before you decide to use a demo, because the demo will cost you information. Once you've demonstrated how to use a feature, you forfeit the chance to observe how the user would have used it otherwise. Pilot test your briefing, demo, and tasks, before the user test session. Use another group member or another member of the class for your pilot testing.

 

Conduct a formative evaluation with each user:

  • Provide your briefing and (optionally) demo.
  • Then provide the tasks one at a time, observe, and take notes. One member of your group should be the facilitator of the test, and the rest should be observers. 

 

Redesign Collect the usability problems found by your user tests into a list. Assign each problem a severity rating (as in T7 above), and brainstorm possible solutions for the problems. Then, fix your implementation to solve as many problems as you can in the time available, giving priority to severe problems.

 

On 12/16 your team will give a 20 minute presentation of your project. This talk should include the following:

  • Problem. What user problem are you trying to solve? Who are the users? What are their tasks?
  • Demonstration. Demonstrate your design and implementation via a live demo of your system, working through 1-3 sample tasks. Discuss major design decisions.
  • Evaluation. Discuss the major findings from all three of your user evaluations (paper prototyping, heuristic evaluation, and user testing).

 

T9

Final Report

 

What to Post Your final project report should contain the following:

  • Problem. What user problem are you trying to solve? Who are the users? What are their tasks?
  • Design. Describe the final design of your interface, including any redesign you did after user testing. Illustrate with screenshots. Point out important design decisions and discuss the design alternatives that you considered. Particularly, discuss design decisions that were motivated by the three evaluations you did (paper prototyping, heuristic evaluation, and user testing).
  • Implementation. Describe the internals of your implementation, but keep the discussion on 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. Describe how you conducted your user test. Describe how you found your users and how representative they are of your target user population. Describe how users were briefed and what tasks they performed. Discuss the critical incidents you observed. Discuss any remaining usability problems that you didn't solve in your final design, and suggest solutions.
  • 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.

 

Your report should be 8 pages long, following the CHI long paper format. Post a PDF if possible.