Web Login Page Design: States, Tools and a Review Checklist

A web login page should help people access an account and recover when something goes wrong. Start with the supported authentication methods and required states, then design the visual layout. A polished mockup does not implement authentication or establish that a service is secure.

Browse login-related community resources for visual starting points. Check each resource’s screen type and contents; the examples later in this guide include mobile flows and a dashboard, not three complete web login templates.

1. Define the login states before the layout

Agree on account access and recovery requirements with the product and engineering team. Map each state to a screen or component variant, including the action that moves a user to the next state.

• Ready: persistent field labels, supported sign-in methods and a clear primary action.
• Submitting: visible progress and a way to prevent accidental duplicate submission.
• Invalid or incomplete input: a text explanation beside the affected field and a clear next step.
• Authentication failed: wording agreed with the security team so it does not unnecessarily disclose account information.
• Recovery: password reset or the recovery route appropriate to the chosen authentication method.
• Additional verification: instructions, expiry and retry behavior for any supported second step.
• Service or network problem: explain whether the user can retry and what information is retained.

A lock icon or security badge is not a security control. Use only accurate assurances, link to the applicable privacy information, and have engineers implement and review the authentication system.

2. Review the web and mobile behavior

The original login resource can help you discuss field grouping. Validate the implemented form using keyboard, touch, zoom and assistive technology; a canvas preview cannot verify all of those behaviors.

1. Keep labels visible after typing. Provide input purpose and password-manager support in implementation; do not rely on placeholder text as the only label.
2. Tab through the form in a logical order and check that focus stays visible, including when an on-screen keyboard is open.
3. Test long localized labels and error messages at narrow widths. Allow content to reflow without hiding the submit or recovery controls.
4. Use words as well as color for errors. Ensure messages can be associated with the affected inputs.
5. Load the form before decorative media where possible. Measure on the actual mobile route and network rather than promise instant loading.
6. Review contrast, target size, focus and accessible authentication using the WCAG 2.2 reference. Record the applicable criteria and outstanding implementation issues.

3. Choose a tool for the states and handoff you need

Compare tools using the same login-flow file. Free plans, trials and open-source licenses have different conditions; none is a blanket promise of free hosting, unlimited collaboration or secure production code.

Pixso

Use Pixso for shared UI design, prototype review and developer inspection. Create component variants for ready, loading and error states, then check the team’s permissions and current plan limits. Generated or inspected properties still need application implementation and testing.

Adobe XD

Adobe XD supports interface design, prototypes and cloud-document co-editing. Adobe states that XD is in maintenance mode. For an established XD project, confirm current account access and required resources; consider product status before choosing a new long-term workflow. See Adobe XD support.

Sketch

Sketch is a Mac design app with browser-based viewing, commenting and inspection. Real-time co-editing uses a shared Workspace, compatible Mac app versions and an active subscription. Check the current trial and license terms; do not assume a free trial is a permanent team plan.

Penpot

Penpot is an open-source design platform with browser-based workflows. Compare the hosted offering with self-hosting, including plan features, infrastructure, maintenance and backups. Open-source software does not make every deployment or hosted feature cost-free.

Lunacy

Lunacy supports desktop design on Windows, macOS and Linux, with local files and cloud documents. Its cloud-document documentation describes collaboration and sharing. Check the current history and access limits, then test the same login-flow file.

4. Adapt the available resources to a web login task

The resources below illustrate different parts of a product. Inspect their actual layers and interactions before reuse. Their visual appearance does not establish a working authentication flow or production accessibility.

Mobile registration screens: a flow reference

The first resource contains mobile registration and sign-in layouts, with examples of social sign-on, phone fields and verification inputs. Use it to identify states. For a web version, redesign the responsive container, keyboard order, browser autofill and recovery route instead of simply stretching the phone frame.

Open the mobile registration resource

YoFit: a mobile login and sign-up starting point

YoFit shows a wellness-oriented mobile welcome, login and sign-up flow. Its illustration and field grouping can inform a visual direction. Add the error, loading, recovery and wider-screen states your web product needs; verify resource permissions before reuse.

Open the YoFit mobile resource

Project and leads dashboard: the destination after sign-in

This dark dashboard resource illustrates project and lead-management screens. It is not a login-page template. Use it to check visual continuity between account access and the signed-in destination, while designing the missing authentication states separately. A chart or notification shown in a design is not evidence of a working live-data feature.

Open the project and leads dashboard resource

5. Questions to resolve before developer handoff

Does a passkey flow remove every recovery problem?

No. Specify the authentication methods your product supports and the recovery route when a device, credential or email link is unavailable. Review the complete flow with the engineering team instead of deleting password fields from a mockup and treating the work as finished.

How should bot or abuse protection appear?

Define the risk and challenge policy with the security team. Design understandable challenge, retry and recovery states, and evaluate accessibility. A UI template cannot determine the right detection system or guarantee protection.

What should the handoff include?

Provide state variants, transitions, field labels, error copy, responsive behavior and unresolved questions. Link to the relevant requirements and test the implemented form with realistic success and failure cases. Measure completion and failure rates before claiming a conversion improvement.