Activity Card Sort Assessment

How to Run an Activity Card Sort Assessment Without Losing Your Mind

You hand someone a stack of printed cards, ask them to group activities they might do on your product or service, and hope the result tells you how to structure the navigation. That's basically it. The messy part is the execution. I learned this the hard way on a healthcare portal project. We were mapping patient self-service workflows, and the Activity Card Sort Assessment produced exactly the chaos you'd expect. Participants kept putting "schedule appointment" and "reschedule appointment" in different piles even though they're essentially the same task with a different verb. Our dev team was ready to build two separate navigation paths. I had to stop the project, go back, and rewrite those cards to include disambiguation notes on the reverse side like "creating a new booking" versus "changing an existing booking." That fixed it. But it cost us three days and a frustrated product manager who had already started talking to engineering about scope. The method itself is straightforward enough that most people underestimate it. You write each activity as a single action on an index card or digital equivalent. Activities should be verb-noun phrases: "submit expense report," "download receipt," "cancel subscription." Keep them to one activity per card. No compound tasks. Then you give the participant the full deck and ask them to group the cards however makes sense to them. They label each group themselves. You don't provide categories upfront unless you're doing a closed sort, which is a different conversation entirely.

When to Actually Use Activity Card Sort Assessment

This method works best when you're building or restructuring a product from scratch and genuinely don't know how users conceptualize the work they need to get done. It's also useful when you suspect your internal jargon doesn't match what your users say out loud. If your support team keeps hearing "I want to pause my account" and your UI says "deactivate subscription," that gap shows up clearly in the sorts. It does not work well if you already have a reasonably functional information architecture. In that case, tree testing or first-click testing will give you more actionable data for a fraction of the effort. I've seen teams run activity sorts on mature products and then try to redesign the navigation based on results that just confirmed what was already there with slightly different wording. The number of participants matters more than most guides admit. Fifteen to twenty is the minimum for stable patterns. Below that, you're seeing individual idiosyncrasies rather than shared mental models. Above twenty-five, you start hitting diminishing returns unless you're specifically looking for edge-case behaviors. I usually run twelve to fifteen in the core round and then bring in three or four more if the first batch shows clear ambiguity in how certain activities cluster.

Recording the process is non-negotiable. Even with a solid video setup, you'll miss things. I keep a second person taking notes on verbal comments and body language during the sort. People will say "hmm, this feels like it goes with that one" and then put it elsewhere. That tension between what they say and what they do is where the useful insights hide. Video alone won't capture it. Analysis is where most teams stumble. You'll end up with a bunch of photos showing how different people grouped the same set of cards. The manual approach is to print all the sort photos and lay them side by side on a wall. It sounds primitive and it is. It also works better than any software for spotting patterns because your brain processes visual clusters faster than spreadsheets. Once you've done the visual pass, you can move the data into a tool like OptimalSort or SPSS to generate a similarity matrix and dendrogram. The matrix will show you which activities people consistently grouped together across participants. The dendrogram visualizes the hierarchy that emerged from those groupings. Here's a detail people overlook: the order in which you present the cards matters. I used to shuffle them randomly and assumed that neutralized bias. It doesn't. First-card placement creates an anchor. Participants tend to define their first category around whichever card they happen to pick up first, and everything else gets sorted relative to that. My workaround is to run the sort twice with the same participant. First round: free sort, any grouping. Second round: re-sort the same cards into exactly three groups. The tension between the two rounds reveals which categories are robust and which are just noise. That second pass usually takes five to eight minutes extra per participant but surfaces structural problems that a single sort misses entirely.

The biggest failure mode is when participants treat the activity cards like features rather than tasks. This happens especially with B2B products where users have strong professional mental models. They'll sort "generate monthly invoice" and "process monthly invoice" into different categories because in their head those are two different departments' work. What you actually need to understand is how the system should expose these functions to the user. I deal with this by adding a brief framing prompt before the sort starts: "Think about what you personally would need to do, not what your team or company does." It doesn't eliminate the problem but it reduces it noticeably. Another trap is over-indexing on the category labels participants create. Those labels are informative but secondary. The actual structure — which activities cluster together — is what determines your navigation architecture. I've seen teams build entire information architectures around a clever category name that happened to appear in four out of twelve sorts, then wonder why users got lost. The label is a nice-to-have for naming conventions. The clustering is the signal. Time investment for a proper session runs about forty-five minutes per participant including setup, the sort itself, and a brief debrief where you ask why they placed certain cards together. Preparation — writing the cards, printing them, setting up the space or digital tool — takes roughly three to four hours for a deck of thirty to fifty activities. Analysis of a fifteen-participant study takes about six to eight hours if you're doing it manually with the wall method plus software validation. Budget accordingly or the study gets rushed and the data becomes unusable.

There are situations where this method simply doesn't apply. Highly regulated industries with strict compliance workflows benefit more from contextual inquiry and task analysis than from card sorts. If your users can't deviate from a prescribed sequence of steps, you're not discovering mental models, you're documenting regulatory requirements. A compliance audit will serve you better there. Similarly, if your product has fewer than ten core activities, the sort will be too small to reveal meaningful patterns and you're better off doing a simple stakeholder interview. The Activity Card Sort Assessment is a real tool, not a magic bullet. It reveals how people think about work, and that's valuable when you're designing for unknown territory. It's expensive, it requires careful preparation, and it produces ambiguous results if you don't know what questions to ask during debrief. Use it when you need to understand task mental models before building structure. Don't use it when you already have enough information to make design decisions.