Taskflow Analysis Essay

Activity-Centered Design & Scenarios

In your article Human-Centered Design Considered Harmful you say that "activities are not the same as tasks," but are scenarios the same as tasks?

In my line of work (web application design & development) our personas are 80% scenario descriptions (one likely scenario per activity) — which we then break down into user needs, tasks and system features.

From these we then build task-flow diagrams to describe an "activity" (e.g. registration), followed by prototyping.

Your article is making me rethink this process, but I am keen to know where scenarios fit into the picture!

Scenarios are usually specified at too high a level to be of much value in the design of specific interface elements. Task-flow diagrams are important.

Tasks are situations with a single, well-specified goal, such as "respond to this email." Activities are larger groupings, comprised of multiple tasks that fit together, such as "get caught up on the day's correspondence" which means reading email, responding, looking up information, sometimes to copy and paste into emails, checking calendars, and other associated, related tasks. Thus, to me, "registration," from your example above, sounds more like a task than an activity.

To me, error analysis is the sweet spot for improvement. Usually, designers do think of the order in which activities will be done. But they seldom think properly about what should be done when the person encounters problems, or when the situation is novel.

It doesn't matter whether the analysis is called task analysis, task-flow diagram, scenario, activity analysis, or activity-flow diagram. What does matter is that it be a detailed analysis of the steps a person might follow when things go wrong. What should you tell the person? What choices should you offer?

What would the person wish to do in each of the situations?

It is relatively easy to design for the perfect cases, when everything goes right, or when all the information required is available in proper format. Good design, however, will handle the unexpected situation, when there are special cases, when the information is entered incorrectly or incompletely, or correctly. but in the wrong location or wrong sequence.

This is where the difference arises between a pleasant experience and a frustrating one.

One way to do this is to look at all the error messages, determine why they might arise, and redesign so that they either never appear, or if they might, that they are transformed into assistance. Not "help" which tells the person what should have been done, but "assistance" which offers the proper action and makes it so easy to proceed that the person might deliberately type incomplete information to get the guidance.

Remember: the "perfect" behavior seldom arises. Almost ever situation is a special case of one sort or another. So design for the special cases, design to eliminate error messages.

One of the most important steps in the Design Thinking process that is often employed as standard practice in UX design is to define the users’ problems. This means being able to clearly identify and articulate problems in the user experience so that you can later begin the process of ideating (i.e., generating great ideas on how to solve them). Task Analysis is a simple exercise that UX designers can undertake during the definition of a problem, which can help not just in identifying where opportunities to improve the user experience exist but also to generate some preliminary ideas as to how you might approach these challenges. Let’s find out how.

Task analysis is one of the tools that you can use during the “define” stage of the Design Thinking process. The most frequent deliverable of a task analysis activity is a diagram explaining the steps that a user must take in order to complete a goal. In this diagram, you can depict the actions taken by the users (or some system) to help them achieve their goals. Once you have laid all the steps out, you will then be in a position to see where additional user support is required (for example, you might wish to automate some actions that the user currently undertakes), or eliminate unnecessary steps, in order to minimize the number of actions that a user has to undertake, unassisted.

Joann Hackos, communications expert, and Janice Redish, UX consultant and writer, advise that task analysis is useful for understanding (1998):

  • Your users’ goals and what they are trying to achieve
  • The steps that your users currently take in order to achieve their goals (very helpful to see how they follow instructions or have devised ways to work around problems in current practices!)
  • The personal, social and cultural experiences that users bring to the tasks
  • The influence of the physical environment on the users while attempting to meet a goal

A clear understanding of the above factors will help you to define and frame the users’ problems so that you can then ideate ways to help improve their experiences.

Preparing to conduct a task analysis process

Usability professionals Courage, Redish and Wixon (2007) argue that task analysis is an activity based on four core principles:

  1. It is an integral part of a broader analysis that includes understanding users and their environments.
  2. Task analysis includes understanding users’ goals.
  3. Although the focus, methods, granularity, and presentation of information may differ at different times, task analysis is relevant at all stages of the design and development process.
  4. The practical reality is that task analysis for a given project depends on many factors.

Breaking down these principles, you will notice that the first two advocate for a deep understanding of users, their environments and their goals. Since the Design Thinking methodology produces outputs during each step, it’s natural to expect that task analysis is a process that has to be informed by the outputs of the previous phase—i.e., empathizing with your users. During this step, you may have already undertaken user interviews, or collected data through observing how your users go about their daily lives, in order to understand them better and build empathy with them. In short, you will have engaged in some user research, which may result in several outputs such as user personas, scenarios and storyboards. All of this data is essential for task analysis, as you will base your work according to these outputs.

