4753 Secion B Project Details

NOTE: This list is not and end all, comprehensive list. It is simply more details and guidelines on what to include.

Documentation	Details
Audience Analysis	http://www.cc.gatech.edu/classes/cs4753b_98_fall/no1200.html Some basic characteristics: age gender physical abilities education cultural background training motivation goals personality computer background, etc... There are details for each category: General education (how much schooling) Specific education (on the job training) Skills (Do you want to force typists to use a mouse?-- job related, motor, verbal) Computer experience - programming, applications, systems, business, home computer, frequency Computer background - Novice: anxiety, little syntactic knowledge, requires menu, guidance, feedback Intermediate: can't recall all syntactic details, help, manuals, menus Frequent (expert): wants to work quickly, fast response time, few keystrokes, shortcuts, abbreviating, accelerations
Task Descriptions	Issues: Who is going to use system? What tasks do they now perform? What tasks are desired? How are the tasks learned? Where are the tasks performed? What's the relationship between user & data? What other tools does the user have? How do users communicate with each other? How often do the users perform the tasks? What are the time constraints on the tasks? What happens when things go wrong? What Should Tasks Look Like? Say what the user wants to do, but not how the user would do it allows comparing different design alternatives They should be very specific: forces us to fill out description with other details that become relevant Some should describe a complete job: forces us to consider how features work together See where inputs (outpus) come from (go) working with other tools, saving / loading, etc... Tasks should say who the users are If possible, name names - allows getting more info as it becomes relevant Also, characteristics of the users - job, expertise, etc Reflect interests of potential users - illustrate proposed functionality in context of work users really want to do Users are not always right - cannot anticipate new technology accurately Job is to build system users will want not system users say they want - be very careful about this (you are outsider). If you can't get users interested in your hot idea, you're probably missing something
Questionnaire	Extensive Information was given in class and is in the Usability Engineering class notes
Usability Specification Table	http://www.cc.gatech.edu/classes/cs4753b_98_fall/no1400.html Attribute - installability (first time use, performance) Measuring Concept - installation task A descriptive definition of the attribute Measuring Method - time to install What is the metric? Worst Allowable Case - 1 day with media (visual/learning aides) Lowest acceptable level for metric (lower bound on "what counts as a success") How to determine? 1. If existing systems set to its level 2. Practical experience 5. Planned Level - 1 hour without media Represents a "success" What is the "Now" level? - How much improvement should be expected 6. Best Case - 10 min. with media It should be an agreed-upon state of the art limit for the attribute--What are the capabilities of the competitor 7. "Now" level - many can't install present level of the attribute in current systems An example in table form is in the Usability Engineering class notes
Usability Testing Plan	Details to come...
Annotated Screen Sequence for Critical Tasks	Screen mockups, either printed or on overheads or on a disk. Have mock data in them to get a sense of how the screen really looks. For example if creating a registration system, have class names and numbers in a list box. Don't just have an empty list box with a title Classes. If your system uses color have your screen shots in color. The system does not have to work. You simply need the interface for it.