How can card sorting improve your information architecture?

You build a product, you organise the content in a way that feels logical, and then real users arrive and cannot find anything. The navigation makes sense to your team because your team built it. The labels feel obvious to the people who chose them. The groupings reflect how the business thinks about its own content, not how a first-time visitor thinks about what they need. This gap between internal logic and user expectation is one of the oldest problems in digital product design, and card sorting is one of the most direct ways to measure it.

Card sorting surfaces the mental models users bring to a product before they have been trained by your interface.

Card sorting is a research method that asks real users to organise content into groups that feel natural to them. That sounds deceptively simple. What it actually does is surface the mental models people bring to your product before they have been trained by your interface. And those mental models are often quite different from the ones your team assumed.

The method is useful at any scale, from a ten-page website to a large document portal with hundreds of content types. The principles stay consistent throughout: stop guessing how users think, and start finding out.

What is card sorting?

Card sorting works by writing individual pieces of content, features, or topics onto separate cards, one item per card, and then asking participants to group them in whatever way makes sense to them. In a physical session, these are literal cards on a table. In a remote study, they are items on a digital screen that participants drag into groups. Either format works. The important thing is that the participant does the organising, not the researcher.

Once participants have created their groups, they are usually asked to give each group a name. These names matter as much as the groupings themselves. They reveal the language users reach for naturally, which is rarely the same language the product team uses internally.

What the method measures

Card sorting measures two things simultaneously. First, it shows which items users see as belonging together, giving you a picture of their mental model for your content. Second, it shows which items no one agrees on, which is often more useful. An item that lands in five different groups across twenty participants is a content problem, a label problem, or a category problem, and it needs resolving before you build anything around it.

When to run it

The best time to run card sorting is before your information architecture is finalised, so the findings can shape structural decisions rather than confirm ones already made. It also has value after a redesign when navigation complaints emerge, or before a significant content expansion where new material needs to sit somewhere sensible.

Open, closed, and hybrid card sorting: which to use when

There are three formats, and choosing the right one depends on where you are in the design process.

Open card sorting gives participants blank cards and asks them to create their own groups from scratch, name those groups, and decide how many groups to make. This format is generative. It tells you how users naturally categorise your content without imposing any structure. Run it early, when you are building an information architecture for the first time or rethinking one substantially.

Closed card sorting gives participants a fixed set of pre-labelled categories and asks them to sort content cards into those categories. This format is evaluative. It tests whether an existing structure works. Run it when you have a proposed navigation and want to know whether users can match content to the categories you have chosen.

Hybrid as a middle ground

Hybrid card sorting combines both. Participants sort into existing categories but can also create new ones if nothing fits. This works well when you have a partial structure that needs pressure-testing, or when you want to evaluate existing categories while remaining open to discovering gaps.

What card sorting reveals that other methods miss

Analytics will tell you where users drop off. Heatmaps will show you where they click. Neither tells you why a navigation felt wrong in the first place. Card sorting operates upstream of both, at the point where a user forms an expectation and either finds it confirmed or does not.

One of the things it reliably surfaces is label mismatch. A team might label a section "Resources" when users expect "Guides", or call something "Solutions" when users are looking for "Services". These are not trivial word choices. When the label on a navigation item does not match the word a user searched for mentally, they often conclude the content they need does not exist, and they leave.

When the navigation label does not match the word a user searched for mentally, they often conclude the content does not exist.

Card sorting also reveals boundary problems, the places where two categories blur and users are genuinely unsure which one to look under. A charity website might have content that fits both "Our Work" and "Impact". A healthcare platform might have content that sits uncomfortably between "Conditions" and "Treatments". These ambiguities look obvious once card sorting data shows the pattern, but they are nearly invisible when you are too close to your own content.

The method also shows disagreement between user groups. If younger users sort content one way and older users sort it a completely different way, that is a signal worth designing for, not averaging out.

When you write your cards, use language your users would recognise, not your internal product terminology. If the card labels are already confusing, the grouping data will reflect that confusion rather than genuine mental model differences.

How card sorting data shapes your information architecture