Of course, just collecting any data during your user research is far from enough. If you plan to use task analysis (or indeed many of the other tools in a UX designer’s skillset, such as customer journey maps), your data collection must be focused. Larry Marine, a UX consultant, argues that your user research should focus on collecting the following five types of data, which you will use later during the task analysis phase:

  • Trigger: What prompts users to start their task?
  • Desired Outcome: How users will know when the task is complete?
  • Base Knowledge: What will the users be expected to know when starting the task?
  • Required Knowledge: What the users actually need to know in order to complete the task?
  • Artifacts: What tools or information do the users utilize during the course of the task?

First steps in Conducting a task analysis

Armed with the information you gathered during the empathy phase, you can then begin to sketch out how a user goes about his or her daily life by mapping out the sequence of activities required to achieve a goal. Before you begin, it’s important to have an overview of the process and its steps, so you can better prepare.

According to the UXPA’s Usability Body of Knowledge Site, the process of task analysis can be broken down into the following steps:

  • Identify the task to be analyzed: Pick a persona and scenario for your user research, and repeat the task analysis process for each one. What is that user’s goal and motivation for achieving it?
  • Break this goal (high-level task) down into subtasks: You should have around 4–8 subtasks after this process. If you have more, then it means that your identified goal is too high-level and possibly too abstract. As Don Norman (1998) said, users are notoriously bad at clearly articulating goals: e.g., ”I want to be a good mom” – where do you even begin? Each subtask should be specified in terms of objectives. Put together, these objectives should cover the whole area of interest—i.e., help a user achieve a goal in full.
  • Draw a layered task diagram of each subtask and ensure it is complete: You can use any notation you like for the diagram, since there is no real standard here. Larry Marine shares some helpful advice on the notation he uses, which is examined below.
  • Write the story: A diagram is not enough. Many of the nuances, motivations and reasons behind each action are simply lost in the diagram, because all that does is to depict the actions and not the reasons behind them. Make sure you accompany your diagram with a full narrative that focuses on the whys.
  • Validate your analysis: Once you’re happy with your work, review the analysis with someone who was not involved in the decomposition, but who knows the tasks well enough to check for consistency. This person can be another team member working on the same project, but you could also enlist the help of actual users and stakeholders for this purpose.

One more trick you might wish to consider is conducting a parallel task analysis. This means simply to get more than one person on your UX team to undertake the process simultaneously—so that you can later compare your outputs and merge them into a final deliverable. This can be especially helpful if you are working internationally, or where multiple personas have to be considered for the same goal.

Author/Copyright holder: University of Strathclyde, Management Science Dept., Wikimedia. Copyright terms and licence: CC BY-SA 3.0

An example layered diagram from a task analysis process (goal: warm up a furnace)

Types of Task Analysis

You can approach a task analysis activity from two main viewpoints. So far, we have discussed breaking down tasks into sub-tasks, an approach termed Hierarchial Task Analysis. However, you can also differentiate your viewpoint by focusing on tasks that require decision-making, problem-solving, memory, attention and judgment. This process is called a Cognitive Task Analysis. From this viewpoint, you would be concerned not just with how the actual activities involved in meeting a goal are performed but also with finer details that aim to uncover how a novice might perform compared to an expert, the level of cognitive load required for each step, how experts make decisions, or how users develop mental models for an activity which are later reused or adapted for other purposes.

An example of Task Analysis

Let’s now work through an example to illustrate how you might undertake a task analysis. Assume that Rosie, a home-visit doctor, needs to update the hospital’s system with her whereabouts (i.e., that she’s left one patient to go to the next) via text message. Rosie uses a custom device which appears to be a mobile phone but is tailored for use by doctors. All she needs to do is send a short SMS-like text with the words “next patient” to a certain number.

Goal: 1. Send a text message to hospital’s system


1.1. Open the messaging application on her mobile phone.

1.2. Enter the hospital system’s special number.

1.3. Move to the text input field.

1.4. Type the words “next patient”.

1.5. Check the spelling (because it needs to be precise for the system to accept it).

1.6. Hit the “send” button.

1.7. Exit the messaging application.

Author/Copyright holder: Andreas Komninos, The Interaction Design Foundation. Copyright terms and licence: CC BY-SA 3.0

