The onboarding flow for a consumer fintech app has a drop-off problem. Analytics show that a large share of new users do not complete step 3 of a five-step sign-up. The product manager briefs the designer: Reduce drop-off at step 3. We have three weeks.
Both designers, the T-shaped and the π-shaped, receive the same brief. Both are senior, with enough breadth to read a flow, talk to engineering, and understand why onboarding matters commercially. The difference begins before either opens a design tool.
The T-shaped designer takes the brief as handed. Step 3 is the problem. The design of step 3 is the solution. They audit the current screens, run a heuristic review, look at comparable onboarding patterns. Step 3 has real friction: too many fields, an ambiguous progress indicator, a form layout that breaks on smaller screens, all fixable. Within a week they have three redesign concepts, cleaner layout, reduced fields, better copy. The work is good. The team builds it. Three weeks later, drop-off at step 3 has barely moved.
The π-shaped designer pauses before opening the design tool. A prior question demands answering first: why does drop-off happen at step 3 specifically? They pull the analytics more carefully, looking past the drop-off rate to the drop-off timing. Users are abandoning after spending longer than average on the screen, with no immediate bounce. Something is making them wait and then leave. They talk to engineering. Step 3 triggers an email verification from a legacy auth system, and the email takes forty to ninety seconds to arrive. Users are leaving because they are waiting, and nothing in the flow tells them to wait. The drop-off looks like UX — it is a backend constraint.
7.6 — The Same Brief where T and π diverge in practice · H3