CMSC 434 - Spring 2006
Prof Guimbretiere

Introduction to Human-Computer Interaction

Project phase #1 (due 02/23/06)

Gathering users goals

Overview

During phase #1 you will focus on the "Analysis" and "Definition" steps of the design process that we are studying in class. In the next three weeks, your team will need to identify actual users for your target application, interview them about which goals they are trying to accomplish, and understand the context in which they are accomplishing these goals. Based on these pieces of information, you will then be able to identify key personas and their goals.

What do you have to do

Generating a list of expected users, and an initial list of tasks.

In this step, you interview knowledgeable people about their real-world tasks and observe them doing their tasks. Your goal is to generate an initial list of concrete task descriptions.

1. The ideal: Interviewing users. Get in touch with current or potential users. Ask them about why and how they do key activities related to your project, and what they expect out of your system. Ideally, this interview will occur while you are observing them performing these activities. These interviews and observations will give you some contact with customers and give you a feel for the real situation. This is more important than you think, for it will make you realize that ‘the user’ is not an abstract notion, but real people with real needs and concerns. It will help you put a face on the faceless, and will help you understand where they are coming from.

2. A reasonable alternative: Interviewing user representatives. When you cannot get in direct contact with end users, you can use user representatives instead. These will be people who have the most knowledge of the users' needs. Examples are help desk people, or a worker's manager. However, it is crucial that the client representative has a deep and real (rather than idealized) understanding of what the users actually do. People who work "in the trenches" with the users are the best bet.

For whatever approach you chose, do the following steps:

1. Have the user/representative recount a few (3-4) stories that typify the actual use of their system and/or process. Where possible, have them describe other people involved, the particular problems he/she wanted to solve (i.e. their goals), the steps taken in the actual process, the constraints he/she had (e.g., time), what was produced, and whether he she was satisfied with the outcome and why . All details are relevant. Alternatively, the task could be derived from direct observation of user/representative doing their work. For example taking pictures of how users use, annotate, store, and more generally interact with books might be a great way to document key aspect of current paper book interface.

2. On a more general and less detailed level, list as many related tasks and their variations as possible.

3. There will be many task variations in the list. Identify (with the user, if possible) which tasks are frequent, which are infrequent but still important, and which are rarer and not very important.

At this point, you will have a set of concrete, detailed examples of user tasks. Each tasks description should have the attributes described in the appendix and the second reading (see attached).

Because it is unrealistic to meet all requirements and address all users, it is your job to prioritize them. From your interviews (and possibly by further discussion with end users), identify 2 to 3 typical users and they primary goals while interacting with the system. Each goals should be prioritized into a) absolutely must include; b) should include; and c) could include. Similarly, rank your personas. Note that goals are not tasks: they do not depend on any specific implementation. The following reference might be a useful source of inspiration: "Perfecting your personas" by Kim Goodwin.

Validating your findings

The next step is to get a reality check of your goals list for each persona. First, for each persona, identify the user which is closer to that persona, and present him/her your goals list, observing his/her reaction and taking note of possible improvement. The user should check to see if the your list of goals capture the variations of those done by real people, and if details are realistic (they will be, if they are based on real customers!). You should ask for details that were left out of the original goal description, get corrections, clarifications, and suggestions, and then re-write the goal descriptions.

Note: This step is critical if you used a user representative instead of a real user. While it may not be possible for you to interview and observe many real users, you can probably get one to comment on a compiled list of goals.

Deliverables

Your group will deliver a portfolio written to the imaginary vice-president of your company. The portfolio will include the following sections.

Section 1 (40 points): Analysis phase (user interviews)

1. Introduction. Overall description of your group investigative process

2. Result of your user study. This section should describe the result of your interview in detail including:

   • Who you interviewed and why you interviewed them. This part should describe how each interviewee  relates to the system (for example, a UMD undergraduate renting 6-8 movies a month,...). In order preserve the privacy of the interviewees you should not gather private information such as name, ID and the like.

   • When and where you interviewed them

   • A summary of the interview including the key topics which were discussed and the corresponding findings. You can include quotes, sketches and pictures if necessary. Example can be found in Appendix 1 bellow.
      

3. Wishes list. After a first round of interviews, it is often the case that one wishes one had more time to interview more users. It is important to document this part so that this information could be used in the next design cycle. Your report should include a 1-2 paragraphs description of your wish list.

Section 2 (40 points): Persona and their goals

1. Introduction. Describe in general terms the background of the system. You should describe (in general) the expected users, their work contexts, and what they will use the envisaged system for.

2. Description of key personas for your system. You will list between 2 to 3 key typical users (personas) of your system. For each persona you will provide a description of this persona (as narratives or otherwise), including:

   • Who they are (typical age, socio-economic background, education level, possible disability...)

   • Their goals while using the system. Each goal should be described in detail and should refer to factual evidences gathered during your discussion with users. You should include between 3 and 5 goals for each persona ordering them from the most important (i.e. frequently done and important, infrequently done but still important, rare and not important, etc) to the least important.

   • How important this persona is for your design.

