Field notes
Reading drop-off without blaming the button
A high exit rate on one screen rarely means the control is wrong. Here is how we separate design friction from missing context and unfinished work.
When a step in a business application loses a large share of sessions, the first reaction is often to redesign the button, shorten the form, or rewrite the label. Sometimes that helps. Often it papers over a different problem: the customer arrived without the information the step assumes they already have.
In audits across order-management and booking-style applications, we look at three signals before we talk about interface changes. First, time on step versus time since the previous successful action. Second, whether the same accounts return later and complete the step after talking to support. Third, whether exits cluster around roles that lack permission or around accounts missing required reference data.
If returning users finish the step after a phone call, the interface may be fine and the upstream data incomplete. If first-time users leave in under ten seconds and never retry, the screen may be asking for decisions the customer cannot make yet. Those two cases need different responses from product and operations.
A useful habit is to annotate each major drop-off with a short hypothesis and a check you can run in the next week. Avoid treating the exit percentage as a single verdict. Pair it with who left, what they did next, and whether the application ever gave them a path back.