Onboarding Findings Report
Cumulative pool: ClickUp, Notion, PostHog, Attio, Linear, HubSpot, Webflow, Zendesk
This run came with a harder brief than usual: the walkthrough itself is genuinely close to clean. Nielsen's heuristics were applied more deliberately than in prior runs specifically because there was no obvious blocker to anchor to — no rejected signup, no stalled checkout, no mismatched wizard label sitting in plain view. The instruction was to evaluate every screen the way a first-time user actually would, not the way a researcher who already knows what he's looking for would, and to find the exact point — singular — where a well-built onboarding flow still cracks. One finding is reported below, not several, because padding a near-clean flow with manufactured secondary findings would be the same dishonesty as ignoring a real one. A minor copy inconsistency (the 2FA fallback text assumes an existing administrator, which cannot be true for a brand-new trial's first user) was noted and set aside — real, but too small to be the target.
Rated in a previous run; not re-analyzed this cycle.
Rated in a previous run; not re-analyzed this cycle.
Full analysis in report run 2.
Full analysis in report run 2. Case-study finalist.
Full analysis in report run 2. Case-study finalist.
Full analysis in report run 3.
Full analysis in report run 4. Case-study finalist — targeted fix in report run 5.
Zendesk
~16 min 32 sec · ~30+ distinct product states · signup via Google OAuth · Suite trial, admin-side walkthrough
Most of this flow works. The demo ticket queue behind the email-verification modal is realistic and immediately shows product value. Two-step verification is clear and well-copied. The AI-agent setup wizard is a genuinely good sequence — brainpower, personality, then a live test panel before the agent goes anywhere real. None of that is the finding. The finding is one click, from the admin center's own product-switcher menu, that a curious first-time user has every reason to make.
Z1 — The admin nav lists a retired, un-signup-able product as a normal peer of every live one, with no way back once you land on it
This was reached during open exploration of the admin center, not while completing a required setup step — the kind of clicking any new user does to see what's in the product they just paid nothing for. The click itself was unhesitant: nothing in the flyout signals that “Sales” behaves differently from the other ten items in the same list.
Nielsen's heuristics, applied directly
- Visibility of system status — mild violation. Nothing in the flyout, or in the moment of clicking, indicates that this destination is categorically different from the others. The system gives no status signal before the jump.
- User control and freedom — the clearest violation. Every other item in that flyout keeps the user inside the live admin shell. This one strips it entirely and supplies no back button, no breadcrumb, no “return to admin center” — only outbound links to a help article and a support form. The one built-in escape is the small, unlabeled logo mark in the top-left corner, which nothing on the page identifies as clickable or as a way home.
- Consistency and standards — mild violation. Ten items in the list follow one behavior (stay in-shell); one silently doesn't. Consistency is broken exactly where a user has no way to predict it.
Ruling out
Copy ruled out as the primary cause — the retirement notice itself is clear, accurate, and dated. The problem isn't what it says; it's that nothing before it warned this destination would say anything like it at all.
Hierarchy is the primary cause — the flyout presents a sunset product as a peer-level entry alongside ten live ones, with identical visual weight and zero differentiation.
Placement ruled out — the item sits exactly where a user would expect to find it in an alphabetically-organized product list.
Load time ruled out — the notice renders immediately; this isn't a performance issue.
Motivation ruled out — this was low-stakes exploratory clicking, not a user pushing through friction to reach something they needed. The crack doesn't require a motivated user to find; a mildly curious one is enough.
Outside signal
Not sought for this finding, deliberately. The retirement date and cutoff are stated as fact directly on Zendesk's own screen — this is a case where the product's own copy is the primary source, and searching for external corroboration of a company's own announced sunset timeline would have added a step without adding rigor.
This is a real crack, not a manufactured one — and it is a small one, exactly as the walkthrough itself suggested it would be. It sits on an optional exploration path, not the critical path to finishing setup, and a user who never opens that flyout never encounters it. But it is a genuine, reproducible dead end reachable in one unremarkable click from the main admin surface, with no way back except an unlabeled logo click or the browser's own back button — and the session's own ending, stopped on that exact screen, is itself evidence of how easy it is to get stuck there.
The target: it's not the checkout, the wizard, or the pricing page — it's one item in a product-switcher flyout menu. “Sales” sits between “Analytics” and “Workforce management” looking exactly as safe to click as either of them, and it isn't. Everything upstream of that click is genuinely well-made. That's what makes this the actual target and not a footnote: in a flow this polished, one inconsistent menu item is the whole gap.
The fix: don't remove the item and don't rewrite the retirement notice — both treat the symptom. Two changes, scoped to the exact place this breaks: (1) mark the flyout entry itself — a muted label, a small “retiring” tag, anything that tells the user before the click that this one behaves differently, and (2) never let a navigation click strip the admin shell entirely. Keep the sidebar and top bar present and let the retirement notice render in the content area beneath them, the same as every other destination in that list. That alone converts a dead end into a page you can casually leave, which is all this ever needed to not be a crack.
— written by the person operating Howard this session, not by Howard
Cross-cutting observations, this cycle
- This is the first run where the brief itself asked for a harder standard of scrutiny on a flow with no obvious blocker, and the finding that surfaced is qualitatively different from every prior one in the pool — not a broken step in a required flow, but a trap on an optional one. Worth tracking as its own category going forward: required-path friction vs. exploration-path friction.
- Pool has reached 8 tools, the top of the stated 6–8 range. Any further additions should come with an explicit decision on whether the pool grows past 8 or whether new tools now replace an existing carried-forward entry.
- Per this run's brief, this finding goes directly to the findthetarget.com case-studies section rather than waiting on a separate case-study synthesis decision, as Webflow's did.
Pool is now 8 tools (ClickUp, Notion, PostHog, Attio, Linear, HubSpot, Webflow, Zendesk).