The raw output of a card sort is a matrix: participants across one axis, cards across the other, and group assignments in the cells. This is useful but not yet actionable. The step between data and decisions requires looking for patterns across the whole dataset, not just the most common single grouping.

Similarity matrices show how often any two cards were placed in the same group across all participants. Cards that appear together frequently share a perceived relationship in users' minds. Cards that rarely appear together are seen as distinct. This information gives you the skeleton of a user-driven architecture, which you can then refine against practical constraints like content volume and navigation depth.

Group labels as navigation language

The names participants give to their groups are often the most immediately useful part of the output. When twelve out of fifteen participants use the word "Help" rather than "Support", that is a data point about your navigation labels, not just a curiosity. Product teams frequently name categories using internal jargon or aspirational brand language. Users name them using the word they would type into a search bar. The two are often not the same.

Identifying outliers and anomalies

Cards that participants consistently struggle to place, or that land in entirely different groups depending on the participant, point to either ambiguous content or a labelling problem at the card level. These items need a decision before you commit to a structure. Sometimes the right answer is splitting one piece of content into two clearer ones. Sometimes it is rewriting the label so the content's purpose becomes self-evident.

When assumptions about content grouping go wrong

Teams that skip card sorting often discover the cost of that decision further down the line, when structure is already built and users are already confused. The assumption that content groupings are self-evident is one of the most persistent errors in product design, and it compounds quickly. One misplaced category affects every piece of content inside it.

On a project we ran for a document portal serving the film industry, the user base was broad: directors, production assistants, finance teams, legal departments, and on-set crew all needed to find different things quickly. The structure had been designed around the document type, which made sense from a filing perspective. But users were navigating by project and then by need, not by document type. They were looking for "what I need for this shoot" and finding "contracts", "call sheets", "clearances" all in separate silos they had to know to look for individually.

We redesigned the architecture around the user's workflow rather than the document taxonomy. The content was identical. The structure changed entirely. Navigation time dropped and support requests about "where to find things" fell away almost immediately after launch.

Before finalising any category structure, ask this: are these categories organised around how the business produces content, or around how users go looking for it? The answer to that question predicts whether card sorting will confirm your structure or overturn it.

Running a card sorting study: participants, cards, and moderation

A card sorting study does not require a large sample to produce useful patterns. For most products, fifteen to twenty participants from the target user group will reveal the main grouping patterns clearly. Adding more participants beyond that point tends to reinforce what you already found rather than surface new insights, though it can be worth doing if you need to compare distinct user groups rather than treating users as a single population.

The cards themselves need care. Aim for between thirty and sixty items. Fewer than twenty and you will not see enough grouping behaviour to identify patterns. More than eighty and participants become fatigued and start making arbitrary decisions just to get through the task, which contaminates the data. Write each card label clearly and concisely, as a phrase rather than a sentence, and avoid labels that already imply a category.

Moderated versus unmoderated

Moderated sessions let you ask follow-up questions. When a participant puts two seemingly unrelated items together, you can ask why. That reasoning is often more valuable than the grouping itself. Unmoderated remote studies scale more easily and are less expensive to run, but you lose the ability to probe. For exploratory work or ambiguous content, moderated sessions pay for themselves.

Remote delivery considerations

Remote card sorting tools handle the data collection automatically and produce similarity matrices from the raw sort data without manual calculation. The tradeoff is reduced ability to observe hesitation, backtracking, or facial reactions that signal genuine uncertainty. Where possible, running even a small number of moderated sessions alongside a larger unmoderated study gives you both depth and scale.

Analysing card sorting results

The analysis phase is where card sorting data becomes architectural direction. Start with the similarity matrix, which shows the percentage of participants who placed each pair of cards in the same group. Pairs with high co-occurrence are strong candidates for being in the same category. Pairs with near-zero co-occurrence belong in different categories and should not be grouped together regardless of how logical it seemed before the study.

Dendrograms, which are branching diagrams that cluster items by similarity, give you a visual picture of how the content naturally organises itself at different levels of grouping. At a high level of clustering, broad categories emerge. At finer levels, subcategories appear. This gives you a starting point for both top-level navigation and second-level organisation within each section.

