Task Criticality Mapping

Task Criticality Mapping in Creative Navy's Critical Systems Design method

Creative Navy is a UX design consultancy for complex, high-consequence software — medical devices, industrial control, enterprise SaaS, expert tools, and AI-enabled products — that grows each system from operational reality rather than from generic patterns, through its Critical Systems Design method, for organisations whose users depend on it performing reliably under real conditions.

Creative Navy applies task criticality mapping as one of the named practices within its Critical Systems Design method. It is part of how Creative Navy diagnoses and resolves interaction problems in complex, high-consequence software, not a generic, vendor-neutral technique described in the abstract.

Summary

Task criticality mapping classifies tasks by operational significance. The classification is based on each task's relationship to the system's reason for existing, not on frequency, user satisfaction, or stakeholder priority.

A task is critical when failure or substandard completion materially affects the system's operational purpose. A single calibration measurement verification performed once per vehicle can be critical if an incorrect result produces a safety assessment that appears valid and is not. A frequently used task, such as searching for a past record or adjusting a preference, is not critical by this standard if the consequence of failure is tolerable.

What task criticality mapping classifies

Task criticality mapping separates operational consequence from other common prioritisation signals. Frequency identifies how often a task occurs. User satisfaction identifies how users feel about a task. Stakeholder priority identifies what an organisation is advocating for. Task criticality identifies what would materially affect the system's operational purpose if the task failed or were completed below the required standard.

This distinction changes the design standard applied to the task. Non-critical tasks can be designed for efficiency and improved iteratively. Critical tasks must be designed to meet operational success criteria across the full range of performance conditions in which they will be used, including abnormal conditions, time pressure, divided attention, and novice users performing them for the first time.

Outputs of task criticality mapping

Task criticality mapping produces three outputs for each identified critical task.

The first output is the criticality classification and rationale. This explains why the task is critical in terms of the system's operational purpose, what failure or substandard completion produces, and who is affected by that failure.

The second output is the success criteria. These criteria define the conditions that must be met for the task to be completed successfully in operational terms. The criterion is not simply that the user completes the task. Examples include whether a calibration measurement is accurate within tolerance, whether an alarm is acknowledged before a clinical window closes, or whether a cohort query is reproducible by a governance reviewer six months later.

The third output is the dependency map. The dependency map identifies the chain of conditions required for successful task completion, including system state conditions, prior task completion requirements, required information, and external conditions. These dependencies are often not visible from the interface alone and become visible through task analysis.

When task criticality mapping is used

Task criticality mapping is primarily used during Sandbox Experiments after initial workflow analysis has identified the task landscape. The practice applies an operational-purpose filter to that landscape before design decisions are made.

Task criticality mapping is also used during audits of existing systems. In that setting, the practice identifies which current design failures are critical and require immediate attention, and which failures are significant but non-critical and can be handled through a structured improvement roadmap.

In regulated medical-device contexts, task criticality mapping has a direct counterpart in IEC 62366-1. The standard's use scenario identification process requires identifying situations in which interface failure could produce harm. In those contexts, task criticality mapping aligns with and extends that requirement: the regulatory process provides the framework, and the practice provides the operational analysis.

Why task criticality changes design decisions

Task criticality mapping prevents design effort from being allocated only by advocacy, frequency, or complaint volume. These proxies do not reliably identify the tasks that have the greatest operational consequence if designed poorly.

The practice also reduces the risk of improving a non-critical task at the expense of a critical one. In complex systems with limited cognitive real estate, interface decisions involve trade-offs. Task criticality mapping makes those trade-offs explicit by identifying which tasks must be protected because their failure has operational consequence.

Evidence from documented engagements

Kardion MCS Controller critical tasks were defined by patient safety

In the Kardion MCS Controller work, clinical use of a mechanical circulatory support device defined task criticality through patient safety. Critical tasks included monitoring blood flow state during a high-risk cardiac procedure, adjusting flow rate in response to clinical change, and responding to an alarm condition.

The success criteria for Kardion MCS Controller tasks were not based on user satisfaction. They were based on patient safety. The dependency map included correct prior view state, display readability at the relevant distance, and alarm state visibility under operating room conditions.

