Core model
Task modeling turns individual use cases into a usable system shape.
Once roles and essential use cases exist, the team must organize them: what is common, what is rare, what comes before what, and which tasks define the product's main work rhythm.
Purpose
A task model prevents use cases from becoming an unordered inventory. It shows the relationship among tasks and helps the team decide interface structure, release priority, and evaluation coverage.
Task Relationships
| Relationship | Question | Design consequence |
|---|---|---|
| Sequence | Does one task normally follow another? | Support continuation, progressive disclosure, and state preservation. |
| Containment | Is one task a smaller part of a larger task? | Consider inline subflows, panels, or reusable task fragments. |
| Alternative | Are there mutually exclusive ways to accomplish a goal? | Make the choice explicit and avoid mixing incompatible paths. |
| Exception | What interrupts normal completion? | Design recovery, explanations, and re-entry points. |
| Collaboration | Does another role take over part of the work? | Expose status, ownership, handoff, and notification clearly. |
Priority And Frequency
Not every modeled task deserves the same interface weight. A high-frequency, high-value task should be easier to reach and faster to execute than a rare administrative task.
Frequent and important
Optimize for speed, low friction, keyboard support, saved context, and direct access.
Rare but risky
Optimize for guidance, confirmation, auditability, and clear explanation.
Frequent but low consequence
Make it lightweight and forgiving. Avoid heavy confirmation unless error cost is real.
Rare and low consequence
Keep it available, but do not let it dominate navigation or primary workspaces.
Task Case Inventory
A useful inventory records enough information to sort and design without becoming a specification dump.
- Task case name and short purpose.
- Primary and secondary roles.
- Trigger or starting condition.
- Main success result.
- Frequency, urgency, and error cost.
- Related tasks, variants, and exceptions.
- Candidate release priority.
- Open questions that block design decisions.
From Model To Design
The task model starts to imply interface architecture. Tasks that share objects may belong in the same workspace. Tasks with different roles, risk, or frequency may need separate flows. Tasks that are always performed together may become one integrated interaction.
Heuristic
When two tasks have different roles, different completion criteria, and different failure consequences, be skeptical of placing them behind the same primary command.