HCI Project: Interactive System Design and Test

This project involves designing and testing a working mock-up of an interactive system that addresses a significant problem for a group of users, focusing on the theme of transportation. The project is divided into several deliverables, including a preliminary project proposal, background information research, paper prototype development and testing, and a final interactive prototype with user testing. Students will work in teams to create a system with a substantial user interface, informed by design methods discussed in class. The project emphasizes user analysis, task analysis, and iterative design, culminating in a final report and presentation.

Guidelines for Project:
In lecture and in the course readings, you are learning about the theories and issues that are
central to Human-Computer Interaction. Through this Project and related work in sections, you
will have the opportunity to put these ideas into practice. Using the requirements in this
document, set up a table of contents that can be used as a guide for the project. Of course,
there probably will be some changes, but at least you will have a starting outline.
The goal of this project is to design and test a working mock-up of an interactive system that
solves a problem of significance to a group of users. Therefore, your team will create a
working prototype, informed by the design methods discussed in class!
Here are some guidelines to help you develop your project proposal.
 Your project must have a substantial user interface. An information providing 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.
The goal of the project is to create a working prototype, informed by the design methods
discussed in class, of a system related to the project theme: Transportation
 The project will be done in teams. You can implement your interface in any software
or programming language you like using, any UI toolkit you like (including none),
even Power Point, but it must run on garden variety PCs
 This project accumulates information as the semester progresses. You cannot finish
the whole project in the last week. Your final deliverable builds on the initial
deliverables.
Project Deliverables and descriptions. All deliverables are to be uploaded to the team file
exchange area, include in the file name – the team number and the type of deliverable – for
instance – Team1PrelimaryProposal.
1. Preliminary Project Proposal – Due September 26th – posted both in the team file section
and the discussion board for review by colleagues.
Brainstorming and Idea Generation: This idea should be in the form of
1) a problem statement
2) a possible solution
Your brainstorming should help guide your team to a good idea that you will use to write up
your project proposal.

Preliminary Project Proposal: This should be a 1-2 page document describing the problem/need
your system will address, the specific tasks users will need to accomplish using your system.
You should also describe the target user population. It is important to note that you may need
to conduct some user interviews and tests during the course of the project, so make sure you
will actually have access to members of this target group (e.g., if your project is meant for
doctors to use, make sure you have some connections at the med school, or if your product is
aimed at children, make sure you have called some local schools to get permission to interview
and work with the kids, etc.).
Your project proposal must include the following three areas:
 The problem statement and the possible solution from your Brainstorming session.
 User analysis: Identify the characteristics of your user population. 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.
2. Background Information – Due October 3rd – 10 points – post in team file section
Description:
Complete this assignment after you have brainstormed with your group and you have decided
on a preliminary project proposal. This document will be more in-depth – build on the problem
statement.
Research current technological solutions to the problem your project seeks to address (use the
library, Google, etc). If the item is readily available (a common device, software with free demos
to download, etc), try using it yourself. If you can't use it yourself, the next best thing is to
interview one or more people who do use that technology. If that is also not possible, try to find
online newsgroups or reviews (include references for any interviews, newsgroups, or product
reviews).
Based on this information, write a critique of the existing solution, focusing on the strengths
and weaknesses of the interaction design.
 Briefly describe the problem as viewed by the creators of the technology, and the
solution they provide.
 Reflect on how you can apply the lessons learned from this system to the one you will
be designing for your project.

Your final critique should be about 2 pages long.
Target Population:
You are expected to interview at least 3 - 4 members (or one for each team member –
therefore, each team member should report on their interview) of your target user population
to ascertain their current needs within your problem domain and to learn about their
suggestions for how your system could be designed to assist them. This deliverable is a 1 - 2
page summary of your findings. Include, in an appendix, the questionnaire and process you
followed when conducting the interviews and identify tasks and themes that potential users
shared in their work practices.
Total deliverable:
 Documentation from proposal
 Review of existing solutions (if any) and how yours is different. If none exist, explain the
need for your solution.
 Summary of the interviews (what you discovered from them)
o Include the actual interview transcripts and questionnaire in an appendix – keep
the main document ‘clean.’
3. Paper Prototype – will set up a meeting with each team
Evaluation of Paper Prototype and Paper Testing –Before you test your paper prototype:
 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. (more below).

Practice running your paper prototype.
- 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.
Paper Prototype
Write a short description of 3 scenarios that your low-fidelity prototype supports.
When prototyping a system, it is often helpful to guide your design by keeping in mind the
scenarios that you wish your system to support. Guided by your initial user interviews and
storyboards, choose 3 scenarios that you will support with your prototype. Pick one easy
scenario, one medium, and one difficult scenario. For example, if one were designing a cell-
phone interface:
 Easy scenario: Fred wishes to call Annie. He picks up the cell phone, enters
