Surfer — Standard Plan Onboarding
No onboarding existed before this. Users landed in the product with no setup guidance.
No completion rates, no drop-off points, no time-on-step. All targets are forward-looking hypotheses.
Design for a user who just paid. They expect the product to be smart. The onboarding has to feel worthy of that expectation.
Alternatives considered
What was chosen
A sequential, step-by-step flow where each screen has one job.
Why
The steps are not independent — brand setup must come first because Pages and Prompts both depend on it. A single page would hide that dependency and leave users unsure of what to fill in first. The step order communicates that the setup has a logic: understand the brand, then configure what to track based on it.
Risk
More screens means more navigation. If any single step causes drop-off, the user loses all progress on the steps that follow.
Alternatives considered
What was chosen
AI pre-selects the top 50 pages silently. User reviews but doesn't need to. One click to continue.
Why
At the start of onboarding, users don't yet know which pages matter. The AI has more signal than they do. Asking them to pick from 100 articles would stall the flow and erode confidence before the product has delivered any value. Low trust is earned through results, not through making users do work.
Risk
Bad AI pre-selection is invisible. If the quality is poor, the user won't know until they see wrong data downstream — at which point they blame the product, not the onboarding.
Alternatives considered
What was chosen
GSC connection is the primary recommended path. Manual URL entry is secondary, visually de-emphasized.
Why
GSC data directly improves AI pre-selection accuracy in Steps 2 and 3. A user who connects GSC gives the system real search data — which pages get traffic, which topics are covered, which competitors appear. Manual URL gives much less. The hierarchy in the UI is a product quality decision, not just a UX convenience.
Risk
GSC requires a Google account with sufficient permissions. Users without access or without an established site are pushed toward a worse experience from the first screen.
Alternatives considered
What was chosen
Pages and Prompts combined in one step, side-by-side. Both AI pre-selected. One confirm button to continue — effective for the Fast Pass approach.
Why
Both depend on brand setup being complete but neither depends on the other. Keeping them separate could build a false impression that Pages must be confirmed before Prompts can be configured — a dependency that doesn't exist. Combining them removes that ambiguity, reduces the step count, and keeps the Fast Pass fast.
Risk
The combined view is more information-dense. Users who want to review everything carefully may feel rushed. The Manage panel (See all →) exists as the escape hatch, but it requires an extra click.
Run usability tests with existing Surfer users
Current users already understand what the platform does and what value it delivers. They can quickly spot if something is misleading, if a label doesn't match their mental model, or if a default wouldn't work for their real use case. This is a different signal than unrelated users — less about comprehension, more about fit with existing expectations.
Run usability tests with unrelated users
Recruit a small number of people who have no prior context on Surfer or this project. The goal is to test whether the flow makes sense to a complete stranger — not someone who already understands the product concept. Watch where they hesitate, what they ignore, and whether they trust the AI pre-selection without questioning it.
Focus testing on the page and prompt selection step
This is the highest-uncertainty part of the flow. Observe whether users accept the AI defaults, open the Manage panel, or feel stuck. If most users just confirm without reviewing — is that confidence or confusion? That distinction matters for whether the Fast Pass approach is actually working.
Ship and collect baseline data
Once usability issues are addressed, ship the flow to real users and start measuring. The hypotheses in the Metrics page are only useful once there is real data to compare against. Everything before that is still a guess.
Once baseline data is in from real users, these are the most promising directions. See the Metrics page for the full measurement framework behind these.