Context
Ledger asked new businesses for nine screens of information before showing them a single useful thing. Sixty-one percent never finished. The internal assumption was that the form was too long, which was true but not useful — every field had a stakeholder who could explain why it was essential.
Approach
Separate what is needed to start from what is needed eventually
I mapped each field against the first moment it was actually read by the system. Only four of the twenty-three were required before a user could send their first payment. The rest were compliance and enrichment data needed within thirty days, not within thirty seconds.
That reframing changed the argument. Nobody had to give up their field. They had to move it later.
Design for resumption, not completion
The remaining three steps assume interruption. Progress persists per keystroke, the flow is linkable at any step, and returning users land exactly where they stopped, with a plain sentence telling them what is left.
Make errors survivable
Validation moved from submit-time to blur-time, error copy names the fix rather than the violation, and no error state ever clears a field the user typed.
Outcome
Signup completion rose thirty-four percent over the following quarter. Setup support tickets fell by half, which mattered more to the business than the completion number — it was the first time the support cost of onboarding went down while signups went up.
What I would do differently
I would instrument the deferred fields from day one. We moved nineteen fields later without measuring how many were ever completed afterwards, so I still cannot answer the obvious follow-up question: how many of them did we need at all?