|
|
Project 11: Designing a User Interface |
|
|
|
|
|
|
This is NOT a programming project - the entire project can be done without a microprocessor!
|
|
|
Item Description |
|
|
Discuss project in class and form groups | |
|
|
Bring idea for project to class & tell me who is in the group | |
|
|
|
Description of the system, users, and tasks |
|
|
|
Revisions to week 4 deliverable (optional) |
|
|
|
Initial design document and Usability specifications |
|
|
|
Revised design document |
|
|
|
Presentations |
|
|
|
Final report |
This is the major project for the quarter. This project involves identifying a system for which you will design an interface and then defining what the system does, who the users are, and what tasks users perform. Next, you define usability goals and start designing the system. The design process should involve several iterations of design and evaluation. The results of these evaluations should suggest changes to improve the system.
This project should parallel the goals for the course. After defining the system you are interested in, you must analyze the users, tasks, and work environment to identify any important characteristics that may influence you interface design (deliverable for week 4). After this analysis is complete, you should have a good understanding of the problem you are trying to solve and what will determine the success or failure of your new system. Now you must define the specific goals you are setting for your system that will determine if your design is done or not (deliverable for week 6). At this point, you should understand the users, their tasks, the work environment, and what determines success so you are ready to start designing the interface. The first step is to come up with rough sketches of your interface so you can figure out if users can understand the general design ideas (deliverable for week 6). Once you determine that users will understand and accept your basic ideas, and this may take several attempts, you start refining the design. You continue to evaluate your refined design until you have a complete interface for the system you are designing that has been evaluated successfully by users (deliverable for week 8). Throughout this process you will be showing your designs to potential users and other interface designers (students in class and me) to get feedback. The final result for this project is a low-fidelity prototype designed using paper, pencils, post-it notes, etc. that has been evaluated and determined to be a successful solution. If we had time, this paper design would then be computerized for further evaluation and refinement and eventually turned into a working system.
Remember, your interface does not have to be a standard graphical user interface. If a cryptic command language is the best solution for your system use it. Other projects may involve touchscreens, voice input, or something completely new. You don't have to worry about being able to implement the system at this point, but it must be feasible. For instance, a system based on the idea of 100% accurate voice recognition and 100% accurate natural language processing is not feasible because the technology doesn't exist at this point.
This project is a team activity. One team member should be identified as the contact person. This contact person is NOT necessarily the team leader. You do not have to have a team leader if you do not want to. The contact person simply acts as a mechanism to simplify communication. I will send email comments about each project deliverable to the contact person to speed feedback. Include the contact person's email address on every deliverable. Do not divide the project among team members. The goal is for every member of the team to experience each phase of this process.
Think carefully about who is on your team. Consider schedules, jobs, where you live, where you work, and anything else that might impact how well your team will function before forming a group.
Some possible projects include:
Bring your project idea for a project to class. This should include a one or two page description of the system including a rough idea of who the users will be, what the users' tasks will be, and what functions the system will provide for the users. We have not discussed how to gather this information at this point, so rough ideas are fine. This document should make it clear who is on what team. There is one important limitation on the systems you can choose: other students in the class must be able to qualify as users of your system so we can perform in-class evaluations of your designs.
This document must include:
You can revise your description of the system, users, and tasks if you are not satisfied with the results of week four. You can earn up to one-half of the points you lost in week four by revising this part of the project.
Design document and Usability specifications
The design document should provide a complete description of the content and style of the interface. This document should address the following:
State the purpose of the system including describing the functions the system must perform.The usability specifications should state:Include rough sketches of the interface at various stages and describe the functionality of the interface.
A brief (and rough at this point) narrative walk-though of how the system works (referring to the pictures mentioned above).
Justification for design decisions that were made based on design principles and guidelines.
During the design phase questions will arise which do not have definitive answers. Keep a list of these issues since they will be important during testing.
Who are the intended usersPeer evaluationWhat kind of training should be necessary
What objective goals are you setting for this interface?
What subjective goals are you setting for this interface?
A description of how you intend to do your usability testing
The design document is worth 70% of this deliverable and the usability specifications are worth 30%.
Each group will exchange their project descriptions with another group. You should bring one copy of your design document to turn in to me and a second copy to use during the peer evaluation. This second set should include sketches of your screens, written descriptions of how the screens work, a summary of the user/task analysis, and anything else that might be useful when evaluating the system. Remember, the people that evaluate your system may not have ever heard of it before they get your documents. You want the other group to do a thorough evaluation since their comments should help you improve your design. The more complete your design at this point, the more feedback you can get. The designs may be early ideas that will be refined extensively or nearly complete designs.
During class, each group will evaluate the project they have been given by another group. This evaluation should result in a list of potential problems. It may also result in a list of suggested improvements. You should begin by looking for what you would consider major problems. If there don't appear to be any major problems, or you think you have found them all, then start looking at more of the details.
Turn in copies of all of the major screens in the interface (and as many minor screens as possible). Include a description of what the various controls on the screens allow users to accomplish. This may not be the final version of the system, but it should have been refined since week six. This revision should deal with comments from the peer evaluation and from my evaluation. This does not mean you have to listen to each bit of advice, but you should explain how you addressed the comments.
Each group will make a presentation to the class which summarizes the material in the final report. You will have 10-15 minutes, depending on the number of groups in the class. This presentation should include:
An overview of the system (quick)Think of this as a presentation to upper management. You have very little time and you want to convince management that you have a solid design for your system. The one big difference is that this audience will want to hear about alternatives that you tried and why you chose the solutions you did.A summary of the usability specifications (very quick)
A description of the evaluation procedure (very quick)
A walkthrough of the screens and how they would be used
A summary of recommended changes
This should serve as a summary of the entire process including a description of any important problems encountered or lessons learned. This should be a professional, well-written document. This paper cannot be longer than 12 pages including references, pictures, and text. The text should be no more than 8 pages.
The main document should address the following points:Example Deliverablesgive an overview of the system, the users, the users' tasks, and the usability specifications.
describe the interface (included screen sketches).
summarize any changes that were suggested as a result of the evaluations
give an overall summary of this experience. What did you learn? Was this project easy or hard? What should I do differently next time to make this experience more useful?
There are example deliverables available at: http://condor.depaul.edu/~asears/classes/IntroHCI/SampleProject.html
These are not perfect solutions, but they will give you an idea of what
I am looking for.
 |
Please send
comments and suggestions to the Booksite
Director
Last Updated: 12 March 2000 |