Systems Innovation LabPeople · Systems · Design
How we work

Understand the work. Agree what needs to change.

We start with your problem and the decision you need to make. Together we agree the scope, outputs, timing and what a useful result would look like. That may be a focused review, a re-design or help putting a change into practice. You do not need to buy a three-stage programme.

Human-centred design

Designed with the people who do the work.

Every change is developed with your people and tested in their conditions before it is handed over. Not every engagement needs all three stages; what is useful is agreed first.

  1. DiagnoseSee what is actually happening: records, observation and conversations with the people involved.
  2. Co-designRe-design it with your people: options developed with those who do and manage the work.
  3. EmbedMake it the way the work runs: tested in realistic conditions, then handed over with ownership agreed.
The three stages

What each stage involves.

What happens at each stage, and what you receive at the end of it.

When the cause needs investigation
See what is actually happening
Diagnose

We review relevant records, observe the work and speak with the people involved. We compare the intended process with what happens in practice, including the conditions that make a task difficult.

You receive a clear account of the problem, supporting evidence, priorities and recommended next steps. The level of detail depends on the agreed scope. A diagnostic can end here.

When a change needs designing
Re-design it with your people
Co-design

We develop options with the people who do and manage the work. Changes may address the task, instructions, information, tools, responsibilities or handovers. Required safeguards remain part of the design.

You receive the agreed design outputs, such as a revised workflow, a usable procedure or clearer decision criteria. We make ownership and the proposed checks explicit before implementation.

When a change needs implementing
Make it the way the work runs
Embed

We help test the change in realistic conditions and resolve what does not work. Where software is involved, your implementer builds it; we help define and check the operational requirements.

You receive test findings, agreed handover information and clear responsibilities for follow-up. The completion criteria, remaining limitations and measures to watch are made explicit.

Principles

Four commitments.

What we hold to in every engagement, whatever its size.

Ask before assuming.

We examine what people knew, the demands they faced and the options available. We do not assume either individual fault or a system explanation before looking at the evidence.

Learn from everyday work.

We study routine work as well as incidents. A workaround can reveal a design difficulty; it still needs to be checked against the risks and requirements involved.

Keep safeguards useful.

We clarify which checks are needed, who can act and what evidence they need. Simplification must preserve applicable requirements and effective protections.

Design with, not for.

We involve the people who use and manage the process, then test proposed changes with them. Practical use and feedback inform the final design.

Prefer an illustration? Explore two models of how work is shaped: the gap between what an organisation plans and what the floor can do, and how pressures move a system toward its limits over time.

Explore the research and methods
Research and methods

Every figure on this site has a source.

These sources inform our work. The method is selected for the question and the available evidence; you do not need to study it before getting in touch.

Rasmussen, 1997
Safety Science 27
Migration toward the boundary. Under pressure for efficiency and toward least effort, work drifts to the boundary of functionally acceptable performance. The recommendation is to make that boundary visible. Fig. 02 in the illustrated models.
Hollnagel, 2014
Safety-I and Safety-II
Work as imagined and work as done. The gap between them is inevitable; the everyday adjustments people make are why things go right as well as wrong. Fig. 01 and "learn from everyday work".
Dekker, 2014
The Field Guide to Understanding ‘Human Error’
Local rationality. Examining actions in the context of what people knew, their goals and the pressures they faced. A starting point for inquiry, not a finding made in advance.
Leveson, 2011
Engineering a Safer World
Safety as a control problem. Losses come from inadequately enforced constraints; STAMP analyses the control structure. It is why our gates have an owner, evidence and a rule in the system the work runs in. The four-part test is how to check one.
Rasmussen & Svedung, 2000
AcciMap
Systemic accident analysis. Contributing factors mapped across the levels of the socio-technical system, from government to the work itself, our incident-investigation method.
ISO 9241-210:2019
Human-centred design. Understand the context of use, involve users throughout, iterate, evaluate with them, "design with, not for".
Existing requirements stay in view.

Where the work affects a certified management system, changes are planned around the relevant requirements and audit arrangements. The aim is to improve practical use while maintaining continuity. Certification decisions remain with your certification body.

Tell us what needs to work better.

Tell us what is happening →