Errors Are Easy To Make

Summary

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.

Errors are easy to make when an interface leaves the incorrect path too accessible relative to the correct one during normal, intentional operation. The interface may be technically complete and may perform all required functions correctly, but it does not provide enough constraints, guidance, or feedback for users to avoid predictable mistakes.

The cost of this failure is not always visible as error counts. It can appear as training investment required to produce reliable users, recurring support burden across the user population, and an adoption ceiling where non-specialist users cannot operate the system reliably without specialist assistance.

Failure pattern: predictable errors during standard operation

The errors-easy failure pattern concerns interface conditions that produce errors while users are on the designed path. The user is trying to perform a valid task, but the interface does not distinguish valid from invalid actions in terms the user can read before acting.

This failure is distinct from poor interaction support for rare or non-standard scenarios. Rare-scenario support concerns what happens when the user is outside the standard path. Errors-easy design concerns what happens when the user is on the standard path, but the design does not adequately prevent the user from going wrong on it.

A system can satisfy functional requirements and still make errors easy. The failure is not that the software cannot perform the operation. The failure is that the software does not communicate what conditions, selections, inputs, or sequence steps are required before the user commits to an action.

Absence of pre-action constraint and validation

The most preventable errors-easy condition occurs when an interface accepts an action or input that is structurally invalid for the current context. The user provides data in a format the operation cannot use, selects an element that is incompatible with the current operation, or starts a sequence that requires an unmet precondition. The interface accepts the action, and the error occurs.

Pre-action constraint and validation are architecturally different from post-action error messages. A field that accepts only certain formats communicates constraints before entry. A column list that distinguishes operable from non-operable columns communicates operability before selection. A workflow that cannot proceed without a necessary precondition makes the precondition visible before the user attempts to pass it.

The design requirement is to make valid choices substantially more visible than invalid ones before the user acts. The correct action becomes easier not because users have memorised the rules, but because the interface exposes the relevant constraints at the decision point.

Absent or ambiguous feedback at decision points

Errors are also easy to make when an interface does not clearly communicate whether the action just taken was the intended one. The user makes a selection, the interface updates, and the user cannot read from the update whether the expected result occurred.

This condition appears at decision points where several actions are available and the difference between them is not visually or interactively clear. If the user cannot tell whether the right element was operated on, whether the right configuration was applied, or whether a required step was completed correctly, the error may only become visible much later.

Late feedback makes the origin of the error harder to trace. The user sees the consequence in a later context, but the interface did not provide actionable feedback at the moment when the error was still easy to identify and correct.

Interface complexity can hide the operative element

A third errors-easy condition occurs when interface complexity prevents users from identifying which element or condition is currently operative. The user's intended action may be correct, but the user applies it to the wrong element because the interface does not make the relevant element sufficiently distinct.

This condition is common in data-heavy interfaces where multiple elements look similar but serve different operational functions. It appears when columns contain multiple types of content, when the current operative element depends on a state that is not surfaced clearly, or when many similar items have similar visual weight.

The same structural failure appears in information-dense content systems. A user navigating dense legislative text who cannot distinguish which regulatory item is correct for the current purpose is experiencing a retrieval and orientation version of the same failure: the interface does not communicate which element is relevant before the user commits to it.

Polymatica analytics platform: column operability was not visible before operation

In the Polymatica analytics platform, users needed to perform OLAP operations on imported datasets. The workflow required identifying the relevant column, applying the appropriate operation type, and obtaining the intended analytical output.

Before the redesign, the interface did not visually distinguish which columns were operable for which operations and under what conditions. When users imported real datasets, they encountered columns with mixed content, inconsistent formats, or values the system could not operate on for the intended purpose. The interface presented all columns without distinction.

The specific error condition was column selection without operability guidance. Users could not tell which column would support the intended operation, which column contained the issue preventing the operation, or what the issue was. Users attempted operations on columns that would not produce the intended result, received errors or unexpected outputs, and had no designed path for diagnosing what had gone wrong.

