Workflow Analysis

Workflow Analysis 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 workflow analysis 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

Workflow analysis documents how work is actually done in operational settings. It maps the sequences, decision points, deviations, workarounds, informal adaptations, and role-spanning handoffs that are often absent from process documentation, requirements, and user self-report.

The core distinction in workflow analysis is the difference between designed workflow and actual workflow. A workflow diagram drawn from requirements or stakeholder interviews captures how a system was intended to operate. Workflow analysis captures how work proceeds under real conditions. In complex professional systems, the divergence between the two is often the main finding.

What workflow analysis documents

Workflow analysis produces a map of actual workflows rather than intended workflows. The map shows where a system supports work, where it fights the work, which informal practices have developed to compensate for interface failures, and which informal practices encode operational knowledge that a redesign must preserve.

Workflow analysis treats workarounds as evidence rather than noise. Some workarounds are failure signals: they show that the interface does not support what users need to do. Other workarounds are preservation signals: they contain operational knowledge that the redesigned system must carry forward.

Workflow analysis also documents role-spanning handoffs. These handoffs are primary failure locations in multi-role systems because work or context passes between people, roles, or operational groups.

When workflow analysis is used

Workflow analysis is primarily used during Sandbox Experiments before design decisions are made. It is also used diagnostically during audits of existing systems, where the goal is to understand what the platform supports and does not support before recommending changes.

In multi-role systems, workflow analysis must be conducted per role. The scheduler's workflow, the field technician's workflow, and the operations manager's workflow in a workforce management system are distinct workflows. Aggregating them produces a picture that is accurate for none of the roles.

When direct observation is not feasible, session recording analysis can substitute for or supplement in-situ observation. This applies when a platform is already deployed at scale, when the user base is geographically distributed, or when the operational context does not permit in-person access.

How workflow analysis is applied

Workflow analysis requires observation rather than interview alone. Complex professional work includes tacit sequences, informal adaptations, and decisions made in fractions of a second that practitioners cannot fully reconstruct in retrospect.

In-situ observation involves observing work in its actual operational environment under real conditions. It surfaces behaviour that self-report often misses, including checklists taped to monitors, parallel spreadsheets running alongside the system, and shortcuts developed under pressure.

Contextual interview asks practitioners to walk through their work while doing it, or immediately after completing a task. Proximity to the actual work produces more accurate accounts than a separate retrospective interview.

Protocol walkthroughs are structured sessions in which practitioners describe specific workflows as if teaching them to a newcomer. These walkthroughs surface implicit sequence logic that experienced practitioners no longer consciously notice.

Documentation analysis reviews process documents, training materials, and system specifications to establish the intended workflow before investigating the actual workflow. The gap between intended workflow and actual workflow is the starting point for the analysis.

Session recording analysis systematically reviews recorded usage sessions from a deployed platform to reconstruct actual user behaviour at scale. In-situ observation provides contextual depth; session recording analysis provides behavioural breadth. The two methods are complementary when both are available.

The research protocol adapts in real time based on what early sessions reveal. When a workaround pattern appears in the first clinic or workshop, subsequent sessions probe it explicitly. Workflow analysis in complex operational contexts does not depend on a fixed protocol that remains unchanged after early findings emerge.

Outputs of workflow analysis

Workflow analysis produces a documented map of actual workflows per role. The map shows sequences, decision points, and deviations from the designed flow.

Workflow analysis produces a workaround catalogue. Each workaround is tagged as either a failure signal, where the behaviour compensates for a system failure, or a preservation signal, where the behaviour encodes operational knowledge that the design must preserve.

Workflow analysis produces an error catalogue. The catalogue identifies recurring failure conditions across the user population, each with its frequency and, where measurable, the time cost of detection and recovery. Error catalogues inform both error prevention design and error recovery design.

Workflow analysis identifies handoff points. These are the points where work or context passes between roles and where failures commonly occur in multi-role systems.

Workflow analysis provides the empirical starting point for Microtask Analysis and Task-Criticality Mapping. Workflow analysis identifies the boundaries of significant workflows; Microtask Analysis decomposes those workflows into discrete actions; Task-Criticality Mapping assesses which tasks carry the highest operational consequence.

