| UI or UX | UI + UX - Visible personal identity and profile presentation setup | UI + UX - Persistent account establishment flow | UI + UX - First-run or new-feature orientation that leads to first value | UI + UX - Short related multi-field submission page | UI + UX - Personal-name capture field or field group |
| UI guidance | Render profile creation as a focused identity setup surface with required display identity, optional photo or initials, optional role or bio fields, visibility choices, managed-field indicators, and a live preview of how the profile will appear. | 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 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. | Render a clear form heading, short instruction, required or optional indicator explanation, grouped related fields, one primary submit action, and a visible error summary only after failed submit. | Render name entry with a visible label that says exactly which name is needed, such as Full name, name on your passport, given names, family name, previous name, or what should we call you. |
| UX guidance | Use create user profile when users need to decide what personal information represents them to other people or public surfaces. | Use account creation only when a persistent account is necessary for repeated access, saved data, updates, security, or legal accountability. | 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 a single-page form when users benefit from seeing, comparing, and editing a small related set of fields before one submission. | Use name entry when a product must identify, address, verify, correspond with, or officially record a person by name. |
| Good UI | A new workspace member chooses a display name, sees initials as the default avatar, optionally adds pronouns and job title, chooses whether location is visible to the team, and previews a mention card before saving. | 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 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 contact-details form shows one heading, a required-field note, grouped name and contact fields, communication preference radios, aligned field errors, and a Save details button at the end. | A profile form asks for Full name, uses autocomplete name and spellcheck false, accepts María-José Carreño Quiñones, and shows the exact value before saving. |
| Bad UI | A profile setup screen requires a photo, birthday, location, phone number, biography, and social links before the user can enter a private project. | A checkout asks for account registration before showing shipping cost or guest checkout even though the purchase can complete without an account. | A first launch shows six promotional slides about every feature, requires Next on each slide, and lands on an empty dashboard. | A long application with eligibility, address history, uploads, and payment fields is dumped onto one scrolling page. | A form forces Title, First name, Middle initial, and Last name before it knows whether those parts exist or are needed. |
| Good UX | A user saves a profile with only display name and initials, sees how it appears to teammates, and adds a bio later from the profile page. | 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. | 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. | A user edits email and phone together, submits, sees two linked errors, fixes both without losing the preference selection, and saves the whole form once. | A user enters 小林康宏, optionally adds Yasuhiro Kobayashi as a Latin transcription for staff, and sees both values reviewed separately. |
| Bad UX | A user's legal name is shown to external collaborators because the profile creation screen did not distinguish legal name from public display name. | A user must create an account before learning whether the service is suitable, then abandons because registration feels unnecessary. | A user is forced to configure integrations, notifications, billing, and profile details before they know whether the product solves their task. | A user submits a mixed form, sees a generic red banner, scrolls through many unrelated fields, and cannot find which answers failed. | A user with one name cannot continue because Last name is required and enters a period just to pass validation. |
| Best fit | Users need to create a visible profile for collaboration, community, directory, marketplace, public contribution, support, or social interaction. | Users need to save and resume drafts, regularly update their data, manage records, check ongoing status, collaborate, or protect repeated access. | New users need orientation, setup, personalization, or instruction before the regular interface can deliver value. | A compact set of related fields should be reviewed together before one submit. | The product must capture a person's name for display, correspondence, booking, application, payment, account details, identity matching, support, or official records. |
| Avoid when | The task is only creating credentials, signing in, setting a password, or verifying an email. | The task is a one-off transaction that can be completed with a reference number, receipt, guest route, or emailed status link. | The product is already understandable through the normal interface. | The form is long, high-stakes, branched, or too hard to recover from on one page. | The product only needs a username, email address, account number, organization name, reference, or anonymous interaction. |
| Required state | Initial profile purpose state explaining where the profile will appear. | Need-for-account state explaining why an account is required or beneficial at this point. | First-run welcome state with benefit-focused copy and one clear next action. | Initial empty state with form heading, instruction, required or optional indicator explanation, grouped fields, and submit action. | Initial full-name state with visible label, purpose hint, autocomplete name, spellcheck false, and adequate width for long names. |
| Accessibility burden | Use explicit labels for display name, public name, full name, username, and handle so users know what each value means. | 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. | Keep onboarding screens in normal heading order with clear titles and step labels. | Keep field order in the DOM the same as the visible order. | Use visible labels that state the exact name representation requested. |
| Common misuse | Forcing optional profile completion before users can do the task they came for. | Forcing accounts before users can evaluate a service or complete a one-off transaction. | Forcing all users through a feature tour before they can do useful work. | Using one page for a long complex application just to avoid designing steps. | Requiring first name and last name when a full-name field would work. |