Lesson 23 of 30

Card Sorting & IA Research Methods

Q: A stakeholder wants to skip research and go straight to designing the navigation for a new product area, since "the team already knows how it should be organized." How would you respond, and what would you actually propose doing first?

A strong answer covers: Distinguish open card sorting (generating categories from users, run early) from closed card sorting (validating an existing structure); Describe tree testing as a complementary method that tests findability in an already-built hierarchy, independent of visual design; Make the case that both methods replace gut-feel structural decisions with evidence, the same way the rest of the track replaces gut-feel visual decisions with falsifiable checks.

Two cheap research methods answer a question visual design can't: does the structure itself make sense, independent of color, icons, or wording. Skipping straight to a polished nav design without them is designing the label before checking the shelf.

11 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

After running an open card sort with 20 participants, each participant used somewhat different words for their groups. What's the correct way to find the useful signal in the results?

Look for which cards recur together in the same group across many participants, regardless of the specific label each person usedDiscard the results, since disagreement on labels means the card sort failed to produce useful dataPick whichever single participant's grouping and labeling seems most thoughtful and use that as the final structure

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on Card Sorting & IA Research Methods

What interviewers actually ask about this, and what a strong answer has to cover.

A stakeholder wants to skip research and go straight to designing the navigation for a new product area, since "the team already knows how it should be organized." How would you respond, and what would you actually propose doing first?

A strong answer covers

Distinguish open card sorting (generating categories from users, run early) from closed card sorting (validating an existing structure)
Describe tree testing as a complementary method that tests findability in an already-built hierarchy, independent of visual design
Make the case that both methods replace gut-feel structural decisions with evidence, the same way the rest of the track replaces gut-feel visual decisions with falsifiable checks

Likely follow-ups

If you only had budget for one of these methods on a product that already has a shipped, underperforming navigation, which would you run and why?
How would you synthesize open card sort results from 20 participants who all used somewhat different words for similar groupings?

Practice these with the AI interviewer →

The plain-language idea

Card sorting and tree testing validate the structure of a product's navigation or information architecture, deliberately stripped of every visual detail — no colors, no icons, no styling — so the result is about the structure itself, not how appealingly it's presented.

Open card sorting hands participants a set of unlabeled cards (each naming one piece of content or one feature) and asks them to group the cards into categories they invent, then name each group themselves. Run early, before any structure exists, it reveals how people naturally think the domain should be organized — the categories and labels come from users, not from a team's internal mental model of the product.

Closed card sorting uses the same cards, but the categories already exist — participants place each card into whichever predefined bucket it seems to fit best. This validates (or breaks) a structure that's already been proposed, so it belongs later in the process, once a candidate information architecture exists to test.

Tree testing is the complementary check, and it asks a different question entirely: not "how would you group this" but "given an already-built hierarchy, can you find item X inside it." A participant navigates a bare, text-only tree — clicking through category labels with zero visual design — to where they believe an item lives. It isolates whether the structure is findable, independent of visual polish, catching a real failure mode a good-looking page can't fix: a well-designed page sitting inside the wrong branch of the navigation is still lost.

See it in a real thing: what the raw results actually look like

Participant 3 grouped:
  "Refund a payment" + "View past orders" + "Cancel a subscription"  →  "Billing"
  "Change email" + "Reset password" + "Two-factor setup"             →  "Account & Security"

No individual participant's exact wording is the useful signal — the value is in the pattern across many participants: which cards keep landing in the same group together, regardless of what any one person calls that group. A tree test produces a different, more directly measurable kind of result:

Task: "Find where you'd go to cancel a subscription."
72% of participants succeeded.
Of those who failed, most navigated into "Account & Security" first.

That's a concrete, structural finding, independent of any visual redesign — it says the label or branch placement is misleading people toward a plausible-but-wrong path, something no amount of icon or color work on the existing structure would fix. This is the research that should inform an information architecture's category structure and navigation labels before those get built and styled, rather than adjusting them after the fact based on gut feeling.

What people usually miss

Watch out

Running an open card sort too late wastes its main value. Its job is to shape the categories in the first place — run after a structure is already decided, it can only rubber-stamp or mildly critique something that's already fixed, not genuinely inform it.
Open versus closed isn't "better" versus "worse" — it's a sequencing decision tied to how much structure already exists: open when nothing's proposed yet, closed when something is and needs validating.
Tree testing's stripped-down, text-only presentation is a deliberate feature, not a limitation — removing visual design is exactly what isolates whether the structure is findable, independent of every other variable a polished UI would introduce.
Card-sort results need real synthesis, not eyeballing one participant's result. The useful signal is which cards recur together across many different people, even when their individual labels for that group differ.
This replaces gut-feel navigation decisions with falsifiable evidence, the same throughline the rest of this track argues for spacing, contrast, and type — a hierarchy that "feels obviously right" to the team building it is still a hypothesis, not a validated structure, until it's tested.

Why this matters in interviews

"How would you validate a proposed navigation structure before it's built?" is testing whether a candidate knows structural research methods exist that are independent of visual design — and can distinguish them from usability testing on an already-built UI, which tests something different (can users operate the interface) rather than whether the underlying structure itself makes sense.