Create a simple task model

If your goal is to ultimately design and build software, it's important to understand the work that potential users of the application engage in. This includes work both inside and outside of your potential system. If your software doesn't yet exist, it's currently all outside your current system. Given an understanding of this work, you'll be able to better understand what software is appropriate to build to support people and their work.

A task model is built as an index card model where each card represents a particular task engaged in by users in pursuit of their goals. The task cards in the model will be clustered by affinity where similar tasks done by similar people at similar times cluster together. The clusters are given names that are helpful in identifying user activities; and, when you begin to think concretely about software solutions that will help your users, these named clusters of activities are good candidates for named interaction contexts in the software.

Additional ad hoc notation can be written on a task model to describe details about relationships between tasks or other information relevant to the task model.

Before attempting to construct a user task model, you should be familiar with the concepts of user task, task goal level, and user activity. You should have some understanding of the candidate users of your system which is best represented in some type of User Model.

While a task model may be built as a solitary activity, it's best accomplished in a collaborative work session. These step by step instructions will give basic directions on hosting a collaborative modeling work session.

Prepare

Identify Scope and Goals

Before hosting the collaborative modeling session to build your task model, discuss the scope and goals of the session.

When looking at a number of users engaged in some type of work, the number of tasks in that space may be large. Your team may already have ideas about the types of activities your users engage in that are most relevant to both the users' goals, and the business goals for building this system. Limit scope of the discussion to activities and tasks relevant to those user and system goals.

While the session will have the obvious goal to build a task model, write a goal statement that will help you and participants understand the intended use of the resulting model.

A good scope and goal statement for a software company writing an addition to their point of sale software might read:

This is a fairly narrow scope for a modeling session. Your session may be much broader scope

Identify Participants

Your session will need information suppliers that understand the users of the candidate system, those users' goals, and the way they do their work. Invite end users of the existing system or others currently engaged in this work. Also invite domain experts - people who while they may not be currently engaged in doing this work are experts in the domain. Also invite members of your team who have conducted user interviews and/or direct user observation with members of your target user constituencies.

To make sure the information suppliers' understanding gets both captured in the model, and moved to the heads of people that can best leverage it, make sure you invite members of the design and development team responsible for arriving at the finished solution. I make it a habit to invite at least a senior developer and senior tester from the team.

Choose a facilitator familiar with the card modeling process and this type of task model. Ideally the facilitator is not one of the information suppliers.

Prepare Data

Your task model will represent the task for some set of user constituencies. Those user constituencies should be described in some type of user model. Make sure that user model is available and posted as a model poster during the session.

In addition it's important to keep visible the business goals that motivate this discussion. If you have business goals expressed in a goal model, display these as a model poster.

Information suppliers who've gathered information on users and their work through user interviews or contextual observation should bring their notes and observations ready to reference during the session. Ideally these notes have been consolidated and distilled in a collaborative data consolidation session.

Never rely on information contained on paper alone during the task modeling session. Always make sure someone thoroughly reads the information and is prepared to speak about it verbally in their role as an information supplier.

Gather Supplies

To quickly create a task model, you'll need your collaboration supplies. You'll likely run through lots of index cards or sticky notes depending on what you like to model with. You'll need poster paper to fix the model to when it's done, and to create a parking lot and feed forward bins. You'll need a camera to shoot a model photo and ideally a model movie.

Schedule

The time you'll need will depend on the scope and goals of the model to be built. A single 90 minute session is ideal. If you believe your model will be larger, schedule two sessions with a break in between. Make sure you leave 15 minutes or so to wrap up the session.

Perform

Kickoff

Start the meeting by reviewing the goal statement for the meeting. Make sure everyone knows each other, in particular make sure everyone knows who the information suppliers are, and what knowledge they bring to this activity. Point out the posted parking lot, and any feed forward bins you've hung.

Using just a couple minutes review the business goals of the software you're considering.

Review the user model for the software you're considering. Reviewing the user model, in particular the goals and types of activities these users engage in, will start your participants thinking about the tasks these users need to engage in.

If participants are unfamiliar with the task concept, take a few minutes to discuss tasks with them.

Identify a candidate list of tasks

Use CardStorming to quickly write as many user tasks as participants can think of onto index cards.

Since tasks are the actions that people do to achieve their goals, coach the participants to suggest tasks that start with a verb and end in a noun: like "buy coffee" or "evaluate impact of stock trades on the portfolio."

