Project Guide

Overview

The focus of this course is a semester-long project which will take you through several compressed cycles of designing, implementing and evaluating a user interface. You will do the project in groups.  The project  will be completed in several stages with weekly milestones. Each project group will present and demonstrate its project at a special event held during the last week of class.  Visitors will be invited to see the presentations. Be sure to keep up with the work, and frequently review work scheduled for upcoming weeks.

Project groups should consist of roughly four students. User interface design requires an exchange of ideas, and many of the evaluation mechanisms require several people. We will include activities during the first few class sessions to help people meet project partners and select projects. It is OK to have specialties within the group – for example, 1 – 2 people might take the lead on implementing the prototype, whereas 1 – 2 others might take more responsibility for written reports. However, all members must participate in all facets of the project, and must be prepared to discuss any aspect of an assignment at a weekly instructor meeting.

The application domain or problem shall be chosen by the group, but with the following key requirements:

1.                   The problem must be primarily an interface problem -- this is not the place to focus on computation or database solutions for which the interface is well-known or obvious.

2.                  The problem must be one for which your group can find at least two real users who are willing to work with your group.  At the minimum, these users must agree to spend an hour or two with you two different times during the semester  - early in project to educate you about their activities and later in the project when you will conduct user testing.  While this is a minimum, it is helpful if you can identify users who can be more flexible and meet with you for small blocks of time on an ongoing basis to provide valuable intermediate feedback on your designs.  Users need not be (and indeed ought not to be) special experts; the only qualification is that they already do the task your project will help support (or will once the project is completed) and that they not be members of your group. Furthermore, it is far better if your users are not your friend, roommate, fiancée, etc.  Past experience has shown that projects that use your peers as users do not turn out as well as those with "real" users (although this is often a problem with the project choice as much as it is a problem with the users).

3.                   The problem must be one that is suitable for the task-centered design approach we will be following in the course.  That rules out most applications where users interact without specific goals or tasks to accomplish.  For example, a purely decorative screen-saver would not fit.  Game-related applications should be reviewed carefully.  The instructor will help you determine whether a project is likely to work well, and I can often help you identify an aspect of a domain that interests you that would be suitable. 

The goal of the project is to learn how to design, evaluate, and implement user interfaces. It is the process and the user interface, not the application itself, which are being evaluated. For this reason, an excellent project might tie together (or wrap around) existing applications with poor interfaces. Some good projects also select a particularly ineffective part of an existing application and redesign and implement just that part.  (This is a common approach for dealing with existing web systems.)  Writing a complete, detailed application is probably a bad idea unless you are doing it anyway for other reasons.

You may implement the project in the tool/environment of your choice.  Successful implementations usually involve either high-level prototyping tools (e.g., Visual Basic, web development tools) or toolkits with which group members are already familiar (e.g., Java Swing).  You should be careful not to let ‘tool time’ dominate your efforts at the expense of usability engineering.

Some of the class discussion will revolve around your projects, and you will have several opportunities to evaluate and change your designs. Please bring your project materials to class each week. Also, please do not hesitate to ask questions both about the assignments and about how the class material applies to particular projects. The rest of this document lists the specific tasks associated with the project on a week by week basis.

Administrative Details

To help me keep track of project progress, one of the primary documents that you will turn in at the end of the semester is the project report log.  Every project report log will have the same sections that correspond to the weekly deliverables:

You should be building this report log over the course of the semester by placing a copy of each week's deliverables and notes that helped develop this deliverable into your log as you go.  Do not depend on using the copies that you submit, since I may not return this copy.

Weekly Activities and Weekly Deliverables

The following is a week-by-week listing of what we will be doing and what you are responsible to complete either as a team, or as individuals.  Unless otherwise noted, the deliverables are due at the start of "studio" on the Friday of the week it is listed.

For weeks where the deliverable is a written document from your team, this document should be emailed to me by noon on the day that it is used in studio and a paper copy that will be used on the document camera during the studio and used by me for evaluation purposes.

Week 1: It Bugs Me!

