ed-informatics.org

In past articles, we discussed human-illiterate computers, usability, memorability, learnability, Tognazzini’s Paradox, design integrity, simplicity, abstraction, discount usability testing, and personas. Now, we will discuss goals and tasks. These are similar terms, and sometimes used almost interchangeably. But using the terms task and goal sloppily is, according to expert software designers, an error that leads to disastrous software design. So it behooves us to understand the differences between tasks and goals in solid detail.

This is written as if I’m writing to someone who’s developing software; and though it is certainly my intent to get people writing software for Emergency Departments to pay attention, it’s just as much to for those of use who use ED software – or someone who is doing something homebrew using Excel or Microsoft Word macros.

The difference between tasks and goals relates to our previous discussion of personas in the last article. First, let’s look at some excerpts from a nice online overview of UML, the Uniform Modeling Language. UML, which is a couple of decades old, was a breakthrough in its day. It allows you to specify how a computer program should interact with people, not in ambiguous English, but using a grammar that allows a more precise specification. Key ideas incorporated in UML include actors:

Actors should be described, indicating what interests an actor has in interacting with the system. For example, the project manager is responsible for ensuring the success of projects, and the project database is responsible for housing project management data.

Actors include humans as well as other computer programs – anything that interacts with your computer program.

By allowing unambiguous specification of how humans and other computer programs interact with a computer program, UML was a big step forward. But as Alan Cooper and others have pointed out, UML doesn’t quite go far enough.

If you analyze tasks that people do, and use UML to describe how they interact with the new program you’re coding to accomplish these tasks, you are creating what are known as use cases. Again quoting the above-referenced online article:

Use cases define the scope of a system and define the functionality provided by the system and those elements on which the system depends in order to provide the functionality. For example, these use case diagrams indicate that the project management system provides functionality to mange projects to a project manager, and this functionality is implemented using the project database.

So assume you’re coding a new computer program to help your ED staff with QI project management, as none of the off-the-shelf programs really address your staff’s needs.

If you use task analysis to look at what people do in their daily work, and develop use cases to describe specific interactions with the computer program, will this help you to code a program that is a big winner and wins you fame and fortune? Maybe yes, maybe no. Those promoting software Design with a capital D say that task analysis and use cases are necessary but insufficient. And, further, the proponents of design-with-a-capital-D say that you shouldn’t even start your task analysis and use case development until you have started at a more basic place: goals.

Now the word goal is a tricky one. Sometimes it means one thing, sometimes another. Designers (again with a capital D) insist that we be very precise when we talk about goals. Designers say that people sometimes confuse goals with tasks. The above-referenced article on UML seems to, at least in my mind, do just this:

Use cases should facilitate actors in reaching their goals. Use cases are system functionality or responsibilities (requirements) that actors use in order to reach or satisfy their goals. Use cases are not simply actor goals. For example, a project manager is responsible for ensuring the success of projects, and a project database is responsible for housing project management data. The project management system provides functionality to manage projects to a project manager such that the project manger can ensure the success of projects.

Designers look at this and say “No!” The definition of an “actor” is broad enough to include people, other computer systems, and remote-reading barometers. And designers-with-a-capital-D say that if you treat people like a remote-reading barometer you may not have happy users. And in the above italicized paragraph, the word “goal” is used to describe things that are really tasks. For example, Designers point out that a project manager – let’s call him Carl, an R.N. who now is the assistant department manager – has many goals. His goals may include:

• Being happy at work
• Making enough money
• Getting out of work in time to pick up his daughter at daycare
• Getting his work done without feeling frustrated or stupid

If you read the last article on personas you’ll realize what I’ve just done. I’ve created a mini-persona.

If we analyze the “goals” of our “actor” who is a “project manager” we will make sure that our new program is very good at managing projects.

If we analyze Carl’s goals, we realize that Carl has to be able to save his work and leave to pick up his daughter when the time comes. So even if our software is really, really good at managing QI projects, but Carl has to spend 10 minutes exiting out gracefully to save his work, and ends up being late to pick up his daughter on a regular basis because of your otherwise-great program, he’s going to hate it.

Yes, I know this is a clumsily-manufactured example. But hey, it gets the idea across. Goals and tasks are very, very different.

And that’s it for this short essay. That’s because the point is simple but very, very important.

Tags: User Interaction Design, ED Systems, User Interface, Emergency Department, goals, Computers, tasks, ED, UML, Information Technology, use cases, Healthcare, IT, Healthcare IT, Tutorial, Usability