Encourage those who are information suppliers to contribute task suggestions. You'll find that even if they're not previously familiar with the work being done by the users, they'll catch on quickly and be able to suggest tasks that fill in holes that others hadn't considered. You'll find that if developers are present in the room, they may suggest administrative, setup, or housekeeping type tasks that support the activities in the model.

I haven't suggested you give your group any direction on task goal level. I've found that people almost always suggest function and sub-function level tasks. Later as we prepare for modeling, and then during the modeling activity, goal level may begin to be more relevant, but during cardstorming don't let it be a concern.

Cardstorming should leave you with dozens of tasks.

Less than ten may indicate your scope is fairly small, or that participants may in fact be thinking at a very high goal level. Consider widening scope to include activities related to the activities you've placed in scope, then continuing brainstorming. If goal level seems high, for each high goal level task, take a short amount of time to brainstorm lower level tasks that make up the higher goal level task.

More than 100 tasks may indicate that your scope is too large, or participants may be thinking at a very low goal level. Consider narrowing scope and using filtering to place some task cards in a "don't include" pile. When goal level is low, this can be resolved later during modeling where related tasks will naturally cluster together giving you the opportunity "find" higher level tasks by labeling clusters of lower level tasks.

Clean, Filter, and Correct

If your team has done well at brainstorming, you should have a fair number of duplicates, and obviously wrong or silly cards to throw out.

Take a deep breath. Everyone take a moment and look back at the scope and goal of the modeling session. Cleaning, filtering, and correcting will be done to make sure you have a good set of tasks relevant to the scope and goal.

The information suppliers start by filtering the cards into three piles: keep, maybe keep, and throw out. Others observe and comment.

Beginning with the cards to keep, the information suppliers should go through each card one by one. If duplicate cards still exist, throw the duplicate out. For each task name written on the card:

• Discuss the task name.
  • Is it a good name?
  • Should it be changed or corrected?
• Change task names, rip up and rewrite cards as necessary.

Follow the same approach for the "maybe keep" pile. While discussing each task consider moving some to the "throw out" pile if they don't seem relevant.

Common problems with tasks

While cleaning and filtering, there a few common problems to watch for and avoid. Use the cleaning and filtering to observe and correct these sorts of smells in your collection of tasks:

Take a break

After cleaning and filtering is finished, it may be a good time for a break. Take one here if you're approaching the end of an hour and a half time block. At the very least everyone should stand up and stretch.

Model by Affinity

Now that you've got a pretty good list of user tasks, let's see how these tasks relate to each other. Using the task cards, create an affinity diagram. If modeling on a table top, don't forget to cover the table top with poster paper so you can more easily fix the model in place when you've finished.

Allow everyone interested to participate in building the affinity diagram. Ask participants to place tasks performed by similar people at similar times close together.

Don't give too much guidance. I find that people often naturally do fine with this activity. Ironically, the more guidance they ask for, and the more you give, the more likely they are to run into trouble.

Identify clusters and relationships

For each cluster in the affinity diagram, circle the cluster and, as a team, discuss a good label for this cluster. Ask "why are these tasks related?"

You'll find that tasks may be related because they're part of the same activity. In this case a label for a cluster might be the activity name.

You'll find that related tasks that may be automated by software you intend to build might likely belong together in the software's user interface. In this case a label for a cluster might be a candidate interaction context - a named place in your user interface that will likely support these tasks.

Look inside each cluster. This is where you might find tasks with varying goal levels. You might find one task with a functional goal level perched atop a few others with a sub-function goal level. The sub-function goal level task may in fact be part of the functional task. They could also be optional variations that might occur in the functional level task. For these types of task relationships, draw lines from task to task and make some notations on the line to indicate why they're related.

At this point consider how clusters might relate to each other. Draw a line from one cluster to another to symbolize the relationship. You might make the line an arrow by drawing arrow heads on one end of the line or both. Discuss a good label for that line.

For example if you were creating software used in a retail point of sale setting you might have a cluster of cards labeled "ringing up sales," and another cluster labeled "looking up inventory items." A line between those two clusters might carry a label "looking up items is done while ringing up sales" or some abbreviation of that.

This type of notation helps you understand how tasks work together to support larger activities and bigger user goals.

Wow, what a mess

The model you've constructed may have lots of clusters and lots of lines. Little bits of notes may be written all over the model. The members of your group in attendance at this session will understand the meaning of what you've written here. They'll likely be able to explain it to others. But, you've arranged and annotated your model very informally. This model could be represented more formally using use-case modeling approaches and more precise relationships between tasks such as the "specializes," "extends," or "composition" relationships described in fine texts like Constantine & Lockwood's Software for Use. You will find information contained in the model that can't easily be moved into any formal modeling approach.

