Writing use cases that capture edge cases and errors

A use case should explain how a person achieves a goal through a system, including what happens when the smooth path breaks down. Happy-path descriptions are useful, but they rarely reflect the conditions people encounter in daily life. Network dropouts, missing information, access needs, unusual account states and simple misunderstandings can all change the outcome. Learn more about Why Heuristic Evaluations Are Essential Early In Design.html.

For UX teams, an edge case is not necessarily an unlikely curiosity. It may be a routine situation for a smaller but important group of users. An older person using a screen reader, someone in regional Australia dealing with unreliable connectivity, or a customer whose payment has been held for review may experience the “exception” as the main journey.

Clear use case writing gives researchers, designers, developers and testers a shared reference point. It turns vague concerns such as “the system should handle errors well” into observable behaviour, decision points and recovery paths. This makes requirements easier to review and usability findings easier to act on.

UCDmanager supports teams documenting use cases alongside personas, user roles, evaluations and testing activities. A structured record helps preserve the reasoning behind a workflow, rather than reducing it to a collection of screens or tickets that become difficult to interpret later.

Begin with the user’s goal

Start by defining the outcome the user is trying to achieve, not the feature they are using. “Submit a Medicare claim” or “change delivery details” describes a meaningful goal, while “click the claims button” describes only an interface action. The goal gives the scenario purpose and helps the team judge whether an error message supports progress.

Identify the primary actor, supporting actors, preconditions and successful outcome. Include relevant assumptions, such as the user having verified contact details or the service being available. In Australia, a workflow may also involve a carer, interpreter, support worker or authorised representative, especially in health, government and community services.

Separate variations from failures

An alternative flow is a legitimate variation that still leads towards the goal. A user might choose a postal address instead of a residential address, pay by card rather than bank transfer, or use a keyboard instead of a mouse. These paths should be documented because they reveal different requirements without representing a system failure.

An exception flow occurs when the intended action cannot continue as expected. Examples include an expired session, an invalid format, duplicate submission, insufficient permissions or an unavailable service. Describe the trigger, the system response, the user’s next available action and the final state. Avoid treating every unusual route as an error; the distinction keeps scenarios precise.

Describe failure conditions precisely

Replace broad statements with conditions that can be observed and tested. “The payment fails” is too general. A useful scenario might state that a bank authorisation times out after the user selects “Pay”, no receipt is issued, the order remains unpaid, and the user can retry without creating a second order.

Error copy deserves the same attention as functional behaviour. State what the user can do, explain the problem in plain language, and preserve any information already entered where appropriate. Terms such as “arvo” may feel friendly in Australian products, but important instructions should remain clear across age groups, regions and formal service contexts.

Early evaluation can expose confusing recovery paths before development work becomes expensive. A heuristic evaluation guide can help teams examine feedback, consistency, error prevention and user control while the use case is still being refined.

Include real-world constraints

Edge cases often come from the environment rather than the interface. A customer in rural Queensland may lose mobile coverage during an upload. Someone using public Wi-Fi in a library may close a browser tab accidentally. A person in Western Australia may complete a task in a different time zone from the service team handling a manual review.

Record what happens when connectivity disappears, a device changes orientation, a browser is unsupported or a user returns after several hours. Consider latency as well as total failure. If the system appears frozen during a slow connection, a user may press the submit button repeatedly, creating duplicate requests and uncertainty about whether an order was accepted.

Model risky and unusual journeys

Some domains need scenarios for behaviour that is uncommon but financially or emotionally significant. A commerce or entertainment service, for example, should document what happens when a bonus offer expires during a transaction, a balance is updated late, or a user tries to continue after a responsible-use limit has been reached. A comparison with bonus round behaviour illustrates why product teams must distinguish promotional states from ordinary transaction states.

Do not use unusual examples merely to make a document look thorough. Prioritise situations based on harm, frequency, regulatory exposure and difficulty of recovery. In Australia, consumer guarantees, privacy obligations and state-based service requirements can make a seemingly minor failure important. A misleading confirmation or inaccessible cancellation path may create support costs as well as compliance risks.

Make accessibility part of every path

Accessibility should appear in the main scenario and its alternatives, not in a separate note added at the end. Explain how a keyboard-only user reaches the error, how a screen reader announces a changed status, and whether colour is being used as the only indication of failure. Include timeout extensions, focus management and readable validation messages where they affect task completion.

Consider users who enlarge text, use voice input or rely on captions. A form that rejects an address without identifying the exact field can be difficult for many people, not just users with disabilities. Web Content Accessibility Guidelines provide useful reference points, but the use case should still describe the practical experience and the user’s recovery options.

Link scenarios to design and testing

A use case becomes more valuable when each exception can be traced to a requirement, design decision, prototype state or test case. Give flows stable names, such as “expired session during application submission” or “duplicate payment after delayed response”. This allows a team to discuss a specific risk instead of arguing about a broad feature.

UCDmanager’s use case workspace can help teams organise primary flows, alternative paths and error handling in one project. Connect each scenario to personas and user roles so that assumptions remain visible. A person applying on behalf of a family member may have different permissions from the account holder, and that distinction should be testable.

Review scenarios with people who know the service

Designers may identify interface failures, while customer support staff know the questions people ask after something goes wrong. Developers understand technical limits, and compliance specialists can identify obligations that are easy to miss. Reviewing use cases together often reveals missing states, unclear ownership and recovery steps that no single discipline can see.

Use realistic Australian examples during workshops: a payment made through an unstable connection, an NDIS-related representative acting for another person, or a user completing a form on a small mobile screen while travelling between regional towns. Keep the wording neutral and respectful, then validate the assumptions with research or support data.

When a scenario exposes uncertainty, document it as an open decision rather than silently choosing an answer. Teams using UCDmanager can contact the UCDmanager team when they need help understanding how to organise their project documentation. Regular reviews keep edge cases current as policies, integrations and user expectations change.