Account creation

Problem Context

• Users need to regularly access, update, save, resume, manage, or protect data in a service or product.
• The service may need an account for drafts, history, status checks, notifications, recovery, payments, permissions, auditability, or collaboration.
• A one-off transaction may be possible without an account and should not force one unless policy, security, or later management requires it.
• Users may already have an account, may be using a password manager, may need email or phone verification, or may be vulnerable to enumeration if responses reveal account existence.
• Account creation often touches email entry, password creation, terms acceptance, MFA setup, profile setup, and onboarding, but should not absorb those tasks unless they are necessary to establish the account.

Selection Rules

• Choose account creation when a persistent account is required for repeated access, saved data, account management, security, authorization, legal accountability, or returning to drafts.
• Avoid account creation when a one-off service can use a reference number, email link, receipt, guest checkout, or existing identity route.
• Let users use as much of the service as practical before account creation when the account is only needed for save, return, submit, or manage-later behavior.
• Use Create an account language rather than ambiguous Register or Sign up copy when the task is establishing a new account.
• Label new credentials clearly, such as Create a password, so users do not think they are entering an existing password.
• Separate account creation from sign-in through page title, copy, route, and recovery link; do not rely only on two adjacent buttons.
• Reuse email, name, phone, address, or other data already entered rather than asking users to repeat it for the account.
• Use neutral messages for duplicate or existing accounts where enumeration risk matters, and route users through email, sign-in, or recovery.
• Ask for verification, MFA, terms, or consent only when needed for the account; defer profile setup, preferences, marketing opt-ins, and onboarding until after creation.
• Avoid CAPTCHAs and similar cognitive tests as the default abuse defense; prefer rate limits, risk controls, email verification, or other accessible security measures.
• Do not use National Insurance numbers or similarly high-risk identifiers as default account verification shortcuts.
• After successful creation, return users to the draft, task, dashboard, or next account-security step that explains why the account was created.

Required States

• Need-for-account state explaining why an account is required or beneficial at this point.
• New-account entry state with clear identifier and new credential labels.
• Already-have-account state with sign-in and recovery routes separated from creation.
• Duplicate or existing-account neutral response state that avoids exposing account existence.
• Verification pending state for email, phone, magic link, or activation code.
• Verification failed or expired state with resend, change contact, and support routes.
• Password-manager and autofill state supporting email, username, and new-password fields.
• Save-and-return state that lands back on a draft or interrupted task after creation.
• Optional setup deferred state where profile, preferences, MFA, or onboarding are offered without blocking unnecessary progress.
• Unavailable, rate-limited, or abuse-protection state with accessible recovery and no CAPTCHA-only dead end.

Interaction Contract

• The flow states why the account is needed before asking for credentials.
• Submitting account details validates required fields, preserves entered values except secrets when appropriate, and never displays raw passwords later.
• Existing-account detection does not reveal account existence on sensitive surfaces; users receive a neutral next step or are routed through email, sign-in, or recovery.
• Create-account and sign-in routes cannot silently switch modes while keeping the same field values in a misleading state.
• Verification links or codes identify the service, expire predictably, support resend, and allow users to change the target email or phone.
• Successful creation establishes an authenticated or pending account state and returns to the task or account area promised by the page.
• Security controls such as rate limits, bot defenses, and MFA setup are explained and accessible without turning into unrelated profile setup.
• Account creation records required consent or terms separately from optional marketing, personalization, or notification preferences.

Implementation Checklist

• Decide whether an account is truly required; document the saved data, repeated access, authorization, legal, security, or collaboration need.
• Choose the account identifier, verification channel, credential method, recovery route, existing-account response, and post-creation destination before designing screens.
• Use native email, username, and new-password fields with correct autocomplete values and password-manager compatibility.
• Reuse information already entered in the service and clearly show when it will become part of the account.
• Design neutral duplicate-account, activation-link, expired-link, resend, change-contact, sign-in, recovery, and rate-limited states.
• Separate required account setup from profile details, notification preferences, consent choices, onboarding, and marketing opt-ins.
• Test new user, existing user, duplicate email, password manager, paste, verification timeout, mobile, keyboard, screen reader, slow network, translated copy, and abuse-control states.
• Monitor account-creation abandonment, duplicate-account creation, activation completion, recovery after duplicate attempts, and downstream return-to-task success.

Common Generated-UI Mistakes

• Forcing accounts before users can evaluate a service or complete a one-off transaction.
• Using account creation to collect profile, marketing, or preference data that is not needed to establish the account.
• Presenting create account and sign in as identical forms with unclear labels.
• Revealing This email already exists on a public registration page.
• Asking users to retype information they already entered earlier in the service.
• Adding CAPTCHA as the only abuse defense or making it block assistive-technology users.
• Treating password creation, profile setup, onboarding, and account creation as one undifferentiated flow.
• Landing users on a blank account dashboard instead of returning to the draft or task that required the account.

Critique Questions

• Why is a persistent account needed here, and could a reference number or email link satisfy the user need?
• Can users do useful service work before account creation becomes necessary?
• How does the page make Create an account different from Sign in?
• What happens if the email or username already belongs to an account?
• Which entered information is reused, and which fields are unnecessary at this point?
• Where does the user land after creation, verification, expiration, or failure?