Designing for Restoration Not Extraction
A formative qualitative study with seven program sites, conducted before the system that would serve them was designed.
The Question
Before building a centralized data system for a 150-person youth-serving nonprofit, I wanted to know what the people who would actually use it were already doing. Not in the abstract. In their daily workflows, at their specific sites, on the actual mornings they ran intake.
The org's instinct was to design the system first and roll it out second. The risk in that sequence is well-known: tools land on workflows they don't understand, staff route around the system, the system becomes a reporting requirement instead of a daily tool, and the data it captures stops mapping to reality. The research below was the work I ran to keep that from happening.
I designed a formative qualitative study — seven in-depth interviews, one team per school site, deliberately scoped to listen before designing. The goal was discovery, not validation. I didn't bring a prototype. I brought questions.
The Method
Semi-structured interviews, AI-assisted thematic analysis, researcher review at every layer.
The method was designed to surface what existed already — workflows, workarounds, pain points, the systems sites had quietly built for themselves — rather than to test what was being planned. Three components, each doing distinct work.
The full study took four months in a nonprofit setting. The same study in a SaaS or product environment would run in roughly two weeks. The difference isn't methodological. It's that I ran this study solo, as one of many concurrent priorities, in an org without dedicated research infrastructure. In a product environment with a research function, scheduling, transcription, and synthesis support compress that timeline by an order of magnitude.
Walk me through a typical day. What changes by season. How data moves through your workflow, end to end. Where it breaks. The hours each task actually takes. What you've built locally to compensate for what doesn't work.
Semi-structured, 60-minute interviews with site teams of 2–4 — site leaders and assistant leaders together — so workflow descriptions could be cross-checked in real time.
Every interview ended with an open invitation to add anything else. Most participants used that space to surface system-level grievances they hadn't been asked about directly — which became some of the highest-signal data in the study.
The protocol was built to find what I didn't know to ask about. Walkthroughs surface workflows; open closes surface beliefs. The combination is what makes formative research formative.
I coded the first 12 parent codes manually, based on the protocol's question architecture and what emerged in the first two interview transcripts.
I gave Claude the 12 codes and asked it to apply them across the full transcript set as a first pass, surfacing where codes applied, where they didn't fit, and where new themes were emerging.
I worked through Claude's output line by line. Where I agreed, the code held. Where I disagreed, I revised. Where Claude surfaced a theme I hadn't seen, I assessed it against the full transcript and either adopted, refined, or rejected it. The final code structure landed at roughly 15 parent codes with 4–5 child codes each.
AI-assisted coding compresses synthesis time without sacrificing researcher judgment — provided the researcher reviews every output. The method is faster than manual coding and more rigorous than AI alone.
A key findings and recommendations report for the executive director, structured around the themes that emerged and the workflow shifts those themes pointed to.
Executive leadership. The report was designed to surface what the research changed about how the system should be designed — not to validate decisions already made.
The recommendation was a sequencing call: pause new quantitative metric expansion, prioritize Salesforce adoption and staff onboarding, allow iterative adjustment of the existing system, and route qualitative material to the revenue-generating department (development) in the interim. Primary and secondary data analysis showed the org had 18–24 months of qualitative runway before quantitative expansion was warranted. The evidence didn't support asking site staff to carry more measurement work; it supported consolidating what existed.
Recommendations rooted in seven workflow walkthroughs hold up better than recommendations rooted in assumptions. The deliverable was meant to be the foundation of the next phase of evaluation framework design.
What We Heard
The patterns the interviews surfaced.
The dominant finding was the gap between the org's stated data ambitions and the workflow reality at the sites. Site teams were already running on tight margins, building local workarounds — spreadsheets, paper trackers, side conversations with school administrators — to keep their programs viable. The systems they'd quietly constructed weren't gaps to fill with more tooling. They were evidence of what the central system would need to honor.
MGMT and school administration emerged as the most common pain points across sites, surfacing in nearly every interview through the open-close prompt. Site staff didn't volunteer those grievances when asked about workflows directly. They surfaced them when invited to add anything else — which made the open close the single most generative protocol decision in the study.
The research challenged the org's working assumption that more metrics would produce better evaluation. Primary and secondary data analysis showed the opposite: the existing qualitative material was underutilized, and the revenue-generating department could draw more value from what already existed than from anything new the sites might produce. The recommendation that followed wasn't to slow down. It was to sequence — adoption first, qualitative consolidation second, quantitative expansion deferred.
Where It Maps
The work was discovery research, framed as evaluation.
Discovery research and formative evaluation share a methodological core: structured listening before structured intervention. The vocabulary differs by industry, but the work runs on the same logic.
Seven interviews is a small sample for product UX research and a real sample for formative evaluation. The bridge between the two is what the research was designed to find — not what users wanted in the abstract, but what their daily work actually required of any system that hoped to land. The methodology travels across industries. The patience for listening is what's harder to find.
Hiring for a research role where this method and mindset would land? I'd love to talk.