The design response introduced a data preparation and preview step between data import and operations. Users could inspect their actual data before committing to operations, see a sample of what their columns contained, rename columns to match their mental model, and identify structural inconsistencies before errors occurred downstream.

The Polymatica outcome is evidence-calibrated. The messy-data failure mode, specifically the inability to identify which column to operate on, largely disappeared from support requests after the data preparation step was introduced. This was a Creative Navy-observed operational change, not a measured error-rate reduction.

The broader Polymatica outcome was that independent task completion rose from 2% to 40% and then 56%, measured through product analytics from the live system. That broader independence gain includes but is not limited to the errors-easy improvement.

Enhesa legal compliance platform: orientation and retrieval errors in dense content

In the Enhesa legal compliance platform, regulatory affairs managers, compliance officers, and legal teams navigated dense baseline regulation pages. These pages aggregated legislative text, implementation timelines, requirements, and changes for individual regulations across jurisdictions.

A systematic review of 95 session recordings produced a catalogue of 12 error types, each with measured time-to-redress. Known error types included clicking into the wrong legislative text, creating the wrong filter, and missing a correct search result that was present in the system.

These were orientation and retrieval errors. Users were not necessarily misunderstanding their task. They were arriving at or acting on the wrong element because the interface did not make the relevant element sufficiently distinct from irrelevant elements at the moment of selection.

The Enhesa design response used three levels of intervention. Three error types were made structurally impossible because the interaction conditions that produced them were eliminated. Five error types were made easier to recover from because the interface provided clearer feedback and a shorter correction path. Six error types were expected to reduce in frequency because the correct path became more visible and the incorrect path less accessible.

The Enhesa evidence has a stated limit. The 12 error types and 31 workarounds were Creative Navy-recorded from session recording analysis during Sandbox Experiments. The post-redesign outcomes of 3 error types made impossible, 5 easier to recover from, and 6 reduced in frequency were inferred from design decisions and were not independently measured post-deployment.

Of the 31 workarounds documented in the same session recording analysis, 80% were addressed in the redesign. The concentration of 17 of 31 workarounds in the primary content area, "Using legal texts", indicated that the errors-easy condition was concentrated where the platform's core function operated.

How Creative Navy's Critical Systems Design method addresses errors-easy interfaces

Creative Navy's Critical Systems Design method addresses errors-easy interfaces by identifying the specific points where predictable errors occur and by making the correct path substantially more accessible than the incorrect one at those points.

Microtask analysis is the practice that makes error-point identification specific. A generic usability finding might say that users struggled with column selection. Microtask analysis produces a design requirement such as: users could not distinguish operable from non-operable columns because the interface presented all columns with equal visual treatment and provided no preview of what operations would produce with actual data.

In the Polymatica engagement, domain learning included Creative Navy performing operations on real data. That activity exposed the messy-data column-identification problem as an experienced failure rather than only an inferred one. The resulting design requirement was that the interface needed to communicate column operability status before the user selected a column.

In the Enhesa engagement, session recording analysis provided the equivalent evidence practice for a content-heavy platform. The systematic review of 95 recorded usage sessions surfaced actual error patterns at scale, and the time-to-redress measurement added a cost dimension to the error catalogue.

Boundaries and limits

This failure pattern is limited to errors made during standard operation. It does not cover rare scenarios where the user is outside the standard path and needs interaction support for a non-standard situation.

The Polymatica error-specific outcome is directional and observed rather than quantified as a measured error-rate reduction. The broader independent task completion figures of 2%, 40%, and 56% were measured through product analytics from the live system, but those figures include more than the errors-easy improvement.

The Enhesa post-redesign error outcomes were inferred from design decisions. The available evidence does not state that the 3 impossible, 5 easier-to-recover, and 6 frequency-reduced error outcomes were independently measured after deployment.