← Glossary
Operational truth
Operational truth is the difference between what a service claims to do and what operations can actually deliver—at scale, under constraints, with exceptions. Designing with operational truth means you design the real system, not the brochure.
Definition
- Operational truth is the ground reality of delivery: dependencies, failure modes, throughput limits, handoffs, SLAs, and the messy middle between teams and vendors.
- It’s expressed in states and transitions, not aspirations: what happens when a payment fails, a document is missing, a user changes their mind, a partner API is down.
- Operational truth becomes visible through blueprints, logs, support tickets, and frontline routines.
Why it matters
- Most design debt is operational debt in disguise: exceptions that were never modelled end up as support work, escalations, and manual fixes.
- Ecosystems make truth non‑optional. If you don’t own the whole stack, your experience quality is capped by the weakest dependency.
- Operational truth is how you ship faster: fewer surprises, fewer late reversals, fewer “we didn’t know this was impossible”.
Common failure modes
- Happy‑path bias: the journey map looks elegant, the live service breaks on day two.
- No ownership map: nobody knows who owns a broken handoff, so issues bounce between teams.
- Invisible constraints: operations improvises workarounds that never become product requirements.
- Exception leakage: edge cases are pushed into customer service, where they become expensive and slow.
- Metrics are purely funnel‑based: conversion improves while support debt explodes.
How I design it
- Model the service as states + operators, not screens. Define what the system can guarantee and where humans intervene.
- Blueprint exceptions first: list the top failure modes and design recovery paths before polishing the UI.
- Make handoffs explicit: owner, input, output, SLA, escalation path.
- Design operator UX: internal tooling, dashboards, and audit trails that make the system governable.
- Close the loop: treat support tickets and ops workarounds as a product backlog with prioritised fixes.
Related work
Proof map claims
Case studies
See also
Contact
Let’s discuss a leadership role, advisory work, or a complex product challenge.