Designing For MedTech: Theory of Success (and why you need one)

Background

• Key Moments identify where commitments are made.

• Value Settlements clarify how conflicting interests are resolved at those moments.

• TOCUS makes those settlements explicit and testable by linking commitments to mechanisms, evidence, and decisions.

Introduction

Most design teams can describe what they’re building. Fewer can say, in plain and concrete terms, what specific outcomes it is supposed to produce. Fewer still can name the instruments they will use to measure the factors that reliably generate those outcomes.

This happens because design teams are typically rewarded for shipping artefacts rather than proving effects. As feedback from clinical, operational, or business outcomes fades, so does the pressure to specify outcomes and causal pathways. This is especially in MedTech, where causality is distributed across time, roles, workflows, and incentives.

Describing a solution (“we are building X”) is easier than specifying a falsifiable theory linking that solution to real-world change (“X leads to Y through mechanisms A, B, and C”). Take a familiar example from retail:

A customer walks into an electronics store looking for a laptop. The store can log observable facts: someone entered, they spoke with a salesperson, and they expressed interest in purchasing. None of these measurements determine the outcome. What happens next depends on factors the store cannot see without a theory: whether the customer trusts the recommendation, whether the salesperson understands the use-case, how hesitation is handled, and what happens by default if nobody acts.

Turning intent into commitments that work for both sides requires a usable theory of success: an account of which decisions and actions resolve conflicting goals (e.g., the customer wants maximum value for money; the store wants profitable sales) and under what conditions those actions generate satisfaction and repeat business. For sophisticated retail operations, this will seem uncontroversial, even obvious. In the more complex (and higher-stakes) environment of healthcare, this kind of thinking is much less common.

What a Theory of Success is (and what it isn’t)

A Theory of Success is a plain-language, falsifiable hypothesis about how an intervention will produce better outcomes in the real world. It is not a vision statement, but a causal account you can test, revise, and govern.

TOCUS (Theory of Customer/User Success) is the form of a Theory of Success I use with my team in MedTech, where users, customers, and risk holders are often different actors.

In this form, a TOCUS consists of three commitments:

1. It names a pathway: how information will move through people, workflows, decisions, incentives, and constraints to produce better outcomes.

2. It names mechanisms: the factors that actually move behaviour, especially at the moments when decisions become commitments.

3. It names evidence: how we will measure outcomes and verify the mechanisms, using a standard set of instruments and governance artefacts.

If our TOCUS doesn’t do all three, it becomes either a story (no evidence) or a measurement plan (no causal logic).

TOCUS and Key Moments

Key Moments are the small, observable points in a workflow where new information becomes salient and a commitment is made (or avoided) that locks in downstream consequences.

Key Moments are not always the biggest or most dramatic events. Often they’re mundane: a threshold is crossed; an alert is acknowledged; a result is documented; a call is or isn’t made; a medication order is adjusted; a handoff occurs.

But Key Moments alone don’t tell you what “better” means, or how you’ll know you got it. They tell you where leverage exists. TOCUS tells you what leverage you intend to apply, and why. In practice, TOCUS and Key Moments work as a pair.

Commitments Rather Than Measurements

A common failure mode in digital health is to treat measurement as if it is the bottleneck. The implied chain goes: more data (lead to) better decisions (lead to) better outcomes.

In clinical settings, that chain often breaks at decisions, which occur under time pressure, partial information, competing priorities, and ambiguous ownership. The failure isn’t the result of data obscurity. Systems fail when responsibility, authority, or default action at the next commitment point is undefined.

A Theory of Success forces you to write the missing middle. It turns “data” into “commitment” by making you specify:

• Who is expected to notice the new information?

• When will it be noticed relative to the workflow?

• What action or decision is expected, by whom, and under what authority?

• What makes that action the default rather than the exception?

• What happens when the system is wrong, or uncertain, or ignored?

This is where safety and adoption live: in the mundane governance of commitments.

Value Conflicts Are The Work, Not The Exception

Healthcare design rarely fails because people are irrational or malicious. It fails because multiple parties are rational in different directions.

Nurses may value reducing interruptions and keeping a stable rhythm of care. Physicians may value avoiding missed deterioration and maintaining clinical autonomy. Administrators may value throughput and standardisation. Patients value dignity, clarity, and not being surprised by complications.

These are not misunderstandings, but legitimate value conflicts.

In my earlier writing I’ve argued that “when everyone is right,” the work is not to force alignment by rhetoric, but to make the conflict explicit and choose a settlement (a practical agreement about who bears what burden, who gains what benefit, and who holds decision rights).

A TOCUS must explicitly address these settlements, or it will quietly assume them. Quiet assumptions are where products become unsafe, unusable, or quietly bypassed.

So, in a TOCUS, we make value settlements explicit:

• What new burden are we asking of each role?

• What benefit are we promising in exchange?

• What risk is introduced, and who carries it?

• Who can override whom at a Key Moment, and what is the escalation path?

TOCUS Bridges Design Intent and Controls

TOCUS connects what you claim to what you control and what you measure.

If you’re pursuing a 510(k) pathway, or example, this matters a lot. You need to demonstrate safety and effectiveness in a way that is legible to regulators, clinicians, and your own team. A TOCUS can act as a plain-language front end to your design controls:

• Identifying the critical tasks (the actions that matter for safety and intended use).

• Tying hazards and using errors to the Key Moments where they occur.

• Specifying the controls (design, workflow, training, governance) that prevent harm.

• Specifying the evidence plan (formative studies, summative evidence where relevant, and ongoing surveillance signals).

This is one reason we favour simplicity in the TOCUS itself: it should be readable by a cross-functional team, and it should point cleanly to the deeper artefacts (risk analysis, traceability, study plans, decision logs) rather than duplicating them.

How I Use TOCUS With Key Moments

Here is the minimal loop I use with my team:

1. Map the pathway.Write a single “data → decision → action” pathway for the use case, including handoffs and backstage processes. Keep it concrete.

2. Identify Key Moments. Find the points where new information becomes available and a commitment is made. Describe each Key Moment in a consistent structure: trigger, actors, options, artefacts, constraints, incentives, defaults, feedback, consequences.

3. Write settlement statements. For the Key Moments that matter most, write one or two plain settlement statements: who is responsible for what, what the default is, and how exceptions are handled. Be explicit about decision rights and escalation.

4. Instrument and gate. Choose a small set of trusted instruments and governance artefacts you’ll use across use cases (critical error rates on critical tasks, alert burden and response, workflow-fit friction logs, trust calibration signals, adverse event and near-miss capture). Define evidence gates tied to Key Moments: what you need to see to proceed, what would trigger revision, and what would halt or constrain use.

That’s it. The point is not to create a perfect theory. The point is to create a theory that can be tested and revised without ambiguity.

Why This Matters

Your TOCUS is not just a document. It’s a discipline that ensures product teams are accountable for causal claims, and integrates safety and usability. It defines “success” operationally without ignoring value conflicts, linking design intent to real-world outcomes. The next piece will illustrate this with a use case, showing how the mechanism and settlement patterns apply across roles and clinical contexts.