Consider representing this model using a formal modeling approach if you have an audience that could consume and benefit from that approach. That audience may include your own group if you feel you'd like a more precise understanding of the relationships between specific user tasks.

Optionally Annotate Tasks

To better understand each task, it may helpful to add additional information such as user or users likely to perform this task, and the frequency they're likely to perform the task. This sort of information may make the model more informative, or it could make the model too noisy. You'll need to use your judgment here regarding what might be helpful to know about these tasks. Look back to the goals of the session and potentially the goals of the business for guidance.

To annotate tasks choose a characteristic you'd like to annotate tasks with such as "frequency of performance." Information suppliers take pens, and task by task add this characteristic to each card. As a team discuss the annotations out loud while this happens. Ask questions and debate if necessary so that the information annotated on the model arrives both on the model and into the heads of those in the session.

To keep cards shorter, I find it simple to choose a corner of the card to add information to - say the bottom left corner to place the frequency of use characteristic. Then I don't have to write "frequency of use" on every darn card. If you do this, place a card at the bottom of your model with the words "frequency of use" written in the bottom left corner. The card is your legend - so label it "Legend."

You may choose any characteristic relevant to your users or the product you intend to design. Possible characteristics to annotate might include:

Optionally Identify Focal Tasks

Some of these tasks are more important than others. Understanding which tasks are more important will help you better make decisions about which to prioritize as high when creating release plans or making specific user interface design choices. Use the focal concept to identify critical tasks in this model.

To identify focal tasks look back to the business goals for this product. Look also to the user model for this project. Then ask the question:

The answers to those questions identify the focal tasks.

You may identify the focal tasks through discussion. I prefer to vote with tokens using democratic prioritization.

For a task model of around 50 tasks, 3-5 focal tasks are about right. Identifying more will make it difficult to prioritize your later design efforts.

Annotated characteristics sometimes make it easier to identify focal tasks. For example a high frequency task of high value to users may strongly suggest it's focal.

If you're having trouble identifying focal tasks, if everything looks focal or nothing does, this may be a symptom of having poorly defined business goals, or knowing less than you should about your users and their work. Consider revisiting the business goal model, your user models, or collecting more information from users or stakeholders using interviews or observation.

Take a deep breath

You've built a task model that should effectively distill and represent what the information providers in your group understand about the work your users engage in. While you've been doing this everyone in the group will have acquired this basic distilled level of understanding. This model, and the understanding here will serve as foundation for making future design choices in the software.

Summarize & reflect

After taking a few deep breaths, standing up and stretching, it's time to summarize what you've built.

Fix the cards down with tape if you haven't already. Hang the model on the wall.

It's time for one of the information providers to grab a pen, stand, and verbally summarize what's going on in the model. Point to parts of the model and discuss important tasks and relationships. Discuss focal roles. Discuss any other interesting bits of the model. Everyone else ask questions or ask for clarifications if necessary. If changes need to be made to the model, make them now. Feel free to make additional annotations on the model. Consider recording this activity as a model movie.

Take a model photo.

As a group review parking lots and feed forward bins. Is there any work left to do here or topics to discuss?

The facilitator should indicate who will be responsible for documenting the session. The documenter lets everyone know where and when they'll see the results of this session posted.

Conclude the session by doing a round of parting takeaways.

Consolidate, document and communicate

Ideally the finished model will be posted in a public area visible to the team to serve as an information radiator.

Create an electronic task list

The tasks in this model are valuable pieces of information that will likely find their way into other models. To best support this it works well to enter the tasks into an electronic spreadsheet. Using spreadsheet data it's relatively easy to print out new task cards using a word process and/or mail merge. In a spreadsheet document you'll likely have columns for:

• Task name: the words written on the card
• A task number: trust me, start numbering these things now. You'll need to identify them by number later when you're using them in other models or as a basis for features in an upcoming software release.
• A task group: the cluster the task fell in likely indicates its group. If your team agreed these clusters were likely activities, go ahead and label the column activity.
• Focal: is this a focal task?
• Columns for other annotated attributes such as users, frequency of use, user value, business value, location, or any other attributes collected during the modeling session.

The electronic task list will form the foundation of your electronic feature backlog.

Optionally create an electronic version of the task model

If external communication of this session is necessary, consider creating an electronic version of this model. This could take hours, so do try to avoid this.

Write up and post notes you've made about the session including the list of collaborators who built the model, the scope and goal statement, the model photo, model movie, notes or observations made during the session, and the electronic task list that came from the session.