Task-Centered Design
This is a variation on user-centered design,
but it concentrates on the tasks to be performed using the
system instead of the user performing them.
The task-centered design process involves two phases:
- Get in touch with real potential users
Many projects fail (and startup companies go bankrupt) because they
develop a system for which nobody has any use.
Even though the system may be user-friendly,
it is important that it serves to perform tasks which need to be
performed by real people.
Never believe yourself when you think the system will be good for many
people because you believe it will be good for you.
Sometimes you may be able to find real users but they consider their time
to be too valuable to collaborate in the development of the new system.
A bribe (t-shirt, mug, ...) may work better than a professional reward.
If you can't find them, who is actually going to use (and buy) your system?
- Learn about the user's tasks
Develop concrete, detailed examples of tasks the user will perform
using the system.
It is important to consider whole tasks, not a list of simple steps.
Whole tasks provide insight in how interface features will interact
and work together, and how information flows through the system.
Develop concrete, detailed examples of tasks the user performs.
Not single steps but complete tasks!
Concrete examples work better than abstract scenarios.
Example:
Mr. Jones arrives at the information counter of the
Gamma hardware store and wishes to return
a Black and Decker drill because he is not satisfied with it.
Verify that this return satisfies the company's rules, arrange the refund
and, if appropriate, return the drill to the inventory.
- The example says what the user wants to do but not how the user would do it.
It leaves many open questions related to how this task could be
handled. It should not say something like: "Check whether the serial
number of the drill occurs in the past-inventory database."
This would have made assumptions about some aspect of the system that
has not yet been designed and discussed.
- It is very specific.
It states exactly what the user wants to do.
It actually states the name of the customer, the make (or type) of the
object, the company whose return policy applies, etc.
- It describes a complete job.
Describing only parts, like "check whether the receipt is legitimate"
and "register a refund for an item" and
"return an item to inventory", would not
uncover certain problems related to the task as a whole.
What for instance if the price of the drill has changed since mr. Jones
bought the drill? The generation of the refund might not match the
amount on the receipt.
- It indicates who the users are.
The example indicates that the user-interface and application will be
used by the clerk who sits behind the information counter, not by the
store manager.
Examples of task descriptions and how the system would be used for a given
task can be treated as scenarios.
They lead to feedback:
- uncovering details that were missing in the original task description,
usually through what-if questions.
- finding corrections and clarifications.
- finding redundant steps, like subsequent forms that require
the same information to be entered twice.
- step by step descriptions of how the user would perform the task
using the new system.