Communicating Decision Making via Task Modeling
Designing for Choice Architecture Series — Part 3 of 3
This is the final article of the choice architecture series. The first post was an introduction to choice architecture and the second post outlined foundational principles. This article describes task modeling and how they help you communicate how decisions are evaluated. Most designers in the UX realm are familiar with journey mapping, service blueprints, and mindset personas. I find that synthesizing my research into user task models (visual examples below) is an effective way of communicating how a person approaches making a decision and how that decision can vary depending on their current need.
When to Use Task Models
- Anytime you want to model decision making
- As a generative activity to help creatively plan exploratory research
- A visual way to collaborate with a data science team. See if they can help put metrics to steps in your model.
- To synthesize your user research into task-based mental models focused on showing decisions that go into completing a specific task.
Task Modeling Overview
Task models are one of my favorite diagrams to communicate both research we’ve done and research we need to do. They focus on the decisions steps in a flow and the evaluation that takes place to make a decision. Typically I diagram the following types of information:
- The goal of the task
- Steps
- Task phases
- Evaluations
- Outcomes
- Annotations
Evaluation Types
- Complex: when the variables a user is evaluating are difficult to quantify and compare
- Controlled: when the variables a user is evaluating are easy to compare
- Unspecified: depending on the decision you may not need to visualize the type of evaluation.
Annotation Types
- Insights: What you’ve learned from primary or secondary research
- Questions
- Ideas
- Issues areas that you want to highlight
When defining the task you want to model it’s most useful to define the task in terms of the persona’s desired outcome. Avoid a vague task such as: I want to order delivery food because I’m hungry. This is too generic. I’d turn this into a series of different task models based on research around why people get motivated to order delivery food. I’ll give example how to break this up into better scenarios below.
Task Models vs. User Flows
Task models can initially be confused with user flows. User flow diagrams tend to focus on the step by step path a user must take to accomplish a task, but user flows don’t often show the evaluation process as a user makes decisions. User flows often simplify decisions into a single question and the possible outcomes are fairly discrete.
Example: User Flow Excerpt
User flows can be created for each persona’s approach to a task. Unfortunately most designers just create one version for each user flow. This is for two reasons. The first is user flows focus on steps and simple decisions so their isn’t often a lot of variation from one persona to another. The second is that many applications don’t offer multiple ways of completing a task. Partially, this is due to how fast applications are designed and developed. Many teams don’t get the time and support to conduct the necessary research to explore the different mental models of their user base.
A user flow can easily be turned into a series of different task models based on how a persona, mindset, or other behavioral variable affects the decision making process. For example, people don’t order delivery food from a mobile just because they are hungry. This isn’t an argument that user flows aren’t useful. They are useful, they just focus on synthesizing information to communicate a different set of information then a task model.
Common Behavior Variables
There are a many behavior variables [1] to consider when modeling a task. These are in addition to the standard information you may have in a traditional persona. [2]
1. Motivations and Goals
These are often way more diverse and situational then traditional personas account for. The great thing about mindsets is that a traditional user persona can take different mindsets depending on where they are in a journey or depending on their current motivations.
2. Frequency and Length of Tasks
How often do they do this task? Is it their first time? Will they eventually development muscle memory because the task is completed frequently or will the user only do this task infrequently and therefore may need help orienting?You can add a timeline and annotations to a task model to help show time data.
3. Experience With Making These Types of Decisions
In general: Do they currently use an array of solutions, only your solution, or a competitor’s solution? If they do use your solution are they new, novice, intermediate, or an expert?
4. Comfort with Domain Knowledge
How comfortable is the user with the domain and similar systems? How can you support an array of knowledge levels?
5. Comfort with Technology
How comfortable is the user with the technology and similar systems? How can you support an array of technology comfort and trust levels?
6. Perceptions and Attitudes
What are the users attitudes towards the domain, technology, and the decisions they will need to make?
7. Contextual Information
Is this decision something they have time to do or do they need to make it as fast as possible? Are they in an environment with tons of distractions or can they focus most of their attention to the task? Etc.
8. Cultural Variables
What are the social norms regarding conflict or how hospitality is given? What other environmental factors might affect the decision making process e.g. Workplace culture, family dynamics, or social factors?
9. Accessibility and Access
Do they need to access the system all the time from anywhere? What functionality is needed where?
Examples of Task Model Scenarios
Below are some examples of how I’d break up the common task of ordering delivery food from an aggregator service. These were derived from research (interviews, observations, diary studies, and surveys) related to how people decide to order in. While there isn’t anything profound about the scenarios, having research like this helps a design team prioritize features based on common patterns rather trying to guess every single feature for every use case.
The research your conducting should help you define common situations and scenarios. This contextual information combined with user personas will help you understand how decision making tasks can differ based on the persona’s situation, the task they want to complete and other factors related to the task such as what trigger them to want to start the task, expectations, motivations, etc.
This article isn’t about personas, so I’m not going to define their backgrounds, goals, behaviors, and mindsets of the personas used in the following examples, but those are key aspects to properly utilizing personas to communicate different needs in a design. [2]
Personas: Myla & Ian
We order together, but I (Myla) tend to be the one who uses the app while Ian and I talk about what we want to order.
Situation 1
“We plan on staying in tonight to watch Westworld. We haven’t went shopping and don’t feel like cooking. On Sundays we usually order either pizza, chicken wings, or Thai. Tonight I think we’re gonna get chicken wings from our favorite delivery restaurant.”
Scenario A: Let’s order our chicken wings from our usual spot.
Scenario B: I want chicken wings from our usual spot, but Ian wants something healthier.
Situation 2
“We plan on staying in tonight to watch Westworld. We haven’t went shopping and don’t feel like cooking. On Sundays we usually order either pizza, sushi, or Thai, but tonight I (Myla) have a craving for chicken wings. I’m gonna see if I can find a restaurant that will deliver chicken wings to me.”
Scenario C: I’m craving chicken wings, where can I get them.*
Scenario D: I want chicken wings*, but Ian wants something healthier, let’s see if I can find a place that has both options.
*In this scenario they don’t have a goto restaurant for ordering chicken wings.
Situation 3
“It’s raining outside and we don’t want to go out to eat and we don’t feel like cooking. We just ordered from our favorite Thai place a couple days ago and don’t feel like ordering from one of our other usual spots: pizza or sushi. Pizza seems to heavy and I don’t want to spend the money to get sushi. Let’s see what else we can find.”
Scenario E: I want to see if I can find something new to order because I’m bored with my usual restaurants.
Persona: Carlos
I don’t order in very often, but I when I work late I don’t want to go out to eat or cook.
Scenario F: I don’t know what to order, but I want take-out.
Nuances in Scenarios can have Large Implications
“Bored with the Usuals” vs. “Not Sure What to Eat”
Based on interviews and observational research scenarios E and F are actually quite different. In scenario F, “not sure what to eat,” there are two common negative outcomes: Carlos orders something he doesn’t like and regrets using the service or Carlos ends up not placing an order.
In scenario E, “bored with the usuals” there are three common negative outcomes:
- They order something from a new place and they don’t like it
- They don’t place an order
- They end up being afraid to order something new and end up placing an order at one of their usual restaurants.
Outcome 3 for Myla & Ian is pretty common, because diners end up not wanting to risk getting something that isn’t as good or safe [3] as one of their usuals. This is because most apps don’t help assure users throughout the decision making process by providing them with the information and framing they need to make decisions with a great level of certainty.
Interaction that involve a conversion, but don’t align with the user’s original intent often get overlooked by businesses and product teams. The business gets a conversion, but from a UX perspective the user’s task wasn’t completed. To compound the issue customers often won’t give negative feedback to a business regarding this type of outcome, because they made the decision. The customer settled for food they are bored with rather than ordering something exciting and delicious. This is a failed opportunity for business to best support a user’s desire and to extend the utility of the service. Research (quantitative) supported a theory that the more scenarios you can support for a customer the more frequently they will convert. [4]
The metrics used to measure success revolve around conversion and self-reported customer satisfaction. This is why interviews, observations, data science, and synthesis are key to finding opportunities to improve and experience. [4]
Task Model Examples
Below are diagrams to show how something simple like ordering food through a mobile app can be modeled differently depending on a persona’s task. I picked a few of the above scenarios to show some contrast. These task models have been simplified to make it easier to demo. I created these in a Miro board if you want to zoom-in and check out any details.
Task Model of Scenario A
Task Model of Scenario C
Task Model Examples
The same diagrams above can be seen in better quality on Miro and includes a simple legend for the task diagram.
Footnotes
- Behavior variables list was inspired by content from: Goodwin, K. (2009). Designing for the digital age how to create human-centered products and services. Indianapolis, IN: Wiley Pub.
- Regarding personas: There is a constant debate about the value of personas. I agree personas as deliverables are mostly crap. I use the word persona to mean some sort of model of user-types and audience based on qualitative and quantitative research. I always focus my personas on goals, motivations and mindsets not demographics. They should be updated and refined frequently. Personas are best used as a “character in story” rather than just as a deliverable.
- Expected Utility (wikipedia)
- This was from user research I conducted for a client
