A one-phone-one-user onboarding model can exclude a whole household when several people share the same device or SIM. Before launch, the team needed to redesign identity, consent and return access around the way people actually used the phone.
At 4:47 on Friday afternoon, Adwoa, the product lead, was holding the final test sheet beside a packed launch checklist in Accra. One line stopped her: “New account created. Previous session replaced.” She had entered a second person’s details on the same Android phone, exactly as two sisters in one household might. The first account had disappeared.
Adwoa is an illustrative composite, but the decision is familiar. The launch was scheduled for Monday. If the team shipped, one person registering could lock another out, inherit their unfinished application or expose information left behind on the device. If they postponed, they would miss the date promised to partners and spend runway on a problem nobody had included in the original scope.
The room went quiet. Monday was still possible, but the onboarding flow was no longer safe to release.
The assumption hidden inside the login screen
The team had designed a tidy sequence: enter a phone number, receive a code, create a profile, stay signed in. Every screen worked. The mistake sat underneath them.
They had treated possession of a phone as proof of one stable user.
That assumption can survive every internal demo because founders, designers and engineers usually test on personal devices. Each tester has their own number, inbox and saved session. The flow feels obvious because the test environment quietly matches the design.
Adwoa asked the team to stop reviewing screens and describe access instead. Who owns the handset? Who knows the passcode? Can another person receive the verification message? What happens when the original person returns after someone else signs in?
The answers changed the product boundary. A shared phone was not an edge case to place in a backlog. It affected identity, privacy and whether a person could complete onboarding at all.
This is the same kind of warning explored in Ama’s identity question: a small test can reveal that the product has assigned certainty where the real situation remains ambiguous.
Rebuild around access, not ownership
Adwoa made one call before anyone opened the codebase: the phone number could help a person return, but it could not stand in for the person.
That distinction gave the team a workable plan. They separated account identity from the device session. They removed personal details from the first screen shown after reopening the app. They added a clear way to switch accounts and required fresh verification before showing sensitive information or resuming an unfinished step.
They also rewrote the onboarding copy. “Your phone number” became language that acknowledged the number might be reachable through a shared device. The sign-out action moved into view instead of sitting behind a settings menu that a hurried person might never find.
None of this required predicting every household arrangement. The team needed to support three realities:
- A device may serve more than one person.
- Access to a number may change during onboarding.
- A returning person may arrive after somebody else has used the same phone.
By Friday evening, the team had reduced Monday’s release rather than pretending the full flow remained ready. They kept the parts that could identify the active person safely and held back the shortcut that restored an old session without checking who had returned.
That trade protected the launch from a worse outcome: discovering after release that convenience for one person had created exposure for another.
Test the handoff, not only the happy path
Most onboarding tests begin with a clean device and end when one account reaches the home screen. Shared access becomes visible only after the apparent success.
The useful test begins there. Hand the phone to a second person. Let them start registration. Then return it to the first person and observe what appears before either person proves who they are.
This handoff test catches problems that screen-by-screen reviews miss. Saved names can appear in form fields. Notifications can reveal activity. A resumed application can place one person inside another person’s decision. Even a friendly greeting can disclose that somebody else has an account.
The test should also include interruption. Close the app halfway through onboarding. Change the active account. Reopen it. Ask what the next person can see, change or submit.
Teams with limited runway may resist this because each access pattern appears to add scope. The better constraint is narrower: protect identity boundaries first, then reduce the number of flows released. Postponing one convenience feature costs less than repairing trust after private information crosses between household members.
The decision resembles Chidi postponing a launch after one customer appeared three times. In both cases, duplicated activity was evidence that the model of the person, account and device needed another pass.
Monday’s smaller launch
On Monday morning, Adwoa watched the same phone move through the revised test. The second account no longer erased the first. Reopening the app revealed no name, balance or unfinished application until the returning person verified access.
The release contained fewer shortcuts than the team had planned. It also matched a fact their first design had ignored: access patterns are part of product architecture.
Before approving your next onboarding flow, borrow a colleague’s phone. Create one account, pass the device across the table, create another, and pass it back. The screen that appears before verification will tell you whether you designed for a person or merely for a phone.
Comments
No comments yet.