Annie's phone number, and initiates the call.
 Medium: Annie wants to save Fred's phone number (since he just called her).
She picks the number of the last incoming call, assigns a name to that number,
and saves the record into her phone. \
 Difficult: Jennifer wishes to remind herself that she should call John at 9:20 am
three days from today. She adds a note, and sets an alarm for this note.
Then, construct a low-fidelity prototype to support these scenarios, following the directions in
the tutorial posted and Rettig's article. Your "paper" prototype may be constructed from
cardboard, paper, post-its, transparencies, etc. If appropriate, your prototype may include
more than just "paper".... it may also include constructions in prototyping environments that
allow you to use Wizard-of-Oz techniques to demonstrate or test your system.
Paper Prototype Testing. October 17th, in class
Before Testing: Turn the 3 scenarios you developed in your prototype into "task cards". For
example, if the scenario is: "Anna wants to call Bob", you can turn it into a task for your user by
writing "Place a call to your friend Bob (650-555-1823)" onto a 3x5" index card. Go through the
testing procedure using one of your teammates as a pretend user (aka guinea pig). This is a
good way to debug your test before you actually get your sample users. You should conduct
each of the 3 user tests in the same manner. A good way to do this is to write a script that each
team member will use to test your prototype.

During Testing:
 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.
The observer should make note of critical incidents (good and bad). If the user gets stuck,
scribble this down on your note pad, describing why he or she was stuck. If the user says,
"Wow! Cool," do the same. Remember, try not to help the users, unless they seem to be stuck
forever and throw their hands up in frustration.
Right after the session, you may give your user a questionnaire (or interview) to determine
various things: whether he/she liked the system, what parts confused him/her, or any
suggestions he/she may have for your system.
4. Due: October 31st – copy of Paper Prototype and testing report posted in the team file
section – 15 points
After Testing: After the experiments, collect your observations and assign severity ratings to
them. A table is usually a clear presentation of findings, and how to adjust the prototype if
necessary.
To maintain consistency, we will use these ratings:
0 -- Not a usability problem.
1 -- Cosmetic problem.
2 -- Minor usability problem.
3 -- Major problem: should fix.
4 -- Usability catastrophe: must fix.
Deliverable:
 Summarize your findings from your testing. Include the following sections:
o Documentation from background information (this is already done)
o Method (Participants, Environment, Tasks (verbatim))

o Results and Discussion (What did you learn? How will you change your
prototype? Is there anything that the experiments did not reveal?)
- Observations
- Severity ratings
5. Completed Project - Interactive interface
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.
 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.
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.
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.
 Similar to the Paper Prototyping, each team member must test the final interface
with a user.
6. Final Deliverable – December 5th – with Interactive Interface, documentation and
narrated Power Point – posted in both the team file section and the discussion board – 15
points
Write-up: Each group should turn in a written report which answers the following questions
(please structure your write-up as a list of explicit numbered responses to these questions, not
a combined essay). There should be a table of contents. There should be an appendix that
includes whatever additional drawings, screen shots, etc. you think are useful.
Sections of the Write-up (1,2,3 are completed already: some of the additional material should
have been collected during testing):
1. Briefly state the goal of your application. Who are the intended users? What
need will the interface address for them?
2. What existing systems did you use as inspiration or guides for your concept or
parts of your design? Say briefly what you borrowed from them and where you
added something new. Don't try to include everything that has something in
common, just ones that are particularly close to what you did, or from which you
used key design ideas.
3. What were the three scenarios (easy, medium, hard) that you used throughout
to guide your design?
4. What design priorities and usability guidelines were most important in your
design (learnability, functionality, ...). How was this motivated by your intended
user population and setting of use? How was it affected by your user testing?
5. Discuss important design decisions you made in the implementation. Also
discuss how implementation problems may have affected the usability of your
interface.
6. What is the most interesting feature of your interface from the perspective of
interaction techniques or applications?

7. Briefly describe the user testing you did (how many people, for how long, etc...),
and the most important observations from it that led to changes in your design
(or would lead to changes if you had more time). Don't make observations like
"people found it easy and liked using it." Focus on feedback that leads to specific
design changes.
8. Describe a challenging design tradeoff that you dealt with. Describe the
conflicting goals, and justify your final decision.
Please prepare a maximum of 5 PowerPoint slides with narration to:
1. Describe your project
2. Major design decisions
3. Lessons learned
***The three final files (prototype, documentation and narrated PowerPoint) will be
posted in the team file exchange area and on the discussion board to enable the other
students to evaluate your design.
SUMMARY OF DELIVERABLES:
1. September 26th – Preliminary ideas on Project
2. October 3rd – Project background information – report - graded
3. October 17th – Paper Prototype testing in class
4. October 24th – Results of Paper Prototype testing - graded
5. December 5th – Final report, prototype, narrated Power Point submitted in team file
section a discussion board. Presentation to class. - graded