Information architecture and navigation: card sorting and tree testing

Information architecture is the way a website’s content is grouped and labelled: which pages sit under which menu headings, and what those headings are called. When it’s wrong, people can’t find things that are plainly on the site, and they leave or phone you instead. Most small business sites grow their menus by accident, adding a page here and a section there, until the structure reflects the company’s org chart rather than how customers think.

Two research methods fix this cheaply. Card sorting shows you how customers would group your content. Tree testing checks whether a proposed menu works. This guide explains both, how to run them, and how to use them together.

Why menus go wrong

Teams name sections after their own departments and jargon. A training company may file courses under “Programmes”, “Academy” and “Learning solutions” because those are internal product lines, while a visitor is looking for “Courses for managers”. Visual design can’t rescue a structure like this. A beautiful mega menu with the wrong groupings is still the wrong groupings.

The fix is to learn the customer’s mental model (how they expect things to be organised) and build the menu around it, then test it before anyone designs a page.

Card sorting: learning how people group things

NN/g’s guide to card sorting sums it up in one line: participants place individually labelled cards into groups that make sense to them. Each card names a piece of content, such as “Delivery costs” or “Returns policy”.

There are three types:

• Open sort. Participants make their own groups and name them. This is the most common type and the best for discovering how people think about your content and the words they use.
• Closed sort. You supply the group names and participants place cards into them. NN/g notes that tree testing usually does this validation job better.
• Hybrid. Some groups are given, others created. NN/g generally advises against it, because the given groups can bias the results.

Practical settings from the same guide: use 30 to 50 cards, since more than 50 tires people and they start dumping cards into a “miscellaneous” pile. Ask participants to group first and name the groups afterwards. Remote tools such as OptimalSort analyse the results for you, while paper cards still work well in person.

On sample size, NN/g’s current guide suggests at least 15 participants for a qualitative sort and 30 to 50 for quantitative results. An older Jakob Nielsen article on how many users to test for card sorting explains where 15 comes from: in a study by Tullis and Wood, results from 15 people correlated at 0.90 with results from the full 168, while five people reached only 0.75.

Reading card sort results

The Wikipedia entry on card sorting sets out the standard analysis. A similarity matrix counts how often each pair of cards was placed together. High counts suggest content that belongs in the same section. Cluster analysis turns that matrix into a dendrogram, a tree diagram showing which cards group together at different levels of agreement. Look at the group names people invented too: they are a ready-made list of candidate menu labels in your customers’ own words.

Don’t copy the most common grouping straight into your menu. Use the patterns to draft a structure, then test it.

Tree testing: checking that the menu works

Tree testing is the evaluative partner to card sorting. In Page Laubheimer’s NN/g article on tree testing, participants see your proposed hierarchy as plain text menus and click through it to find where they would expect something to be. There are no visuals, no page content and no search box, so you test the structure and labels on their own. Wikipedia calls this reverse card sorting.

You need two things: the tree (every category and subcategory, usually entered as a spreadsheet into a tool such as Treejack) and a set of tasks. You mark the correct location for each task, and the tool reports:

• Success rate: how many people ended at the right place.
• Directness: whether they went straight there or backtracked, which NN/g links to how clear the labels are.
• Time on task: how long it took.

Task writing follows usability testing rules. Don’t use the category label in the task, keep the scenario short and realistic, and include an easy warm-up task first.

Using the two together

NN/g’s recommended sequence is to run a card sort to generate options, then tree test the resulting hierarchy before any content, design or coding begins. In NN/g’s broader map of research methods, both sit in the design stage, where the goal is to improve a design rather than measure a finished one.

1. Inventory. List the content that matters. Pick the 30 to 50 items customers most need.
2. Open card sort. Run it with at least 15 people who match your customers.
3. Draft. Turn the strongest clusters into a draft menu, using participants’ words for labels.
4. Tree test. Write eight to ten tasks covering the most important content and the labels you are least sure about.
5. Revise and retest. Fix the branches where people went wrong, then test again.

A worked example

An example (illustration only). A garden centre with a growing online shop has a menu with “Outdoor living”, “Garden care”, “Seasonal” and “Gifts”. Customers keep phoning to ask whether it sells compost.

The owner writes 40 cards, including “Compost”, “Bird feeders”, “Lawn seed”, “Christmas trees” and “Gift vouchers”. Twenty customers do an open sort online. Most put compost with lawn seed and plant food under groups they call “Feeding and soil” or “Lawn and soil”. Christmas trees and bird feeders rarely end up together, which suggests “Seasonal” means little to people.

The owner drafts a new tree with “Plants”, “Soil, feed and lawn”, “Tools”, “Garden furniture”, “Wildlife” and “Christmas”. A tree test with tasks such as “You want to improve a patchy lawn. Where would you look?” shows most people now find compost directly. One task, about outdoor lighting, still scatters across three branches, so that label gets reworked before the next round.

Common mistakes and when not to use these methods

• Using internal jargon on the cards, which teaches participants your vocabulary instead of revealing theirs.
• Including too many cards, so results end up shaped by tiredness.
• Treating card sort output as a finished menu instead of a draft.
• Writing tree test tasks that repeat a category name.
• Testing with staff, who already know where everything is.
• Skipping the retest after changes.

These methods are worth it when your site has enough content for structure to matter, roughly when a menu has more than one level, or when you are planning a redesign or migration. A five-page brochure site with Home, Services, About, Prices and Contact rarely needs a card sort. And neither method tells you how a finished page performs, so once the structure is settled, move on to usability testing of real pages.