UX Patterns Guide
Back to compare picker

Sign in vs Account creation vs Password input vs Session timeout warning vs Email address entry

Use sign in for returning access to an existing account, account creation for establishing a new persistent account, password input for the secret-entry control inside a flow, and session timeout warning for an authenticated session that is expiring or requires reauthentication.

Sign in live exampleAccount creation live examplePassword input live exampleSession timeout warning live exampleEmail address entry live example
Learn the decision

Match the interaction to the person's task

Use sign in for returning access to an existing account, account creation for establishing a new persistent account, password input for the secret-entry control inside a flow, and session timeout warning for an authenticated session that is expiring or requires reauthentication.

Sign in

Use it when: Users need to access an existing account or protected destination.

Make this state clear: Initial sign-in state with service or destination context.

Observe the result: A user opens a private document link, signs in with a saved passkey, and lands back on the same document with focus near the access confirmation.

Study the full pattern →

Account creation

Use it when: Users need to save and resume drafts, regularly update their data, manage records, check ongoing status, collaborate, or protect repeated access.

Make this state clear: Need-for-account state explaining why an account is required or beneficial at this point.

Observe the result: A user completes most of a one-hour permit application, chooses to save progress, creates an account using the email already entered, verifies the email, and returns to the same draft.

Study the full pattern →

Password input

Use it when: The user needs to enter an existing password, passphrase, or PIN-like memorized secret.

Make this state clear: Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.

Observe the result: The person reaches a clear outcome.

Study the full pattern →

Session timeout warning

Use it when: An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.

Make this state clear: Early idle warning with remaining time and current save state.

Observe the result: A user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.

Study the full pattern →

Email address entry

Use it when: The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification.

Make this state clear: Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.

Observe the result: A user pastes alex+receipts@example.co.uk, sees it preserved exactly, reviews it on the check page, and changes it only if needed.

Study the full pattern →

Practice the judgment: Imagine this situation: Users successfully authenticate but lose the protected page, checkout, draft, invite, or document they came from. Write the person's goal, choose one of these patterns, and show the state that helps the person continue. Use the decision rules and source trail below to explain your choice.

Review the underlying principle →

Decision dimensions

Dimension Sign inAccount creationPassword inputSession timeout warningEmail address entry
UI or UX UI + UX - Returning-account authentication and session start flowUI + UX - Persistent account establishment flowUI + UX - Authentication secret entry controlUI + UX - Authenticated-session expiry and reauthentication boundary warningUI + UX - Contactable email address capture field
UI guidance Render sign in as a focused authentication surface with a clear service or destination name, account identifier field, current-password or passkey path, password-manager-friendly attributes, recovery routes, create-account route, and neutral error area.Render account creation as a focused task with a clear reason for the account, one identifier path, new-credential fields, verification or activation state, existing-account route, and post-creation destination.Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input.Show a visible countdown or clear expiry time before inactivity, absolute session, or reauthentication limits can interrupt work; place the warning near the current task or as a focused dialog when immediate action is required.Render email entry as a labelled single-line field with purpose text, type email, autocomplete email, spellcheck disabled, enough visible width for review, field-specific errors, and optional typo warning and review states.
UX guidance Use sign in when users are returning to an existing account, protected resource, invitation, draft, checkout, or workspace and need to prove control of an authenticator.Use account creation only when a persistent account is necessary for repeated access, saved data, updates, security, or legal accountability.Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.Use session timeout warning to balance security, privacy, accessibility, and continuity when an authenticated session is about to expire or require reauthentication.Use email address entry when the product must contact the user, identify an account, send a receipt, invite someone, or confirm access to a mailbox.
Good UI A sign-in page names the workspace, shows email or username, password with current-password autocomplete, passkey option, forgot-password link, create-account link, and a destination reminder such as Continue to Q2 budget review.A service lets users draft an application, then asks them to create an account to save and return later with email, new password, terms acknowledgement, and a clear activation message.A reauthentication dialog asks for Current password, lets the user show it temporarily, accepts a pasted manager value, and clears the field after an incorrect attempt.A benefits form shows Your session will end in 2 minutes, says the draft is saved, and offers Stay signed in, Save and sign out, and Sign out.A receipt form asks for Email address, says We will only use this to send your receipt, uses type email and autocomplete email, and shows a review row before submit.
Bad UI A failed sign-in says This email exists but the password is wrong, exposing account status.A registration screen has Sign in and Sign up side by side with identical email and password fields, plus newsletter, profile photo, and referral-code fields.A login form uses a normal text field named Password and leaves the secret visible on screen.The countdown shows time remaining after the server has already expired the session.A page asks users to type the email twice, blocks paste, and silently changes homtail.com to hotmail.com.
Good UX A user opens a private document link, signs in with a saved passkey, and lands back on the same document with focus near the access confirmation.A user completes most of a one-hour permit application, chooses to save progress, creates an account using the email already entered, verifies the email, and returns to the same draft.The person reaches the intended result with clear feedback.A user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.A user pastes alex+receipts@example.co.uk, sees it preserved exactly, reviews it on the check page, and changes it only if needed.
Bad UX A user signs in from checkout and lands on a generic account dashboard, losing the cart and payment context.A user must create an account before learning whether the service is suitable, then abandons because registration feels unnecessary.A failed login page says the password is wrong, confirming that the username exists.A user returns from a phone call to find the form gone and a generic access denied page.A user enters a valid plus-addressed mailbox and the form rejects it because the validator only allows letters before the at sign.
Best fit Users need to access an existing account or protected destination.Users need to save and resume drafts, regularly update their data, manage records, check ongoing status, collaborate, or protect repeated access.The user needs to enter an existing password, passphrase, or PIN-like memorized secret.An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification.
Avoid when The user is creating a new account, choosing a new password, or verifying a new contact method.The task is a one-off transaction that can be completed with a reference number, receipt, guest route, or emailed status link.The task is choosing a new password and needs creation-specific guidance, strength feedback, and blocklist rejection.The user lacks authorization while still signed in.The flow needs a phone number, postal address, payment account, password, or one-time code instead.
Required state Initial sign-in state with service or destination context.Need-for-account state explaining why an account is required or beneficial at this point.Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.Early idle warning with remaining time and current save state.Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.
Accessibility burden Use explicit labels for identifier, password, passkey, SSO, and one-time-code controls rather than placeholder-only prompts.Use a clear H1 such as Create an account and visible labels that say Create a password or Email address rather than ambiguous credential labels.Use a visible label that names the password purpose, such as Password or Current password.Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information.Use a visible label that names the value as an email address and a hint that explains why it is requested.
Common misuse Using account-specific error messages that reveal whether an identifier exists.Forcing accounts before users can evaluate a service or complete a one-off transaction.Using type text for passwords.Using a client-only timer that disagrees with the server session.Blocking paste or browser autofill.

