Quick Answer: What Is a Login Page Wireframe?
A login page wireframe is a low-fidelity layout sketch of an authentication interface showing the arrangement of key elements: email/username field, password field, primary CTA button, forgot password link, sign-up link, and optional social login buttons. It maps the structural logic of the auth flow — sign in, registration, password reset, and MFA — before any visual design begins.
5 Login Page Wireframe Examples (Sign In, Sign Up & Auth Flows)
Authentication screens are the highest-friction moment in any digital product. A poorly designed login flow causes drop-offs, support tickets, and lost revenue. These 5 annotated wireframe examples cover every major auth pattern — from a basic email/password form to multi-factor authentication — with design rationale, UX principles, and layout annotations for each.
Last updated: June 2026 | 12 min read
Why Wireframing Your Login Page Matters
Logo anchors trust before any input
Email + Password with show/hide toggle
Full-width Sign In button
Google / Apple — separated by "or" divider
Subordinate — below CTA, not competing
The login page is the gateway to your entire product — a single centered card that carries enormous functional weight. Every field, every button placement, and every link decision affects conversion, security perception, and user trust.
- Forces authentication decisions early: Should users log in with email/password or social login? What happens after a wrong password? How many failed attempts trigger a lockout? These are far cheaper to answer on a wireframe than in production code.
- Reduces abandonment: Baymard Institute research found 18% of users abandon checkout because it requires account creation — and checkout is downstream from login. Getting authentication UX wrong means users never get inside your product.
- Translates UX into technical requirements: A "Remember me" checkbox tells the backend team they need persistent session tokens. "Sign in with Google" signals OAuth integration. A six-digit SMS code entry signals an MFA provider. Good wireframes surface these requirements before sprint planning.
- Aligns the full team: Security, product, and engineering rarely discuss auth flows together until login wireframes make the decisions visible and reviewable by everyone at once.
The examples below walk through five common login wireframe patterns: the classic email/password form, the modern social-first layout, a multi-step registration flow, a password recovery flow, and a two-factor authentication screen — each with a detailed CSS wireframe and annotation covering every design decision.
5 Login Page Wireframe Examples
Basic Email/Password Login
Wireframe Annotations
The basic email/password login is the most common authentication pattern on the web. Its simplicity is its greatest strength — there are no distractions, no ambiguity, and the user's task is completely clear from the moment the page loads. Despite its ubiquity, many implementations get subtle details wrong. Let's walk through every design decision in this wireframe.
The page heading ("Sign In" or "Welcome back") should be concise and action-oriented. Avoid generic labels like "Login" — "Sign In" is warmer and matches the CTA button language. The subheading can display the app name or a short value reinforcement phrase such as "Continue to YourApp" or "Sign in to your account."
The email field should use type="email" in HTML, which triggers the email keyboard on mobile devices and provides basic browser-level validation. The label sits above the field (not inside as placeholder text — more on this in the mistakes section). The field stretches the full card width to maximise target area.
The password field includes a show/hide toggle icon on the right side, represented in the wireframe as the small icon block. This is now an accessibility requirement in many design systems — users making typos in a hidden field is one of the most common sources of failed login attempts. The toggle allows users to verify what they typed before submitting.
The "Remember me" checkbox is placed in the lower-left, paired with "Forgot password?" on the right. This layout follows the F-pattern of reading — users scan left then drift right. "Forgot password?" should be a text link styled in the brand's primary colour, not a button. Buttons imply a heavier action; a link implies a light navigational action.
The primary CTA button spans the full card width. This is critical — full-width buttons in contained cards convert better than narrower alternatives because the large touch target reduces friction, especially on mobile. The button label should be "Sign In" rather than "Submit" or "Login" — action verbs that match what the user is doing perform better.
The sign-up prompt at the bottom ("Don't have an account? Sign up") is a low-priority secondary action. It should be visually subordinate to the primary CTA — smaller text, less contrast. Some apps use a text link here; others use a secondary outlined button. For conversion-focused products, this link should be clearly visible but not compete with the sign-in action.
Social Auth First (SSO / OAuth Login)
Wireframe Annotations
The social-first login pattern has become the dominant approach in modern SaaS, developer tools, and consumer apps. The reasoning is straightforward: users already have Google or GitHub accounts, those accounts already have verified email addresses, and authenticating via OAuth takes two clicks rather than filling out a form and potentially resetting a forgotten password three weeks later.
The visual divider between social buttons and the email/password form is essential. Without it, users are confused about whether they should fill in the email form AND click Google, or choose one or the other. The divider typically contains a centered "or" label, which is represented in the wireframe as the small label block between two horizontal lines.
Provider selection: The choice of which social providers to display is a product decision that belongs in the wireframe, not the final design phase. For developer-focused tools, GitHub is often more valuable than Google. For consumer apps, Google + Apple covers the majority of mobile users. For enterprise B2B, Microsoft (Azure AD) or SAML SSO may be required. The wireframe should show the providers that match your target user base.
Button order matters. The provider with the highest expected usage should appear first. For most consumer web apps, Google comes first. If you have analytics showing 70% of users sign up with GitHub, GitHub should be first. This is a data-driven decision that the wireframe documents.
The email/password form remains below the divider as a fallback option. It should not be visually suppressed to the point of being invisible — some users actively prefer not to use social login for privacy reasons, and enterprise users may be prohibited from using personal OAuth accounts. The form is deprioritised visually but remains fully accessible.
Implicit sign-up: Many modern apps handle sign-up and sign-in through the same social auth button. If a user clicks "Continue with Google" and their Google email is not in the system, the app creates an account automatically. If it is in the system, they are logged in. This pattern eliminates the sign-up vs. sign-in distinction for OAuth users. Your wireframe should document this behaviour in an annotation, as it has significant implications for your onboarding flow.
Sign Up / Registration Flow (Multi-Step)
Wireframe Annotations
A registration flow is more complex than a login form because you are collecting new data, not verifying existing data. The wireframe must make decisions about how much information to collect, in what order, and how to communicate progress. Multi-step registration flows — where the process is broken into 2–4 shorter screens — consistently outperform single-screen mega-forms for completion rates.
Step 1 — Email & Password: The first step should ask for the minimum necessary information to create an account: an email address and a password. Some products also ask for a name here. The goal is to get the user committed to the account creation process quickly — the more fields you show on the first screen, the higher the abandonment rate.
Two-column name fields: First name and last name can be placed side-by-side to save vertical space. However, be aware that this creates accessibility issues on mobile — two narrow fields are harder to tap accurately. Consider whether you actually need both a first and last name, or whether a single "Display name" field would suffice for your use case.
Password strength indicator: The horizontal bar below the password field provides real-time feedback on password strength. The wireframe shows this as a partially-filled bar. In final design, the bar colour changes from red (weak) to yellow (medium) to green (strong) as the user types. This is a well-established pattern that reduces the number of rejected passwords and improves security.
Terms and Privacy checkbox: The wireframe shows a checkbox linking to both the Terms of Service and Privacy Policy. This is a legal requirement in most jurisdictions — GDPR, CCPA, and similar regulations require explicit consent. The checkbox must be unchecked by default. The links should open in a new tab to avoid disrupting the registration flow. Never pre-check this box.
Step 2 — Profile: The second step typically collects additional information needed to personalise the experience — a company name, job role, use case, team size, or profile photo. Keep this step genuinely optional data that improves the experience; never use step 2 as a way to extract marketing data you could collect later.
Step 3 — Verify Email: After form submission, the user receives a verification email. The final step of the wireframe shows a confirmation screen that tells the user to check their inbox. It should include a "Resend email" link and ideally detect the user's email provider and offer a direct link (e.g., "Open Gmail" if the email domain is gmail.com).
Forgot Password Flow
Step 1: Enter Email
Step 2: Check Inbox
Step 3: New Password
Wireframe Annotations
Password recovery is one of the most neglected flows in application design, yet it directly impacts user retention. A study by Auth0 found that up to 45% of users forget their passwords within 30 days of account creation. An awkward or confusing recovery flow drives those users away permanently. The wireframe above shows three distinct screens that make up a complete password recovery flow.
Step 2 — Confirmation screen: After submitting the email, the user sees a confirmation screen. This screen should visually communicate success (the green circle icon in the wireframe) and provide clear next steps. A "Open Gmail" or "Open Outlook" button — which detects the email domain and links directly to the appropriate webmail client — significantly reduces the friction of this step. Include a "Didn't receive an email?" resend link with a 60-second cooldown to prevent spam.
Step 3 — New Password form: When the user clicks the link in their email, they arrive at the password reset form. This form should contain two fields: "New Password" and "Confirm Password", both with show/hide toggles. A password strength indicator should update in real-time. The "Confirm Password" field should validate on blur (when the user leaves the field) and show an inline error if the passwords don't match — not wait until form submission to surface this error.
Token expiration handling: Password reset links should expire (typically after 1–24 hours). Your wireframe should include a design for the expired-token state — a screen that explains the link has expired and provides a single-click path back to the forgot password flow to request a new link. This state is often forgotten and users encounter a dead-end instead.
Post-reset behaviour: After a successful password reset, automatically log the user in and redirect them to their dashboard. Do not redirect them to the login page and make them log in again with their new password. This extra friction is a common mistake that creates a frustrating final impression of what should be a moment of relief.
Two-Factor Authentication (MFA) Screen
Wireframe Annotations
Two-factor authentication adds a second verification layer after the user's password has been confirmed. The MFA screen is a separate view that appears only for users who have MFA enabled on their accounts. Wireframing this screen carefully is essential because it is a flow that users encounter regularly and any friction here translates directly into support tickets and workarounds.
Six individual digit boxes vs. a single text input: The wireframe uses six individual OTP boxes, which is the modern preferred pattern. This approach provides clear visual feedback showing which digit position is being entered, works well with SMS autofill on iOS and Android (which can auto-populate the code from the incoming message), and creates a satisfying tactile experience. The alternative — a single input field for the full 6-digit code — is simpler to implement but provides less visual feedback.
Countdown timer: SMS codes should expire within 5–10 minutes. The wireframe shows a timer display in amber/yellow ("Resend code in 2:34"). Once the timer hits zero, a "Resend Code" link becomes active. The timer prevents code enumeration attacks while giving legitimate users plenty of time. Display the timer prominently — users get anxious when they see a code input without knowing how long they have.
Verify button state: The "Verify" button should be disabled until all six digit boxes are filled. This prevents premature form submission and removes an entire class of user error. As each digit is entered, the button should animate into an active state, giving users immediate feedback that the form is ready to submit.
Alternative method option: Below the primary SMS verification flow, the wireframe includes a secondary option to use an authenticator app (like Google Authenticator or Authy). This is represented by the outlined secondary button. Users who have lost access to their phone number need this fallback. Some products also include "Use a backup code" as a third option, which should appear as a text link beneath the secondary button.
Error handling for wrong codes: The wireframe should include an error state — the OTP boxes flash red, the input is cleared, and an error message appears explaining that the code was incorrect with the number of attempts remaining. After 3–5 failed attempts, the account should be temporarily locked and the user redirected to account recovery. This behaviour should be documented in wireframe annotations even if it cannot be shown in a single static frame.
"Back to Login" link: The bottom of the card includes a link back to the login screen. This is important for users who accidentally land on the MFA screen or who realise they entered the wrong account credentials. Never remove this escape hatch from the flow.
Login Page UX Best Practices
These twelve principles represent the current consensus on login page design, drawn from usability research, A/B test data, accessibility guidelines (WCAG 2.2), and security best practices. Apply them to any authentication wireframe.
On page load, the cursor should be placed in the email/username field automatically. Users shouldn't have to click to begin typing. This reduces the time-to-first-keystroke and removes a point of friction. Always auto-focus the first field, never the password field.
Placeholder text disappears when the user starts typing, leaving them unable to remember what the field required. Always use visible labels above input fields. Placeholders can be used as supplementary hints but should never replace labels. This is also an accessibility requirement.
A password visibility toggle on the right side of the password field is now considered a baseline usability requirement. Users making typos in a masked field is one of the most common causes of failed login attempts. The toggle should use a clear eye icon and include an accessible label for screen readers.
In a contained card layout, the primary CTA button should span the full card width. A wider button is easier to tap on mobile, creates a clear visual anchor for the call to action, and converts better than narrower buttons in A/B tests. Use a single, specific label: "Sign In" not "Submit".
When a field fails validation, show the error message directly below the relevant field — not in a banner at the top of the form. Field-level errors are faster to scan and easier to correct. Validate on blur (when the user leaves the field), not on keystroke, which can feel aggressive.
Never show "Invalid credentials" as a login error — it tells the user nothing actionable. Instead, use messages that guide: "That email address isn't registered. Did you mean to sign up?" or "Incorrect password. Try again or reset your password." Clarity converts users from confusion to successful login.
When the user submits the login form, the button should immediately show a loading state — a spinner, animated dots, or a "Signing in..." label. Without this, users often re-click the button, causing double submission attempts. Disable the button during the API call and restore it only on error.
Design your login form to be fully compatible with password managers (1Password, Bitwarden, browser autofill). This means using standard name attributes: name="email" and name="password". Avoid custom JS that prevents paste events — this breaks all password managers and is a security anti-pattern.
Login pages should have minimal navigation — hide the main nav menu, reduce the header to just the logo, and remove all sidebar content. The user's only job is to authenticate. Every distraction is an opportunity to abandon the flow. An exception: the app logo should link back to the homepage as an escape route.
If a user is redirected to the login page from a deep URL (e.g., after clicking a link in an email), store that intended destination and redirect them there after a successful login. Do not always redirect to /dashboard. This "redirect after login" pattern significantly improves perceived performance and reduces post-login navigation clicks.
After several failed password attempts, accounts should be temporarily locked to prevent brute-force attacks. The lockout screen should clearly explain: how long the lockout lasts, how the user can unlock the account (often via email), and include a direct link to account recovery. Never show a generic error page for this state.
New users who arrive at the login page need a clear, visible path to create an account. The "Don't have an account? Sign up" link should be present but visually subordinate to the sign-in flow. Placement below the primary button is optimal. The link copy should use the word "Sign up" rather than "Register" — it tests better across most demographics.
Common Login Page Wireframe Mistakes
These six mistakes appear regularly in login page wireframes across product teams. Identifying them early in the wireframe phase — before any code is written — saves significant rework.
Using placeholder text as the only label means the user loses context the moment they start typing. Once their cursor is in the password field, they can no longer see whether it said "Password" or "Current Password" or something else. This is also a WCAG 2.2 failure. Always use visible, persistent labels above fields.
Many wireframes show only the happy path. A complete login wireframe must also design error states: wrong password, account not found, account locked, rate limited, and network failure. These states are equally important to wireframe because they require copy, layout, and interaction design decisions that affect user trust.
A desktop login wireframe that hasn't been tested at 375px mobile width often breaks in predictable ways: two-column name fields become too narrow to tap, the CTA button doesn't fill available width, and the form extends below the viewport fold. Always create or review the mobile version of every auth wireframe.
Password recovery is a critical flow. "Forgot password?" should be immediately visible near the password field — not buried in fine print, not below the CTA button, not in a tooltip. Users who cannot quickly find the password reset link will generate support tickets or simply leave the app.
Authentication calls can take 200ms to 2 seconds depending on network conditions. A button that appears unresponsive during this time leads to double-clicks and duplicate API calls. Every login wireframe should include a button loading state annotation. Some teams use a separate loading-state frame or annotation callout.
Asking for phone number, company name, job title, team size, and use case on the initial sign-up screen dramatically increases abandonment. The wireframe for step 1 of registration should contain only what is strictly necessary to create an account. Additional profile information should be collected progressively — during onboarding, not at the account creation gate.
Mobile Login Wireframe Considerations
Fingerprint circle + Face ID square — system-level modal on native apps. Centred on screen for thumb reach.
"Use password instead" — always visible below biometric area for users who can't use biometrics.
Apple Pay style Sign In — fixed at bottom of screen, always in thumb reach zone on iPhone.
All tappable elements min 44px tall (Apple HIG). Annotate in wireframe for dev handoff.
Mobile authentication has its own set of UX requirements that differ meaningfully from desktop. Over 60% of web traffic is now mobile, and a significant percentage of SaaS products see higher mobile usage than their analytics dashboards suggest (because mobile users who have a poor experience are less likely to complete sign-up and be counted as active users at all).
Field sizing on mobile: Touch targets for input fields should be at least 44px tall (Apple HIG recommendation) and 48dp (Android Material Design). Most desktop wireframes show 36px inputs. When adapting for mobile, increase field height and ensure padding inside the field allows the user's thumb to tap accurately without accidentally activating the wrong element.
Keyboard type hints: In your mobile wireframe annotations, specify the input type for each field. Email fields should trigger the email keyboard (type="email"), which shows the @ symbol prominently. Password fields should use type="password". OTP/code fields should use inputmode="numeric" to show the numeric keyboard. These are wireframe-level decisions, not purely development concerns.
Biometric login: On native mobile apps (and increasingly on mobile web with the Web Authentication API), users expect the option to use Face ID or Touch ID after their first login. A mobile wireframe for a native app should include a biometric authentication prompt state — a system-level modal that appears when the user opens the app after their initial login.
Social login on mobile: On iOS, "Sign in with Apple" is required by App Store guidelines for any app that offers other social login options. If your wireframe shows Google and GitHub login buttons for a native iOS app, it must also show "Sign in with Apple" — failure to include it will result in App Store rejection. This is a wireframe-level decision because it affects layout and button order.
Autofill and SMS OTP: iOS and Android can automatically intercept SMS messages containing verification codes and fill them into OTP input fields. To enable this on mobile web, the input should use autocomplete="one-time-code". Annotate this in the mobile wireframe so developers implement it correctly.
Mobile login with biometric option and 44px touch targets
Login Method Preference by User Type
Understanding which login methods your target users prefer helps you prioritise your wireframe layout decisions. The data below is aggregated from industry surveys and auth provider analytics, segmented by user type.
Source: Aggregated from Auth0 Identity Report, Okta Business at Work, and UX surveys (2024–2025). Values are approximate and vary by industry vertical.
Frequently Asked Questions
-
A basic login page wireframe should include an email or username field, a password field with a show/hide toggle, a primary CTA button ("Sign In"), a forgot password link, an optional "Remember me" checkbox, and a link to the registration page. Social login buttons (Google, GitHub) are increasingly common as a secondary or primary auth method. For enterprise applications, consider adding a "Sign in with SSO" option for SAML/OIDC enterprise identity providers.
-
To wireframe an SSO flow, place social provider buttons (Google, GitHub, Microsoft, Apple) prominently at the top of the login card. Use a visual divider labeled "or" to separate social login from the email/password form below. Each button should show the provider logo placeholder and label. In your annotations, note that clicking a social button redirects to the provider's OAuth screen, then returns the user to your app. For enterprise SAML SSO, include a separate text input where users can enter their company email domain to trigger the correct identity provider redirect.
-
Multi-Factor Authentication (MFA) adds a second verification step after the user enters their password. In wireframes, MFA is typically shown as a second screen that appears after successful password entry. The screen contains a 6-digit code input (either a single field or 6 individual digit boxes), instructions telling the user where the code was sent (SMS or authenticator app), a resend link with a countdown timer, and an alternative method option (e.g., switch from SMS to authenticator app). Always wireframe the error state for incorrect codes and the locked-out state for too many failed attempts.
-
Generally no — combining both on a single page creates cognitive overload and increases form abandonment. Best practice is to have a focused login page with a prominent sign-up link, and a separate registration page. The exception is tab-switching interfaces, where a single card has Login/Register tabs at the top. This pattern works well for apps where new user acquisition is a primary goal and you want minimal navigation friction. However, extensive A/B testing has shown that separate dedicated pages outperform tab-switching in most contexts because each page can be more focused and less visually complex.
-
The most effective login page layout is a centered card on a neutral background. The card should contain the app logo or name at the top, followed by a concise heading ("Sign In"), the form fields, the primary CTA button spanning the full card width, secondary links (forgot password, sign up) below the button, and optional social login separated by a divider. The card width should be between 360–440px on desktop. This layout requires minimal adaptation for mobile — the card simply becomes full-width with 16px horizontal margins. Split-screen layouts (image on the left, form on the right) work well for marketing-forward products but require more complex responsive design handling.
Summary and Next Steps
A well-designed login page wireframe is one of the highest-ROI design deliverables your team can produce. Authentication flows appear in every single user session, so small improvements in UX quality compound into measurable conversion and retention gains. The five wireframe examples above — basic email/password, social-first, multi-step registration, password recovery, and two-factor authentication — cover the authentication patterns that appear in the vast majority of modern web and mobile products.
Use these examples as a starting point for your own wireframes. Copy the structural patterns, adapt the field arrangements to your specific data requirements, and annotate every design decision explicitly so your engineering team has clear implementation guidance. Pay particular attention to the error states and edge cases — the happy path is easy to design; the real UX work happens in the failure modes.
Explore More Wireframe Examples
See how login wireframes compare to other common UI patterns — from dashboard layouts to onboarding flows.
View All Examples Best Wireframing Tools
Social Login vs. Email/Password: When to Prioritise Which
One of the most consequential design decisions in a login wireframe is the relative priority of social login buttons versus the email/password form. There is no universal answer — the right choice depends on your product, your audience, and your technical capabilities. Here is a framework for making this decision.
For most modern consumer and SaaS products, a hybrid approach works best: social login options appear prominently at the top (with the most popular provider for your audience listed first), followed by a clear divider, followed by an email/password form for users who prefer or require it. This hybrid layout serves both audiences without forcing a choice that disadvantages either group.
The one case where you should not show social login at all is a regulated enterprise environment — healthcare (HIPAA), government (FedRAMP), or finance (SOC 2 Type II). In these contexts, IT administrators often prohibit personal OAuth accounts for company system access, and your login wireframe should reflect this by offering only email/password or enterprise SSO (SAML/OIDC) options.