Merging Two Data Sites Around the Survey
CBHSQ / SAMHSA — reuniting a scattered experience by reorganizing around what people came to do, not which site owned the content.
Snapshot
Role: Information architect and design lead (at ICF)— I devised the merge approach and led the design of the new data-tools site
Client: Center for Behavioral Health Statistics and Quality (CBHSQ), SAMHSA
The problem space: Two established sites, two audiences, one set of surveys split across both
Method: A hand-coded (11ty) wireframe prototype to reason through and communicate the merge
Year: 2026
Live: samhsa.gov/data/data-we-collect → datatools.samhsa.gov
The short version
Information about each survey was scattered across two separate sites, so the people who needed it kept traveling back and forth and losing their place. I reorganized the content around a simple question — did you come to understand this survey, or to analyze its data? — and rebuilt each survey's page as a self-contained home for everything you'd read, with a clean handoff to a dedicated tools site for everything you'd run. I worked the merge out in a coded wireframe prototype so stakeholders could see the new structure before anyone committed to it, and I led the design of the new tools site. The model is still live today.
Context
CBHSQ is SAMHSA's statistical arm — the source of the nation's behavioral-health survey data. That data reached the public through two separate web properties, each built for a different audience:
The data site (on the SAMHSA domain) served researchers. It took the surveys and their reports and explained them — what each study measured, what the findings meant.
SAMHDA served statisticians — people who needed to work the data directly, with tools to build their own custom reports.
Two real audiences, two genuinely different jobs: understand the findings versus run the numbers yourself.
The challenge
The trouble was that any single survey lived in both places. Its explanation and reports sat on one site; its data and tools sat on the other. A person holds a survey in their head as one thing — but the experience scattered it across two homes with different navigation and different logic. So people traveled back and forth between the sites looking for the piece they needed, and got lost in the gap between them.
The split wasn't wrong because it existed. It was wrong because it was drawn along the organizational line — which site owned the content — instead of along the line that actually mattered to a user: what they came to do.
My approach
I re-drew the boundary around intent.
Each survey's page became a self-contained home — a mini-site holding everything you need to understand that study: its purpose, its methodology, and its reports, all in one place, no site-hopping. Then, for the people who came to analyze rather than read, each collection offers a clean handoff out to a dedicated data-tools site, built just for the tooling. Read here; build there. The back-and-forth disappears, because the separation is now intentional and legible instead of accidental.
I worked this out in a coded wireframe prototype, not a slide deck. A merge is almost impossible to argue in the abstract — stakeholders need to move through the proposed structure to believe it. The prototype let everyone walk the new flows, see where a given survey would finally live, and react to something concrete before a line of production code was written.
And I led the team that designed the new data-tools site the model hands off to.
What I built
I focused on the largest collection, the smallest collection, and then collections that had unusual patterns to prove out my design.
A survey-as-mini-site model: each collection (NSDUH, TEDS, MH-CLD, N-SUMHSS, DAWN, and the rest) became one consolidated home for its information and reports.
A clear read-here / analyze-there split: collection pages for understanding; a dedicated tools site for analysis, reached by a deliberate in-context handoff from each collection that has a tool.
Design leadership on the new tools site — the destination that now houses the Data Analysis System and the rest of the interactive tooling.
The coded wireframe prototype that made the whole reorganization reviewable before the build.
Why a coded prototype
The flat comps were the tell. When a client can't see the vision in static screens, that's not a failure of the comps — it's information about the problem. Some ideas only become real once you can move through them, and a merge is one of them. So the code became the decision artifact: instead of debating where content should go in the abstract, where people argue about words, stakeholders could walk the actual structure and feel whether it held. It also gave the production team a working reference to build from, not a spec to interpret.
The judgment I carried out of it isn't "always prototype in code." It's knowing when to — when an idea is spatial or sequential enough that flat screens can't carry it, and only a working model can.
Outcome
The model shipped, and it's still live. Today, SAMHSA's data collections each live as their own home under samhsa.gov/data, and the ones with tools hand off to datatools.samhsa.gov — the read-here / analyze-there structure, years on.
What it shows
Systems thinking, made concrete. I reorganized two complex, established sites around user intent — and proved the new structure in a working model before the build.
Design-to-code as communication. I use prototypes to make hard, abstract decisions — like a merge — something a room can see and agree on.
I can lead a net-new product. I didn't just propose the split; I led the design of the tools site it created.
Durability. The architecture has held in production for years — the truest test of an IA decision.
take a peak @