ForUSE - Making Usage More Productive - Lucy Lockwood

Raw Notes... added retrospectively. NB - Usage here refers to Usage Centred Design.

U-CD can dramatically increase productivity of users. We can measure this by how quick people can get in and start, through to error rates.

The primary tenet of U-CD is in understanding Users (Roles), Work (Tasks) and Needs (Tools). The aim is to look at how things are REALLY done and focus on key issues and immediate intentions. What's next?. Look at the purpose of actions in the larger context or workflow. Identify difficulties and how to deal with them.

A Usage Centred Design Approach encourages sound decision making based on realistic assessment of Priorities (business importance + user importance) and tradeoffs. It is business realistic.

Ranking user roles and task cases by frequency of use is key to deciding what is floated to the top level of the User Interface.

Task Case modeling is a powerful tool for Business Process Analysis and redesign. [Say it Sister... This is such a hard one for many to grasp. Design can, does and should inform business models and processes]. Use Task Case modeling to identify 'Technology Steps' or what user actions impact technological solutions.

User ROI. Is a feature worth having if it is too hard to use, too laborious or too hard to get to within an interface?

Design objectives

UI architecture should be easily understood by users, even beginners, after brief exposure or practice. [Learnability if not Usability]. Related information should be gathered about WHEN an interface is used.

WYSIWYN - What you see is what you NEED.

Task cases + User roles are re-usable - e.g. Help topics can be defined by them, test cases, acceptance tests... etc.

Help, whether in context or elsewhere should cover:

• What is this?
• How do I?
• What should I do here?
• What do you mean?
• Tell me more!

Most external help entries should explain and support common extensions of:
Explain
..Show Me
....More Info please
......Next|Back

Role Incumbants (this is Lockwood&Constantinese for the characteristics of people performing a certain role. Think Personas). These should bring with them measures of:

• Proficency - distrubution of skill levels
• Interaction - charateristic usage patterns
• Information - communication characteristics

Operational Risks - What are the consequences of error, failur, misuse or delay associated with the application's role? Accuracy, confirmation, error handling, clarity are all to be proportionately well addressed according to operational risk.

Work Environment - Where will the application be used? Noise, Vibration, Lighting etc must all be considered.

Device Constraints - What devices will be used to access the application or information? Input devices (e.g. stylus or keyboard), displays etc must all be considered.

Structure - Be consistent with layout and graphic treatment of elements. Don't represent the same concept differently within the same interface or application.

----

Clustering task cases [This can really help to define what gets done within a sprint or iteration]. Group 'co-operating' task cases together either necessarily or optionally. Cluster toward more efficient interaction and simpler navigation. Visually distance, or seperate cases where co-operation is unlikely.

Conventional use case narratives are fully ordered. Sometimes in the real world these aren't intrinsically fixed. Thus, Flexible ordering should be supported and is preferrable.

Performance metrics: Performance measures directly evaluate actual usage. They can be based on a working system or a prototype. Task completion time, completion rate, percentage complete and correct, help requests, error rates and reworks are all considered when measuring the performance of an interface.

Measurement of an interface should be directly related to design goals.

Measuring the productivity ratio done through the calculation: Unproductive time subtracted from total time, divided by total time. Unproductive time is all time spent not directly working toward the goal (e.g. errors, help requests, delay in interpreting interface etc.)

All measurements of course, are only any good if there is a measure before and after the the change of which measurement is desired.

Posted by Ant at October 24, 2003 11:16 PM | TrackBack