Represent work people perform as tasks

Represent the Work People Do as Tasks

One early morning I sat with a friend at breakfast. Being a bit of a coffee snob, he didn't trust the hotel restaurant where we were eating to have good coffee, so he'd stopped at a coffee shop on the way in [you know the brand] and picked up a big cup of coffee. Together we sat at breakfast talking; me with my hotel restaurant coffee in a white ceramic cup with a handle, him with his likely better coffee in a tall paper cup with a plastic lid and a brown cardboard sleeve to prevent him from burning his hand.

We both shared the goal to enjoy a hot tasty beverage with our breakfast. In response to that goal he stopped at a coffee shop and bought coffee before meeting me. I chose to order coffee form the waiter at the hotel restaurant. But we both bought coffee. And, during breakfast, we both drank coffee.

There's a point to my story, honestly.

Tasks represent the little bits of work we do to move us toward a goal. Two of the tasks my friend and I shared this morning were: "buy coffee" and "drink coffee." Although we went about at least one of our tasks in very different ways, and with different results, we shared the same tasks.

Tasks contain other tasks

Tasks are interesting things. If we were to take a task, place it in the floor and hit it with a big sledge hammer it would likely splinter into a number of pieces. If you were to pick up each one of these pieces and look at it, you'd find each piece was also a task. The tasks contained inside of other tasks compose the steps I might take to achieve the larger task that contains them.

For example at breakfast to accomplish my task of "buying coffee" I might first get the attention of the waiter and next ask the waiter for coffee. The waiter might then ask me if I'd like cream and sugar to which I'd respond "yes please." Later on I might check that the coffee was on my breakfast bill and check the price. Then I'd pay the bill by charging it to my hotel room. If I look at the buying coffee task, it might contain a list of tasks like this:

Buying coffee

• Get attention of server
• Order coffee
• Respond to server's inquiries regarding coffee options
• Review coffee bill
• Pay coffee bill

Small tasks recombine to support other tasks

The example above is really a bit of a lie. It's true I ordered coffee, but I actually ordered coffee as part of ordering breakfast. As part of ordering breakfast, I chose a main dish, asked the server questions about it, ordered coffee, and ordered toast. My friend also ordered breakfast at the same time. When it came time to pay the bill, although there was coffee on the bill, it contained breakfast for both my friend and I, and since it was my turn I paid the bill for all of breakfast - not just the coffee.

The tasks to order coffee, review the bill, and pay the bill were essentially the same tasks as if I'd just ordered coffee, but they were recombined in support of a larger task to buy breakfast.

When using computer software, think how often you recombine the tasks of cutting, pasting, or opening files to support the larger tasks you're engaged in.

Tasks use short term objectives to support the pursuit of less tangible personal goals

Tasks support the pursuit of larger, often less tangible goals that are closely associated with the person engaged in the task. However, the tasks themselves generally have a smaller more easily evaluated goals. Think of these smaller goals as success criteria. I'll know when I'm successful buying coffee because I'll see it right there in my hand. If I bought coffee in support of the less tangible goal of having a pleasant morning - my evaluation of whether my morning is pleasant or not might change from moment to moment.

My head constantly evaluates this intangible personal goal "Is my morning pleasant?" If my morning isn't pleasant, or could be more pleasant, what might I do? You might have guessed it already… some kind of task with a smaller more tangible goal. Achieving that smaller goal allows me to reevaluate my standing on the larger goal.

Tasks have an abstraction level

We often express tasks abstractly. By that I mean I say generally what I intend to do, not precisely. In my previous examples I've said "buy coffee." I could have said "buy coffee to take out from the counter of a corner coffee franchise store that serves gourmet style coffees." That's more precise - more concrete. It's also a mouthful. I could have also said "buy hot breakfast beverage," or simply "buy beverage." That's pretty imprecise, pretty abstract, so much so that it may not be useful to help me visualize how I might go about it if I were a person trying to complete such a task.

