CMSC 434 - Spring 2009
Prof Bederson

Introduction to Human-Computer Interaction

Project Description

The course project centers around the International Children's Digital Library (ICDL).  I will assign groups of 3-4 people, and you can define any project you would like following the project theme.  The primary goal is to design, create, prototype and test a tool that will enable and encourage people to add a feature to the ICDL.You can pick any web technology for implementing your project, although I suggest (and will briefly teach) JavaScript and the JQuery AJAX library. You will be given access to a MySQL database with the metadata about the library, and scans from sample books.

During phase #0 and #1 you will focus on the "Definition" and "Analysis" steps of the design process. In the next few weeks, your team will need to identify actual users for your 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.

Key challenges:

• Developing the project in a way that focuses primarily on user goals, with technical constraints and personal preferences being secondary.
• Developing a useful project idea - for some users, who you define.
• Designing something new and unknown under a deadline.

Sample projects.  You are free to define any project that fits within the context of the ICDL, but here are some possible ideas to get you started.

1. Book readers - audio, notes, different content types
2. Social - safe discussion
3. Education - activities
4. Translations - quality assurance

Phase 0:  Proposal (10 points) - Due February 24, 2008

Decide what problem you want to work on. Since you have not yet explored the design space or talked to users, your focus should be on the problem, not the particular system you're going to build. Thus, there should be nothing of the form, "We're going to build a ....".

Your report should include the following:

1. List names and preferred email addresses of all group members.
2. Describe in 1 or 2 paragraphs the problem you are attempting to solve
3. Describe in general terms who your expected users are

Scoring will be based on the quality, difficulty, and sophistication of the idea. An original idea that shows independent, creative thinking, and captures the intent of the assignment will get a higher score than one that would seem fairly obvious to anybody taking the class.

Email your submission (1 per group) to the TA with "434-proj0" in the subject line.

Phase 1:  Goals / Personas (100 points) - Due March 10, 2008

1. (45 points) Interview representative users.
   • If actual representatives are available to interview:
     • Perform 3 face-to-face interviews with people who could reasonably be expected to use your target system.
     • The goal of the interview is to determine the interviewee's user goals as they relate to your project, and to better understand the potential problems you may face in designing an effective system.
     • Interviews should last at least 15 minutes.
     • For each interview, assign a fictitious first name (pseudonym) to the interviewee, for use in your reports.  Never include information in your report that could be used to personally identify your interviewees or test users.
     • In your report, for each interview, include the following:
       • Interviewee's pseudonym
       • Time, place, and duration of the interview
       • A list of at least 5 topics discussed and the interviewee's point of view on each of the topics.
   • If there is some obvious and compelling reason why actual donors or recipients are clearly not available due to the nature of your project, explain why this is so.  For example, maybe your users are all super-busy billionnaires or your beneficiaries are all children that you do not have access to. However, if you can't interview in person, but you can reach the person electronically, then conducting an electronic or telephone interview is acceptable. If you cannot do in-person or electronic interviews, then for each of the missing interviews:
     • Consider finding someone that does know about the user - perhaps an existing organization, or someone who for some reason has knowledge of the problem you are trying to solve.
     • Use a minimum of 3 sources and give references, including URL, name of site/publication, and date of information.
     • Write some key questions you would like to ask them, and how you think they would answer.  For each answer, give quotes or other examples based on your research.
2. (30 points) Personas
   • Define a primary and secondary persona for the users you are targetting
   • List 6 user goals and specify which of the personas (or both) each goal applies to.
3. (15 points) Risks
   • Provide a list of at least 5 potential problems, you might face in designing and deploying your system.  For each risk, specify why it is a concern, by referring to an interview (best) or common knowledge.
4. (10 points) In-class presentation
   • In class on March 10th, your group should make a short presentation (max 5 minutes) that describes the essence of your project.
   • Be sure to introduce yourselves
   • Give each group member a small part of the presentation.  I want to hear everyone's voice
   • Describe the problem you are solving
   • Describe what you learned from interviewing the representative users
   • Feel free to say anything else about what you have learned or done so far - except:
   • Do not describe your solution.

Submission guidelines

Although turn-ins will be electronic, your goal should be to produce a document that looks professional and will be presentable in paper form.

• All materials should be included in a single PDF (preferred) or DOC file.
• If possible, hand-drawn or other non-digital materials should be scanned and included digitally in a way that preserves readability.  If that cannot be accomplished due to size or other technological constraints, then you may turn in just those non-digital materials as an appendix, and include a full page in your report as a placeholder for the missing material with a message such as "See appendix A, submitted in class on 12/31/2009".
• Many free options exist for creating PDF files (e.g. CutePDF, OpenOffice, and various online services).  If you need help creating a PDF file, see the TA
• Your report should be neat, readable, and easy to navigate.
• Include a table of contents at the beginning.
• Put everything in the same order it appeared in the assignment description.
• Include page numbers at the bottom of each page.
• Use headings, bold type, and numbered/bulleted lists, as appropriate.
• See the TA if you need help with accomplishing any of this in Word or OpenOffice.

• In addition to completeness, scores will be based on the logic, sophistication, and clarity of your answers.
• Email your submission (1 per group) to the TA with "434-proj1" in the subject line.

Appendix 1: 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
• Is 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.

Good user interview report:

Note: This example pertains to an interview that seeks to study what people are already doing. Since this semester's project pertains to a new system (as opposed to a direct improvement on something existing, your report will be a little different. These are included in order to give you a general idea of how interviews can be conducted and described.

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 and 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.