Articles

Documenting use case variations for different user types

A use case becomes misleading when it contains one seamless path. People may share a goal—refreshing a prescription, claiming a subsidy or changing a booking—yet begin with different permissions, devices, locations, support needs or urgent constraints. Documenting use case variations makes those differences visible without creating a separate story for every individual.

Australian services often cross complex contexts. A customer in suburban Sydney may expect a self-service app, while someone in regional Western Australia may rely on intermittent mobile coverage and telephone support. Visitors speaking English as an additional language, older residents using screen readers, and small-business staff working “arvo” shifts may need the same outcome through different routes.

The aim is to record conditions that change a journey: what a role can do, which channel is available, what information must be supplied and how the person can recover. UCDmanager provides a free, collaborative workspace for linking roles, personas, use cases and evaluations, giving teams one traceable place to compare the core flow with its approved alternatives.

Capture the core journey first

Begin with a goal-level use case, such as “submit a refund request”, and define its trigger, preconditions, main success path and completion criterion. Keep this baseline deliberately small. Then identify variation dimensions rather than personas alone: customer status, account ownership, device capability, channel, urgency, language support and prior knowledge. A person may occupy more than one role, and the same role may change across circumstances.

For each dimension, ask whether it changes access, order, content, assistance or failure handling. A temporary visitor might enter through a kiosk and provide extra identity evidence; an existing account holder might use an authenticated portal. Record these as named variants such as first-time claimant, delegated carer or assisted applicant, with the shared goal and the point of divergence stated explicitly.

Model context, capability and access

Context determines which route is realistic. Urban customers in Melbourne and Brisbane often have fast mobile data and several payment options, whereas remote customers may face latency, data caps or a need to save and resume. Seasonal conditions matter too: smoke, extreme heat or bushfire disruption can prevent travel or delay delivery. These constraints should appear as assumptions or alternative paths, not decorative persona details.

Capability and accessibility need equal precision. Document screen-reader operation, keyboard-only steps, plain-language prompts, larger touch targets and the availability of human assistance. A comparison of evaluation methods can help a team decide whether interface rules or task reasoning warrants greater attention. Evaluate each variation with representative content and realistic failure states, not the ideal mock-up.

Document branches, exceptions and recovery

A variant is not complete if it only changes the entry screen. Capture optional steps, skipped checks, different approval chains and varied data requirements. Also name abandonment points. For a booking service, an interstate traveller may need an instant digital payment, while a community organisation paying by bank transfer may wait for an invoice and receive a different confirmation. Australian use of BPAY, cards, bank transfers and buy-now-pay-later services makes payment channel a genuine variation.

Failure paths deserve the same visibility as successful ones. Specify what happens when verification expires, a document is unreadable, stock changes or a connection drops, plus any telephone, staffed-counter or resumption route. If a team shares exported PDFs as well as live records, this guide to unlocking PDFs for editing can help reviewers annotate variants without altering the source artefact. The authoritative use case should retain every approved workaround.

Validate variants with representative users

Review variants before implementation by walking through their triggers, decisions and recovery routes. Distributed reviewers can use a distributed heuristic evaluation to inspect consistency across web, mobile, tablet and assisted-service channels. Check that labels match Australian service language, that prompts do not assume local knowledge and that conversational reassurance is balanced by a clear next step.

Then test the highest-risk paths with people who can credibly experience them, including people using assistive technology and people with limited connectivity. Compare completion, time, errors and support requests across variants. A variant that creates extra work may still be valid; document that trade-off and the operational support required so the business does not quietly push users back onto the default path.

Maintain the variation catalogue

A variation catalogue works best as a living record. Give every branch a stable identifier, owner, rationale, status and links to supporting research. Keep accepted, provisional and retired paths distinct, and record the date and evidence behind each decision. This makes it easier for product, service, compliance and design teams to understand why multiple routes exist.

Each documented variation should meet these standards:

Project owners can use contact UCDmanager to confirm access for distributed reviewers and accessibility specialists. Each release-milestone review records changed branches, while retired flows remain archived with their original rationale.