Sign in

UI or UX
UI + UX - Returning-account authentication and session start flow
UI guidance
Render sign in as a focused authentication surface with a clear service or destination name, account identifier field, current-password or passkey path, password-manager-friendly attributes, recovery routes, create-account route, and neutral error area.
UX guidance
Use sign in when users are returning to an existing account, protected resource, invitation, draft, checkout, or workspace and need to prove control of an authenticator.
Good UI
A sign-in page names the workspace, shows email or username, password with current-password autocomplete, passkey option, forgot-password link, create-account link, and a destination reminder such as Continue to Q2 budget review.
Bad UI
A failed sign-in says This email exists but the password is wrong, exposing account status.
Good UX
A user opens a private document link, signs in with a saved passkey, and lands back on the same document with focus near the access confirmation.
Bad UX
A user signs in from checkout and lands on a generic account dashboard, losing the cart and payment context.
Best fit
Users need to access an existing account or protected destination.
Avoid when
The user is creating a new account, choosing a new password, or verifying a new contact method.
Required state
Initial sign-in state with service or destination context.
Accessibility burden
Use explicit labels for identifier, password, passkey, SSO, and one-time-code controls rather than placeholder-only prompts.
Common misuse
Using account-specific error messages that reveal whether an identifier exists.

Account creation

UI or UX
UI + UX - Persistent account establishment flow
UI guidance
Render account creation as a focused task with a clear reason for the account, one identifier path, new-credential fields, verification or activation state, existing-account route, and post-creation destination.
UX guidance
Use account creation only when a persistent account is necessary for repeated access, saved data, updates, security, or legal accountability.
Good UI
A service lets users draft an application, then asks them to create an account to save and return later with email, new password, terms acknowledgement, and a clear activation message.
Bad UI
A registration screen has Sign in and Sign up side by side with identical email and password fields, plus newsletter, profile photo, and referral-code fields.
Good UX
A user completes most of a one-hour permit application, chooses to save progress, creates an account using the email already entered, verifies the email, and returns to the same draft.
Bad UX
A user must create an account before learning whether the service is suitable, then abandons because registration feels unnecessary.
Best fit
Users need to save and resume drafts, regularly update their data, manage records, check ongoing status, collaborate, or protect repeated access.
Avoid when
The task is a one-off transaction that can be completed with a reference number, receipt, guest route, or emailed status link.
Required state
Need-for-account state explaining why an account is required or beneficial at this point.
Accessibility burden
Use a clear H1 such as Create an account and visible labels that say Create a password or Email address rather than ambiguous credential labels.
Common misuse
Forcing accounts before users can evaluate a service or complete a one-off transaction.

Password input

