Designing login, registration, and password recovery UI in Figma: auth flows, states, and handoff

Quick answer

Login and registration screens gate access to account areas, checkout benefits, and saved data—usually as a dedicated page or modal with email/password fields, social sign-in options, and links to sign up or reset password. Design three core flows: Sign in, Create account, and Forgot password (email capture → confirmation → new password). Include loading, error, locked-account, and MFA challenge states. Keep forms short: email + password for login; add name and marketing opt-in only when needed. Start from the Figma guides hub and pair with the account dashboard and forms patterns guides.

---

Who this is for

• Product designers building auth gates before checkout, wishlist, or account areas.
• Design system teams standardizing sign-in modals vs full-page auth across web and mobile.
• Engineers implementing session redirects, OAuth buttons, rate limits, and password policy validation.

---

Auth surface comparison

Surface	When to use	Trade-off
Full-page auth	Dedicated /login and /register routes	Best for SEO, deep links, and return URLs
Modal / drawer	Quick gate on PDP, wishlist, or mini cart	Faster but harder to bookmark
Inline checkout auth	Guest vs account choice at checkout	Reduces abandonment if optional
Header account menu	Logged-in state only	Links to dashboard, not login form

Verdict: use a full-page sign-in as the canonical pattern; reuse the same AuthForm component inside modals when you need lightweight gates.

---

AuthForm anatomy

Part	Spec	Notes
Brand header	Logo + short headline	”Sign in to your account”
Social row	Google, Apple, optional Facebook	Full-width stacked buttons
Divider	”or continue with email”	Centered text on line
Email field	type=email, autocomplete	Required
Password field	Show/hide toggle	Link to forgot password
Primary CTA	”Sign in” / “Create account”	Full width
Secondary link	Toggle login ↔ register	”Don’t have an account? Sign up”
Legal footer	Terms + Privacy links	Required for registration
Return URL note	”You’ll return to checkout”	When ?redirect= present

AuthForm
├── Variant: mode=signIn | signUp | forgotPassword | resetPassword | mfaChallenge
├── Variant: layout=page | modal
├── Property: socialEnabled=true
└── Layers:
    ├── BrandHeader
    ├── SocialAuthStack
    │   └── SocialButton (repeat)
    ├── Divider
    ├── EmailField
    ├── PasswordField
    ├── ForgotPasswordLink (signIn only)
    ├── MarketingOptIn (signUp only)
    ├── SubmitButton
    ├── ModeToggleLink
    └── LegalFooter (signUp only)

Use form input states—default, focus, error, disabled—and toggle switches for marketing consent on sign-up.

---

Sign-in flow states

State	UI treatment	Copy example
Default	Empty fields, enabled CTA	”Sign in”
Loading	Spinner on button, fields disabled	”Signing in…”
Invalid credentials	Inline error below password	”Email or password is incorrect”
Account locked	Banner + support link	”Too many attempts. Try again in 15 minutes.”
Unverified email	Banner + resend link	”Confirm your email to continue”
MFA required	Switch to code entry step	”Enter the 6-digit code”
Success	Brief toast then redirect	Redirect to return URL or dashboard

Never use vague errors like “Something went wrong” for credential failures—users retry blindly and support tickets spike.

---

Registration flow fields

Field	Required	When to skip
Email	Yes	Never
Password	Yes	Social-only signup
Confirm password	Optional	Use strength meter instead of duplicate field
First / last name	Often yes	Collect at checkout if guest-first
Phone	Optional	SMS tracking or MFA only
Marketing opt-in	Unchecked default	GDPR/CAN-SPAM compliant
Terms acceptance	Checkbox or implicit link	Jurisdiction-dependent

SignUpForm
├── Variant: state=default | validating | success | emailExists
└── Layers:
    ├── NameRow (First + Last)
    ├── EmailField
    ├── PasswordField + StrengthMeter
    ├── MarketingCheckbox
    ├── TermsCheckbox
    └── CreateAccountButton

Pair password fields with a strength meter (weak/fair/strong) and policy hint: “8+ characters, one number.”

---

Password recovery flow

Step	Screen	Primary action
1	Forgot password	Submit email
2	Check your email	Open mail app / resend
3	Reset password (from link)	New password + confirm
4	Success	Sign in with new password

