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:
- Establish context (one quick question if it's not already known).
- Apply the always-true core — the patterns that are correct for essentially every auth screen.
- 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)
- Reset link below the password field, where users expect it, clearly labeled (it's the "emergency exit" — Nielsen's user control & freedom).
- Ask for only 1–2 fields (email or phone) to verify identity.
- Confirmation page telling the user what happens next ("check your inbox").
- Clear next-step instructions in the email/SMS — a prominent link or code, minimal text.
- Reset page with the new-password input and requirements visible.
- 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 |