UI or UX
UI + UX - Authentication secret entry control
UI guidance
Render password entry as a labelled password field that is hidden by default, uses the correct autocomplete purpose, offers a clear show and hide control, disables spellcheck and automatic capitalization, and keeps helper and error text connected to the input.
UX guidance
Use password input when a user enters an existing secret to sign in, reauthenticate, unlock a protected action, or confirm account ownership.
Good UI
A reauthentication dialog asks for Current password, lets the user show it temporarily, accepts a pasted manager value, and clears the field after an incorrect attempt.
Bad UI
A login form uses a normal text field named Password and leaves the secret visible on screen.
Good UX
The person reaches the intended result with clear feedback.
Bad UX
A failed login page says the password is wrong, confirming that the username exists.
Best fit
The user needs to enter an existing password, passphrase, or PIN-like memorized secret.
Avoid when
The task is choosing a new password and needs creation-specific guidance, strength feedback, and blocklist rejection.
Required state
Initial hidden state with label, autocomplete purpose, spellcheck off, autocapitalization off, and show control.
Accessibility burden
Use a visible label that names the password purpose, such as Password or Current password.
Common misuse
Using type text for passwords.

Session timeout warning

UI or UX
UI + UX - Authenticated-session expiry and reauthentication boundary warning
UI guidance
Show a visible countdown or clear expiry time before inactivity, absolute session, or reauthentication limits can interrupt work; place the warning near the current task or as a focused dialog when immediate action is required.
UX guidance
Use session timeout warning to balance security, privacy, accessibility, and continuity when an authenticated session is about to expire or require reauthentication.
Good UI
A benefits form shows Your session will end in 2 minutes, says the draft is saved, and offers Stay signed in, Save and sign out, and Sign out.
Bad UI
The countdown shows time remaining after the server has already expired the session.
Good UX
A user pauses while gathering documents, sees the remaining time, extends the session once, then saves the draft before policy requires reauthentication.
Bad UX
A user returns from a phone call to find the form gone and a generic access denied page.
Best fit
An authenticated session can expire because of inactivity, overall lifetime, assurance policy, or reauthentication requirement.
Avoid when
The user lacks authorization while still signed in.
Required state
Early idle warning with remaining time and current save state.
Accessibility burden
Warn users early enough to respond and avoid relying on a rapidly changing countdown as the only information.
Common misuse
Using a client-only timer that disagrees with the server session.

Email address entry

UI or UX
UI + UX - Contactable email address capture field
UI guidance
Render email entry as a labelled single-line field with purpose text, type email, autocomplete email, spellcheck disabled, enough visible width for review, field-specific errors, and optional typo warning and review states.
UX guidance
Use email address entry when the product must contact the user, identify an account, send a receipt, invite someone, or confirm access to a mailbox.
Good UI
A receipt form asks for Email address, says We will only use this to send your receipt, uses type email and autocomplete email, and shows a review row before submit.
Bad UI
A page asks users to type the email twice, blocks paste, and silently changes homtail.com to hotmail.com.
Good UX
A user pastes alex+receipts@example.co.uk, sees it preserved exactly, reviews it on the check page, and changes it only if needed.
Bad UX
A user enters a valid plus-addressed mailbox and the form rejects it because the validator only allows letters before the at sign.
Best fit
The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification.
Avoid when
The flow needs a phone number, postal address, payment account, password, or one-time code instead.
Required state
Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width.
Accessibility burden
Use a visible label that names the value as an email address and a hint that explains why it is requested.
Common misuse
Blocking paste or browser autofill.
Decision rules
  • Choose sign in when a user already has an account or identity provider relationship and needs to start or restore an authenticated session before reaching a protected destination.
  • Choose account creation when the primary work is establishing a new persistent account, identifier, credential, verification, and recovery path rather than proving access to an existing one.
  • Choose password input when the design problem is the individual existing-secret field, visibility toggle, paste behavior, current-password autocomplete, or credential error binding inside a wider sign-in or reauthentication flow.
  • Choose session timeout warning when a user is already authenticated and a server or identity-provider boundary is about to expire, requiring extension, sign out, or reauthentication without losing work.
  • Choose email address entry when the field is only contact or notification capture; sign in uses an identifier to authenticate and must handle unknown, locked, disabled, throttled, or federated accounts without enumeration.
  • A sign-in flow should preserve the intended return destination, distinguish create-account, forgot-password, passkey, SSO, and help routes, and avoid landing successful users on an unrelated dashboard.
  • A sign-in error should not reveal whether the identifier, password, account existence, lock, or disabled state caused the failure; recovery and support routes can explain next steps without exposing account status.
  • A sign-in form should use credential autocomplete tokens and password-manager-friendly controls rather than blocking paste, renaming fields to defeat autofill, or hiding saved-credential suggestions.
  • Step-up authentication belongs in sign in when risk, policy, or authenticator choice requires it before access; broader two-factor enrollment or recovery is a separate flow.
Inspect live examples
Sign inAccount creationPassword inputSession timeout warningEmail address entry
Failure modes
  • The sign-in form reveals This email has no account, That password is wrong, or This account is disabled as separate failures.
  • Users successfully authenticate but lose the protected page, checkout, draft, invite, or document they came from.
  • The page blocks password manager paste or uses nonstandard field names that prevent saved credentials and passkeys from appearing.
  • Create account, forgot password, SSO, passkey, and help links are visually equal to the primary sign-in action with no explanation of when to use each.
  • A session expiry boundary is shown as a fresh sign-in page without preserving private work or explaining the timeout.

Saved items