Create user profile

Problem Context

• Users are entering a collaboration product, community, marketplace, developer platform, employee directory, social surface, or public contribution system.
• Other people need enough profile information to identify, mention, assign, contact, trust, or understand the user.
• Profile details can be visible to teammates, organizations, external collaborators, public pages, search, apps, or marketplaces.
• Some fields may be synced from an identity provider, admin-managed, legally required, or optional self-expression.
• Users may not know the difference between full name, public name, display name, username, handle, bio, status, job title, pronouns, location, local time, and profile photo.

Selection Rules

• Choose create user profile when the user is defining visible identity information that other people or public surfaces will see.
• Require only the smallest set of profile fields needed for recognition or safety, such as display name or public name.
• Make optional fields clearly optional and explain why adding them helps, where they appear, and whether they can be skipped.
• Show safe defaults such as initials, empty bio, hidden location, or organization-only visibility before asking for extra details.
• Preview the profile card, public profile, mention, comment byline, or directory result before saving when profile visibility matters.
• Use visibility choices for fields that can expose personal information, especially photo, full name, pronouns, location, local time, email, bio, and social links.
• Mark organization-managed or identity-provider-synced fields as managed and provide a route to request changes.
• Avoid using profile creation to collect account credentials, marketing preferences, onboarding answers, or broad settings.
• Use account creation when the user is establishing credentials and recovery; use onboarding when the user is learning the product; use profile setup later when users are enriching an existing profile.
• Do not publish profile information to public pages, search, or third-party apps until visibility consequences are explicit.

Required States

• Initial profile purpose state explaining where the profile will appear.
• Required display identity state with clear labels for display name, public name, handle, or full name.
• Optional avatar state with upload, remove, initials fallback, and image-crop or alt-text guidance where relevant.
• Optional bio, role, title, pronouns, location, local time, social link, or status state with skip path.
• Field visibility state showing audience such as Only you, organization, teammates, external collaborators, or anyone.
• Managed field state for values controlled by admin, directory sync, SSO, or identity provider.
• Preview state showing how the profile appears in at least one real destination.
• Save confirmation state that returns users to the context that needed the profile.
• Edit later state explaining where profile details and visibility can be changed.
• Public or external exposure warning state when profile information may be indexed, shared, or accessed by apps.

Interaction Contract

• The form states which profile fields are required, optional, managed, hidden, or public before users save.
• Users can skip optional profile enrichment without losing access to the core product unless policy requires it.
• Changing a field updates the preview and any visibility summary tied to that field.
• Photo upload has a fallback path and does not block saving when a photo is optional.
• Visibility controls apply to the actual downstream profile surfaces, not just the setup page.
• Managed fields cannot be edited as if user-controlled; the UI explains the source and change path.
• Saving the profile preserves user-entered fields, records visibility choices, and returns focus to the next useful task or profile preview.

Implementation Checklist

• Inventory where each profile field appears: mentions, cards, directories, search, public pages, apps, comments, assignments, and exports.
• Classify each field as required, optional, managed, derived, private, organization-visible, external-visible, or public.
• Use existing name, email, avatar, locale, and organization data only when users understand how it will be displayed.
• Design initials fallback, missing-photo state, skipped-bio state, invalid link state, long-name state, and translated-label state.
• Show a profile preview for the most important destination, and include audience or visibility labels near sensitive fields.
• Keep account credentials, MFA, notification preferences, marketing consent, and onboarding choices out of the required profile step.
• Test display names with spaces, capitalization, non-English characters, long names, initials, no photo, managed fields, mobile keyboard, screen readers, high contrast, and public/private visibility.

Common Generated-UI Mistakes

• Forcing optional profile completion before users can do the task they came for.
• Publishing profile data without a preview or visibility explanation.
• Confusing legal name, full name, public name, display name, username, and handle.
• Making profile photo mandatory when initials or a neutral avatar would work.
• Letting users edit fields that are later overwritten by directory sync.
• Using profile creation to ask for credentials, security setup, marketing preferences, or product onboarding data.
• Hiding required fields among optional enrichment fields.
• Showing the same profile preview for all audiences when visibility differs.

Critique Questions

• Where will each profile field appear after save?
• Which fields are truly required for recognition, safety, collaboration, or policy?
• Can users skip photo, bio, location, pronouns, and social links?
• What visibility does each sensitive field have by default?
• Which fields are user-controlled versus admin-managed or synced?
• Does the preview match mentions, cards, directories, public pages, and app access?