24

Growth eng here. Our old signup was a single screen with nine fields and a 38% completion rate. I wanted AI to help me design a progressive flow, but the naive prompt just gave me the same nine fields split arbitrarily across three screens, which is worse.

The insight was to prompt it around a job-to-be-done sequence with a strict rule: each step asks for exactly one thing and only what's required to unlock the next moment of value. I also make it defer everything not needed for first value to a later 'complete your profile' nudge.

It now proposes a flow with a real activation moment instead of a data-collection gauntlet. Sharing the prompt and the React scaffold instruction. How do you decide what counts as the true minimum for step one?

THE PROMPT
Design a progressive onboarding flow, then scaffold it in React (function components + a single useReducer for flow state, no router library). Product: {PRODUCT}. The 'aha' / first-value moment we want the user to reach: {ACTIVATION_MOMENT}.

PRINCIPLES:
- Work backward from the activation moment. A field/step is only allowed if it is REQUIRED to reach that moment. Everything else is deferred to a post-activation 'finish your profile' nudge.
- One decision per screen. No screen may ask for more than one primary input (a short group of tightly-related fields counts as one).
- Show progress honestly (Step X of N) and allow Back without data loss.
- Prefer smart defaults and detected values over asking; ask only when you truly can't infer.
DELIVERABLES:
1. The step list as a table: step, the single thing asked, why it's required for activation, what it unlocks.
2. A list of fields you DEFERRED and why.
3. React scaffold: a <OnboardingFlow/> with typed step config array, useReducer for {step, data}, per-step validation, and an inline progress indicator. Steps render from the config so adding/removing a step is a one-line change.
4. Empty/skeleton and error states for any async step.
No marketing copy filler; write the real microcopy for each step of the described product.
5"work backward from the activation moment" reframes onboarding from data collection to value delivery. that one line changed how i scope every flow now.greenfield_gus 2 months ago
add a comment

2 Answers

11

The config-array-driven steps pattern is what makes this maintainable. I extended it so each step declares requiredForActivation: boolean, and a tiny assertion in dev throws if the flow has more than 3 activation-required steps. It's a forcing function against scope creep when a PM inevitably wants to add "just one more field".

THE PROMPT
Add to each step config: requiredForActivation: boolean. In development, assert the count of requiredForActivation steps is <= 3 and warn loudly otherwise.
10

One caveat from shipping this: get the model to type the step data as a discriminated union keyed by step id, not one big optional-everything object. Otherwise the reducer becomes a soup of data.email? and you lose the compiler's help exactly where validation matters most.

THE PROMPT
Type flow state as a discriminated union: each step contributes its own required slice, so completed-step data is non-optional and future-step data is absent from the type until reached.

Your Answer