PasswordRecovery
├── Step: requestEmail
├── Step: emailSent
├── Step: resetForm
└── Step: resetSuccess

Design the email sent step even if engineering handles it as a toast—users need confirmation the request worked. Include resend with cooldown annotation (e.g. 60 seconds). Reset form should validate token expiry with a clear “Link expired” state and CTA to request a new link.

---

Social auth button specs

Provider	Label	Icon placement
Google	”Continue with Google”	Leading brand icon
Apple	”Continue with Apple”	Required on iOS-heavy audiences
Facebook	”Continue with Facebook”	Optional; declining in B2C

Stack buttons full width with consistent height (44–48px). Do not bury social auth below a long registration form—put social options above email fields to reduce friction.

---

Modal vs page layout

Breakpoint	Page layout	Modal layout
Desktop	Centered card max 400–440px	Same card inside overlay
Mobile	Full-width padded form	Full-screen sheet with close
Focus	Single column	Trap focus; Esc closes only if safe

For modals, reuse modal overlay patterns with backdrop dim and close button. Auth modals should not close on backdrop click if a half-filled form risks data loss—confirm first or disable backdrop dismiss.

---

MFA and security UI

Pattern	UI	Notes
Email OTP	6 single-digit inputs or one code field	Auto-advance between boxes
Authenticator app	Code field + “Use backup code” link	Show device name if known
SMS OTP	Code field + resend timer	Pair with phone on file
Remember device	Checkbox	30-day trust annotation

MFA screens need back to sign-in without losing the email context. Show which method is active: “We sent a code to j***@email.com.”

---

Handoff checklist

Item	Dev Mode annotation
Return URL	?redirect=/checkout preserved through auth
Session merge	Guest cart → account on login
OAuth callbacks	Provider-specific error states
Rate limiting	Lockout UI after N failures
Password policy	Min length, complexity rules in validation copy
Autocomplete	email, current-password, new-password
Analytics	auth_sign_in_start, auth_sign_in_success, auth_sign_up_complete
a11y	Labels, aria-invalid, error announcements
Localization	RTL layout for Arabic storefronts

Pair with Dev Mode checklist and password-protected prototype guidance for stakeholder reviews.

---

Common mistakes

Mistake	Why it hurts	Fix
Login and register as unrelated layouts	Inconsistent trust	One AuthForm with mode variant
No forgot-password link	Support load + abandonment	Always visible on sign-in
Confirm-password field only	Extra friction	Strength meter + show/hide toggle
Social buttons below long forms	Low OAuth uptake	Social first, email second
Generic error messages	Brute-force retries	Specific, safe copy per failure type
Modal with no return context	Users lose checkout	Show “Return to cart” note
Marketing opt-in pre-checked	Legal risk	Unchecked default
Missing logged-out header state	Confusing nav	Show “Sign in” in header account slot

---

Recommended workflow

1. Pick auth surfaces (page, modal, checkout inline) from your funnel map.
2. Build AuthForm with signIn, signUp, and forgotPassword variants.
3. Add social auth row and divider above email fields.
4. Design all field states using shared form components.
5. Wire password recovery as a four-step mini-flow with email-sent confirmation.
6. Add MFA challenge frame if your platform supports 2FA.
7. Spec return URL, cart merge, and analytics in Dev Mode.
8. Prototype sign-in → account dashboard and checkout redirect paths.

---

FAQ

Separate mobile app login screens?

Reuse the same AuthForm component; on native apps, prefer full-screen over modals and follow platform HIG for Apple/Google button styling.

Show password requirements upfront?

Yes—a short hint under the password field beats errors after submit. Update copy when engineering changes policy.

Account creation during checkout?

Offer optional account creation after payment (“Save details for next time”) rather than forcing registration before purchase. See guest checkout patterns.

Magic link vs password?

If the product supports passwordless email links, add a “Email me a sign-in link” tertiary action—do not replace password fields unless the backend is link-only.

---

Next steps

• Design account dashboard and my account UI in Figma — post-login home
• Design guest checkout and account creation UI in Figma — checkout auth choice
• Design forms in Figma: inputs, states, and handoff — shared field patterns
• Design saved addresses and address book UI in Figma — pre-fill after sign-up
• Design shopping cart and checkout UI in Figma — checkout entry point