A sample task analysis diagram for sending a short message to the hospital system. Note how each step represents a sub-task that can be broken down into further sub-tasks.

In the above diagram, you will notice that we have identified different “plans” about how Rosie might achieve a certain goal. In the diagram, pretty much everything except for displaying matching contact names is performed by the user. We can see that Rosie is not getting much support here. Perhaps we can intervene by redesigning the device’s messaging application.

  • We can eliminate the “hit search icon” step by showing a list of matching contacts to Rosie as soon as she begins typing any letters or numbers in the “To:” text input field.
  • We could even eliminate the typing by displaying a “frequently used contacts” dropdown under the “To:” field, even when Rosie hasn’t yet typed anything.
  • We can help Rosie spellcheck her message by highlighting the words that are spelled incorrectly or by causing the device to vibrate whenever a word is misspelled.
  • In order to prevent errors, we could disable the “send” button if spelling mistakes are present in the text.
  • We can eliminate the “exit message” step by automatically closing the messaging application once the message has been sent.

You will note that some of the ideas for improvement discussed here are based on the simple hierarchy of tasks (i.e., eliminating needless steps), whereas others depend on a cognitive analysis approach (i.e., lessening the mental workload of the user). What we ultimately decide to do will depend on how the user visualizes the problem. If the users believe that entering correctly spelled text is the source of their greatest frustration, then our design should focus on that aspect. Solving the real issues has the biggest impact on the project, and you should continuously strive to see the task analysis from the user’s perspective and not what you could actually do (or want to do).

“In my 25 years of experience on over 250 projects, not one single product has been focused on solving the right problem.”
—Larry Marine, UX consultant

Larry Marine likes to annotate his task analysis diagrams using different colors in the various flows:

  • Green represents the actions that users need to do.
  • Yellow represents a step the system can do.
  • Purple represents objects, tools, or information that the users need.
  • Orange represents questions or issues about the task.

A task analysis would probably have a greater proportion of “green” flows originally. A re-designed task would probably have fewer “green” and more “yellow” flows, to show that you’ve really managed to off-load tasks from a user to a system, thus improving their overall experience by making their lives easier.

The Take Away

Task analysis is one of the most powerful tools in a UX designer’s skillset. As you will have undoubtedly seen, it’s not hard to get to know how to do it. However, the difficult part is remembering to keep the user’s perspective and resist the temptation to generate your own interpretations of the problem, or to “stick in” bits of design just for the sake of doing it. Remember also that task analysis is useless when it isn’t backed by rigorous user research. Without user research data, any efforts to proceed with task analysis will be in the blind and will result in failure, because you will be capturing mostly what you think the problem involves, as opposed to what the users’ actual needs are. Remember also that task analysis is not a one-off process. You can repeat it on your own designs later in the process, since Design Thinking is an iterative process that will eventually lead you back to the “define” stage at some point. Finally, remember that—like any other activity in UX design—task analysis requires time, resources, people and budget. Be sure to balance these requirements carefully and engage in the process only if you have a sufficient amount of all!

References & Where to Learn More

Hero Image: Copyright holder: falcowata, Flickr. Copyright terms and license: CC BY 2.0

Christou, G. & Saraiva, C. (2012). Hierarchical Task Analysishttp://www.usabilitybok.org/hierarchical-task-analysis

Courage, C., Redish, J. G., & Wixon, D. (2009). Task analysis. Human-computer interaction: Development process, 33-53.

Hackos, J. T., & Redish, J. (1998). User and task analysis for interface design.

Hornsby, P. (2010) Hierarchical Task Analysis https://www.uxmatters.com/mt/archives/2010/02/hierarchical-task-analysis.php

Marine, L. (2014). Task Analysis: The Key UX Design Step Everyone Skips https://searchenginewatch.com/sew/how-to/2336547/task-analysis-the-key-ux-design-step-everyone-skips

Min, L. (2014) experience mapping vs. Task analysis https://www.akendi.com/blog/experience-mapping-vs-task-analysis/

Saraiva, C. & Bevan, N. (2012). Cognitive Task Analysis http://www.usabilitybok.org/cognitive-task-analysis

Sudhindra, V., & Saraiva, C. (2012). Task Analysis http://www.usabilitybok.org/task-analysis

Task Analysis, Usability.gov https://www.usability.gov/how-to-and-tools/methods/task-analysis.html


Leave a Reply

Your email address will not be published. Required fields are marked *