Tree Testing

Menu names and groupings usually get decided from the inside of the company outward. Putting "change payment method" in the same group as "plan and pricing" feels obvious internally, because one team owns billing and that team handles both. The customer, who knows nothing about how the company is organized, goes looking under "my account" for something called "payment."

The trouble was that this mismatch only surfaced late. Build all the screens, run a usability test — sitting with people while they attempt real tasks and watching where they stall — and you will certainly see participants fail to find the setting. What you cannot see is why. The label might be unfamiliar, the text might be too small, or the menu item might be tucked into the bottom right of the screen. All three explanations arrive tangled together in one observation.

By that point the fix is also expensive. Moving one level of the menu means reworking the titles and navigation paths of the twenty screens underneath it. This is where a team decides to postpone a restructure it already knows is wrong until next quarter, and next quarter it is twenty-five screens.

Tree testing inverts the order. Nothing is drawn. The menu labels are laid out as a collapsed list, and you measure whether people reach the right destination reading names only. It puts the information architecture — the skeleton that decides how content is divided, what each part is called, and where it lives — on the test bench before any of it is expensive to move.

Write out the menu structure as text, give participants a task, and have them drill down through that list to the place they think the answer lives.

1. Write the structure as text. One to three levels deep is typical. No screens, no icons, no search box. All a participant sees is a collapsed list, and clicking one item expands what sits under it.
2. Write the tasks. Keeping the answer's own words out of the question is nearly the whole job at this step. "Find the plan and pricing page" has already given the answer away. "Your company card has changed and you need to replace the card used for payment — where would you go?" tests whether the label does its work. Six to ten tasks is the usual range.
3. Recruit participants. This is a quantitative study read as percentages, so aim for 30 to 50 people. Dedicated online tools handle the mechanics, and once recruiting is done, collection takes about two days.
4. Run it. Participants expand their way down the list and can back out upward when a branch looks wrong. Those backtracking events turn out to be the most useful thing in the dataset.
5. Read three numbers per task: the share who landed on the correct item, the share who got there without backing out even once, and the distribution of which top-level item people opened first.

Reading the three together narrows down what is actually broken. Suppose the card-replacement task has a 41 percent success rate but only 18 percent got there directly. That means more than half the people who succeeded wandered first. Add in a first-click distribution piled up on "settings" and the problem is not the label on the correct item — it is that "settings" is carrying too much.

It fits when no screens exist yet, or when you are about to change a structure that does. Because it needs nothing drawn, it is one of the few studies available during planning rather than after.

It is especially worth the effort when comparing a before and an after. Build one version of the current structure and one of the proposed structure, run each with a different group, and you can put the two success rates side by side. "Forty percent to seventy-two percent" is an argument for a restructure that you can make before anyone opens a design tool.

Three limits are worth knowing.

1. Do not read the absolute success rate as your product's success rate. The real screen has a search box, a recent-documents list, and helper text, so real users do better than these numbers suggest. The figure is a relative one, good for comparing structures against each other.
2. It only examines names and hierarchy. Whether that menu item is visually noticeable, or hidden behind a collapsed panel, is outside what the method can see.
3. Participants scan the list top to bottom, which makes them more thorough than real users. A real user clicks the third plausible thing.

"Let's tree test before we draw anything. If we rename things after the screens exist, that's twenty files to touch again."

Validate the structure while changing it is still cheap.

"The payment task came in at 41 percent, and first clicks piled up on settings."

The diagnosis is the neighboring label pulling people away, not the label on the destination.

"Tree testing won't tell you that. We need to know whether it stands out on the page, so let's do a first click test."

Separating a naming problem from a visual one, and switching instruments accordingly.

At Pagedeck, Noa ran this study before reorganizing the document permissions menu. She built two versions, the current structure and the proposed one, and sent eight tasks to 40 admins on paid plans. Mia's only involvement was reading the task wording to check that none of the answers had leaked into the questions.

What changed first was not the structure but two labels. The proposed version did score higher, but both versions lost about half of participants on the sharing task. The item both versions named identically was the thing at fault, so the rename shipped ahead of the restructure.

The most common mistake is assuming five participants is enough. Usability testing has a well-known rule of thumb that five people surface most of the serious problems, and it migrates over naturally. But tree testing does not produce observations, it produces percentages. With eight participants each person moves the result by 12 points, so a 37 percent and a 50 percent are the same finding. Deciding a structure on that is following coincidence rather than evidence.

The second mistake is concluding straight away that a low success rate means the structure is wrong. The number looks clean, so it feels like a verdict. But there are three reasons a task scores low: the label is unfamiliar, the task was worded in language real users never use, or the item would be equally reasonable in either of two branches. In that third case renaming things never lifts the score, and putting the same item in both places is the correct answer. Without the first-click distribution you cannot tell the three apart, so you end up renaming labels in a loop.