CBDC research: a qualitative and quantitative system for an enterprise program
A multi-year program alternating qualitative and quantitative research at sprint pace, with automations built for recruiting, first-pass coding and reporting.
- Role
- UX Researcher (qualitative & quantitative)
- Team
- Research lead within a larger program team (design, product, client-side)
- Duration
- Multi-year program, ongoing
- Client
- Central bank digital currency initiative (NDA)
The project in one minute
The Challenge
Qualitative and quantitative research use different tools and timelines, but in this program they need to keep informing each other. The risk is that, as phases go by, they turn into two archives and two separate processes.
My contribution
- Designed the research methodology across both qualitative and quantitative tracks
- Designed the recruiting pipeline connecting booking to screening data
- Built the AI-assisted qualitative coding workflow, the same engine behind [qlaude](/portfolio/qlaude)
Results and scope
50+ 1:1 interviews in a single journey-mapping phase
The Challenge
What I was responsible for
- Designed the research methodology across both qualitative and quantitative tracks
- Designed the recruiting pipeline connecting booking to screening data
- Built the AI-assisted qualitative coding workflow, the same engine behind qlaude
- Built the quantitative reporting pipeline for multi-market survey data
- Moderated user test sessions across markets and languages
- Wrote methodology and phase reports throughout the program
Qualitative and quantitative research use different tools and timelines, but in this program they need to keep informing each other. The risk is that, as phases go by, they turn into two archives and two separate processes.
For several years the research has followed a central bank digital currency app for consumers and merchants. Phases alternate journey mapping, moderated tests and multi-market surveys, including the validation of a new flow: offline peer-to-peer payment over NFC.
At this cadence, even tasks that look administrative become a bottleneck: moving screening data across, doing a first pass of coding on transcripts, producing new charts every cycle. I automated these steps because they don't require a methodological decision: a recruiting webhook, assisted coding with the same engine behind qlaude, and a reporting pipeline, Carthago. Research design, review and interpretation stay manual. I'm also building a repository to hold instruments, methodology and findings across phases.
"The team needs findings fast enough to feed into sprints, and solid enough to support decisions about trust, security and adoption."
If these tasks slow down, the research arrives late; if they get squeezed too hard, the quality of review suffers. Automation takes pressure off that step, and the interpretive work stays with the researcher.
Recruiting, first-pass coding and chart production take up time every cycle while requiring relatively little methodological judgment.
Research
Qualitative: exploratory journey mapping and moderated usability testing
50+ 1:1 interviews across a journey-mapping phase; user test rounds of 10 participants each
Every task is scored on completion and User Effort Score rather than only as pass or fail: that separates 'worked eventually' from 'worked easily'.
How a session runs
A participant books through Cal.com, and the screening data they gave (country, age, gender, payment habits, language) arrives in the project the moment they book, with no manual step before the session. The moderator runs a structured protocol in the participant's language: warm-up, tasks, think-aloud, debrief.
First-pass coding assisted by AI
Every session is recorded and transcribed. The same engine behind qlaude proposes a code against an exact passage with its reasoning, and the researcher accepts, edits or rejects it. This division of work makes it possible to code these volumes while keeping traceability.
Quantitative: multi-market panel surveys
Panel surveys across multiple markets, samples in the hundreds of respondents per round
Demographic quotas and exclusion for suspicious completion times are built into the survey design itself, not left to the panel provider's defaults.
How the survey pipeline runs
One instrument gets fielded across markets through a panel provider, with quotas monitored while the survey is live rather than checked only after fielding closes.
Automated reporting
Carthago processes the quota-managed data as it lands and produces the charts every phase report needs directly from it, so quantitative turnaround stays inside the sprint instead of trailing it by days.
Key Insights
The method is chosen by the question
Qualitative and quantitative phases are chosen by what the research question needs at that point in the program, with no fixed alternation.
Recruiting data should never touch a manual transcription step
Every manual step between booking and screening is a place where a transcription error can creep in. The pipeline removes that step entirely.
Assisted coding stays tied to the source
The same split as [qlaude](/portfolio/qlaude): AI-assisted coding proposes against the exact source text, and the researcher accepts, edits or rejects.
Producing charts and interpreting them stay separate steps
The reporting pipeline produces the charts; interpretation remains a step of its own, even when there's a lot of data.
Goals & Principles
Full methodology on both tracks, at sprint cadence
Neither track uses a reduced version of its methodology to fit the schedule; the automations are there to avoid that compromise.
From recruiting to session without retyping data
Screening data should arrive at the session ready to use, with nothing retyped or misread along the way.
AI-assisted coding linked to the source
Every coding proposal must be traceable back to the exact passage it came from, the same standard [qlaude](/portfolio/qlaude) holds elsewhere.
Multi-market reporting, automated where possible
Results from every market go through the same reporting pipeline, with no charts redrawn by hand each cycle.
Guiding Principles
AI proposes, the researcher decides
The same rule as [qlaude](/portfolio/qlaude), applied to a payment product where trust is central: here an unvalidated assumption can affect adoption at scale.
Solution Design
Interactive diagram
From booking to coded transcript
Select a node to highlight its connections and read the design decision behind it.
Booking
A participant books a session. The screening questions they answer are the first data point in the pipeline.
Connected to: Screening data
Conceptual reconstruction of the recruiting-to-coding pipeline, not a live dashboard. No participant data is shown.
From recruiting to session: Cal.com → Notion → Vercel webhook
A manual step between booking and screener introduces transcription errors and delays between recruiting and session prep, and at these volumes errors add up quickly.
Alternatives considered
- Manual handoff between booking tool and project tracker (status quo, error-prone)
- A shared spreadsheet updated after each booking (still manual, still lagged)
- A webhook connecting booking directly to the research project
A webhook brings screening data (country, age, gender, payment habits, language) into the project the moment someone books a session, with no manual step.
That step added nothing to the research and was only a source of errors. Removing it eliminated a whole class of screening errors for the rest of the program.
Trade-off: The pipeline is built around this program's screener and isn't meant as a general recruiting tool.
AI-assisted qualitative coding, same engine as qlaude
Coding interview and user-test transcripts to qlaude's traceability standard, with every proposal anchored to exact source text, takes a lot of time at these volumes.
Alternatives considered
- Hand-code every transcript (rigorous but doesn't hold at this volume and cadence)
- Generic AI summarization (fast, but loses the traceability the methodology requires)
- The qlaude propose/decide engine applied to this program's transcripts
The same split as qlaude: the AI proposes a code against an exact passage with its reasoning, and the researcher reviews, edits, accepts, or rejects it.
Many design and product decisions rest on the coding, so its rigor is a requirement of the method.
Trade-off: The proposing step gets faster; the researcher's review takes the same time and grows with transcript volume.
Quantitative reporting with Carthago
Redrawing multi-market survey charts by hand every sprint isn't sustainable at a continuous cadence, especially with quotas and exclusions to handle.
Alternatives considered
- Manual charts rebuilt each cycle (status quo, doesn't scale with cadence)
- A generic BI dashboard tool (overkill for this data shape, still needs manual setup per market)
- A built analysis and chart pipeline scoped to this program's survey schema
A dedicated pipeline processes the quota-managed survey data every cycle and produces the charts the reports need directly from it.
Keeps quantitative turnaround inside the sprint instead of trailing it by days.
Trade-off: It's built around this program's data, unlike a general-purpose tool such as SenseKit.
A research repo to hold qual and quant together, still in progress
A multi-year program produces two years of interviews, transcripts, survey waves and phase reports. Without a shared place for methodology, instruments and past findings, the qualitative and quantitative tracks risk becoming two archives that no longer talk to each other, which is exactly the problem the other automations try to avoid.
Alternatives considered
- Leave it in Notion alongside the recruiting data (works for screening, not for methodology history)
- A wiki page per phase (drifts out of date once the phase ends)
- A dedicated research repo built for this purpose
A separate research repo, still being built, meant to hold methodology decisions, instruments and prior findings in one place across phases, so a new phase can start from what the program already knows instead of from scratch.
The other three automations each solve a single mechanical step and, once built, need little maintenance. The repo is about the program's memory instead: a slower, less mechanical problem, especially in a program that changes from phase to phase.
Trade-off: This piece is unfinished. Unlike the webhook, the coding workflow and the reporting pipeline, the research repo doesn't yet support day-to-day work: it's still being built.
Outcomes & Impact
The program can run qualitative and quantitative rounds side by side at sprint cadence without handing the interpretive part to automation. The automations remove repetitive manual steps; methodology, code review and reading the results remain the researcher's responsibility.
50+ 1:1 interviews in a single journey-mapping phase
User test rounds of 10 participants each, moderated with think-aloud and User Effort Score
Survey samples in the hundreds of respondents per round, across multiple markets
3 automations in daily use (recruiting webhook, AI-assisted coding, quantitative reporting) and a fourth still being built: a research repo to hold methodology and findings together across phases
Qualitative and quantitative tracks held to the same rigor on the same cadence
Zero manual screening-transcription errors since the recruiting pipeline went live
AI coding proposals traceable to exact source text, the same standard as qlaude
Quota management and completion-time exclusion built in as standing methodological safeguards
What I delivered
- Research methodology and instruments per phase
- Recruiting pipeline (Cal.com → Notion → Vercel webhook)
- AI-assisted qualitative coding workflow
- Quantitative reporting pipeline
- Phase reports across the program
- Research repo holding methodology and findings across phases (in progress)
Reflections
Automation added the most value in repetitive, error-prone steps, far more than in interpretive work.
What I would change
- Would formalize the cross-track sync method earlier in the program rather than refining it phase by phase
- Would start the research repo on day one instead of only once the two-track archive problem became visible
What worked and what was difficult
What Worked
The qlaude workflow held up in a more sensitive context
The propose/decide split for coding moved from qlaude's original context to this program's transcripts without changes.
The webhook removed manual screening transcription
Booking and screening data now move through the webhook without being copied by hand. The workflow removes that transcription step; it does not validate the screening answers themselves.
Challenges
Keeping the two tracks aligned took method choices
Putting qualitative and quantitative phases side by side isn't enough for them to inform each other. It took explicit method decisions, which the automations support but don't make on their own.
Review stays human
In a payment product where trust is central, an unvalidated assumption about authentication or security perception can affect adoption at scale. That's why review has to stay with the researcher.
The research repo should have started earlier
It only became a visible gap once two years of qualitative and quantitative history had already piled up separately. Starting it early, even in a rough form, would have been cheaper than retrofitting it now.