Landing page best practices: the first screen

Landing page advice usually lists parts: a headline, a subhead, a button, some proof and a form. A stranger does not read the page as a list. They read the first screen in a fixed order, asking what the product is, whether it is for them and what to do next. If the headline describes how the company feels about its work, the visitor has no product to check, and the button asks them to commit to something they cannot name. A page can be well designed and still fail that order. The fault shows up as a short scroll and a quick exit, not as an error.

• The headline names the product and the kind of buyer in plain words.
• The main button names the next step, not a vague phrase such as learn more.
• The proof is something the visitor can check, such as the product screen itself.
• The form asks only for what the button promised, with the rest after sign-up.
• On a phone, the headline, the button and the first proof all sit on one screen.

A headline does one job on a landing page: it says what the thing is and roughly who it is for. A wrong version is Work better together, a line that could sit on any product page. A right version is Shared calendars for dental offices, which names the thing and the buyer. Check your headline by covering the rest of the page and asking a friend what it sells. If they guess a category you do not serve, rewrite the headline before you touch the color of the button. Keep it short enough to read on a phone without wrapping to four lines.

A button label should say what happens after the click, in the visitor's words. Learn more sends the visitor to another page of claims, and they have to read again to find out what they get. A wrong version places a Get started button under a headline the visitor cannot yet understand. A right version reads Start the free trial, with one line beneath it that says what the trial includes. The button should open the sign-up form on the first tap, not a page that needs a second click.

Landing page testing

Visitors skim past proof they cannot check. A line that reads Loved by teams everywhere has no name, no product and no screen. A right version shows the screen the buyer will actually use, with a caption that says what it does, such as the booking view a receptionist opens each morning. Put it within the first two screens, next to the button it supports. If a real customer has agreed to be named, use their name and role, and check that the words still match what they said.

A form placed high on the page often asks for more than the visitor expects. A wrong version asks for a name, a company, a phone number and a team size before the visitor has seen the product. A right version asks for the one thing the button promised, an email address, and collects the rest after the account exists. On a phone, check that each field opens the right keyboard, that the submit button stays above the keyboard, and that an error sits beside its field.

On a phone, hold the page at its normal width and read the headline, the image and the button in that order, then scroll once. A banner over the button, or a hero image taller than the screen, pushes the button out of the first view. The image may be a stock photo that says nothing about the product. Look for each of these on the first screen only, then check the second screen as well. A page that holds its order across both screens is ready for a simulated visitor, and a page that does not will show the stop in the report.

Best-practice changes come in batches. Each change can push the button below the first screen or change the words the visitor expected. Run the same first-time visitors through the page after each batch, and read the step where each one stopped. A members area behind a login needs a test account, and a preview copy can be checked before the change reaches the public address.