Shift design focus from what users do to what they are trying to achieve
Desired Outcomes describe what users are trying to achieve when performing a task or subtask, independent of the tools or approaches they currently use. Building on outcome-oriented thinking known from Jobs-to-be-Done and Goal-Directed Design, they shift the design discussion from reproducing existing task flows toward exploring alternative ways of achieving the same goals.
Specify the activity you want to analyze. The activity can be a single task, a responsibility, or a multi-phase journey
Example: Order Pizza from a delivery service for a business meeting
Describe the activity in a single sentence without prescribing a particular product or solution.
Optionally include context such as who is performing the activity and under what circumstances.
Adding context helps make the analysis more domain-specific.
A broader scope helps reveal desired outcomes at different levels of activity
The analysis takes several minutes depending on the scope and number of tasks identified
Select a task from the task hierarchy to explore its detailed context-of-use information
Example: Find pizza delivery service
User Requirements are derived for each subtask within the selected task
Desired Outcomes describe what users aim to achieve across the core tasks and subtasks
A desired outcome specifies the dimension and value direction of a user intent
Desired Outcomes are organized along the task hierarchy
Task-level outcomes describe what users ultimately aim to achieve in context of the task
Subtask-level outcomes describe what successful performance means at a more detailed level
Use the Affinity Diagram for Key Opportunities to understand underlying patterns
Use desired outcomes to understand what successful task performance means from the user's perspective
Review the desired outcome against the current way of achieving it
Look for outcomes that remain relevant even when the tools or approaches used to perform the task change
Review Desired Outcomes and User Needs together to understand the “in order to” relationship between them
Follow the hierarchy from detailed outcomes to the higher-level outcomes they contribute to
Look beyond the activity itself to the outcome the user is ultimately trying to achieve.
Separate desired outcomes from today's way of achieving them so existing subtasks and workflows do not automatically become requirements for the future solution.
Keep the intended outcome stable while exploring fundamentally different approaches instead of merely improving the current process.
Use explicit desired outcomes to focus design and product discussions on what should become easier, faster, more reliable, or otherwise better for the user.
Evaluate proposed solutions against what users are trying to accomplish rather than only checking whether they support the expected task flow.
Use desired outcomes as a human-centred basis for defining how you will judge whether a solution successfully supports the user's job.
Use higher-level desired outcomes to describe what an agent should help accomplish without prescribing the sequence of actions it must follow.