Workflow analysis also produces a picture of what the system actually supports versus what it claims to support. This gap between designed and actual operation determines the real scope of a redesign.

Evidence basis from documented engagements

The Triopsis workforce management engagement used 3 in-situ observation sessions under operational pressure. Schedulers were managing weather incidents, crew shortages, and overlapping jobs simultaneously. The observation sessions showed that self-report interviews had not produced an accurate account of how work was done under pressure.

In the Triopsis engagement, observation revealed combinations of exceptions that the interface had not been designed for. The gap between designed workflow and actual workflow widened when operational pressure increased. The system's state communication was insufficient for the rapid assessments schedulers needed to make. These findings drove the 47-microtask analysis and the redesign of the exception-handling architecture.

The IDEXX Animana veterinary practice management engagement involved 35 clinics, 3 countries, and 2 weeks of workflow analysis across 4 role types: vets, nurses, reception staff, and administrative staff. When handwritten workarounds appeared across multiple clinics, including checklists taped to monitors and printed reference sheets near terminals, the research protocol was updated in real time to probe those patterns in later visits.

The IDEXX Animana engagement found that reception and clinical roles had incompatible cognitive requirements that could not be resolved within a single workflow architecture. This structural finding was not visible from stakeholder interviews and emerged from observing the same system used by different roles under different conditions.

The Gexcon CFD simulation engagement used 23 workplace observations and 24 user interviews. Domain learning preceded the workflow analysis: the team became productive CFD users before observing engineers at work, which was necessary to understand what was significant in the observed behaviour. Workflow analysis showed that Gexcon concentrated all expert activity in a single working environment, which determined the scope and structure of the subsequent microtask analysis. The engagement documented 102 individual tasks.

The Swiss petrol forecourt engagement involved 40 hours of structured observation, 532 transactions documented and coded, and 36 cashiers observed. The workflow analysis produced a design standard: 84 transactions per hour as the documented peak rate observed during the research. The engagement also documented complex mixed transactions running up to 7 minutes before redesign and catalogued cashier workaround sequences that had developed under peak load.

The WCO/IPM customs intelligence engagement analysed workflows across three operational groups: inspection officers, intelligence analysts, and rights holder teams. Workflow analysis confirmed that each group had a different operational relationship to the platform. Parallel spreadsheets and email chains across member administrations were the primary diagnostic signal that the designed workflow was being circumvented because it did not support what the work required.

The Enhesa legal compliance platform engagement used session recording analysis as the primary workflow research method. The engagement reviewed 95 session recordings, documented 31 workarounds across four categories, and documented 12 error types with time-to-redress measurement. Direct observation of Enhesa users in their operational context was not part of the research programme.

In the Enhesa engagement, the workaround catalogue included Finding legal texts with 8 workarounds, Using legal texts with 17 workarounds, Account settings with 2 workarounds, and Other with 4 workarounds. The concentration of 17 of 31 workarounds in Using legal texts was the diagnostic signal: users had developed the highest density of compensating behaviours in the platform's primary content area.

The Enhesa error documentation included 12 error types, each with measured time-to-redress where correction occurred. Known error types included clicking into the wrong legislative text, creating the wrong filter, and missing a search result that was present in the system. The engagement records that 80% of the documented workarounds were addressed in the redesign. The 6 user interviews conducted alongside the session recording analysis provided contextual depth that the recordings could not supply.

Boundaries and limits

Workflow analysis is not a substitute for all forms of user research. The practice is specifically concerned with actual operational sequences, deviations, workarounds, and handoffs. It requires evidence of behaviour and cannot rely on stakeholder interviews alone.

Session recording analysis has different evidential properties from in-situ observation. Session recordings show what users do with the interface, but they do not show the contextual conditions, time pressures, or external factors that drove those behaviours.

Session recording analysis is most appropriate when the platform generates sufficient session data and when workaround patterns are visible in interface interactions. It is less suitable when the important workaround behaviour occurs in the physical or organisational context around the interface rather than in visible interaction sequences.

Workflow analysis in multi-role systems must avoid aggregation across roles. A combined workflow map may appear complete, but it can erase the different operational requirements of each role.