You'll find that if you express tasks in writing, you'll likely do some generalizing about that task. This generalization doesn't omit details, rather it defers specifying details. It leaves the specification for a later activity, an activity that's a design or decision making activity.

Keeping tasks written abstractly allows us to rewind design decisions. If I make some specific choices about how a person would complete a task, I may at some later time decide those weren't the best choices and wish to consider alternatives. Looking back to and starting design from the more abstract task name allows me to start to think about those other alternatives.

Expressing tasks too generally isn't helpful. When looking at the tasks most commonly done in software, it's easy to abstract things up to tasks like: create information, update information, delete information, find information, review information. While at an abstract level that may be what I'm doing, it's certainly not enough detail to allow me to effectively make more detailed design decisions.

Tasks use tools

Humans engage in tasks as part of an activity in support of goals or to relieve some discomfort. Once tasks are undertaken, we'll look for tools in our environment to leverage. Tools may be something concrete like a hammer, paperclip, or computer, or less tangible like business processes, or rules of thumb. If you're helping to build software, you're in the tool business. You help to build tools that people will hopefully use to make their tasks go more smoothly. The design work is in choosing a best tool to accomplish this secondary goal of making the task go more smoothly.

It's important to keep in mind that the goal of completing the task itself is a secondary goal. No one completes a task for the sake of doing so. It's the goal that motivated the task in the first place that's important.

Looking at the coffee example we started with, I and my friend both bought and drank coffee. The tools he used were a corner gourmet coffee shop, and a paper cup with a lid. The tools I used were a hotel restaurant and a ceramic coffee cup - without a lid. Someone put some thought into designing these tools for us. Someone gave a little thought to our goals, and our context of use and made choices to use ceramic vs. paper, corner coffee shop vs. restaurant. The design choices they made were tuned for a particular type of user/consumer in a particular context.

The software we choose to build has the same forces at work: people in a particular context of use trying to reach a particular goal. To help us better recognize when we're designing, it's valuable to separate the tool from the task that motivates its design and construction.

Tasks are not tools. Tools support the execution of tasks.

Stepping one level back, it's important to separate the tasks people choose to execute from the goals they actually hold. Specific individuals choose a wide variety of tasks to reach their goals. In an ideal world the task would be as effortless and automatic as possible - it would almost go away.

I used to have a task to mow my lawn. Well I still sort of do. But, with all the traveling I've done lately I've hired a service to mow my lawn. Now the task of mowing my lawn has mutated to paying the monthly lawn care bill. The lawn still gets mowed but my specific task changed. And my goal of feeling good about the curb appeal of my house is still met.

Software is a big multi-function tool

While the information here about tasks may be useful for all sorts of things, from buying coffee to building restaurants or airplanes, the reason you're likely reading it is because you're involved in some way with building software. Software is one of the tools people reach for to perform tasks in pursuit of their goals, but it's a big tool. Picture a garage full of tools. Software is more like a garage outfitted to support woodworking, auto repair, or practicing and recording punk rock. Like software, there are lots of things you can do with a garage. The tools you outfit your garage with - like wood lathes, ratchet wrenches, or Fender guitars – hint at what goals and tasks it supports. It's likely that people go to your software like they go to their garage. They'll spend some time there engaged in a number of tasks in pursuit of a number of goals.

In software we can refer to the stuff we build to support specific tasks as functions or features. In this book we'll use the term feature. Throughout this book you'll hear repeated the natural dependency between the goals a person wishes to achieve or discomfort to eliminate, the tasks they choose to pursue to do so, and the software features we choose, design, and develop to help them.

In Agile development approaches it's common to use the term user story to refer to bits of software we plan on building. It's a good term because as the name implies, it should be a story told by our users that should contain information about who they are, what the goal is, and what they might do to reach it. As we approach development time, the user story may come to mean the specific feature we intend to build. I'm not going to regularly use the term user story partly because all Agile development methodologies don't use the term, and because the term could be used to indicate a user task, a product feature, or a mixture of both.

Available tools change the way we think about tasks

