User research studies

The problem

Most AI-feature roadmaps are built on guesswork about what users want. The good ones use research. The fast ones use prototypes. The fastest ones use prototypes as the research instrument: surveys, demos, and tools wrapped together so the prototype itself becomes the source of insight.

The problem I was trying to solve wasn’t “what should we build?” That’s the outcome of good research, not the starting condition. The problem was velocity. How do you learn faster than the product roadmap moves? How do you generate insight at the pace of a sprint, not a quarter?

Who it serves

Internal product, design, and research teams that need to learn quickly about AI use-case adoption, user friction, and where automation actually helps versus where it gets in the way. The audience for research artifacts is small; the audience for the decisions those artifacts inform is large.

How it helps

Each prototype follows the same loop: design hypothesis → small prototype → small-N test → learn. The point isn’t the tool. It’s the velocity.

Agentic prototyping tools (Lovable, Bolt, and similar) compressed the build time from days to hours. That compression changes what’s worth testing. When a prototype takes two days to build, you only run it if you’re reasonably confident it’ll teach you something. When it takes two hours, you run three variants and let the data tell you which questions to ask next.

The insight is about learning velocity, not prototype quality. The prototype is a disposable instrument. The learning is the asset.

What it does

A small collection of studies, two of them publicly accessible:

• Funding-data feedback tool. Gathered foundation feedback about friction in the funding-data experience. The goal was understanding where Candid’s data products created confusion or blocked workflows, not validating a pre-formed solution.
• Fundraiser toolkit. Two demo and survey tools for AI use-case feedback and agent testing. Tested appetite for AI-assisted grant discovery and donor-communications workflows.
• Plus internal-only studies (described in aggregate, not linked) covering search behavior, data-quality perception, and AI-feature adoption patterns.

Each study informed decisions in the active product roadmap, not just future planning. The lead time between research and decision was typically one sprint.

What I learned

Prototypes-as-instrument shortens the feedback loop dramatically. The trade-off: prototype quality has to be high enough that survey data isn’t polluted by frustration with the prototype itself. There’s a sweet spot around “enough polish to feel intentional, not so much that you’ve spent two weeks on a research artifact.” Getting to that threshold in two hours rather than two days is the actual skill.

The second lesson is about AI feature research specifically. Users have strong opinions about what AI should do and much weaker intuitions about what it can do well. The useful research question is rarely “do you want this?” It’s “what breaks when you use this on a real task?” That question only gets answered when the prototype is functional enough to run a real task, not a demo task. The difference is meaningful.

The third lesson: research velocity compounds. A team that runs five small tests per quarter learns faster than one that runs two large ones, even if the large tests are methodologically cleaner. Speed of iteration matters more than depth per iteration, especially in early-stage AI feature work where the design space is still being defined.

Status

Studies completed. Learnings folded into broader product work at Candid. The methodology is repeatable; future studies will use the same rapid-prototype-as-instrument pattern.