In this part it is important that you explain how your group reaches it conclusions. As you explain persona and goals you should reference key evidences (such a picture, user quotes, user stories...) which lead you to your conclusion. In particular please note how users reacted to the goal description during the validation phase.

1. Introduction. Using the result of your interview as a starting point, provide an overview of the source of user frustration using current system (or system closely related to you system).

2. Storyboarding key interaction breakdowns. Pick two of the most frustrating experiences described by the users you interviewed and create a 4x2 cell storyboard of this experience. Your storyboard should be self-contained but might include a short introduction paragraph setting the stage.

3. Conclusion. Describe the conclusions you drew from these interaction breakdowns and how they will influence your design.

Notes

The portfolio is intended to document the progression of your design, which includes your final project. Your portfolio must be neat, well-organized, and visually appealing. Portfolios should be constructed out of a 1" or smaller 3-ring binder (we will not appreciate having to carry around larger binders). Your portfolio should also use titled section separators to separate the major sections. The cover of the portfolio should include the names of the group members, the group number, and the title of the project. The first page should be a table of contents, which will grow over time.

Each group should be prepared to give a 10 minutes presentation of their portfolio during the class when the project is due. The presentation could be made either using PowerPoint slides or by using material provided in the portfolio.

Grading

Grading will be based upon the sophistication, logic and maturity of the presentation, and the completeness of the work.

Appendix 1: Good user interview report

Good user interview report:

• Says what the user wants to do but does not say how the user would do it

  • you are not to make any assumptions about the system interface

  • we will eventually use this to compare different interface design alternatives in a fair way
     

• Are very specific

  • says exactly what the user wants to do

  • we will eventually use this to specify the actual information users would like to input to a system, and what information they would like out of it
     

• Describes a complete job

  • should list all aspects of the task, from beginning to end

  • this forces designer to consider how interface features will work together

  • we will eventually use this to contrast how information input and output is carried through the dialog, i.e.:

    • where does information come from?

    • where does it go?

    • what has to happen next?
       

• Says who the users are

  • use particular people, if possible

  • reflects real interests of real users

  • the success of a design is strongly influenced by what users know and their real work context; we will eventually use this information to see if people realistically have the desire, knowledge and/or capabilities to accomplish their task with the system.

Example task description for a clerk in a video store, including discussion. The eventual system will assist the clerks to perform their tasks.

Mary Farness, an experienced full-time clerk at the video store, opens the store in the morning. She begins the day by checking in all the videos returned in the night video slot, which typically number between 90 to 150 videos. She pauses her task whenever customers ask for her services. She usually checks in ten videos, and then reshelves them before going onto the next ten.

Discussion. In this case, the "user" is the full time person who normally carries out this task. We expect them to be typical of an experienced clerk who will know the process well, and who will become well practiced at using the target system. The task is routine and frequently done.

George Marlay, a regular video store customer, approaches Mary and asks if they have the Frankenstein comedy video. She asks if he mean "Young Frankenstein" by Mel Brooks, and he says yes. She then directs him to the shelf where the video is expected to be. George retrieves the video card and brings it to the front desk. Mary asks for George's membership card, but George has forgotten it. Mary then looks up his membership number. Mary checks out the video, but reminds George that he has not yet returned the video "Brazil", which is now a day late. George says that he will bring it in later today, and leaves with the video.

Discussion. This task contains many typical clerk activities, which deals with vague requests about video titles, the location of the video in the store, forgotten membership cards, the video checkout activity, as well as reminders to customers about late videos. Most of these tasks are frequently done, and are important.

Anil, a part time clerk who works the telephone, comes in for an hour every third evening. His job is to search the rental records to find customers who are at least one day late on their video returns. For example, he phones Bob Jakobs, who is two days late. Bob answers, and Anil identifies himself, tells him that he still has the video "Volcano", and reminds him to return the video. Bob says he will bring it back in an hour or so, and Anil crosses his name off the list. He then phones Ania Sliven, and says (more or less) the same thing. However, Ania says that she has already returned the video the day before. Anil puts her on hold, runs to check the shelf and finds the video there. He apologizes and hangs up. He then phones Ang Lee, but there is no answer. He notes on another list that he should try this person again later. He continues in this manner. When he has finished the list, he starts again on those who have not answered.

Discussion. This task identifies a specific activity that is less frequently done but still quite important. It also indicates that a non-regular staff member may be doing this task.

Why these are good examples:

• They say what the person wants to do, but does not say how it will be done. For later exercises, we can use these examples to see if a particular system would allow the person to accomplish their task.

• They are specific. They say exactly what type of information a person is bringing in to the task, exactly what information the person wants out of it, and how the person will use it.

• They describe a complete job. When we test a system, we can actually follow this sequence of events and see the amount of work that has to be done to get from one step to the next.

• They say who the user is. In this case, they identify particular people, their experience, and what knowledge/experience they have in their head. Again, this has implications to eventual use of a system.