| UI or UX | UI + UX - Persistent account establishment flow | UI + UX - Single-service or single-task entry point before a transaction begins | UI + UX - First-run or new-feature orientation that leads to first value | UI + UX - New authentication secret selection flow | UI + UX - Contactable email address capture field |
| 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. | Render the service or task name, short purpose statement, who can use it, what users need, outcome expectation, time or cost where relevant, one primary start action, resume or sign-in route when relevant, and other access routes in a narrow readable page. | Render onboarding as a short purposeful path with a visible benefit, current step, skip or later path when safe, persistent resume point, and the next product action users can take immediately after finishing. | Keep the guidance focused on what actually affects acceptance: length, banned or breached value checks, service-specific terms, and password-manager compatibility rather than a decorative checklist of character classes. | 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 account creation only when a persistent account is necessary for repeated access, saved data, updates, security, or legal accountability. | Use a start page to help users decide whether they are in the right place and begin a specific service with the right materials, expectations, and recovery routes. | Use onboarding only when users need orientation, minimal setup, personalization, or instruction before the normal interface can deliver value, and remove steps that merely market features or repeat what the UI already explains. | Use password creation when a user is choosing a new reusable secret during registration, password reset, first-time setup, or password change. | 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 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 permit application start page states who can apply, the fee, the estimated time, required documents, what happens after submission, a Start now button, and a Resume application link. | A project-management app asks for role and team size, creates a sample board, highlights the first Add task action, and lets users skip the tour while keeping a setup checklist available. | A signup form labels the field New password, uses autocomplete new-password, allows password-manager generation, says Use at least 15 characters or a generated password, and rejects Password123 because it is commonly used. | 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 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. | Returning users create duplicate applications because the resume route is missing. | A first launch shows six promotional slides about every feature, requires Next on each slide, and lands on an empty dashboard. | A reset form asks for a password reminder question and then emails the new password to the user. | A page asks users to type the email twice, blocks paste, and silently changes homtail.com to hotmail.com. |
| 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. | The person reaches the intended result with clear feedback. | A new admin selects Invite teammates as their goal, imports two sample users, sees progress saved, skips notification setup, and arrives on the team page with the invite action focused. | The person reaches the intended result with clear feedback. | 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 must create an account before learning whether the service is suitable, then abandons because registration feels unnecessary. | Returning users create duplicate applications because the resume route is missing. | A user is forced to configure integrations, notifications, billing, and profile details before they know whether the product solves their task. | A user is forced to rotate a password every month and chooses predictable variations that are easier to guess. | 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 save and resume drafts, regularly update their data, manage records, check ongoing status, collaborate, or protect repeated access. | A user is about to start one named service, transaction, booking, application, check, request, or registration. | New users need orientation, setup, personalization, or instruction before the regular interface can deliver value. | The user is creating an account with a reusable password. | The product must capture an email address for contact, receipt, notification, invitation, account identifier, recovery, or verification. |
| Avoid when | The task is a one-off transaction that can be completed with a reference number, receipt, guest route, or emailed status link. | Users are still choosing among many topics, products, services, or articles. | The product is already understandable through the normal interface. | The user is only entering an existing password to sign in or reauthenticate. | The flow needs a phone number, postal address, payment account, password, or one-time code instead. |
| Required state | Need-for-account state explaining why an account is required or beneficial at this point. | Default entry state with service name, purpose, user fit, pre-start requirements, expected outcome, and primary start action. | First-run welcome state with benefit-focused copy and one clear next action. | Too-short state with the entered value preserved and a field-level length message. | Initial state with label, purpose hint, type email, autocomplete email, spellcheck false, and adequate width. |
| 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. | Use a clear H1 that names the service or task and matches the page title. | Keep onboarding screens in normal heading order with clear titles and step labels. | Use a visible label that says New password or Create a password rather than only Password when the user is choosing a new value. | Use a visible label that names the value as an email address and a hint that explains why it is requested. |
| Common misuse | Forcing accounts before users can evaluate a service or complete a one-off transaction. | Treating a product homepage, marketing landing page, or category directory as a start page for a specific service. | Forcing all users through a feature tour before they can do useful work. | Using uppercase, lowercase, number, and symbol checklists as the main security signal. | Blocking paste or browser autofill. |