Card Sorting and Tree Testing: Cheap Research That Prevents Expensive Mistakes

Early in the redesign of a client's internal knowledge base, an enterprise software tool used by thousands of support agents, we skipped formal card sorting because the internal stakeholders were confident they knew how content should be grouped, having worked with the taxonomy for years. We built the new navigation structure around their mental model and shipped it. Within two weeks, ticket resolution time had actually gotten worse, not better, and support agents were filing complaints that they couldn't find articles they used to find easily.

We went back and ran the card sort we'd skipped, this time with actual frontline agents rather than the managers who'd originally specified the structure. The results were strikingly different from the stakeholder-driven structure we'd shipped: agents grouped content by the customer problem they were solving, not by the internal product-team taxonomy the original stakeholders used day to day. The people closest to the org chart had, unsurprisingly, organized information around the org chart.

Tree testing after that became a standard gate before we touch navigation on any project, not an optional nice-to-have. It's cheap, a task-based test against a text-only outline of the proposed structure, no visual design needed, and it catches structural problems before a single screen gets built, when fixing them costs an afternoon of relabeling rather than a sprint of rework.

The specific failure we watch for now is a structure that tests fine with five categories but falls apart once real content volume is loaded into it. On the knowledge base project, a category called 'Account Issues' tested well as a label with a handful of sample articles, but once all 340 real articles were sorted into the live structure, that category became an unusable dumping ground. We now stress-test proposed structures with realistic content volume, not a curated sample.

The broader case for this kind of research isn't that it's sophisticated, it's that it's disproportionately cheap relative to the cost of getting information architecture wrong after launch. A rebuilt navigation structure six months post-launch means retraining users who've already formed habits around the wrong structure, which is a much harder problem than getting it right before anyone's muscle memory sets in.