Nimo onboarding makeover

Show value before asking for commitment.

The current local flow works, but it turns into setup too quickly: sign in, enter websites, connect alerts, choose schedule, then wait. The makeover should teach the product model while creating an immediate first win before the paywall.

What the reference teaches

The supplied inspiration page is effective because it explains one model in plain language, gives compact choices, and ties every ask to value the user just received.

Ask after valueThe ask happens when the user understands what they gained.
Offer a choiceBuying, inviting, sharing, and referring are framed as options, not one forced path.
Track the right stepSlack connection is treated as a high-intent milestone, not a secondary setting.
Remember the workContext persists so the next session starts warm instead of cold.
Reference page with growth loop notes and cards.

Reference screenshot

The useful pattern is not the visual style alone. It is the rhythm: thesis, model, choices, then concrete next actions.

Current flow health

Captured locally on August 16, 2026. Auth and onboarding API calls used a local mock server with canned responses so the UI could advance; no real Slack, Telegram, billing, audit, or production account was used.

Current nimo landing page with URL audit field.
Step 1Healthy

Landing page: clear URL entry and product promise

The first screen does promise a site-speed check and includes a URL field. The page also has educational sections lower down, but a signup user may not carry that learning into auth.

Current nimo sign-in screen.
Step 2Functional but thin

Sign in: clean, but context-free

The screen is calm and usable. It does not preserve the motivation from the landing page: no promise of what happens next, no preview of the first payoff, and no reminder that this takes seconds.

Magic link confirmation screen.
Step 3Missed education moment

Magic link sent: status only

This confirms the action, but the waiting state could explain what nimo will prepare: field data, Lighthouse diagnostics, first fix, and how the audit will be verified.

Website entry step in onboarding.
Step 4Low perceived reward

Websites: asks for data before showing why

The email-domain prefill is useful. The screen should translate “add up to 3” into value: “we’ll benchmark the pages that cost you signups,” “homepage plus pricing/signup,” or “paste one URL and we’ll suggest the rest.”

Chat and alerts step with Telegram and Slack connection buttons.
Step 5High-friction ask

Chat and alerts: integration value is undersold

Telegram and Slack are presented as plumbing. The reference suggests making Slack a value signal: “send the first finding where your team can act on it,” with skip preserved for users who just want the report.

Schedule step with weekly audit selector.
Step 6Clear but premature

Schedule: simple control, weak payoff

Weekly is a sane default, but scheduling before the first result feels administrative. This should come after a small success state: queued audit, likely page type detected, or first quick insight.

Makeover direction

Keep the app’s restrained visual system, but change the sequence from “configure nimo” to “understand your first performance opportunity.”

1. Pre-paywall dopamine hit: let the user run or resume one lightweight public audit and reveal a tangible finding before plan selection.
2. Education in-line: explain field data vs lab data, first safe fix, and verification in the same places where the user makes choices.
3. Tool connection as payoff: frame Slack/Telegram as “send the first actionable finding to the right place,” not “connect alerts.”
4. Progressive commitment: ask for schedule and paid plan after the user has seen what nimo found and wants monitoring or team delivery.
5. Remember context: carry the entered URL, detected stack, selected channel, and unfinished audit across signup so auth feels like a continuation.

Recommended new flow

Before authURL entered. Show “checking what matters,” then a partial result: detected page, metric status, likely first bottleneck, and what nimo can verify after a fix.
After authResume with the same URL and explain: “I saved this audit. Connect Slack to send the first finding, or continue to see the report here.”
Before paywallReveal one concrete insight or queue state: “Hero image is likely the LCP candidate” or “field data unavailable, lab audit started.”
Paywall momentUpgrade unlocks monitoring, repeat checks, team alerts, and more sites. The user already understands the job because they saw the first win.

The product should ask second.

Use the signup path to prove the core loop: find the slowdown, explain it, send it where work happens, and verify the next audit. Then the paywall is attached to more value, not access to understanding.

Accessibility risks to verify

Focus order: verify keyboard movement through OAuth buttons, email field, website rows, trash buttons, selects, and skip/continue actions.
Disabled choices: the alert-channel buttons become disabled until a tool is connected; add visible explanation for why they are unavailable.
Contrast: low-contrast helper text and disabled controls should be tested against WCAG contrast targets, especially on the grid background.
Status changes: loading, magic-link sent, connected, audit queued, and redirect states need screen-reader announcements beyond visual spinners and toast messages.