Registration fields should be the minimum necessary

What it is

Minimum necessary means the fields required to create an identity someone can return with—not everything marketing, risk, or personalization would like to know. Typical inflation adds name, gender, birthday, company, invite code, and preference checklists on top of an email. This entry is only about what the registration screen collects and why it must be collected now. It does not decide whether a wall should appear first, and it does not recast “ask later” as a guest identity.

Why it happens

Each field is a disclosure decision; costs do not add linearly. A contact channel is already expensive; demographic or workplace questions reframe “open a door” as “build a dossier.” Items with no immediate use read as surveillance or future spam, so trust drops and even a short remainder is abandoned. Password confirmation, OTP, and consent checkboxes are not “profile fields,” yet they occupy the same decision chain and inflate visible work. The test is downstream consumption: if nothing in the system reads a field in the first hour after signup, it does not belong on the registration screen.

Studying it

Run the same entry with an “identity-only” set versus an “identity plus profile” set, and compare completion against later fill-in.

Independent variables: field list (contact only, contact plus demographics, plus marketing preferences), mixing optional with required, OTP on the same screen as profile. Dependent variables: leave points from start to submit, dwell and clear per field, profile completeness after submit, subjective “asked too much.”

Completion rate conflates cannot-fill with will-not-fill; open questions or interviews separate “no invite code” from “no birthday.” Lab tasks often hand out test accounts, which dampens sensitivity. In production, keep “registered” and “profile complete” as separate events so field cuts are not just renamed into the next screen.

Where it stops holding

Regulated onboarding must collect statutory items (real-name checks, age gates, investor suitability); those cannot be cut, only separated from optional marketing. B2B provisioning that already has company data in a contract should not ask it again. Products that only federate a third-party identity may have a consent scope rather than input fields as their minimum. OTP and password rules are a different friction; deleting fields will not fix a failed SMS channel or a blocked paste.

Applying it

• Write a downstream consumer for every registration field: sign-in, recovery, billing, security notices. Move anything without a consumer off registration and ask it when that feature first needs it.
• Keep the screen to a primary identifier (email or phone) and a credential; name, avatar, and preferences go on a skippable page after success.
• Split statutory items from marketing items; marketing stays unchecked by default and must not block submit.
• Verify by inspecting the registration payload, removing keys unread in the first hour, then shipping; the peak-leave field in the start-to-complete funnel should vanish from the deleted items, not migrate because the completion event was renamed.

Related

• Within the group: H6.01.1 Let people experience core value before registration · H6.01.3 Deferring registration can raise conversion
• Adjacent: H1.12 Abandonment and field reduction · H1.03 Required and optional markers · H6.09 Anonymous and guest mode
• Search terms: minimum necessary · registration fields · data minimization