School of Computing
100 McAdams Hall
Clemson, SC 29634
CS-3750 Section AInstructor: Chris Plaue (chris.p@gatech)
TA: Hyungsin Kim (hyungsin@gatech)
Meeting Place: Klaus 2443
Meeting Time: Spring 2009 MWF 9:05 AM
Broadly stated, there are four goals for this class:
1. Understand the principles of user-centered design and how to apply them to a software-based project.
2) Understand the history of human-computer interaction and how it's changed over time.
3) Explore why "good" interface design is not necessarily "common sense"
4) Utilize skills and knowledge from other disciplines in developing a software-based project.
Course Policies & Reading Schedule: syllabus_v0.pdf (pdf document) as of 1/5/2009
Course ProjectDuring this semester, you will undertake a group project (approximately 4 people per team) to:
The goal of this team-based project is to provide you with hands-on experience with the tasks that interface designers face everyday. The topic of the project will be a problem that relates in some fashion to healthcare and should be a problem that matters to some “real-life” people. These people will serve as your “clients”, whom you must communicate with and learn from. We will be providing a list of possible projects for you to consider or you can come up with your own topic. If you chose the latter, you must get it approved a priori. It is you responsibility to contact the clients for your project. They will not come to you.
Each project group will be graded as a team, that is, each person receives the same grade. Individual group members will be polled to make sure that all team members are contributing. Lack of participation may precipitate an individual reduction of grade. Recall, the group project is over 40% of your final grade.
Within the team, you must negotiate on how much and what each person will contribute. There are many factors that must be discussed at the beginning of the project to ensure that things go smoothly. Such factors include:
It is in your interest to work together and discuss issues. If problems arise with group dynamics, it is your duty to first attempt to work them out before approaching the instructor or TA. However, be warned that waiting too long to seek outside help resolving inter-group conflict will most likely adverse your project and deliverables, which is a large portion of your grade. Many group problems cannot simply be fixed at the last minute.
In my experience, self-selecting student groups tend to be unbalanced. Similarly, randomly generated groups often have similar issues. For this project, we will be using a hybrid system. One class period will be reserved to allow students to introduce themselves to the class, present any potential project ideas, list interests, and talk about their particular strengths.
You will be allowed to specify one person you want to be on your project team and optionally, one person you’d rather not. These votes will be kept strictly private. The instructor and TA will then match up teams of approximately four individuals and try to accommodate all requests, but these requests are not guaranteed.
Each part of the project will include a deliverable report. This report will be placed on the WWW and should be written in HTML. Each team should have a home page that includes: 1) a brief (paragraph) description of the problem/task; 2) the team members; 3) Links to the reports for project parts 1-4 (no report is needed for part 0). The format of the reports for the individual parts is up to you, but it should be professionally prepared, expressive, grammatically sound, illustrative of your efforts and process, and easy to view and understand. A good design effort can easily be hampered by a poor communication of what was done. We will help you get space for your pages and get this all set up.
Part 0 - Topic Definition
This first part of the project is relatively simple. You must list the members of your team and identify the problem that you will be working on. You also must set up your web project space that lists your team name, members, and provides links to all of the project deliverables. Work with the TA to set this up.
You may use your own personal domain for the web project space.
Part 1 - Understanding the Problem
The key goal of this first substantive part of the project is to deeply understand that problem that you are addressing, its set of pertinent users, and the issues and constraints that are involved in the problem. If the task has an existing system/interface, you should perform an interpretive evaluation of that system to help you learn more about it. Most important is identify important characteristics of the problem that will influence your subsequent design.
In class we will discuss different techniques for acquiring this kind of information. Feel free to utilize the techniques that you feel are most appropriate to the particular task you are examining. Your report and deliverable for this part should deeply examine the problem of study. Who are the potential users? What tasks do they seek to perform? What functionality should the system provide? Basically, you are setting up a set of constraints for your subsequent design. What criteria should be used to judge if your design is a success or not?
More specifically, you should develop the following items in this part, and you should communicate them through your report:
• An overview of what they system will do and why it's needed.
• A description of the important characteristics of the users of the system.
• A task analysis consisting of:
o A description of the important characteristics of the tasks performed by users.
o A description of important characteristics of the task environment.
o A simple structured task analysis of the problem in one of the forms described in the textbook.
o An interpretive evaluation (eg., heuristic evaluation, walkthrough, etc.) of the existing system/interface, if one exists.
o A brief description and justification of how the above information was gathered.
• Most important: A discussion of the implications of what you learned above.
The last item in the list above is critical. Don't just describe the target users, tasks, environment, etc. You must also tell us how these attributes should/will influence your design. Are there any implications to be made from the user profiles and other data you learned? We will be very careful to look for this information in your report.
Part 2 - Design Alternatives
The key goal of part 2 of the project is to use the knowledge gained in part 1, as well as that from class, to develop a set of design alternatives for your problem. These multiple design alternatives should explore the potential design space for the problem.
In this part of the project you will develop mock-ups, storyboards, and sketches of your interface designs. That is, you should provide pencil-and-paper or electronic images of the interface at various stages; you do not need to build a working prototype. Your design sketches should be sufficiently detailed for a potential user to provide useful feedback about the design, however. Along with your design mock-ups, you should provide a brief narrative walk-through of how the system will work. Perhaps most importantly, you should also include your justifications for why design decisions were made, and what you consider to be the relative strengths and weaknesses of your different designs.
The design process you follow here is important. Don't do the following: The group splits up and everyone creates one design, then these are all your alternatives to be turned in. This is not how a good, creative design process should work. It should be more like a brainstorming session with all team members present. You should seek to create some fundamentally different design ideas, concepts all over the potential design space for the problem you have chosen.
Your project report should include all the explanatory material mentioned above as well as all the design sketches, drafts, storyboards, etc., that you generated. If some of your sketches are on paper, we will provide you with access to a scanner to scan in these images. Make sure that your report adequately reflects the design process that your group undertook. The key in this part of the project is to come up with many different design ideas, not just a small set of wiggles from some basic design. You should plan on turning in at least three different designs.
We will utilize one full class day as a poster session near the end of this part of the project. Each group will post some of their design ideas on a poster in class. Everyone will then circulate and interact with the designers. The idea here is that each group can use this opportunity to get feedback about their design ideas as they narrow their design space and head into part 3 of the project.
Part 3 - System Prototype and Evaluation Plan
In part 3 of the project, your group will implement a detailed prototype of your interface. You can use any software that you would like to assist this process (e.g., VB, Flash, Hypercard (if you can find it!), Director, etc.). You should be able to get much of the interface functionality working, but clearly you will not be able to implement all back-end application functionality.
Additionally, you must provide a set of initial usability specifications for your system and a plan for an evaluation of it. To develop usability specifications, consider the objectives of your design. For example, if you are working on a calendar manager, you might specify time limits in which you expect a user to be able to schedule or modify an appointment, or a maximum number of errors that you expect to occur. Basically, you should list a set of criteria by which your interface can be evaluated.
Further, this part of the project should include an initial evaluation plan for the system. What kinds of benchmark tasks would you have users perform to help evaluate the interface? What kind of subjective questionnaire would you deploy to have a user critique the interface? You will need to actually carry out some of this evaluation in part 4, so you should do your best to set it up now. The key here is not to do some exhaustive description of a usability evaluation plan, but to motivate why the particular plan you propose is appropriate for this interface.
Note that developing an initial evaluation plan is also a good way to figure out how much of the interface you need to develop. You should be able to build and connect to enough of the application functionality to be able to conduct an initial usability evaluation with the benchmark tasks as you are proposing here.
Your write-up for this part should include a description of your system prototype. You can include screen dumps to help explain it and text to describe how a user would interact with it. Discuss the implementation challenges you faced. Were there aspects that you wanted to build but were unable to do so? The key component to include in your project report is a justification of why you settled on the design that you chose. What's special about this particular design with respect your problem?
The report for this part also must include the usability specifications that you established and a description of the evaluation that you are planning. This needs not be too detailed here as the actual evaluation will occur in part 4. We will try to give you helpful feedback about your plan here to assist with the testing in part 4.
After this part is complete, each group will demo their system for the instructor and the TA.
Part 4 – Evaluation
In the final part of the project, your group will conduct an evaluation of the prototype developed in part 3. You should utilize the evaluation measures that you identified in that part as well. We expect that your evaluation will involve sample users interacting with your system. These users will likely be your client(s) and maybe other students from class or other people who would fit your target user population. Give the users a few simple benchmark tasks and have them interact with your interface. Closely study what occurs. Deploy a questionnaire to get their subjective feedback about the interface and interaction.
Your write-up for this part should include the following components:
1) A description of the evaluation techniques, tasks and users involved in your study
2) Design rationale for the evaluation tasks and materials you employed
3) Description of the results of the study (data presentation)
4) A discussion of the results
5) The implications that you make from the results with respect to your design
6) A description of how the prototype design could be improved in light of the implications
The key to this part of the project is not to simply describe your evaluation methodology but to rise above that and describe what you learned from it. Explain why you chose the benchmark tasks that you did. Why did you ask users what you asked? What conclusions can you draw from the studies? What aspects of your design "worked" and what failed to meet your specifications? If you had more time to work on the design, what would you now change and improve? Remember, no designer ever gets a system "just right." We will reward teams who honestly and carefully assess their design and who clearly provide a plan for its improvement.
Project PresentationDue: Assigned Final Exam Slot.
Warning: There are no late exceptions to this due date.
The design project will culminate in a session in which each group presents their system to the class and to their clients. Each group will present a short 5-7 minute video and then answer any questions during the Q & A session. Videos may be created using your own equipment or equipment borrowed from the library. We will discuss in class of easy ways to make videos and what software will be made available to you. Furthermore we will show you examples of demo videos.
The intent of this video is to summarize in an efficient manner the many parts of the project—what is the problem? What problems do existing solutions have? What did you build? How did it evaluate? You want to make sure that your objectives in the project are discussed, your system is clearly presented, and that your design process is communicated.
Last modified 6 January 2009 at 12:42 pm by Chris Plaue