The Onboarding Cut

---
name: The Onboarding Cut
description: Ruthless review of an onboarding flow where every screen must justify its existence or be cut or deferred.
when_to_use: A PM or designer wants to shorten onboarding and needs a structured argument for every screen's removal.
---

# The Onboarding Cut

## What this skill does
Walks an onboarding flow through a five-step review where the default verdict is "delete" and each screen has to earn its place. Produces a before/after flow, a deferral plan for moved asks, and a short written case for each cut.

## When to load this skill
Load when the user says: "our onboarding is too long", "help me cut onboarding screens", "review our first-run flow", "new-user drop-off is bad", or pastes a flow and asks "which of these can we remove".

## The procedure

### Step 1 — Map the current flow
Ask the user to list every screen in the onboarding in order. For each screen, record: the title, what it asks the user, what fields or interactions are on it, and what happens if the user skips or abandons. If there's analytics data on drop-off by screen, request it — it changes the prioritization. If not, proceed with the structural review and flag "data needed" where analytics would help decide a close call.

### Step 2 — Ask the one question for every screen
For each screen, ask exactly one question: **what would break if this screen were gone?** The answer has three acceptable shapes:
- "The product would literally fail to function" — the screen is load-bearing.
- "We would lose information we need later" — the screen is deferred, not load-bearing.
- "Nothing would break; we'd just know less about the user" — the screen is deletable.

Unacceptable answers: "users need to understand the product" (no, they don't — they need to use it and find out), "the team likes this data" (not the user's problem), "marketing wants this segmentation" (defer to the moment of value, not the moment of signup), "we've always had it" (the weakest possible justification).

### Step 3 — Bucket every screen into load-bearing, deferred, or delete
Run every screen through Step 2 and assign it to a bucket. Be ruthless in the load-bearing bucket — most "required" fields are not actually required for the product to function. An email is load-bearing (account identity). A password is load-bearing (auth). A name is usually deferrable. A "how did you hear about us" survey is almost never load-bearing. A product tour is never load-bearing — users who want one can open it later.

If a screen has multiple asks, bucket each ask separately, then decide whether the screen as a whole should be merged with an adjacent step.

### Step 4 — Redesign around only the load-bearing set
Throw out every non-load-bearing screen and sketch the flow with only what's left. Usually the result is two or three screens, not seven. If the remaining flow feels too thin, resist the urge to pad it — thin is correct. The flow is now "get the user to first value as fast as possible". First value is the moment the product does the thing they signed up for. Everything between signup and first value should feel like the flow is getting out of their way.

### Step 5 — Write the deferral plan
For every deferred ask (not deleted — deferred), name the moment in the lifecycle where it now appears. "Profile photo" moves to the first time the user encounters their own profile. "Notification permission" moves to the first time a notification would actually be useful. "Teammate invites" moves to the first time the user sees a collaboration feature. Each deferred ask needs an answer to: **when does it appear, why then, what does the user get by answering, and what if they skip it again?**

### Step 6 — Write the before/after and the case
Output three things:
1. **Before/after flow** — screen count and list, side by side.
2. **Cut list** — every removed screen with its one-sentence case ("delete: product tour. Users can open it from the help menu, and most never do.").
3. **Deferral plan** — every moved ask with its new home.

Close with a note on what to measure after shipping: completion rate, time-to-first-value, and signup-to-activation rate. Hand off to [Cognitive Load Pass](/agents/skill-cognitive-load-pass) for the remaining screens, or [The Content Design Coach](/agents/soul-the-content-design-coach) for microcopy on the survivors.

## A worked example

**User:** Our note-taking app onboarding has seven screens. Drop-off is 52% between signup and first note written.

**Claude:** List the seven screens with what's asked on each.

**User:**
1. Email + password
2. "What's your name?" + profile photo upload
3. "How will you use us?" — checkbox list (personal, work, school, other)
4. Product tour, 4 slides
5. "Pick a template" (blank, journal, meeting notes, project)
6. Notification permission
7. Empty editor, ready to write