On a daily basis I brush and floss. Those are tasks I perform. Notice how the name of the task is the name of the tool I use? I call the task brushing my teeth because the tool I use is a tooth brush. Same thing goes for flossing my teeth. Really what I'm trying to accomplish with both these tasks in keeping my teeth clean; that's the real task here. If were going to invent something better than a toothbrush or dental floss, I'd need to understand that.

But, what if I didn't have floss?

I suspect many years ago, floss didn't exist. I'm not sure about that since the dentist has made me feel guilty for not flossing enough for as long as I can remember. As far as I know floss was on the planet before we were. But - pretend for a moment that there wasn't floss. Flossing likely wouldn't be a task I'd do every day then. But, some dentist, or someone in collusion with a dentist, invented the idea of floss and the daily task to go with it. And, unless it is somehow proven the entire dental profession is for some reason pulling off a huge scam on the flossing public, flossing does help me better meet my goal of "keeping my teeth till I die," so I am mostly happy it was invented.

When designing software you and your design team will invent tasks and tools in a similar way. Being aware of users' goals will hopefully motivate you to invent better ways for them to reach their goals. With luck you'll invent tools more enjoyable to use than floss.

I floss because I know I should, and because the tool is available to me. People with goals or discomforts will reach for the tools available in their environment. If I was in my garage and I wanted to pound in a nail, I'd reach for a hammer. If I was camping and I wanted to pound in a tent stake, I might use a handily available rock. But no, I'm a technology professional so I'd go more high-tech and employ my camp shovel. If I had a hammer I could use that as well, but a camp shovel seems to do the trick. The shovel tool wasn't built specifically for hammering in tent stakes, but looking at it and feeling its weight while holding on to its handle, I could easily imagine it could work for a bit of hammering.

When we're designing and building software, we may think we know what tasks our users are likely to perform, but it's very common to find out they're using our tools in ways we'd never anticipated. They may have goals we didn't understand, and they certainly devised tasks we hadn't anticipated. For instance, the most common use of a cordless drill on a construction site is to hold down plans so they don't blow away in the wind.

The availability of features in our software, tools in their environment, combined with their goals or discomforts motivated alternative use.

Tasks aren't use cases

A use case is a common approach to documenting a software requirement that originated in the Object Oriented software development communities [Jacobson]. A use case describes the interaction between two or more parties - referred to as actors.

A typical use case might have a simple name that indicates what a person is doing, and a narrative that describes step by step what a user does in a computer system, and what the system does in response. Use cases might also include other humans, or other computer subsystems. For example a use case from a retail sales environment could describe the interaction between a customer, a cashier, a cash register, and the register's on-line credit card approval service - four actors total.

Use cases are an effective mechanism for documenting design decisions but by including tools as actors, they already include some design decisions. The tool choice has already been made.

Using the retail sales application above, the third and fourth actors mentioned are the cash register and the on-line credit card approval service. These are tools, not tasks. They're good tools that allow the tasks of selling something to a customer go faster and smoother, but they are tools. There are still retail stores that may not use electronic cash registers connected to on-line credit card approval services. For example, I like to buy my wife jewelry made by a distinctive local jewelry maker. I deal with the owner whose name is on the sign. He writes up receipts in his receipt book, and calculates tax with a calculator. If I use a credit card, he might call it in for an authorization using a phone. His tool choices are very different than my grocery store, for instance. But both still have the task of selling me something and collecting my money.

Use a use case to document interactions between a human and some chosen tool - usually a piece of software. But, don't loose sight of the task the user is trying to perform.

The odds are your tool won't completely support the task. I use a software tool to enter expense reports when I travel. It asks that I record expenses for hotel bills and meals separately. I often order room service. So in the context of entering my expenses into the tool I have to take the hotel bill and subtract off the meals I ordered from room service and enter them as separate line items. I use a calculator to do this math. A better designed expense tool would probably support doing the math in the tool. But the real point here is that my task of recording expenses includes steps supported by the computer system, and some that aren't. A use case might document my interaction with the software, but may not document my tasks executed outside the software - tasks using different tools.