Research Brief — UX Onboarding
An analysis of Obsidian's first-launch experience and the broader pattern of onboarding failure in complex productivity applications.
New users don't know what they want from a tool until they've had a chance to figure it out. Onboarding that front-loads configuration assumes the opposite — and loses users at the exact moment they most need to succeed.
The other end of that failure is less obvious but just as corrosive. A user who has heard enough about a tool to try it arrives with a sense of its potential. They know, or think they know, that this is a product worth learning. When the first-launch experience gives them no clear line of sight to that result — no path from here to the thing they came for — the gap between what the tool could be and what it is right now becomes demoralizing. They don't just give up. They walk away with the feeling that their time has been wasted. That's a harder thing to recover from than a bad first impression.
We don't know what we want until we know what we don't want — and know what we can have. Then we have to figure out how much work it takes to get there and whether that investment is worth the return.
Obsidian is a powerful, genuinely useful note-taking and knowledge management tool. It's also a near-perfect case study in what happens when a product is built by and for people who already know what they want — and the onboarding is designed accordingly.
The observations below are drawn from a first-time install and launch of Obsidian on a Windows machine by a user with moderate technical literacy and no prior exposure to the product.
Barry Schwartz's foundational work on the paradox of choice has long established that beyond a certain threshold, more options produce paralysis — and that the cognitive cost of choosing from a large number of options is experienced as a chore. Obsidian's onboarding is a textbook illustration: presented with vast configurability and no guidance on where to start, users won't start at all.
The cognitive load literature is equally relevant. Onboarding that demands a user hold new concepts in working memory at the same time — what is a vault, where should it live, what does the graph view do, how do folders work here — exceeds the capacity of a user who's trying to form a basic impression of whether the tool is worth their time. The burden arrives before the benefit, leaving the user with not only the feeling of wasted time, but a sense of failure or incompleteness.
There's also a more structural explanation. Obsidian was built by power users for power users. The decisions that shape its onboarding reflect the priorities and assumptions of people who already knew what they wanted when they built it. The blank slate that feels like endless customizability to an experienced user feels like neglect to a new one. The jargon that appears precise to an insider is experienced as a needless impediment to the new user. The onboarding doesn't fail because no one cared. It fails because the people who built it didn't need it.
Obsidian isn't a case on its own. The same failure mode appears across productivity applications: the product places the result before the process. It relies on the user's awareness of what the tool could be — its reputation, its power-user testimonials, its feature list — rather than doing the work of getting the user there. There's no time for the learning curve. The assumption is that the tool's potential is self-evident enough to carry the user through the early friction. Whether it is or isn't is beyond the point: it's not the user's job to find out.
The pattern has a specific shape: a tool that is powerful, eventually, presents itself as if "eventually" isn't part of the chronological investment. The minutes between first launch and first value is treated as the user's problem to solve, not the product's responsibility to close.
The minimum a new user needs is not a feature list. It's a clear line of sight from here to the thing they came for.
What's missing in every example is not capability — these are capable tools. What's missing is an honest treatment of the learning curve and a structure that makes that curve navigable. A great product, eventually, is still a hope. Onboarding is where the product either fulfills that hope or defers it indefinitely.
Good onboarding doesn't present options, it demonstrates examples. It creates conditions for the user to discover their own preferences. The distinction matters: demonstrating options requires the user to already have preferences; creating conditions allows preferences to emerge from experience.
In practice this means: one clear first action, not a configuration screen. Terminology introduced at the moment it becomes relevant, not before, with consistent reminders throughout. Features revealed progressively, in proportion to the user's growing familiarity with the tool. And an explicit acknowledgment that the tool will take time — not as a disclaimer, but as a reassurance that the time is worth spending.
The user you have on day one isn't the user you'll have on day thirty. Onboarding should be designed for the former, not the latter. Every decision that makes the tool powerful for an experienced user should be evaluated separately for what it costs a new user.
The following recommendations are addressed to Obsidian's product and content teams.
Welcome the user you have. Not the one you wish had showed up.