Card sorting: discover how people organize their content

Organizing a menu based on company departments seems natural for those who work there. For the user, however, content might make sense by objective, moment, or problem. Card sorting helps investigate these relationships before transforming an internal structure into navigation.

Choose the modality according to the question

In open card sorting, participants create groups and their names. In closed, they receive predefined categories. Hybrid combines initial categories with the possibility of creating others.

In UXTap, all three modalities are available. Choose before setting up the cards and consider the effect of the provided categories on the activity.

If the team doesn't yet understand how the audience organizes the topic, open card sorting can help explore. If a proposal already exists, closed card sorting shows how the cards are distributed within it. To verify if people find a destination through a menu, also plan a tree testing.

Prepare cards that represent the content

Imagine a fictional help center for a delivery app. Cards can represent needs such as changing an address, tracking an order, disputing a charge, and recovering access.

Use a similar level of detail between them. Mixing “payments” with “how to change a card declined on the third attempt” creates an asymmetry that hinders grouping.

Avoid cards that already reveal the category name. Also, review words known only by the team. The participant should understand the topic without constant explanation.

Conduct an activity pilot

Before recruitment, ask someone outside the project to organize a small set. Observe if there are ambiguous, duplicated, or overly broad cards.

In UXTap, the order of cards can be shuffled, and there's a setting to allow “I don't know” responses. Use this option when it makes sense for the study, instead of forcing a classification that the person cannot sustain.

Add a question about the cards that were most difficult to place. The explanation might reveal that content belongs to more than one context.

Read the groupings without choosing only the most frequent

Consider which cards appear together and which vary between groups. In UXTap, matrices help examine these relationships; the dendrogram offers a visualization of groupings by similarity.

The design alone does not decide how many categories should exist. Compare the patterns with the content, audience objectives, and product constraints.

In the help center example, “dispute charge” might appear with payments or with order problems. Instead of treating a choice as wrong, investigate if the content needs to be accessible through more than one entry.

Transform categories into navigation language

The names created by participants are research material. Some might be long, overlapping, or unclear outside the activity's context.

Prepare an editorial proposal for labels and record what evidence supports it. Preserve important doubts: a group with a generic name might hide content that still needs organization.

Avoid consolidating categories just because their words are similar. Check what each person placed within them before considering that they represent the same idea.

Curate the cards before inviting people

Revisit the fictional delivery help center. An initial list might contain “change address”, “track order”, “dispute charge”, “recover access”, and “cancel order”. These cards represent needs. Adding a card called “Financial” to the same set mixes an organizational category with specific topics.

Review meaning duplications. “Change destination” and “change delivery address” might describe the same need; if they are different situations, make the difference understandable without an oral explanation. Avoid using synonyms as if they were distinct content just to increase the number of cards.

Document what was left out of the activity. Testing a part of the center does not validate the entire architecture. If the product has help for delivery drivers and customers, decide if these audiences share the same organization or need separate research. A coherent set makes choices interpretable.

Examine cards that cross categories

“Dispute charge” might appear near payment for one person and near an order problem for another. The productive question is what situation each grouping represents. Someone who just saw an undue amount might start with the order; someone checking an invoice might start with the financial area.

Record, per card, the most recurrent groupings, the names used, and the available justifications. Look for contextual differences before consolidating categories. Two categories called “problems” might have very different content. Two called “account” and “access” might represent similar sets, but should not be merged just because they seem alike.

The similarity matrix summarizes the co-occurrence of cards. It does not state that grouped content must necessarily occupy a single menu. A strong relationship might justify a contextual link, an aggregator page, or two entries for the same information. These are architectural hypotheses to evaluate later.

Conduct a synthesis workshop with visible evidence

Bring an initial proposal and the cases it poorly resolves to the team. Discuss ambiguous cards separately from stable groups. This organization prevents an exception from paralyzing the entire structure or the pursuit of simplicity from hiding an important need.

For each proposed category, record its purpose, included content, and examples that do not belong to it. If the description requires many exceptions, the name might be too broad. Compare the labels with the participants' vocabulary without automatically copying every expression used in the activity.

Prepare tasks for the next validation: locate instructions for disputing a charge, canceling a delivery, or recovering an account. The tree testing guide helps transform groupings into a navigable structure. Afterward, check this structure in the interface, where search, shortcuts, and visual elements also guide choices.

Validate the structure with a task

After designing the architecture, use tree testing to verify if someone finds content based on a need. Then, evaluate the menu in the product's visual context.

To begin, select a coherent set of content and set up a card sorting in UXTap. Review the vocabulary in the pilot and analyze both recurrent groupings and difficult cards. The next step should be a testable structure, with explicit hypotheses about where people will look.

After the groupings, prepare a tree testing and learn about information architecture resources to test the proposed structure.

Frequently asked questions about card sorting

Should the result become the menu exactly as it was grouped?

No. Groupings help understand perceived relationships between content. The final architecture also needs to consider tasks, content accessible through more than one path, and product constraints. Produce a research-backed proposal and test if people can find the necessary destinations.

How to deal with cards left in “I don't know”?

Read these cases before treating them as a lack of collaboration. The card might have unknown vocabulary, ambiguous meaning, or a weak relationship with the rest of the set. When explanations are available, use them to decide if the text needs revision or if the content belongs to another segment.

Should I start with open or closed?

Use the question to choose. Open allows exploring forms of organization without providing categories. Closed examines the distribution within categories you have already defined. When the question is about finding information in a hierarchy, consider tree testing, as grouping and navigating are different activities.

Create your UXTap account to prepare your first study.