**Claude:** Running the one question on each.

**Screen 1 — email + password.** What would break if gone? Account identity and auth. **Load-bearing.**

**Screen 2 — name + photo.** What would break? Nothing in the product. The name is nice for greeting the user, but can be pulled from the email or asked later. The photo is pure polish. **Name: deferred. Photo: delete (defer to profile page).**

**Screen 3 — usage survey.** What would break? Nothing for the user. The team gets segmentation data. **Delete.** If the team really wants this, ask once, after two weeks of use, in a small banner. Users who've stuck around will answer honestly; users on day one will click through to get past the screen.

**Screen 4 — product tour.** What would break? Nothing. A product tour teaches you how to use something you haven't needed yet. **Delete.** Move the tour to a "How to use this app" help link in the sidebar of the empty editor. Users who want it can open it; most won't.

**Screen 5 — template picker.** What would break? The user lands on an empty editor with no starting structure. For a first-time user, this might be value — a journal prompt is easier than a blank page. But: the same picker can live inside the empty editor as a "choose a template" chip above the blank note. **Deferred / merged.** Move the picker into screen 7 as an inline option above the cursor.

**Screen 6 — notification permission.** What would break? Nothing at the point of signup. The user has no reason to want notifications yet. Asking now is the worst possible time — users reflexively deny, and the browser remembers. **Deferred.** Move to the first moment a notification would be relevant: after the user's second visit, or when they set up a reminder.

**Screen 7 — empty editor.** What would break? This is where the user writes their first note. **Load-bearing.** This is first value.

**Before:** 7 screens, 5 decisions before first value.
**After:** 2 screens. Screen 1: email + password. Screen 2: empty editor with an inline "choose a template" chip.

**Cut list:**
- Delete: profile photo upload. Defer to profile page.
- Delete: usage survey. Re-ask at 2 weeks if the team insists.
- Delete: product tour slides. Move to help link.

**Deferral plan:**
| Asked for | New home | Why then | If they skip |
|---|---|---|---|
| Name | First time user sees their profile or account menu | They're looking at the space where it appears | Email username is the fallback |
| Photo | Profile page | Same | Initials avatar |
| Usage segmentation | Banner after 2 weeks of use | User has enough context to answer honestly | No data, fine |
| Notification permission | First time user sets a reminder | User is asking for the notification, the product is just confirming | They set no reminders, feature unused |
| Template picker | Inline chip above the blank note | User is at the moment of writing | Blank note, still writable |

**Expected effect:** the screen count drops from 7 to 2. Time-to-first-note should drop dramatically; drop-off should concentrate at screen 1 (where it's unavoidable — users who don't create accounts aren't going to) instead of being spread across five screens where any one of them loses 10–15%.

**What to measure post-launch:**
- Signup-to-first-note rate (should rise).
- Day-1 retention (might not move much; retention is mostly product-driven, not onboarding-driven).
- Survey response rate on the delayed ask (should be higher because respondents self-select as engaged).

**User:** Marketing will push back on deleting the segmentation question.

**Claude:** The structural argument is: a survey answered by every user at signup is 50% noise because half of those users will never return. A survey answered at 2 weeks by surviving users is 100% signal. Marketing gets better data by waiting. If they still push back, offer to run the change as a two-week experiment and compare segmentation data from the two cohorts. The signal-density argument usually wins because it's one marketing argues in their own language.

## What this skill will NOT do
- Will NOT accept "users need to understand the product" as a reason to keep a screen.
- Will NOT cut screens that are genuinely load-bearing (auth, legal consent, age gates where legally required). Those get flagged and kept.
- Will NOT delete asks — it defers or deletes, and says which. A deleted ask is an explicit "we don't need this", not a silent disappearance.
- Will NOT produce cuts the user can't defend to a stakeholder. Every cut comes with a one-sentence case.
- Will NOT promise a specific conversion lift. It predicts direction, not magnitude.