Reading the disagreement data

Low agreement scores are often more useful than high ones. An item where participants split almost evenly across two categories tells you the content sits on a conceptual boundary. That boundary is the thing you need to design around: either place the item in both categories, split it into two distinct pieces of content, or rename it so clearly that the ambiguity disappears.

Analysing the group names participants created in open card sorts gives you a second data layer on top of the grouping behaviour. If the words users choose differ from your current navigation labels, that is a signal that users are arriving at your product with a different vocabulary than the one your team uses, and your navigation needs to meet them where they are.

Turning card sorting findings into structural decisions

Card sorting outputs do not automatically become an information architecture. They provide the evidence. The decisions that follow require you to weigh user mental models against content volume, technical constraints, business priorities, and the practical realities of navigation depth. The aim is a structure that reflects how users think while remaining buildable and maintainable.

Start with the high-confidence groupings, the clusters where most participants agreed. These become your primary categories. Then work through the ambiguous items, the ones that split across groups, and make a deliberate call on each one rather than defaulting to what seemed obvious before the study. Every ambiguous item is a decision point. Leaving it in a category that only half your participants associated it with is a known source of future navigation failure.

Resolving conflicts with business requirements

Occasionally the structure users suggest is in tension with business requirements. A travel company might find that users group holiday types by destination but the business needs to surface promotional packages by price point. The resolution is to design an architecture that accommodates both, perhaps with a primary structure that follows user mental models and a secondary filtering or discovery mechanism that serves the business goal.

Skipping discovery on a dating app we worked on, specifically around the messaging component, cost roughly £15,000 in additional budget and two months of additional work to rewrite that section from scratch. The architecture had been built on assumptions that the research would have corrected early. Card sorting is cheap relative to that kind of rework. The research cost is almost always smaller than the cost of building the wrong thing.

Validating your architecture after card sorting

Card sorting tells you how users group content. It does not tell you whether users can navigate the structure you built from that data. The follow-on method for that is tree testing, sometimes called reverse card sorting. In a tree test, participants are given a text-only version of your proposed navigation structure and asked to find specific items by clicking through the categories. No visual design, no search, just the hierarchy itself.

Tree testing reveals whether the categories you created are findable in practice. A category might have a label users would choose when grouping content, but still fail to communicate clearly enough to work as a navigation destination. The difference between "what users would call this group" and "what users would click on to find this content" is subtle but real, and tree testing is the right tool for measuring it.

Iteration between methods

1. Run open card sorting to discover natural groupings and user vocabulary.
2. Build a proposed architecture based on the findings.
3. Run tree testing on the proposed structure to check findability.
4. Revise any categories or labels where findability scores are low.
5. Run a second round of tree testing if changes were substantial.

This sequence turns what could be a single research event into a feedback loop that produces an architecture you can be confident in before a single line of code is written. The cost of both studies combined is almost always lower than the cost of a post-launch redesign prompted by user complaints about navigation.

Tree testing works best when the tasks you give participants reflect real things real users need to do, not tasks that conveniently route through the parts of the architecture you feel confident about. Write tasks from user goals, not from your navigation structure.

Conclusion

Information architecture problems are invisible until users start failing. At that point, the structure is usually already built, already tested, and already launched. Card sorting is what you do to surface those problems before that point, when fixing them costs time rather than time and money and user trust.

The method is direct. You ask real users to organise real content and you look at what they do. The patterns that emerge reflect mental models your team could not have invented from the inside, because the inside view is always shaped by familiarity with your own product. Users arrive without that familiarity, and their sorting behaviour captures that fresh perspective in a form you can actually analyse.

The work that follows, building a structure from the data, resolving ambiguous groupings, testing the resulting hierarchy, and aligning user mental models with business needs, is where the real decisions get made. Card sorting does not make those decisions for you. It gives you the evidence to make them well rather than by assumption.

Used alongside tree testing and other research methods, card sorting sits at the foundation of a user-centred approach to structure. And structure, in any digital product, is what determines whether users can find what they came for. Everything else depends on that.

Let's talk about your information architecture

Frequently Asked Questions