Task Landscapes
Traditional software design decomposes work into task hierarchies: goals into sub-goals, sub-goals into steps, and steps into actions. This is a logical arrangement, well suited to linear, well-structured tasks. It does not adequately describe complex professional work.
Barbara Mirel offers a better unit of design in the task landscape1: a configurable terrain of activities, decision points, and paths that users traverse differently depending on situational conditions, emerging insights, and professional judgement. There's no single correct path through a task landscape. Instead, there are regions, landmarks, choice points, and well-worn trails that professionals navigate with a mix of pattern recognition and improvisation.
Mainline Tasks vs. Enabling Tasks​
The most important distinction in task landscape design is between mainline tasks and enabling tasks.1
Mainline tasks are the core analytical or creative operations: filtering data, applying effects, modelling geometry, compositing layers. These directly produce the work output and are what design teams typically model and prioritise.
Enabling tasks are the supporting operations that make mainline tasks possible: annotating views, bookmarking states, comparing versions, writing notes, seeding the workspace with reminders, verifying data integrity, managing file organisation. In practice, these require considerable effort and are essential to expert performance, yet they are systematically overlooked in design specifications.
If your design supports "filter, sort, and select" but not "remember why I filtered this way," it will fail users doing complex work.
For every mainline task in your software, ask: What does the user need to remember, compare, annotate, or verify to make this operation meaningful? Those are your missing enabling tasks.
Choice Points​
A choice point is a moment where the user faces multiple legitimate next steps, and the right choice depends on domain knowledge, situational factors, and emerging findings. A 3D artist might refine topology before texturing, or skip ahead to rough textures to test the look first. A data analyst might investigate a suspicious outlier or set it aside to focus on the main trend.
Software cannot make these decisions, but it can support them:
- Make available options visible (feed-forward)
- Provide enough information to make an informed choice (context)
- Allow the user to change course later without penalty (provisionality)
- Preserve the state of the unchosen path for later return (bookmarking)
Cross-Pattern Traversal​
Users of complex software don't stay within a single workflow pattern.1 They move between patterns of inquiry, returning to an earlier analysis with insights gained from a different investigation.
A video editor reviewing colour grades (Pattern A) notices an audio sync issue and switches to audio editing (Pattern B). After fixing the synchronisation, they return to colour grading, now aware that a particular shot needs re-timing, something they discovered during the audio work. The return to Pattern A is informed by Pattern B.
Such transitions are routine. Software must support smooth travel within and across task landscapes:
- State preservation when switching contexts
- Easy re-entry to previous working states
- Visible markers showing what's been done in each area
- No penalty for interrupting one pattern to pursue another
Mapping Your Software's Task Landscapes​
When designing or evaluating IA for complex software:
- Observe real users working on real problems. Watch where they backtrack, switch context, reach for external tools, or pause to orient themselves. These moments reveal the shape of the task landscape.
- Identify mainline tasks, then identify the enabling tasks users perform around them.
- Map the choice points. Where do users face decisions with multiple legitimate paths? What information do they need at those moments?
- Trace cross-pattern traversal. When users switch between different types of work, what state needs preserving? What context do they need to resume?
- Audit for gaps. Where do users leave the software to accomplish something, using notes apps, spreadsheets or paper? Investigate whether these transitions reveal missing enabling tasks or a deliberate choice to use another tool.
Investigate the Reason for an Application Switch​
Leaving an application does not, by itself, identify a missing feature. When mapping a workflow, record why the switch occurs and what it costs the user. The appropriate response may be better interchange or learning material that explains the complete workflow across applications, rather than another feature inside your own.
Check the Task Landscape​
| Check | Practical question or example |
|---|---|
| Design decision | Can the user change approach without losing useful preparation or decisions? |
| Failure to look for | A revised brief forces the user to restart a completed setup. |
| Verification task | Introduce a plausible change of plan, then follow the work through its handoff and application boundary. |