I Built the Onboarding Flow. Eight Users Told Me the Order Was Wrong.

I built an onboarding flow that asked new users to add items right away. It seemed obvious: you open the app, you put things in it. Eight user interviews across two rounds of research later, I had to admit the order was wrong. Every single person did the opposite. (New to UX interviews? Here’s how I structure them.)

The research that broke my assumptions

I ran two rounds of user interviews, each filed with full transcripts and a standardized synthesis matrix in Obsidian. The structure was deliberate: every interview mapped to the same themes, every observation sat in a table where patterns could surface side by side instead of buried in separate documents.

Nine themes emerged across the first four interviews. One pattern stood out immediately: every single user skipped adding items and went straight to building their folder structure. They wanted the scaffolding before the contents. The flow I designed (add items first, organize later) was backwards¹.

I would not have seen it scanning notes one at a time. I saw it because nine themes sat side by side in one table. The synthesis matrix did the heavy lifting; I just had to read across the row.

From insight to prototype

The research turned into a working prototype. I built five web screens in Astro, React 19, and Tailwind, then seven mobile screens in Expo with a real state store and clean TypeScript. Real code, not clickable wireframes. Because the question was not whether the layout made sense, but whether the flow actually worked when someone held a phone and tried to build their folder structure from scratch.

When round two confirmed users wanted a conversational, structure-first flow, I rebuilt the entire mobile chat experience. Three mock personas, 50 industry-matched items each across five subcategories, and a real CSV import path that parses your columns and auto-detects which one holds the item name. The prototype stayed one step behind the research instead of one project phase behind.

What I learned about research velocity

The synthesis matrix is what made the turnaround possible. Eight transcripts, one table, nine themes, one afternoon. When the pattern was obvious enough to reshape the entire onboarding flow, I did not need to schedule a stakeholder meeting to defend it. I pointed at the row.

That speed changes what research can do. Research that takes three weeks lands after the sprint is locked. Research that takes three days lands in time to change the sprint. The difference is not the quality of the questions. It is the structure of the synthesis.

The takeaway

The onboarding flow I designed made logical sense. It was wrong anyway. The only way to catch it was to watch real people use it, structure the observations so the pattern could not hide, and move fast enough to rebuild before the next round. The order of operations matters. Build the scaffolding before you ask people to fill it.

Curious how I used Claude Code to build those prototypes? Read why I code instead of faking them →

Footnotes

1. Sample size of 8 participants across two rounds. Not statistically generalizable, but directionally strong. 100% of round-one participants exhibited the same behavior. ↩