Card Sorting

Menu names and categories used to come out of the heads of the people building the product, and those heads tend to be shaped like the org chart. When one team owns billing and another owns accounts, the menu splits into Billing and Accounts, and a customer who came to swap the company credit card opens both before finding it.

Meetings made it worse rather than better. One person wants things grouped by function, another wants them ordered by frequency of use, and since neither side has evidence the version that survives belongs to whoever outranks the other. A few months later the same support question arrives every week, but by then the screens are all built.

Card sorting moves that argument off taste and onto data. Instead of the team deciding on categories and then asking users whether they fit, users group things first and the categories get read out of what they did. That's why it sits early in information architecture work, which is the job of deciding how content gets divided, named, and connected.

Pick the items to put on cards, let participants group them however they want, and count how much those groupings overlap across people.

1. Choose the items. Write content the user is looking for, not screen names — not "Settings" but "Change payment method," "Download invoice," "Invite a teammate." Thirty to sixty cards is the usual range. Under twenty there isn't enough to group, and over eighty participants get tired and start dropping the later cards anywhere.
2. Choose the format. In an open sort, participants name the groups themselves. In a closed sort, the team supplies the group names and participants file cards into them. Open sorts suit building a structure from scratch; closed sorts suit deciding where new items belong in a menu that already exists.
3. Recruit. An open sort starts showing clear tendencies at around fifteen people. Who they are matters more than how many: they have to be people who would actually look for these items, so a study about admin settings needs people who have administered a team.
4. Run it. An online tool takes a participant about fifteen minutes and collects results automatically. Done in person, one participant at a time sorts while narrating why. That's slower, but it surfaces what numbers don't — which card someone held while hesitating, which label they read to mean something else entirely.
5. Count the overlap. Build a table of how often each pair of cards ended up in the same group. If "Download invoice" and "Change payment method" landed together for fourteen of fifteen people, they belong side by side. If the split is seven to eight, there is no agreed structure in that spot.
6. Name the groups. After an open sort, collect the names participants wrote down. If nine of fifteen wrote "Billing" while the team has been calling it "Payments," the thing that needs to change is the label in the menu, not the word users reach for.

The method pays off most before any screens are drawn, when there are many items and no agreement about how to divide them. If forty settings have piled up and the team is on its third meeting about how to split them, running the study once gets further than meeting a fourth time. It's also used when reworking an existing menu, usually as a closed sort that checks only where the new items fall.

Its biggest limitation is that it answers exactly one question. It tells you how users group things; it does not tell you whether they can find anything once grouped that way. Spreading forty cards on a table and sorting them is not the same act as reading five menu labels and picking one. So a structure built this way gets checked afterward with tree testing, and sometimes with a first click test, which shows a screen and records only where the first click lands.

Results are not always tidy, either. Sometimes participants group so differently that no pair clears fifty percent. That looks like a failed study, but it is also a finding: either the labels are vague enough to be read several ways, or an item genuinely belongs in two places at once. If it's the second, reaching the item from both places beats forcing one structure.

There's also no version of this where you copy the output straight into a menu. Users group by what is easy for them to find, not by what the company is pushing this quarter. The result is raw material; the final structure is that material plus business judgment.

"Let's run a card sort before we settle the settings menu."

Bring evidence instead of deciding this by opinion in a meeting.

"Closed sort this time. We're not changing the top-level groups."

Keep the groups fixed and only look at where new items land.

"The results are split. This card should probably live in both places."

There's no agreed home for it, so don't force it into one.

When Pagedeck reworked its settings screens, Noa built forty-two cards and ran them online with sixteen admins on paid plans. The clearest result was a grouping nobody on the team had predicted: "Invite a teammate" and "Change payment method" landed in the same group for twelve of the sixteen.

The team had them split across Members and Billing, but to an admin, adding people and paying more were one thing. Rather than merging the two menus, Noa put the new seat price directly into the invite screen, so the cost of adding someone shows up where the decision happens.

The most common expectation is that the study produces a menu structure. Tools present results as neat groups with names, so it looks ready to copy. But what the method yields is numbers about which items are close to which, not a finished menu. Deciding how many levels to use and what belongs on the first screen is still a human call. Copy the output literally and you get a settings screen with fourteen top-level groups sitting next to each other.

The other frequent mistake is assuming accuracy scales with participants. It's a study that produces numbers, so that feels right, but grouping tendencies mostly emerge by around fifteen people and flatten out after that. A hundred participants will not sharpen a vague label; they'll scatter across it just as widely. Time that would go into recruiting more people does more good spent rewriting the card labels, or running a second study such as a usability test that answers a different question altogether.