First Click Test

Decisions about menu placement were an argument about taste for a long time. Two people would spend half an hour defending their instincts about whether export belongs in the top bar or inside the document menu, and the louder voice won. A month later the support tickets would arrive and settle it the expensive way.

It wasn't that no method existed. A usability test shows exactly where people get stuck. It also costs an hour per participant and two weeks of recruiting. That's a price worth paying for a whole new flow, and not a price anyone pays to place a single menu item. So the small decisions went unchecked, and enough of them piled up to bend the information architecture (IA) out of shape.

The first click test cuts that cost by shrinking what gets measured. It doesn't watch whether someone completes the task. It watches one click. That turns out to be worth something because of a consistent observation: people whose first click lands in the right place succeed at the task far more often than people whose first click doesn't. A wrong first step often doesn't get walked back, so the first click carries a lot of information about everything after it.

Start by writing the task. There are six steps.

1. Write the task as one sentence. "You want to change the company payment card. Where would you click?" states a goal and no method. "Find billing under settings" has already given away the answer.
2. Prepare a single screen. It doesn't have to be finished; a wireframe is enough. Make sure clicking does nothing. If a second screen loads, this is no longer a study of the first click.
3. Define the correct region in advance. Skip this and you end up deciding what counts as correct after seeing the results, which blurs what the study was for. There can be more than one correct region — if the top menu and the sidebar both lead to the same place, both count.
4. Recruit participants. This study reads a proportion, so five people won't do; 30 or more is the usual target. Thirty is enough to tell a 40 percent hit rate from an 80 percent one.
5. Run it, capturing click position and time to click. The tool collects the coordinates.
6. Read two numbers: the share of people who clicked the correct region, and how long they took. Time separates two designs that score the same on accuracy by showing which one causes less hesitation.

The more useful half of the reading is where the wrong clicks went, not the hit rate itself. If 60 percent of the misses land in one spot, the label sitting there reads to users like the thing they were looking for, and the fix is immediate. If the misses scatter across the whole screen, no single label is at fault — the screen as a whole is giving no cues, and the layout needs rework. The two findings call for different amounts of work, which is why the distribution matters more than the average.

The fit is narrow and clear: a screen exists, and you want to know whether it says at a glance where to go. It earns the most when choosing among two or three design options, especially when the team has already argued about them once. Running the same task with the same number of people and comparing hit rates turns a taste argument into a number comparison, and results land within days.

Three situations call for something else.

First, when you want to know why people clicked where they did. This is quantitative research, so no reasons come back with the numbers. A low hit rate says the label fails; it doesn't say what people thought the label meant. When reasons matter, add a handful of moderated tests where someone can ask follow-up questions.

Second, when the flow runs across several screens. Measuring only the first click means everything past screen one is invisible. A flow where the first click is right and everyone abandons on the third screen looks fine in this study.

Third, when the grouping itself is in question. If you're still deciding how menu items should be organized, there's no screen yet, and card sorting — letting users group the items themselves — comes first. A first click test confirms a layout; it doesn't produce one.

"Let's run both options through a first click test and decide. Two days."

Moving a decision made on taste onto numbers.

"A 38 percent hit rate means this label doesn't work."

A verdict that the menu name fails to convey its purpose.

"Every miss went to the profile icon. People think account settings live there."

Reading a user expectation out of where the wrong clicks clustered.

At Pagedeck, Noa reached for this during an admin screen redesign. Whether team invites belonged in the top navigation or inside workspace settings had gone through two meetings without a decision. Noa built two wireframes and ran each with 40 people on a single task: "you want to invite a new teammate."

The top-bar version scored 71 percent, the settings version 34. That part was expected. What wasn't: half the misses on the settings version landed on the members icon in the top bar. That's where people look first for invites, so Noa took the top-bar version and moved the invite button next to that icon. The second round scored 89 percent. A decision two meetings couldn't close was done in three days.

A high hit rate gets read as proof the screen is well designed. A big number looking like good news is an easy assumption to make. But the study measured one first click on one task. A screen that scores 89 percent for finding invites may score 20 percent for finding billing details. Read one task's score as the screen's score and the other tasks' problems get waved past unchecked.

The other mistake is treating a wrong first click as a failed task. Plenty of people hit back, try again, and finish. The observation this method rests on isn't that a wrong first click guarantees failure — it's that success rates drop sharply. A 60 percent hit rate should not be written down as 40 percent task failure. When the real success rate is the question, run a study that lets people finish.