Rebuilding onboarding around the first useful moment

Checking the brief before accepting it

Ledgerly's brief is to redesign the onboarding checklist. The most useful thing this project does is spend a week deciding not to.

The funnel in the scenario tells a specific story. Checklist completion is around two thirds, which is respectable. But users who complete the checklist convert at almost the same rate as users who abandon it. That single comparison is the whole diagnosis: if finishing a sequence does not predict the outcome, then improving how many people finish it cannot help. The checklist is doing its job faithfully. Its job is the problem.

This is worth dwelling on because the alternative project — better copy, a progress ring, a celebratory animation on completion — is a real project that teams ship every quarter, and it produces a measurable improvement in a metric that does not connect to anything.

Finding the moment

The redesign needs a target, and the target is the first moment the product becomes comprehensible.

For Ledgerly that is a completed reconciliation: a real match, on data the user recognises, that they did not have to make by hand. Not the signup, which is just admission. Not the bank connection, which is cost. Not the checklist, which is a description of cost.

Reaching that moment takes nine steps and around 47 minutes, and eight of the nine steps are administration. Once the target is named, the design work is mostly subtraction with one question asked repeatedly: does this have to happen before the first reconciliation? Teammate invites do not. The chart of accounts does not. The accounting integration does not. Six of the nine move.

They do not disappear — that is the part worth being precise about. They are asked later, in the product, at the point each one is first needed. An invite prompt when a match needs a second opinion is a different request from the same prompt on screen two, even though the form is identical.

Sample data is a real risk

The decision most likely to backfire is demonstrating on sample data.

The logic is sound: the highest-anxiety action in the product is handing over bank credentials, and the current flow asks for it before showing anything. Move the demonstration first and the user decides with evidence.

But users in this scenario explicitly say they do not want a tour, and a sample ledger is one bad execution away from being a tour. If the sample data is too clean, it demonstrates a product that does not exist — every transaction matching neatly, no ambiguity, no partial matches. The user's real ledger will not look like that, and the gap between the demo and the first real batch is where trust is lost rather than built.

So the sample is deliberately messy. It includes a partial match, one transaction the product cannot classify, and a duplicate. It demonstrates the product handling difficulty, which is the only demonstration worth making.

What we gave up

A clean activation metric. Deleting the checklist removes the number the team reports weekly, and nothing replaces it as a single figure. Time to first reconciliation is the honest measure and it is harder to instrument, noisier, and much less satisfying on a slide.

A sense of completion. Some users like a checklist, and progressive setup means there is no moment where a badge says setup is done. The account is permanently, honestly, partially configured. We think that is more truthful than a completed list that hides the same gaps, but it does feel worse.

Determinism. An inferred account map that is subtly wrong is more dangerous than an empty form, because it can be accepted without being read. Marking every inferred row helps the careful user and the second person picking the account up. It does nothing for the person who clicks straight through, and that person exists.