First impressions happen in milliseconds. Research consistently shows users form a judgment about a product within the first few seconds of use — and that judgment is almost never reversed.
Yet most SaaS products spend months, sometimes years, refining features that users never reach. The onboarding flow — the first true conversation between product and user — is treated as a technical problem: modals, tooltips, progress bars. Not a design problem.
The result is a product that works perfectly for the people who built it, and feels foreign to everyone else.
The gap between capability and clarity
A product can have exceptional functionality and still feel broken. What users experience is not the feature set — it's the interface. The gap between what a product can do and what a user understands it can do is the single most underestimated problem in SaaS design.
We've reviewed dozens of products over the years. The pattern is almost universal: the engineering is solid, the product logic makes sense internally, but nothing has been designed for the person encountering it for the first time. Every decision optimised for the builder, none for the visitor.
The best products feel inevitable. Each step feels like the only natural next action — not because users are guided, but because the design decided the path in advance.
What good onboarding design actually does
It doesn't explain. It shows. It doesn't use tooltips to describe buttons — it places users in situations where buttons make themselves obvious. The goal is not to teach the product. The goal is to make the product feel already understood.
This requires making hard decisions early. Which single action do we want the user to take in the first session? Not three actions — one. Everything else is a distraction until that one thing happens.
Hierarchy over completeness
Most onboarding fails because it tries to communicate everything at once. A dashboard with twelve equal-weight widgets tells the user nothing. A dashboard with one clear focal point and eleven supporting elements tells a story. The information may be identical — the hierarchy makes the difference.
The cost of getting this wrong
Activation rates. Churn in the first thirty days. Support tickets asking the same three questions. These are design problems dressed as product problems. They appear in the metrics long after the design decision that caused them — which is why they're so hard to diagnose without someone looking specifically at the interface.
The fix is rarely a new feature. It's almost always a decision about what to show first, what to remove, and what to say less of. Less, but better — applied to the most critical moment in the user's relationship with the product.
That's where we start. Not with the roadmap, but with what the user sees on day one.