INFORMATION ARCHITECTURE · FOUNDATIONAL RESEARCH
Turning twelve card sorts into a platform's architecture
Several teams were building one platform in parallel, each guessing at how the pieces fit together. This study replaced the guesswork with evidence: a tested model of how users actually organize their work.
METHOD
Hybrid Card Sort
PARTICIPANTS
12 agents
CONTEXT
B2B enterprise platform
INSTRUMENT
31 Cards
01
THE PROBLEM
Several product teams were building the same platform in parallel, each designing its own area without a shared picture of how users moved between them.
02
MY ROLE
I was the sole researcher on this study and owned it end to end: writing the research plan, designing and building the sorting instrument in Figma (the team had no card-sorting tool at the time), recruiting participants, moderating all twelve sessions, running the analysis, and presenting findings to cross-functional teams and executive leadership.
03
RESEARCH QUESTIONS
How do users mentally organize the tasks, actions, and data that make up their day?
Where do they see connections between different parts of their work?
Where do they expect information to flow from one stage to the next?
04
APPROACH, AND WHY THIS METHOD
I chose a moderated hybrid card sort — participants group a set of provided cards into categories, and can rename categories or add their own.
Why hybrid, not closed?
A closed sort forces people into the categories the business already believes in and returns a tidy result that just confirms them. The whole value here was surfacing the parts of the model we hadn't anticipated, so the method had to let participants restructure the space themselves.
Why moderated?
The reasoning behind a placement mattered as much as the placement. Moderating let me ask “why did that go there?” in the moment — which is where the workflow logic and the connections between categories actually surfaced.
Neutral labels
Card labels were kept deliberately generic to avoid biasing placement. I used a plain term like “Data” in place of a loaded internal label, so participants weren't nudged toward the framing the business already held.
Varied sample
Twelve participants across different market backgrounds and experience levels. A homogeneous sample would have produced a model that fit only one kind of user.
05
HOW I ANALYZED IT
This is where twelve messy individual sorts became one defensible architecture. Getting from raw sorts to an architectural claim took two steps.
Illustrative reconstruction. Real category labels and values are abstracted; the technique is the point — clustering agreement across sessions separates a genuine pattern from one person's habit.
Step 1 - Acceptance matrices
I built matrices to find where participants agreed across sessions — which cards co-located into the same categories often enough to be a real pattern rather than one person's idiosyncrasy. This separated signal from noise and produced the categories users actually converged on, not the ones the business had assumed.
Step 2 - Relationship mapping
Agreement alone wasn't enough, because duplication could just mean the labels were ambiguous. So I mapped which data and tasks moved between which categories, and in what direction — turning a pile of duplicates into a picture of how information travelled through the work.
.png)
Illustrative reconstruction with generic stage names. The same data element appears at multiple stages and travels in a consistent direction — the signal that the model is a sequence, not a set of parallel buckets.
THE INFERENCE THAT MADE IT ARCHITECTURAL
Duplication alone could have meant unclear labels. What made it a structural finding was directionality — the same information moved through categories in a consistent order across participants. Users weren't confused about where things belonged. They were describing a lifecycle.
06
WHAT I FOUND
Users consistently described their work as a lifecycle, not a set of parallel buckets. A task that began in one context generated data and actions that fed directly into the next stage.
11/12
participants duplicated at least one card across multiple categories
3+
categories participants added themselves, all cross-cutting parts of the work
1 direction
data moved between stages consistently — sequential, not hierarchical
The concepts that got duplicated most were exactly the ones that carried information forward through the work — and the categories participants added were overarching, which is why they refused to sit in any single bucket.
07
RECOMMENDATION
Because users experienced their work as a connected sequence with data flowing between stages, an architecture built as isolated, parallel modules — roughly where the separate product teams were trending — would have fought the users' mental model at every step.
The recommendation was to structure the platform around the lifecycle and its data flows: connect the stages, and let information captured in one stage carry forward into the next rather than requiring re-entry or living in disconnected silos.
08
IMPACT
The findings became the evidence base for a core platform feature that carried users' data forward through their journey instead of making them re-enter it at each stage.
That feature shipped as part of the product, and later research run by a separate team found positive user satisfaction with it.
The larger outcome was a shared mental model. The parallel teams had been trying independently to work out how their areas should fit together. The research gave them one evidence-based answer — how users actually categorized their work, and where the connections were — that they could all design against.
09
WHAT I'D DO DIFFERENTLY
Sample composition
Over half my participants also held management-level roles, which pulled some answers toward a business view rather than a hands-on user's. A more balanced sample would let me weight those views more confidently.
Coverage
Some segments of the user base were only lightly represented. Broader recruitment would have tested whether the model held uniformly across all of them.
Quant confirmation
The duplication and data-flow findings were directional. I scoped a follow-up study specifically to validate those workflows at scale.
Stakeholder communication
I learned to build executive context earlier — bringing senior stakeholders along during fieldwork rather than at the final readout, so findings land with less friction.