---
name: point-of-action-friction-audit
description: Audits the real-world moment a product is used and finds every context switch, delay, and memory tax that causes users to abandon the habit. Produces a friction-scored map of the current flow plus a redesigned flow where the work happens inside the moment of action. Use when retention drops sharply after onboarding, when users report loving the product but not using it, when designing a logging, tracking, capture, or reporting flow, or before committing to a new feature that adds a step.
---

# Point of Action Friction Audit

## What this does

Most abandonment is not a motivation problem. It is a physics problem. The
product asks the user to do something at a moment when their hands, attention,
or environment make it expensive. The user complies for six days and quits on
the seventh.

This audit finds those moments and removes them.

## Inputs to ask for

Ask the user for these before starting. If any are missing, ask once, then
proceed with assumptions clearly labeled as assumptions.

1. The core habit your product depends on, stated as a physical action ("log a
   meal," "record a call note," "photograph a job site").
2. The real-world setting where it happens: where the user is, what their hands
   are doing, who else is present, how much time they have.
3. The current step-by-step flow, including every tap, screen, and decision.
4. Any retention or usage data you have, even rough. Day 7 and day 30 numbers
   are enough.

## Step 1: Write the moment, not the funnel

Describe the 60 seconds around the core habit in plain physical language. No
product nouns. No feature names. What is the user holding? What is hot, wet,
loud, or urgent? What are they in the middle of?

Bad: "User opens app and logs entry."
Good: "User has raw chicken on both hands, a pan heating, and a phone on the
counter two feet away that they do not want to touch."

## Step 2: Enumerate every switch

List every single one of these that appears in the current flow:

- Device switches (put down a tool, pick up a phone)
- Attention switches (leave the task to look at a screen)
- Memory taxes (do it now, log it later)
- Decisions (choose a category, pick from a list, name a thing)
- Waits (loading, syncing, searching)
- Cleanliness or safety blockers (dirty hands, gloves, driving, sterile field)

One line each. Be exhaustive and unkind.

## Step 3: Score each switch

Give every item a friction score from 1 to 5 using this rubric:

- 1: costs a second, no state change
- 2: costs attention but not position
- 3: requires putting something down or picking something up
- 4: requires leaving the moment, or defers the action to memory
- 5: physically impossible or unsafe in the moment, so it will be skipped

Total the score. Anything scoring 4 or 5 is a candidate for elimination, not
optimization. You cannot polish your way out of a 5.

## Step 4: Apply the four eliminations

For every item scoring 3 or higher, try these in order and report which applies:

1. **Move the sensor to the moment.** Can the measurement happen where the
   action already is, instead of on a device the user must reach for?
2. **Collapse the decision.** Can the system infer what the user would have
   selected, and let them correct it later rather than choose it now?
3. **Shrink the input to one gesture.** Can the entire interaction become a
   single press, tap, or voice line with no screen?
4. **Defer the cleanup, never the capture.** Can capture be instant and messy,
   with organizing, naming, and categorizing pushed to a calmer moment?

If none of the four apply, say so plainly and mark the step as a structural
constraint rather than inventing a fix.

## Step 5: Output

Produce exactly these sections:

**Current flow**
Numbered steps, each with its friction score and a one-line reason.

**Total friction score and the kill list**
The total, plus the items scoring 4 or 5 ranked by how often they occur per
week of normal use.

**Redesigned flow**
Numbered steps for the new version. For each step, name which of the four
eliminations you applied.

**The one-week test**
A single measurable experiment that would prove or disprove the redesign.
Specify what to build, how long to run it, the metric to watch, and the number
that would count as a win. Keep the build under one week of work.

**What you gave up**
Honest list of capability, accuracy, or control lost by removing steps, and why
that trade is or is not worth it.

## Rules

- Never recommend adding a step in this audit. If a step must be added, flag it
  as a finding for a different exercise.
- Do not accept "users just need to build the habit" as an explanation. Find the
  physical cost.
- Accuracy that requires a step users will skip is worth less than a rough
  number they will actually capture. Say this out loud when the trade appears.
- If the user's data contradicts the audit's conclusion, follow the data and say
  where the audit was wrong.
- Never invent usage numbers. If data is missing, label the section as
  hypothesis.