Login signup

Login & Sign-up Screen Skill

How this skill behaves (read first)

This is a generative skill, so it does not blindly apply every best practice — login/sign-up has a set of context-dependent levers (social login, "stay logged in", username vs. email, 2FA) where applying everything is wrong for some products and right for others. Auto-applying all of them produces a bloated, insecure, or privacy-hostile screen.

So the skill works in three moves:

1. Establish context (one quick question if it's not already known).
2. Apply the always-true core — the patterns that are correct for essentially every auth screen.
3. Surface the context-dependent decisions with their trade-offs and a recommendation, and let the user choose — don't silently pick.

Then it hands the result to the audit skills for validation: call the heuristics audit (ux-heuristics-audit) and the accessibility audit (ux-accessibility-audit) on the generated screen. This skill deliberately does not re-derive contrast/keyboard/screen-reader rules — that's the accessibility skill's job.

---

Step 0 — Establish context before designing

Auth design changes sharply with these. If they aren't known, ask:

• Platform — mobile (tight horizontal space → top-aligned/floating labels, contextual keypads, ≥38px touch targets) vs. desktop.
• Security sensitivity — casual consumer app vs. banking/health/enterprise. This is the single biggest driver of the gated decisions below.
• Audience — mainstream consumers (favor social login, low friction) vs. security-conscious or regulated users.

State the assumption if you proceed without an answer (e.g. "Assuming a standard consumer SaaS on web").

---

The always-apply core (correct for almost every auth screen)

Structure

• Separate login and sign-up into distinct pages/views. Don't merge them — users try the wrong one and get frustrated.
• Make switching obvious: a clear title states which page you're on, and a "Don't have an account? Sign up" (or vice-versa) link sits above the inputs where users look. Social buttons appear on both pages.
• Keep sign-up to one short screen. Ask only the essentials (identifier + password). Collect everything else later, contextually, after the user has experienced value.

CTAs

• Visually distinct labels. Avoid the "Sign in" / "Sign up" near-collision — prefer "Log in" vs. "Sign up" or "Register".
• Button hierarchy: the primary action gets the brand/primary color and weight; the secondary action is muted or a text button. One dominant action per screen.
• CTA visible without scrolling; on long mobile forms, fix it to the bottom.

Password field

• Show/hide toggle (eye icon) that works both ways — typo prevention, especially on mobile. This also lets you drop the "confirm password" field.
• Password requirements visible while typing (a live checklist), not revealed only on error.

Password recovery (the most-abandoned path — design the whole flow, not just a link)

1. Reset link below the password field, where users expect it, clearly labeled (it's the "emergency exit" — Nielsen's user control & freedom).
2. Ask for only 1–2 fields (email or phone) to verify identity.
3. Confirmation page telling the user what happens next ("check your inbox").
4. Clear next-step instructions in the email/SMS — a prominent link or code, minimal text.
5. Reset page with the new-password input and requirements visible.
6. Success acknowledgement, then redirect to login (or the intended destination).

Validation & submit states

• Inline validation as the user leaves each field — never wait until Submit to reveal all errors. Show the result next to the field; green check for success, red for failure.
• Submit shows a loading state, then a success message or a clear error.
• Security caveat on errors: use a generic "Invalid username or password" rather than revealing which one was wrong.
• Error copy is plain, polite, specific — what went wrong + how to fix it. No jargon, no ALL CAPS, no blame.

Form mechanics (mobile-sensitive)

• Top-aligned or floating labels — never placeholder-only (placeholders vanish on focus and force recall).
• Helper text below fields that need it (e.g. why a phone number is required).
• Contextual keypads (numeric pad for phone/code) and input masks for formatted data.
• Touch targets ≥ ~38px; inputs 32–40px tall; primary button width matched to inputs for balance.

---

The context-dependent decisions (surface, don't auto-apply)

For each, present the trade-off and a recommendation tied to the Step 0 context, then let the user decide. Applying all of these by default is a mistake.

Decision	Apply when	Avoid / adapt when	Default recommendation
Social login (Google/Apple/etc.)	Mainstream consumer apps — ~80% of users prefer it; cuts friction, verifies email for you	Privacy-sensitive audiences, enterprise SSO contexts, or where you need data control	Offer it for consumer apps; pair with an email option. Ask before adding.
Identifier: email/phone vs. username	Username only if social identity/handles matter to the product	Username as a requirement — harder to recall, more failed logins	Default to email or phone; offer username only as an option
"Keep me logged in" / "Remember me"	Low-stakes apps where re-entry is annoying	Banking/health/enterprise — auto-logout after inactivity; remember the username only, not the session	Sensitivity-dependent — this is why Step 0 matters
2FA / biometrics	High-stakes or regulated data; biometrics for quick secure mobile login	Casual low-risk apps where it adds needless friction	Recommend for sensitive data; optional elsewhere
Single screen vs. progressive profiling	Almost always start minimal	—	Minimal now, ask more contextually later

When the product is high-security (banking, health), the convenience levers (stay-logged-in, social) flip toward the secure choice and 2FA/biometrics become recommended rather than optional.

---

Validate the result (orchestration)

Hand-offs name each lens by its installable skill name. Invoke one only if that skill is installed; if it isn't, this skill's own core already carries these rules — proceed without it rather than blocking.

After generating or revising, hand the result to the audit lenses rather than declaring it done. These are candidate lenses — posture is set by docs/orchestration-policy.md, or route the whole thing through ux-design-review. Here, heuristics and dark-patterns are Tier A (auto-run); accessibility and aesthetics are Tier B (offered) — under an existing design system aesthetics is suppressed and accessibility narrows to usage. If the user invoked this skill for one specific thing, respect that scope.

• ux-heuristics-audit (Tier A) — checks feedback/status on submit, error recovery, consistency, recognition (e.g. visible password requirements).
• ux-accessibility-audit (Tier B — offer; narrow under a design system) — label/contrast/keyboard/focus specifics, which this skill intentionally defers.
• ux-aesthetics-audit (Tier B — offer; suppress under a design system) — visual hierarchy and the overdesign check: did the gated levers (social buttons, 2FA, password rules) clutter the screen or bury the primary action?
• ux-dark-patterns-audit (Tier A) — if sign-up adds marketing opt-ins, forced social connect, or over-broad permissions: checks for preselection, forced action, and confirmshaming.

If the audits surface a conflict (e.g. you added social login, a "remember me", 2FA prompt, and a long password policy, and minimalism now suffers), resolve back toward the primary task: getting the user in.

---

Common do/don't patterns

❌ Don't	✅ Do
Merge login and sign-up into one ambiguous form	Separate pages with a clear title and an above-the-form switch link
"Sign in" next to "Sign up"	"Log in" vs. "Sign up" / "Register" — visually distinct
Ask for many fields at sign-up	Identifier + password only; collect the rest contextually later
Placeholder-only fields	Top-aligned or floating labels that persist
Reveal all errors after Submit	Inline validation as the user leaves each field
"Error: invalid input" / ALL CAPS	Plain, polite, specific message next to the field
Reveal whether the username or password was wrong	Generic "Invalid username or password"
Hide the password with no reveal option	Eye icon to show/hide; drop "confirm password"
Just a "Forgot password?" link with no flow	Design the full recovery flow through to success + redirect
Auto-apply social login + stay-logged-in everywhere	Surface them as context-dependent choices with trade-offs
Keep users logged into a banking app indefinitely	Auto-logout on inactivity; remember username only
Ship without checking	Hand off to the heuristics + accessibility audits

---

Source lessons (Uxcel)

• Best Practices for Designing Login & Signup Flows
• Designing Mobile Logins, Signups, & Other Forms
• Resetting Password
• Best Practices for Designing Forms
• Submitting a Form