Before you launch or pay for traffic

Website checklist for design: check the live look

A design can look right in the mockup and still bury the button once real headlines, photos and a cookie banner arrive. Simulated visitors walk the new look at its real content and show where they stop.

5 visitors try to .
First test free with an accountRun it from your coding agent

What should I check in a new website design before it replaces the current site?

Check the design with the copy, photos and pages it will really carry, on a phone and a laptop, at the address a visitor will use. The mockup usually shows short headlines, one photo per section and no cookie banner, so those are the first things to change. A simulated test loads the new design the way a visitor would and shows the step where each one stops, with a screenshot of what they saw.

What this looks like in a report

Who
Ruth, looking for a joiner to build a kitchen island
How they arrived
Opened the new homepage from a search for local joiners, on her phone
Where they stopped
Hero section, after the first scroll

“The headline is big, but the button sits under a gray strip that looks like a cookie notice. I would scroll back up for a phone number. I will try the joiner with the cleaner site.”

The fix. Move the primary button above the first scroll on a phone, and make the cookie banner a thin bar that does not cover it. Test the first screen with the longest real headline, then compare it with the mockup.

An illustration. Run a test to see your own.See a real sample report

The mockup has the short headline, and the site has the long one

A design review usually happens in the tool where the design was drawn, with the designer's sample text and a screen the designer chose. Headlines are shorter there, product names fit on one line, and the hero photo is the one that looked best. Once the real content goes in, a three-word heading wraps onto two lines, a button drops below the fold and a sticky header covers the first sentence of the body. A stranger on a phone meets that version, not the mockup.

  • Headline and button at the length of the real copy, not the sample text
  • Hero photo at the size the server sends, on a phone, with the text still readable
  • Empty states: a blog with no posts, a shop with one product, a gallery with three photos
  • A sticky header, chat bubble or cookie banner covering the first call to action
  • Fonts that swap in after load: does the first screen move once the page settles?

The longest real headline decides the first screen

Designers set type sizes against a sample headline of a few words. The real page has a description of the service, a town name and a promise that runs to two lines. The layout was built for the short version, so the extra words push the button down the screen or squeeze it into a narrow column. Open the new design with the longest headline you will publish, on a phone at its normal width. Count the words above the first button. If the button sits below the first scroll on a phone, the headline is pushing the one action a visitor needs out of view.

Check the same thing on the laptop. A wide screen hides the problem because the headline has room to sit on one line, and the owner tends to judge the page from the laptop they designed it on. Then turn the phone to portrait, where the headline wraps the most. That is the width to judge the first screen by, not the one in the design tool.

Photos, fonts and the banner arrive in an order the mockup skipped

A mockup is a still image, so it never shows the moment a page is still loading. Photos arrive after the text, a web font replaces a system font a moment later, and a cookie banner slides up from the bottom. Each one moves something on the screen. A button that sat in one spot in the design can drop a line when the font swaps, and a visitor who has already aimed a tap at it can land on the wrong link. Throttle the connection in a laptop browser, reload the home page and watch the first screen for the first few seconds, not only the finished page.

Empty states and short lists the mockup never shows

A design shows three blog posts, five products and a gallery that all match. A product grid laid out for rows of three looks fine with six items and breaks with one: the single card stretches across the row, or it sits alone at the left with an empty column beside it. A team page with two people keeps its heading and grid, and the blank space makes the page look unfinished. Make a copy of the site with each list cut to one item and then to none, and open every page at a phone width. A stranger who lands on an empty blog reads the empty heading as the main content of the page.

What you get with Mimiq

  1. 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.

  2. 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.

  3. 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.

  4. 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.

  5. 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 new photo or font can push the button below the first screen again

Live sites keep changing after a redesign: a new hero photo, a holiday banner, a different font file, a longer product name. Each one can move the button a visitor needs. After any change to the first screen, run the same walk on the live address at the real content lengths, and compare where the visitors stop. Pages behind a login need a test account, and the walk should run again before each new ad or campaign.

Starter

Try it on one launch

$9 once
120 credits, never expire

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
Buy 120 credits

Builder

Test every build

$19 a month
500 credits every month

About 20 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Cancel anytime
Choose Builder

Pro

Test every release, as a team

$49 a month
1,500 credits every month

About 60 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Cancel anytime
Choose Pro

Scale

Test at scale, every day

$149 a month
6,000 credits every month

About 240 tests of 5 visitors

  • Everything in Starter
  • Credits refill each month, and what is left rolls over once
  • Priority support
  • Cancel anytime
Choose Scale
$0for your first test, with a free account (Google sign-in, no card). It includes 50 credits, enough for 10 visitors. After that a visitor uses 5 credits, and packs start at $9 for 120 credits.
See a sample report

Questions

Do I need a designer to run this checklist?

No. The checklist uses what the owner can see: the headline, the button, the photos and the lists. A designer will catch spacing and type problems that a visitor never mentions, so run both on the same live address.

Can a simulated test tell me whether the design looks good?

No. It shows whether a visitor can find the next step, where they stop and what the page showed them at that step, with a screenshot. It does not predict how many visitors will sign up, and it does not judge taste.

Should I test before or after the final copy is in?

After, and again after every copy change. A design tested with sample text only proves the layout of the sample, so the first real headline can break it. Test once with the draft copy, then again when the final text and photos are in place.

Which pages should I check first?

The home page, the product or service page that gets the most visits, the contact or order page and one empty list. Check each at a phone width and a laptop width, since a layout can hold on one and fail on the other.

Does the test check my brand colors and fonts?

It shows what the visitor saw at each step, in a screenshot, so you can judge whether the button and the text are visible on that screen. It does not run a contrast check, and it cannot tell you whether the colors match your brand guide or whether a font is the one you chose.

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.

5 visitors try to .