example output
what you receive.
this is a real synthesis output. the brief was B2B onboarding research — 6 product manager interviews. the same structure applies to every submission.
brief
usability research on a B2B onboarding flow. 6 participants — mid-level product managers at companies of 50–200 people. research data: interview transcripts (lightly edited), 45–60 min each, covering first-run experience, week-one usage, and unmet expectations.
executive summary
onboarding fails not at the technical level but at the expectation level. participants arrived expecting to configure a tool; the product expected them to explore one. this mismatch — between a "get to work" mental model and a "discover the value" onboarding philosophy — explains most of the friction. six of six participants described some version of "i didn't know what i was supposed to do first." the word "supposed" is doing work here: they're looking for a prescribed path, not an exploration space. the product doesn't give them one.
the week-one retention risk is specific: participants who didn't connect the tool to a real workflow within the first session stopped logging in. those who did — even imperfectly — came back.
key themes
1. the empty state is the crisis point
every participant encountered an empty dashboard after setup. none found it inviting. five described it as either "blank" (literal) or "intimidating" (emotional).
"i set it up and then stared at it. it didn't tell me what to do next."
this is not a copy problem or a design problem in isolation — it's a product problem. the tool has no concept of a "starter workflow." everything requires the user to invent their own structure before they can experience the value.
2. templates are discovered too late
four participants found the template library after struggling for 10–20 minutes. two found it through search, not navigation. one never found it. when shown the template library in the session, the universal response was some version of "why didn't it show me this at the start?"
templates are the product's best argument for itself. they're buried.
3. collaboration is assumed, not scaffolded
the product's value proposition is explicitly collaborative. but onboarding is entirely single-player. not one participant was prompted to invite a colleague during setup. when asked, four said they would have — but forgot to come back to it.
"i set it up thinking i'd add my team later. later never happened."
the collaboration hook needs to be in the critical path, not post-setup.
4. notifications are the wrong retention mechanism
all six participants mentioned notifications. three had turned them off by week one. the complaints were consistent: too frequent, too vague ("someone made a change"), not actionable. notifications are being used as a retention layer for a product that hasn't yet established its value. that ordering is backwards.
5. power users telegraph the fix
two retained participants described the same behaviour: they imported an existing project from another tool in the first session. this gave them a real artifact to work with, which made the product's features legible. the import flow is not prominent. it's not suggested during onboarding. it works, and it's being ignored.
tensions
the product is designed for exploration; users want direction. the current onboarding resolves the tension wrong — it offers nothing when users need something.
the product's value compounds with team use. but onboarding is optimised for individual setup speed. if you don't capture the team invite during setup, you probably don't get it at all.
heavy early notifications signal that the product isn't confident in its own stickiness. the participants who turned off notifications did so in the first week — a permanent loss of a retention channel, triggered by overuse of it.
design implications
- make the import prominent. surface "import from notion / jira / asana" as the first option in the empty state, above "start from scratch." this gives users a real artifact immediately.
- add a prescriptive onboarding path, toggleable. import or template → invite one person → set one reminder. three steps. users who want to explore can dismiss it; users who need structure will follow it.
- templates in the empty state, not the library. three curated templates by role or use case — not a catalogue of fifty.
- move the team invite into setup. not optional. allow skipping, but put the friction on skipping, not on doing it.
- replace vague notifications with milestone notifications. "your first project has 3 open tasks" is signal. "someone made a change" is noise. tie notifications to workflow milestones.
gaps & uncertainties
this research captured first-run and week-one experience only. it doesn't tell us whether template adoption in week one predicts week-four retention, how the experience differs for technical vs. non-technical users, or what the import flow actually feels like at scale — none of the six attempted it unprompted.
recommend: a follow-up session with 3–4 retained users on the import path, and an analytics pull on template adoption timing.