Picture a team rewriting the third screen of a customer sign-up for the third time. The heading is clearer. The button is bigger. People still leave before they get to the thing they came to do.
In this composite, the argument around the screen goes something like this. “We should make it shorter.” “We should explain it better.” “Could AI walk them through it?”
You’re the leader deciding which fix gets another week of the team’s attention. Before you choose, there is a question missing from the conversation.
How many of the people who need to finish this step are failing to finish it? And what would make that number unacceptable?
If nobody has answered, you can keep approving better screens without knowing whether you’re fixing the right thing.
The screen is where the argument landed
UX is shorthand for user experience: what it feels like to get something done through your website or tool. The wording matters. The buttons matter. A confusing screen can absolutely stop somebody.
But “make the experience better” does not tell your team where to spend its next week.
In our imagined flow, the customer creates an account, answers a few questions, and supplies the information needed to get started. Step three is where they leave. That makes step three worth looking at. It does not tell us why they left, whether they came back, or whether they needed to continue at all.
The visible screen gives everyone something to change. The business decision asks you to say what you’re willing to accept. That is harder to put in a design review.
Here’s the thing. Every onboarding flow is a tolerance call disguised as a UX project. Before the redesign, somebody has to name the amount and kind of unfinished work that would make this flow fail its purpose.
Otherwise, “better” can keep moving every time someone looks at the page.
Write the condition that makes you stop
Our Quality Control framework calls a missing hard boundary The Open Door Problem. In an AI-assisted job, that can mean the system was never told which action it must not take or which question it must return to a person.
There is a related management problem in onboarding: the flow keeps running, people keep leaving, and no condition requires its owner to investigate.
The useful rule is specific. “If the people this step is meant to serve cannot complete it at the level we’ve agreed, I will review the failures before calling the flow acceptable.”
That rule belongs to the person responsible for the flow. A target on a chart is just a target until someone acts on it.
And a completion target is not permission to remove a necessary check. If you need particular information to do the job properly, getting more people past the screen by skipping it has not improved the whole job. It has moved the missing work to somebody else.
Right. You can make a form easier to finish and make the next person’s work harder at the same time.
The boundary has to protect the purpose, not just the percentage.
Count the people who are trying to get somewhere
Go back to the third screen. What does completing it actually mean?
Maybe the useful result is a new customer supplying enough information for the team to take the next step. That is different from creating an account. It is different from clicking a button. It is also different from opening the page to have a look.
Those distinctions decide who belongs in your count.
Start with the same group of people arriving at a step during a stated period. Count how many finish, allowing enough time for the way that step actually works. Keep the number of people beside the percentage. A rate built from a handful of visits cannot carry the same confidence as a pattern repeated through ordinary use.
If the screen asks for something a person has to find, leaving today and returning tomorrow may be part of completing the task. If they can finish with help over the phone, that route needs to stay visible too. Otherwise your website can look as though it lost a customer whom your team successfully helped.
The reverse can happen. A completed form can look like success while the team still lacks what it needs to act.
“They clicked through” is not the same answer as “they got started.”
When you cannot tell which happened, write that down. Don’t ask AI to turn a missing count into a confident explanation. Your first improvement may be finding out whether people finish, rather than changing how the screen looks.
A threshold tells you where to look
The acceptable rate comes from what this flow needs to accomplish. It is a business judgment you can revisit, not a magic number borrowed from somebody else’s website.
If nearly everyone reaching a step already needs your service, losing them there deserves close attention. If people are still deciding whether the service fits, some will choose to leave. Treating both groups as the same problem can send the team toward the wrong fix.
Say it plainly: “We need these people to get this far, within this amount of time, without needing this much help.” Then decide what level of failure would warrant attention and why.
The reason matters. Without it, you can look at an uncomfortable result and quietly move the target until the chart looks fine.
Here’s the thing. Crossing the threshold tells you to investigate. It does not tell you to redesign.
In the composite, perhaps people reach the upload step without the requested material. The useful change could be telling them what to have ready before they start. Perhaps the instruction is confusing. Then clearer wording may help. Perhaps the upload fails. That is a broken step to repair.
An AI guide answering questions would address a different problem from a button that does not work. Until you know what is happening, they are possible solutions looking for a diagnosis.
Same screen. Different work order.
Do not let the average hide a person
A flow can meet its overall target while still leaving some people with no usable way through.
If someone cannot complete a necessary step, help them. You do not need to wait for a large enough pile of failures to make a chart persuasive. And you do not need a measurement project before fixing an obviously broken button.
Acceptable friction is a way to choose improvement work. It is not a reason to shrug at a customer who needs another route.
That also means self-service is not automatically the winning design. A short conversation may be the right route for a difficult case. The question is whether the person gets to the useful next step and whether your team can carry the work around it.
The Professional Recipe calls the measurement-and-revision discipline Feedback. For this flow, that means seeing what the work is doing, choosing a change for a reason, and looking again after the change. The new screen is a proposal until ordinary use tells you whether it helped.
I would be careful about the phrase “we fixed onboarding.” More precisely, you changed a step. Now you need to see what that change did.
The Monday Move
Pick one existing onboarding or inquiry flow. Work with the person who knows what happens when someone leaves it.
Write the useful finish in one sentence. Then walk the steps leading to it. For each step, record arrivals, completions, the period covered, and what you cannot yet see. Use the same group and allow time for people to return. No guessed figures.
Next, write the amount of drop-off you would accept at each step and the reason. Name the person who will investigate if the flow misses that line. If the evidence is too thin, the next action is to close that gap.
Choose one step that deserves investigation. Read the unfinished cases or ask someone who struggled there what happened. Decide on a change only after you have a reason to believe it addresses the problem. Keep the people who need a different route in view.
Leave the steps that meet their purpose alone for this pass. A screen does not need another week of attention just because someone can imagine a nicer version.
The related article The Team Didn’t Need Perfect asks what a tool must do to be useful. This is the next question inside an existing journey: where are people failing to reach that usefulness?
Before the next redesign, name the drop-off you can accept. Then give the team a problem they can actually investigate.
Original framework. Distilled from client work.
