---
name: workflow-consequence-check
description: Use this skill when a team proposes a change to a business workflow (removing a step, adding a shortcut, a "streamlined" screen, a new required field, a free-text option, a redesign) and wants to know whether it is actually an improvement before it ships. It runs the Workflow Frequency × Friction Matrix, the Four Consequences, the Business Workflow Unit Economics Worksheet, and the "Who Is the User?" conflict step, then states ship, change, or don't ship with the reasoning. Triggers on requests like "should we remove this step," "users say this is too many clicks," "is this change worth it," "what does this cost the customer," "who pays for this saving," "run the unit economics on this workflow," or "check the consequences of this change."
---

# Workflow Consequence Check
This skill is Labor as Code™ for the workflow-judgment method in *You
Are Not the User*. Labor as Code is a skill
that encapsulates a person's knowledge, judgment, taste, and skill in
durable, inspectable, versioned form. The know-how is the habit of
judging a workflow change across every role that touches the same unit
of work, in money and consequence, instead of by how easy one screen
looks in review.

The method spans three chapters. "Friction Matters in Proportion to How Often the Work Happens" teaches
the Workflow Frequency × Friction Matrix. "Unit Economics Is Part of
the User Experience" teaches the Four Consequences and the Business
Workflow Unit Economics Worksheet. "There Is No Single User" teaches
the "Who Is the User?" Worksheet and the four moves for deciding a
conflict. Read them for the full argument and the Caseline examples:
the consent step whose 15 seconds protect a monthly claim, and the
Quick Care Plan Note that saved a physician ten seconds and cost a care
manager six minutes. This skill applies the same checks to the user's
own proposed change. It does not retell those examples, and it never
reuses their numbers as if they were the user's.

**This skill asks for every number.** Volumes, frequencies, seconds
lost, loaded costs per minute, revenue per unit, error rates: each one
comes from the user, from their telemetry, or from a person who timed
the work. The skill never supplies a "typical" loaded cost or a
plausible volume. Where a number is missing, the cell reads "unknown,"
and the skill names what would fill it.

**This skill cannot observe users.** Observation is a human act.
Friction per occurrence usually comes from watching someone do the
work with a stopwatch, and downstream work usually comes from watching
the role after the change. The skill can say which cells need a person
to watch. It cannot fill them by reading transcripts or tickets, and it
never labels its own inference as Level 4, observed user research.

## Before running

1. **Get the change and the unit of work.** Ask for the proposed change
   in one or two sentences, and name the unit of work it touches: one
   enrollment, one invoice, one care-plan update, one claim. The whole
   check runs per unit.
2. **Get the reason for the change.** Ask what evidence prompted it and
   at what User Evidence Ladder level. A change prompted by "too many clicks"
   from two people at one site is a Level 1 anecdote. Record that. It
   does not stop the check, but it shapes the conclusion.
3. **Ask what each step being changed pays for.** Before anyone removes
   a step, follow the data it captures to whoever reads it next. If the
   user doesn't know, record "purpose unknown" and make finding out the
   first open item. The book's rule: remove the friction, not the step,
   until you know what the step pays for.
4. **Ask for the numbers up front.** List every number Steps 1–3 will
   need, and ask the user for all of them at once. Accept rough figures.
   The matrix needs the right order of magnitude, not a figure precise
   to the cent. Record the source of each number: telemetry, stopwatch,
   the customer's own report, or the user's estimate.

## Step 1: Find every party with the "Who Is the User?" Worksheet

1. List every party from the Five Names: buyer, customer,
   administrator, user, and affected party.
2. List every user role that touches the unit of work, before and after
   the changed step. Include roles downstream of the change.
3. For each party, record what they need, what they decide, how often
   they touch the workflow, what it costs them, how the team would
   observe them, and where their needs conflict with another party's.
4. Write "no evidence" for any party the user's material says nothing
   about. Do not invent a need for them.
5. Flag the affected party explicitly. In healthcare it is the patient.
   Elsewhere it is whoever bears the result without touching the
   software: the supplier paid twice, the policyholder waiting in a
   queue. They never file a ticket, so they are the easiest to miss.

Rewrite any sentence that starts "the user wants" so it names the role,
the site or sample the evidence came from, its ladder level, and which
other party the change would cost.

## Step 2: Run the Workflow Frequency × Friction Matrix

Run the matrix on the changed workflow and on any neighboring workflow
the change touches.

1. Record frequency: occurrences per user per day, and the number of
   users who perform it. Count across all users, not per user alone.
2. Record friction per occurrence: seconds lost, errors made, and what
   the user must remember.
3. Compute friction cost only where the user supplied all three inputs:

   ```
   friction cost = occurrences × seconds lost × loaded cost per second
   ```

   Show the arithmetic. State the period (per day, per month) and the
   loaded cost used, with its source.
4. Place each workflow in a quadrant:

   | Quadrant | Frequency | Friction | Treatment |
   | --- | --- | --- | --- |
   | Fix first | High | High | Engineering time pays back fastest |
   | Protect | High | Low | It works and is used constantly; the main risk is breaking it |
   | Guide | Low | High | A checklist, a good default, or help in context, not a redesign |
   | Leave alone | Low | Low | No action |

5. Say how the high/low line was drawn. The book gives no fixed
   threshold. Use the comparison among the workflows in front of you,
   or a threshold the user states, and say which.

Two findings deserve a sentence each when they appear. A change that
touches a **Protect** workflow is a risk, however clean the redesign
looks: frequent users are experts, and experts pay the most when a
familiar screen changes. And a loud, painful, rare workflow often costs
less than a quiet four-second friction that repeats all day. Judge each
step at its real frequency, never at one occurrence on a screen.

