Most navigation problems aren't really navigation problems. They're labelling problems, or structure problems, or both. Card sorting is one of the most useful tools for diagnosing which one you're dealing with, but only if you use it correctly.

Used well, it will tell you things about your users' mental models that no analytics dashboard ever could. Used badly, it produces an unreadable mess and the misplaced confidence that you've done your research.

Card sorting is a research method for grouping and labelling information. You give participants a set of cards, each labelled with a piece of content or a concept, and ask them to organise those cards in a way that makes sense to them.

The output tells you how real people think about your content, what they'd group together, and what they'd call things. That's genuinely valuable when you're designing or redesigning the structure of a website, app, or service.

It's not a silver bullet. It's one tool in a set, and knowing when to reach for it matters as much as knowing how to run it.

In an open sort, participants create their own categories. They group the cards however feels logical to them, then label each group with a name that feels meaningful.

This is the right approach when you're starting from scratch, or when you genuinely don't know how your users think about your content. The goal is to surface structure and language that comes from your users rather than from your internal assumptions.

It's also useful early in a design process for understanding the language your stakeholders use, building a glossary of terms, and identifying jargon you'll need to test further before it ends up in your navigation.

In a closed sort, you provide the category labels. Participants sort the cards under the categories you've defined.

This is the right approach when you already have a proposed structure and want to test whether the labels resonate. You're not asking people to invent the categories. You're asking whether the ones you've chosen make sense.

It's a more targeted test, and it's most useful once you have something concrete to validate.

If you're fixing something that's already broken, a card sort can help you pinpoint whether the problem is structure, labelling, or both. Running a sort that mirrors your current navigation tells you whether people would group your content the way you currently have it organised. Divergence from your existing structure is diagnostic information.

Use this alongside interviews and usability testing. A card sort alone won't tell you why something isn't working. Combined with other methods, it can tell you a great deal.

After prototype testing surfaces a labelling problem, a focused card sort can help you resolve it. Rather than rearchitecting everything, you can test specific labels in isolation and find the language that actually works for your users.

If you're building a new product or section and don't have existing data to work from, an open sort gives you a starting point grounded in user logic rather than internal assumptions.

Here's the bit that often gets left out.

Card sorting does not work when participants aren't subject matter experts in what they're sorting.

Account sections of apps are a classic example. Terms like billing cycle, payment method, and subscription tier require prior knowledge to sort meaningfully. If your participants don't have that knowledge, they'll make arbitrary groupings, give those groups unhelpful labels, and you'll have data that looks like research but tells you very little.

The same applies to any content that introduces new concepts, uses unavoidable technical language, or assumes domain knowledge your users don't yet have.

In those situations, you need an information architect or navigation design specialist working alongside a subject matter expert. The structure and the language have to come from people who understand both the content and the user. A card sort won't do that work for you.

Card sorting is a tool for listening. It tells you how people understand what you've built, or what you're planning to build. That's valuable precisely because internal teams almost always have too much context to see their own structure clearly.

But listening to the wrong people, or asking questions the method can't answer, produces noise rather than signal.

Use it at the right moment, with the right participants, as part of a broader research approach. That's when it earns its place.

Murmuration helps digital teams design navigation and labels that actually work for users. Get in touch if you'd like to talk through what a diagnostic might look like for your site.