Before you launch or pay for traffic
Login page checklist: five returning-user checks
A login page fails people who already have an account, which makes it an expensive page to get wrong. This checklist follows a returning user from the first field to the first screen inside.
What should a login page checklist cover?
Cover the fields a returning user touches first: the email, the password and the sign-in button, on a phone with the keyboard open. Then check the reset link, the error for a wrong password and the page a user lands on after signing in. A simulated visitor signs in with a test account you give it, and reports where it stopped, with a screenshot of the error it saw.
What this looks like in a report
“I typed my address with a capital D on my phone, and the page says it does not recognize me. I signed up with it. Either I typed it wrong or the account is gone.”
The fix. Trim spaces and lowercase the email before it is checked, and show one generic message for a wrong email or password. Then sign in from a phone with the address typed by hand, once with a capital letter and once without, and confirm both reach the dashboard.
An illustration. Run a test to see your own.See a real sample report
The returning user fails before they see the product
A person with an account is not new to the product, but they arrive with a password saved in another app, a phone keyboard that capitalizes the first letter of their address, and a reset email that may have landed in spam. The login page fails each of them in a different way. The field rejects a capital letter, the password manager fills the wrong box, or the error says the address is unknown, which tells a stranger whether they have an account. The owner signs in every day from the same browser, so the login always works where they stand.
- Email field: does an address with a capital letter sign in from a phone keyboard?
- Password manager: does autofill fill both boxes, and does the button stay enabled?
- Wrong password: does the error stay generic, without saying the address is unknown?
- Reset link: does the email arrive, and does its link open a page to set a new password?
- After sign in: does the user land on the page they asked for, not back on the form?
Mobile keyboards change what the field receives
A phone keyboard can capitalize the first letter of an address or add a space after it. A field that checks the address strictly will reject a correct login that the owner only ever typed on a laptop. The fix is to trim spaces and lowercase the address before checking it, and to set the input types and autocomplete values so a password manager fills the email box and the password box it expects. The tell is simple. Type your own address with a capital letter on a phone. If sign-in fails there and works on your laptop, the field is the fault, not the password.
The error message tells people whether they have an account
An error that reads No account for this address tells anyone who tries a random address whether the site knows them. The clearer version is one message for both cases: The email or password is not right. Compare the two by signing in with a real address and a wrong password, then with an address you never used. If the messages differ, the page is telling strangers who has an account. The run shows that message as a screenshot at the step where it appeared.
A reset email has to reach an inbox and open a page
The password reset is the path a returning user takes after a long gap, and it has three parts that can each fail. The email must arrive, the link must open a page that asks for a new password, and the new password must sign in without a second error. Check the link's expiry by waiting as long as your own policy allows, then clicking it. A reset normally sends an email only to an address that has an account, so a simulated visitor needs a test account you give it, which needs paid credits. Then the run can follow the email and report what the link opens.
What you get with Mimiq
- 01
Run it by hand, or on every pull request
Paste a link and a task in the app and watch the visitors work. Or run them on every preview deploy: the GitHub Action comments on the pull request, any other CI can call the MCP endpoint, and your coding agent can run it too.
- 02
Bugs and usability problems in one report
The browser records errors and failed or slow requests on the step they happened. The visitors say where the wording or the steps confused them, and where they left.
- 03
Visitors that behave like your audience
Each visitor is a different profile with a reason to be there, matched to who the page is for, described by you, or built from your own customers.
- 04
A prompt to fix each problem
Every problem comes with a fix to paste into Cursor, Claude Code, Lovable or any coding agent, and one prompt hands over the top problems at once. Then send the same visitors through again.
- 05
Follow every visitor
See each visitor's whole path, step by step with screenshots, and what it was thinking at every step. Ask any visitor a question.
The browser records relevant JavaScript errors and failed or slow app requests encountered during the run, attached to the step where they occurred. The visitors are simulated: they find problems, they do not predict how many real people will convert.
A session change or a new sign-in method can send a returning user back to the form
Login pages change when an app adds a sign-in method, moves a session setting or adds a second step. Each change can loop a returning user back to the form after they type the right password. Run the sign-in and reset path again after each change, with a test account, before the change reaches everyone.
Starter
Try it on one launch
About 4 tests of 5 visitors
- Visitors on your landing page, signup and checkout
- Where they left and why, with a fix to copy for each problem
- Run it in the app or on every pull request
- Ask any visitor a question, included
- Test accounts and protected previews
Builder
Test every build
About 20 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Pro
Test every release, as a team
About 60 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Cancel anytime
Scale
Test at scale, every day
About 240 tests of 5 visitors
- Everything in Starter
- Credits refill each month, and what is left rolls over once
- Priority support
- Cancel anytime
Questions
Can a simulated visitor sign in to my app?
Only with a test account you give it, which needs paid credits. Without one, the run stops at the sign-in form and shows that step as where the visitor stopped. Use a test account that is not a real customer's account, and never give a visitor a real password.
Do I need to test on a phone if the login works on my laptop?
Yes. The keyboard, the autofill prompt and the screen width change what the field receives. A login that works from your laptop's saved password can fail for a stranger who types the address by hand on a phone.
Does this checklist cover security?
No. It does not replace a security review, a penetration test or a review of how you store passwords. It shows what a user sees at each step of signing in and resetting a password, which is the part a stranger meets first.
Will a test tell me how many people cannot sign in?
No. It does not predict failed sign-ins across your users, or how many of them leave. Failure counts come from your app's own logs. The run shows the form, the message and the step where a visitor gave up, which is what you need to fix the page.
Keep reading
Send visitors and see what breaks first.
Your first test is free: sign in with Google and it starts right away. Last checked 2026-11-02.