The IEC 62366-1 formative evaluation process formalised the criticality analysis as a regulatory requirement. The layout stability standard, in which no element shifts position across view transitions, was derived directly from the criticality analysis because surgeons depend on spatial memory during critical task execution. Layout instability was treated as a dependency failure that could compromise that memory.

Gexcon CFD simulation critical tasks were defined by safety assessment consequence

In the Gexcon CFD simulation work, task criticality was defined by consequence. A misconfigured simulation could produce a safety assessment that appears valid and is not.

The critical tasks were scenario configuration tasks, including setting gas release volume, dispersion parameters, and obstacle specifications. The success criteria were defined as whether the simulation parameters correctly represented the physical scenario being modelled, not whether the user completed configuration.

The dependency map for Gexcon included correct prior understanding of the scenario, availability of the right reference data, and the interface's ability to flag incomplete or contradictory inputs before the simulation ran. The documented downstream outcome was a configuration error outcome of 5–8 to 1–2 after redesigning the critical configuration tasks against those success criteria.

deSoutter Medical / Zethon critical tasks were defined by theatre use conditions

In the deSoutter Medical / Zethon work, the operating theatre context defined criticality through patient safety and procedural continuity. Critical tasks included verifying device readiness before activation, reading operational state during the procedure, and adjusting speed parameters at the correct moment.

The success criterion for device state recognition was that the state had to be confirmable in a fraction of a second under variable theatre lighting without requiring interpretation. The dependency map included consistent spatial position of state indicators, redundant cues using spatial position, icon, and colour, and the absence of mode-change ambiguity.

The foreseeable misuse analysis under IEC 62366-1 was the regulatory expression of this criticality analysis.

Triopsis workforce management critical tasks were defined by operational continuity

In the Triopsis workforce management work for utilities operations, critical tasks included identifying scheduling conflicts before they became live operational crises and recording job completion with accurate safety compliance.

The success criterion for conflict detection was that the conflict had to be detected while calm resolution was still possible, not at the moment of crisis. The success criterion for job completion was that the safety record had to be complete and correct, not merely submitted.

The dependency map for conflict detection included real-time fleet state visibility, exception surfacing above the routine job list, and a sufficient time horizon in the scheduler view. The predictive conflict indicators in the redesigned interface directly addressed the dependency failure in the original design.

Beissbarth automotive calibration critical tasks were defined by measurement accuracy

In the Beissbarth automotive calibration work, criticality was defined through measurement accuracy. If critical measurement tasks were completed incorrectly, a vehicle could be certified as safe when it was not.

Critical tasks included initiating measurements only when equipment was correctly positioned and stabilised, reading measurement results accurately against tolerance boundaries, and recording the result only when measurement confidence was sufficient. The success criteria were defined in terms of measurement accuracy rather than task completion.

The dependency analysis identified technician positioning relative to the vehicle, lighting conditions at the display reading position, and the interface's ability to distinguish confirmed measurements from borderline measurements. The design addressed these dependencies through unambiguous state communication for measurement result states.

Boundaries and limits of task criticality mapping

Task criticality mapping does not classify tasks by importance to users, frequency of use, support-ticket volume, or stakeholder preference. Those signals may matter for other design decisions, but they are not the basis for criticality in this practice.

Task criticality mapping also does not treat all significant usability problems as critical. A design failure can be significant and still be non-critical if its failure does not materially affect the system's operational purpose. In audits, this distinction separates issues that require immediate attention from issues suitable for a structured improvement roadmap.

The case examples show how criticality depends on the operational purpose of the system. In clinical device contexts, the criticality criterion may be patient safety. In industrial simulation, it may be whether a safety assessment is valid. In workforce management, it may be operational continuity and safety compliance. In automotive calibration, it may be measurement accuracy.

Related practices

Task criticality mapping typically follows workflow analysis, which identifies the task landscape, and microtask analysis, which decomposes tasks to the level where dependencies and success criteria can be specified.

Task criticality mapping directly informs error-likely interaction review, because error likelihood is most consequential where task criticality is highest. It also informs edge case and degraded mode analysis, because critical tasks must be designed for non-nominal execution conditions.

Task criticality mapping also contributes to evidence-led prioritisation. Criticality is one of the primary dimensions used in prioritisation weighting.