Outcome Metrics Coach

Why it exists

I wrote an outcome-driven UX metrics framework for my team: use metrics count actions, outcome metrics verify the action left the customer better off, and only the second kind gets to judge a piece of design. The framework worked when I sat in the room. It slipped when I did not. Statements drifted back to feelings, thresholds appeared without a derivation, and metrics got copied from the last project.

So I turned the framework into a skill: a coach that any designer can open in Claude, that knows the rules better than a tired human on a Thursday, and that will not let a stage pass until its gate is met.

How it behaves

It is Socratic and it is strict. It works one stage at a time and asks one to three short questions, never a wall of them. It never silently fills a gap: if you cannot answer, it offers exactly two options, record a labelled assumption with an owner and a confirm-by date, or park the stage and write down the data ask. It challenges drafts rather than accepting them, naming what fails and why in one line, and it keeps a running canvas of everything agreed so far.

It watches for the five faults that appear in almost every first draft and names them the moment they show up.

1. Feeling words in the statement. "Feels confident" is not observable; "proceeds without opening support" is.
2. A clock used as a success metric. Time to first action measures speed, not benefit.
3. Metrics transplanted from a previous project.
4. Numbers or denominators inside the statement, where they do not belong.
5. An edge case that just restates the feature's job.

The stages

Tier check

Two questions decide how much rigour the work deserves: would leadership review this by name, and could it make the customer's job worse if we got it wrong. Flagship bets get the full treatment. Small fixes and polish ship under standing guardrails, and the coach stops there so nothing slows down small work.

Business outcome intake

A metric, a number and a date, or it is refused. Then the denominator in writing, the organisational priority it moves, the evidence for the causal chain, the baseline and whether it is stable, the dependencies other teams own, and the kill criteria.

Evidence check

No invented customers. The person in the statement has to come from field immersion, calls or tickets, with dates.

Build the statement

Labels first, prose last. If we do a great job on this, we will improve a named person's life by an observable change, bounded in time and context, even when a hard situation occurs, so that specific miseries stop.

Derive the metrics

Every metric comes from a clause of the statement. Success metrics are the finish line. Progress metrics track the climb, as trajectory, milestones and firsts. Problem-value metrics price what it costs to leave the problem unsolved, every month.

Thresholds

Derivation, not vibes. Floor is today's baseline, ceiling is the irreducible failure rate no design can prevent, clock is whether the climb fits the time and the levers you own.

Loophole audit and pre-registration

A final pass for every way the numbers could be gamed or quietly moved, then a pre-registration page: outcome, evidence, statement, job type, success metrics with their derivation, guardrails, progress reporting, and problem value, co-signed by product before any build starts.

What changed

Outcome statements stopped depending on whether I was in the meeting. The quality of a first draft rose, because the coach catches the common faults before a reviewer has to. And pre-registration became the normal way a project starts rather than a thing the design lead had to insist on. The method is written up in Design is judged by what moved, not what shipped.

Get the skill

The skill is open source under the MIT licence at github.com/akashsoti/claude-skills. It is plain Markdown: a SKILL.md with the instructions and a references folder it reads as it works. Copy the outcome-metrics-coach folder into your skills directory and it is ready to use in Claude Code or a Claude project.