A customer who uses an app every few months may not remember how they originally signed in. A worker on a busy site may have little patience for a keyboard-heavy login. The right sign-in experience reflects those circumstances. Begin by deciding which tasks actually require an account, then make the transition into an account clear at the moment it becomes necessary.
Let public tasks stay public
A local activity centre can show session descriptions and opening hours before requiring identity for a booking. This lets customers understand the service before committing to an account. When sign-in becomes necessary, preserve their selected session and explain why access is needed. Avoid returning them to a generic home screen after authentication. Consider whether staff and customers need different entry points or simply different permissions after sign-in. An account system should reflect who is acting and what they can do, rather than forcing everyone through the same confusing introduction.
Use supported identity experiences
Android's Credential Manager supports a unified interface for sign-in methods including passkeys and passwords. Suitability depends on the product and supported platforms, so ask the team to demonstrate the chosen journey on actual devices. The customer-facing requirement is straightforward: people should recognise their account, understand the method and recover when the expected credential is unavailable. Avoid inventing a novel password interface merely to match branding. Make fields compatible with ordinary assistance such as password managers and appropriate keyboards, and keep failure messages useful without exposing another person's account details.
Test the less convenient arrival
Try signing in after changing phones, losing access to an old email and forgetting which method was used. Define the support process before release, especially if the app shows sensitive customer records. Staff should not bypass account checks based solely on a convincing phone conversation. Also test session expiry during a booking: the customer should understand the need to sign in again and retain appropriate unfinished work. Evaluate successful return to the original task as the outcome, not just a successful authentication event that leaves someone stranded elsewhere in the app.
- Which parts of the service genuinely require a recognised account?
- Does sign-in return the customer to the task they were completing?
- Can an occasional user recognise and recover their original sign-in method?
- What evidence and process help support staff resolve access problems safely?