Think about the objects in your everyday world.  Is there anything about their design that bugs you?  For example, the clock radio on my bedside table bugs me.  The on/off/alarm switch has four positions.  Working from left to right they are [On | Off | Tone Alarm | Radio Alarm].  What this means is that it is very difficult to find the off position while groggy from sleep, in the dark, with my arm over my head.  A simple reversal of Off and On would have prevented this problem. 

Look around the room you are sitting in while you are reading this.  How many different specialized objects are there?  There are probably more than a hundred different specialized objects in my office.  How many of the objects around you are designed in a way that pleases you?

  1. The purpose of the "It Bugs Me!" assignment is to identify objects that bug you because of their design.  Make a list of this-bugs-me! objects from everyday life and computing.  You should have ten everyday and ten computing related objects.
  2. For each object, briefly describe why the design of the object bugs you and some ideas of how you would fix it.  I don't need pages and pages of details here.  Limit your response to roughly 50 words per object.
  3. Once you have made a list, categorize it using descriptive headings.  These headings should explain the type of thing that bug you (not what is on the list) and are best if they are "cross list" (in otherwords, some headings probably contain items from both your everyday list and your computer list.  List your responses under these headings.   Coming up with useful categorizations is part of the assignments.
  4. Turn in a copy of your list at the start of class on Friday, January 13th.  Also, keep a copy of the list with you for later.  I will ask for examples from your lists when we discuss Design of Everyday Things.
  5. You will be graded on the creativity and uniqueness of your responses.

Week 2: Project Ideas and team formation

This week, we will start generating project ideas and forming groups.  By the start of class on January 22nd (this is actually the start of week three), you must have formed a group and submitted a group information form including the e-mail address of each member and the project that the group will pursue. 

Week 3: Project Proposals; Reviewing Existing Solutions

The project proposal is due in studio this week. The purpose of this proposal is to summarize the problem domain, the existing interface or infrastructure, related interfaces of interest, and your plans on where to focus as a group. This is a critical step in the process, since it allows the instructor to ensure that the project is appropriate and to suggest changes if parts of the project are not appropriate.

Included in the proposal should be the following things:

The grade on the project proposal will be based on the evidence that you understand the project, the existing solutions, and the project environment. Length is not a good indicator of quality; excessive detail often reveals insufficient understanding and thought. Poor proposals, and proposals for projects that are rejected as inappropriate, can be revised and re-submitted before our next studio.

Week 4: User Visit Plans

This week we will talk about how to gather data from users.  Next week, you will meet with your users to learn from them.  This week's deliverable is to think through what you want to learn and how you will learn it.  In studio this week, you should submit a set of written plans for user visits, with specific goals, approaches, people, dates, and times. You should have a very general ‘script’ which indicates who will ask or observe what in what sequence. You should also decide what types of notes you will take (and whether you need to prepare note-taking forms). You should, of course, be opportunistic during the actual visits, but you should at least imagine and document a possible scenario for this visit. This document can be informal.

It is not necessary for each group member to attend each user visit. However, each group member must participate in at least one visit. Also, recognize that the number and duration of user visits may vary greatly by project.  Remember that you need to build a relationship with these users, in part to help ensure their cooperation later in user testing.

The user visit plan will be graded based on the amount of thought you have given to the visit in general and the particular goals and methods appropriate for your project. 

Week 5: User visit reports; Task Analysis

This week you submit a report on the user visits you carried out and a semi-formal task analysis for the project.

The user visit report should include the following:

The task analysis should include the following:

During this week's studio, you should be prepared to discuss what you learned from the analysis, including any changes in your conception of the project. This discussion will be a major part of the meeting and will be graded.

Week 6: Revised Project Proposal

For your deliverable this week, you should prepare a revised project proposal based on what you learned from your user visits.  This proposal should follow the format of the original proposal, but should provide more detail (roughly one page of description, including a rough description or drawing of your interface ideas; also one page on existing interfaces with a more detailed description of why your design meets an unmet need)

It is expected that you will make reference to principles from the readings to explain why you believe your ideas will result in a good interface.

Week 7: Paper Prototype

NOTE: That this deliverable will be a three day studio starting on WEDNESDAY of Week 7.

Week 7 is a major checkpoint in the project. Your group must submit its first prototype -- a paper prototype. The prototype should illustrate the basic components of the interface with sufficient detail to walk through the interface looking at navigation (labels and icons) and consistency. Ideal prototypes will be paper sketches or print-outs from a drawing program; you may build an executable prototype, but if you do you must print screen shots from it to proceed on paper with the initial analyses.

There are several reasons for building a paper prototype first. First, it will give you an easy way to get significant feedback on your ideas before spending the effort to implement them: remember that it's easy and cheap to make changes early in the design process, hard and expensive to do so later. Second, it allows your group and your instructor to discuss issues related to design, prototyping, and the project. Also, building your prototype now allows it to evolve as you start the process of revision, a key to creating an effective design.

You should be prepared to have a non-member of your team complete one or more tasks using your prototype.  You should also be prepared to discuss the ideas behind your design and why your interface design is likely to be a good one, referring to principles from the readings and to the results of your problem and task analysis. It is acceptable at this point to have more than one prototype. You may have a group consensus on which one is favored, but it is may be that different prototypes will have different patterns of strengths and weaknesses. You should be prepared to compare and contrast any ‘competing’ prototypes in a knowledgeable way.

By this week, you should also be preparing for your executable prototype. While you still have plenty of time for development, you need to decide upon and become comfortable with the development tools you plan to use.

Week 8: Scenarios for User Tasks

Based on your current paper prototype, you must write up detailed scenario descriptions for at least three of your project tasks (including two of the tasks for which you have current scenarios from week 5's task analysis). You should include an up to date and numbered/labeled prototype.  The scenarios should be expressed in terms of standard interface widgets/concepts and should reference specific screen labels when screen changes occur (e.g., "press the button marked ‘GO’ ," "pull down the menu labeled ‘FILE’.," "follow the 'Schedule' link.  This takes you to screen 13," or "Go back.  This takes you to screen B")   The scenarios should be expressed in terms of your user interface. A guideline for evaluating a scenario is that a person familiar with the type of software (e.g., web, windows) but not familiar with the task should be able to follow it.

You are required to submit two complete copies of both these scenarios and an updated paper prototype (since you may discover that there are steps for which the prototype may have been inadequate).  These copies will be distributed to the other two teams for use in the deliverables for week's nine and ten.

Week 9: Cognitive Walkthrough Evaluation Report (Not your interface)

This week's deliverable will be the first of two deliverables that you will perform using a project other than your own.  At the start of week nine I will assign each group some other project that they will be responsible for evaluating during week nine.

Using the project you were assigned for week nine, and the cognitive walkthrough approach, step through at least three scenarios submitted by the other project during week eight.  At each step, you should ask the four questions from section 4.1.3 of TCUID along with the question "Is there another control that the user might select instead of the correct one?" (You may find it useful to assign individual group members to certain questions for the duration of a scenario.) Keep a log (separate from your report) of each walkthrough. You should then write up a list of interface problems discovered during the walkthrough, with a brief note about how you discovered them (e.g., direct result of a particular step in the walkthrough, follow-on discussion based on an issue raised in the walkthrough, etc.).

Finally, make a list of your ideas for improving the interface (both to resolve the identified problems or for other improvements) . These need not correspond individually with problems--some broad re-designs can address several problems.

On your own project, you should be starting work on your executable prototype.  While you have three weeks before it is due, and you will likely make design changes before that time, you should be building the necessary infrastructure for the application. 

Week 10:  Individual Heuristic Evaluations; Heuristic Evaluation Report (Not your interface)

This week's deliverable will be the second of two deliverables that you will perform using a project other than your own.  At the start of week nine I will assign each group some other project that they will be responsible for evaluating during week ten.  Note, this will be different than the one you were assigned for week ten.

Each group member should individually complete a Nielsen-style heuristic evaluation (see section 4.3 of TCUID) using at least the first nine heuristics (help and documentation are optional at this stage). You should each maintain a log of the problems you find, along with a brief note about how you found it. A copy of this log will be turned in to the instructor for grading. The assignment will be graded individually based on the thoroughness of your individual evaluation.

After each member of your group has completed the individual evaluation, your group should meet to combine your individual heuristic evaluation lists into a single list of usability problems. The list should be organized in a manner that makes it easier to address related usability issues together. Once you have a combined list, annotate it with possible solutions and improvements. Note: The group should set a deadline for individual evaluations to be complete -- if a group member has not completed the evaluation in time for the group meeting, the rest of the group should proceed; that member will receive a substantially reduced score.

Week 11:  Individual Plan for User Testing, Group Plan for User Testing

Each group member should write a draft test plan for your user testing. The test model should include asking users to accomplish tasks while thinking aloud, but may include other techniques as well. The test plan should, at a minimum, include the following:

Finally, the group should get together and create a single group test plan, drawing the best from each individual test plan, that includes all of the above along with identification of the users, the time and place for user testing, and the role that will be played by each group member in each user test. 

Week 12:  Coded Prototype

 NOTE: That this deliverable will be a two day studio starting on MONDAY of Week 12.

Your first running prototype is due this week. You must be able to demonstrate it during studio so you either need to bring your prototype on a laptop or a complete executable which can be run off of mine. During studio you will demonstrate the prototype, and discuss issues that arose in implementing it. In particular, be ready to discuss and step through the usability problems identified in the non-user evaluations (the cognitive walkthrough and heuristic evaluations). For each problem, you will need to explain whether and how the problem was addressed and why. We will plan on spending two class periods on this studio.

Week 13: User Evaluation Report, User Evaluation Video, Prioritized Change List

During the preceding two weeks you will have conducted your user tests.  During this week's studio you will have a chance to discuss what you learned from these tests, using several different techniques.  You will submit the following items as a result of user testing:

Week 14:  Plans for Presentation

NOTE: That this deliverable is due on WEDNESDAY of Week 14.

You should bring an outline of the presentation you plan for the open house. This outline should include:

Week 15:  Presentation; Final Implementation, Code, and Documentation; Final Report; Individual Retrospective

On Monday, April 23rd, we will hold a class open house during the class time slot. You will need to arrive about 15 minutes before the open house to set up your station.  Each group should set up a demonstration of its interface and a poster highlighting the design and the key interface decisions.  The presentation provides an opportunity for you to present your project to a wide audience including other students, faculty, and your users (if you choose to invite them). The instructor will use the presentation as part of the project evaluation.

On Friday, April 27th, we will meet for the final studio.  You should bring the following:

 

 

Grading and the Individual Multiplier

The project is the focus of this class and more than half of your grade in the class (approximately 65%).  A small part of the grade will be allocated to individual grades for specific components. The remaining points will be assigned as a series of weekly group grades, and a final group project grade. 

In order to provide me some flexibility in assigning grades when I feel that individuals have carried a group, or worse yet, let the rest of the group carry them, I will be assigning each student a multiplier for the group points.  If every member of the group contributed fully to the project, each student will be assigned a multiplier of 1.00.  That is, each student's grade will be calculated based on the points the team actually earned during the semester.  I expect to assign each student a multiplier of 1.00.

If members of the group did not contribute fully, they may be assigned a multiplier which varies from 1.00.  Except in highly unusual cases, individual multipliers will not be more than 1.20 and not less than 0.80.  My judgment of contribution comes from observation, from the quality of participation in group meetings with the instructor, from knowledge of the project during presentations, and from the group self-assessment.

TIMELINESS IS IMPERATIVE! The project becomes more time-consuming as weeks go by, and projects that get behind will have great difficulty catching up. Each group may have the project items due extended one week without penalty one time only on the condition that the following week’s tasks are completed on time. Other lateness will be penalized at a rate of 5% of the total project grade for each week during which the project is not on-schedule. No extensions of any type can be given on the project presentation or final project submission.

 

Potential Problems

As is the case in real-world teams,  teams may encounter problems including team members who drop from the course, non-contributing team members, and disputes among team members. I am willing to help moderate discussions among team members, but please remember that some inequality of effort and ability is natural. Projects should not be so time-consuming as to require 100% effort from every team member. A good team should have one person more than is strictly necessary for completing the project.