First-click testing: how to test the first click

What is a first-click test

In a first-click test, participants get a screen and a task. They choose where they would click first to complete the task. You record whether that click leads to the right place.

The test looks at a single decision: does the person know where to start? It doesn’t measure the rest of the task.

The screen can be a design mockup or a live website. That is why the test can be used at almost any stage of design.

Why the first click matters so much

In short: people who start right complete the task much more often. The finding goes back to work by Bob Bailey and Cari Wolfson.

A 2023 MeasuringU article summarises it like this. Bailey and Wolfson ran a dozen studies between 2006 and 2009. When the first click was on the best path to the task, 87% completed the task in the end. When it was off, 46% did.

Context matters. Bailey and Wolfson didn’t use a click-test tool but analysed first clicks during tasks on working websites.

MeasuringU also checked the effect with its own data. Across five websites, 21 tasks and 750 participants, the difference was smaller: 78% success with a correct first click, 70% with a wrong one. One reason, according to the authors: for some tasks the best first click is hard to define.

In data from tree tests, the difference was very large. Across 137 tasks and 1,000 participants, 81% with a correct first choice completed the task, only 14% with a wrong one. The rates vary from study to study, but the direction holds: if the first step is right, the task gets done more often.

Live example: find the card statement

Below is the mobile home screen of a made-up bank. Your task: “Find your credit card statement.” Choose where you would click first, then press “Show result”.

Live first-click test

Task“Find your credit card statement.”

Where on the screen would you click first?

MenuExample BankInbox

Hi, Jana

My accountsChecking$2,435.00My cardsCredit card ending in 4821Current balance $612.04

TransferPay billsSend money

Recent activityGrocery store−$24.59Electric bill−$61.20Offers3 new offers for you

HomeAccountsPaymentsMore

Because JavaScript is off, your click isn’t recorded. The made-up result is below: the correct answer is the “My cards” card.

First click of 20 made-up participants

11 of 20 people clicked the correct area. First-click success rate: 55%.

1. My cards Correct11 ppl (55%)
2. Recent activity4 ppl (20%)
3. More2 ppl (10%)
4. Menu2 ppl (10%)
5. My accounts1 ppl (5%)

Nobody clicked other areas. The numbers are made up and don’t come from a real test.

Example Bank, the screen, the amounts and the distribution of the 20 participants are made up by me; it is not a real bank and not a real test. Click an area and then Show result. The number in an area is the number of people who clicked there first. The percentage is calculated from the made-up numbers of the areas.

In this demo, “My cards” is correct. In the made-up result, 11 of 20 people clicked there, so the first-click success rate is 55%. Four people went to “Recent activity”.

If I saw this distribution in a real test, I would ask: do users think the statement is part of the activity history? Then it is worth testing a link to the statement under “Recent activity”, or showing the word “Statement” on the “My cards” card.

When to use it

The first-click test helps when you want to know quickly whether a screen sends users in the right direction. Lyssna’s guide names these situations:

• Early design. Checking sketches, wireframes and prototypes before development.
• Before launch. A redesign, new feature or new app.
• After launch. Improving flows such as checkout, sign-up and onboarding.

The guide stresses one thing: with a new design, test the old one too. Only then do you see whether the change helps.

Does a test with images give the same result as the live website? MeasuringU checked this in 2023 with 130 participants on five home pages. The result: first clicks on images and on the live websites were similar.

The biggest reason for differences was elements missing from the image. Menus that open on hover lead the list, followed by layouts that change with screen width. If you test a screen with a dropdown menu as a single image, read the result with caution.

How to write the task

The quality of the test depends on the quality of the task. Jeff Sauro recommends writing tasks as scenarios, as in a usability test. The person should think about how to solve a problem, not about where to click.

Lyssna’s guide also advises writing the task in the users’ language, not the interface’s. The same need, worded differently:

Task	Problem
“Click My cards.”	Gives away the answer; the test measures nothing.
“Find some information.”	Too vague; the person doesn’t know what to look for.
“Go to the Statements menu.”	Uses the interface’s language and hints at a menu.
“You want to see which purchases make up what you owe on your credit card this month.”	Describes a real need and repeats no words from the screen.

The task in the demo is short, and the word “card” is also on the screen. In a real test I would use the version from the last row of the table, which describes the need.

Sauro also advises settling the correct paths in advance. Define all or most of the paths from the home page to the task. If the statement can be reached both through “My cards” and through the menu, you can count both as correct.

Which metrics count

First-click success rate. This is the main metric. You divide the number of people who clicked correctly by the number of all participants. If 11 of 20 are correct, the rate is 55%.

Don’t confuse this rate with the task success rate. The first click is only the first step.

Time to first click. Sauro counts task time among the most sensitive metrics. According to him, long times and large differences between participants point to a navigation problem.

Lyssna’s guide calls this the “3-second rule”: if someone needs longer than 3 seconds to click, there is a findability problem. I don’t read this threshold as a fixed rule but as a signal to interpret by screen.

Click distribution. If clicks cluster in one place, users’ expectation is clear. According to Lyssna, scattered clicks point to confusion. Clicks on non-clickable elements show that expectation and interface don’t match. Most tools draw this distribution as a heatmap.

Confidence and difficulty. Sauro asks two questions after each task: how confident is the person that they found the right place, and how hard was the task? Both are asked on a 7-point scale. Most answers Sauro gets are 6 and 7; the occasional 3 and 4 point to navigation problems.

How many participants you need

Lyssna’s guide usually recommends 15–30 participants for reliable results. For an early concept, 8–12 people may already show big problems. For business-critical changes it recommends 25–30 people.

The guide also advises reading the results of new and experienced users separately. A long-time bank customer knows the menu by heart; a new customer doesn’t. My general view on sample size is in the guide how many users to test.

The difference from tree tests and five-second tests

These three methods are short and often confused. The difference lies in what you show participants and what you ask.

Method	What the person sees	What is measured
First-click test	A designed screen	Whether the first click for the task leads to the right place
Tree test	Only a text menu tree	Whether content is found in the menu structure
Five-second test	The screen for 5 seconds, then it is hidden	What the screen conveys at first glance

The tree test removes images and layout. It helps tell whether the problem lies in the labels or the structure. The first-click test asks the same question in the design. A label that does well in a tree test can get lost under a promo image in the design.

The five-second test looks at understanding, not action. Lyssna’s distinction sums it up well: the five-second test shows what a screen conveys at first glance. The first-click test shows whether users can act on that understanding.

None of these tests measures whether the task succeeds from start to finish. Lyssna names this limit too: the first-click test doesn’t confirm that the task gets done. It doesn’t catch problems with forms or with understanding content either. For that you need a usability test.

Step by step

1. Choose the screen you want to test: home page, app home screen or a menu.
2. Write tasks from your users’ most common activities. Each describes a need.
3. Mark the correct areas for each task in advance. If there are several correct paths, note them all.
4. As Lyssna recommends, also include a task whose answer isn’t on the screen. That way you spot random clicking.
5. If you compare two designs, alternate the order. Sauro shows half the participants the old design first and the other half the new design first.
6. Record the click, time and confidence score. Ask for the reason when scores are low.
7. Read the results task by task: first the rate, then the time, and last the distribution.

As tools, Sauro names MUiQ and Chalkmark. A tool isn’t a must: you can record the session and note the clicks by hand.

My note

I use the first-click test most often at the start of a redesign. I test the existing screen once and note the rates. When I test the new design with the same tasks, I have a point of comparison.

The most common mistake I see: the task is written with the label from the screen. If a test asks “Go to My cards”, almost everyone clicks correctly and the test teaches nothing. Write the task first without looking at the screen, and compare afterwards.

If you aren’t sure whether your home screen sends users to the right place, I can look at your screen and one flow in the UX audit.