Workflow Consequence Check

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.

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:

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.