The matrix prices friction, not consequence. It is where the check
starts, not where it ends.

## Step 3: Run the Four Consequences

Write four short lines, one per role affected, with the size of the
effect. Write "unknown" where nobody has looked.

1. **User experience.** What the change does for each role that touches
   the workflow, including roles it was not designed for.
2. **Operational effect.** Work the change creates or removes elsewhere,
   and for whom. Look for time that moves rather than disappears.
3. **Unit economics.** Revenue, labor, and error cost per unit of work.
   Step 4 puts numbers on this line.
4. **Clinical consequence.** In healthcare, what the change does to the
   care the patient gets. Outside healthcare, the consequence for the
   affected party.

Mark each line better, worse, mixed, or unknown. A change that improves
one role's experience and is unknown on the other three lines has not
yet been shown to be an improvement.

## Step 4: Fill in the Business Workflow Unit Economics Worksheet

Fill in one column for today and one for the proposed change:

| Line | Today | Proposed |
| --- | --- | --- |
| Unit of work | | |
| Volume per month | | |
| Time per unit, by role | | |
| Loaded cost per minute, by role | | |
| Revenue or value captured per unit | | |
| Error rate and cost per error | | |
| Downstream work created per unit, and by whom | | |
| Net per unit | | |
| Net per month | | |

1. Use only numbers the user supplied. Write "unknown" in every other
   cell.
2. Compute net per unit only from cells that hold numbers. Show the
   arithmetic. Where an unknown cell could change the sign of the net,
   say so.
3. Price time for every role, not only the role whose screen changed.
   A saving on one screen that shows up as new work on another has not
   saved anything.
4. Where a step protects revenue (a consent record, an audit field, a
   required code), put the protected revenue per unit on the worksheet
   next to the step's time cost.
5. Mark each "unknown" and "to be confirmed" cell as an item the pilot
   or the next observation must measure.

## Step 5: Decide conflicts on evidence, not rank

For each conflict Step 1 found, apply the book's four moves in order:

1. **Make the conflict explicit.** Write both needs in one sentence,
   with both roles named.
2. **Name who decides.** The vendor decides what ships to every
   customer. The customer's administrator decides how the customer runs
   its own workflow. Nobody decides by default because they wrote the
   ticket.
3. **Decide on evidence.** Attach a ladder level to each side's claim.
   Where one side is at Level 0 or 1, name the smallest observation that
   would raise it before anyone chooses.
4. **Design for the most frequent role without breaking the
   consequential one.** Make the workflow fast for the role that does it
   most, and refuse any speedup that removes what the rare, high-stakes
   role depends on.

Rank does not appear in these moves. A senior person's view of another
role's workflow is Level 0 or 1, and gets labeled like anyone's.

If the proposal is "make it configurable," apply the book's test. Is
the variation the setting serves something the team has observed across
customers, or a disagreement between roles inside one customer? The
first can justify a setting. The second is a conflict to decide, and a
setting hands it to an administrator who will decide it without the
evidence.

## Step 6: Conclude with ship, change, or don't ship

State one of these, with the reasoning, citing specific lines from the
steps above.

- **Ship.** The net per unit is positive across every role that touches
  the unit of work, no consequence line is worse, and nothing the
  consequential role depends on is removed. Name what production should
  measure after release, including downstream work by other roles.
- **Change.** The change helps one role and costs another, or removes a
  step whose purpose is unknown or proven. Name the specific revision
  that keeps the frequent role's saving and restores what the
  consequential role needs. Typical shapes from the book: pre-fill the
  fields the software already knows instead of removing the step; add a
  short structured pick so the downstream role has nothing to re-enter.
  Say what the pilot must confirm.
- **Don't ship.** The change breaks what the consequential role depends
  on and no revision fixes that, or the net is negative on the numbers
  in hand, or the step it removes protects more than it costs. Say what
  would reverse this.

Where an unknown cell could flip the answer, say so, and make the
recommendation conditional on the smallest measurement that would fill
it: "Change, then pilot; if the error rate exceeds what the user sets as
tolerable, don't ship."

Where the tradeoff has no dominant answer (for example, the frequent
role saves real time, the affected party's risk is unknown, and the
decision belongs to the customer's administrator), present the live
options side by side. Give each option
its reasoning, who pays and who benefits, and what evidence would make
it the right call. Name who decides. Do not force a single verdict the
evidence does not support.

Where the numbers are too thin for any recommendation, say that
plainly, list the missing numbers, and name who can supply each one.

## Checks before calling the work done

- **Every number traces to the user or their data.** Delete any figure
  the skill supplied, and mark the cell "unknown."
- **Roles beyond the one the change was designed for appear** on the
  worksheet and the Four Consequences. If every role comes back
  "saved," look again at work by a different role after the changed
  step.
- **The purpose of every removed step is known,** or the conclusion says
  it is not.
- **Every conflict has a named decider.**
- **The conclusion is ship, change, don't ship, or labeled options,**
  with reasoning. A filled worksheet with no stated conclusion is an
  unfinished run.

## What this skill does not do

This skill does not invent loaded costs, volumes, error rates, or
revenue per unit, and it does not borrow the book's illustrative
figures as defaults. It does not watch the work or time it. It does
not decide a conflict that belongs to a customer's administrator; it
names that person and gives them the evidence. And it does not let the
fewest clicks stand in for the right answer. The best workflow is the
one that helps the whole human system produce the intended outcome with
acceptable effort, reliability, cost, and risk.