AI-Powered UX Research

I wrote a book. Yes, really.

That sentence still feels slightly unreal to type. Not because writing a book is inherently remarkable but because I started this site to think out loud about a problem I kept seeing and could not stop thinking about, and somewhere between the first post and the hundredth the thinking turned into something larger than a blog.

The book is called AI-Powered UX Research: How to Run Research at the Speed Your Team Actually Needs. It publishes summer 2026.

Here is what it is about and why I wrote it.

The Problem I Kept Seeing

Every organization I have worked in or talked to has the same dysfunction. The research function is staffed with capable people running well-designed studies and producing technically sound findings. And the findings keep not mattering. Not because nobody reads them. Because by the time they arrive, the decision has already been made, the roadmap has already moved on, and the readout is now a Confluence page that will be visited three times total, two of which will be the researcher checking whether anyone visited it.

I spent years assuming this was a communication problem. Better readouts. Better stakeholder relationships. Better timing.

It is not a communication problem. It is a structural problem. The research operating model was built for a world where building was slow enough that a study could intercept a decision before it was made. That world is gone. AI has compressed the product build cycle in ways that make the old model not just inefficient but structurally inadequate. Research has not kept up. Not because researchers are not good. Because the function has not been redesigned for the tempo it is now operating in.

That is the problem the book tries to solve.

What the Book Introduces

The book is built around three things.

The first is a taxonomy of research modes. Not all research questions are the same and treating them as if they are is where most research dysfunction starts. Some questions need an answer in 24 hours. Some need two weeks. Some need months of foundational work that cannot be compressed without losing the thing that makes it valuable. The book introduces three modes, micro research, sprint research, and deep research, and a routing logic for deciding which mode a question belongs in based on risk, ambiguity, and how quickly the answer expires. Two of those modes are made possible by AI-moderated data collection with real participants. That is a structural capability that did not exist at meaningful scale until recently and it changes what research can contribute to product decisions.

The second is the Frame. The Frame is the organization's accumulated, actively maintained model of its users. Not what it has studied. What it currently believes, how confident it is in each belief, and where the gaps are. The book makes the case that fast research is only useful if there is something to plug into, and that without the Frame, micro and sprint research produce precise answers to potentially wrong questions. It covers how to build the Frame, how to maintain it, how to make it findable where decisions happen, and what happens when it degrades, which it always does, usually invisibly, usually until something ships and fails in a way that current research would have predicted.

The third is governance. Not the conference-talk version of governance where everyone agrees research should be strategic and nothing changes. The operational version. How to route incoming requests. How to protect deep research from the gravitational pull of fast work. How to maintain quality standards when multiple people are running studies simultaneously. How to scale research output without scaling headcount. And how to make the transition from a service model, a function that responds to requests, to an intelligence function, a function that maintains organizational knowledge and shapes decisions upstream.

Why I Think It Matters

I have been writing about these ideas on this site for a while now. The readout piece. The Frame piece. The dev orgs piece. Etc. Each one was an attempt to name something I kept seeing that nobody else seemed to be naming directly.

The book is where those arguments connect into a system. Not a collection of takes. An operating model with enough specificity that a researcher can close the book and know what to do on Monday morning.

I ran alpha reads with research leaders across the industry. The conversations were good. Some teams are already implementing elements of the framework. That was not what I expected when I started writing and it is the thing that made me feel like the book was worth finishing.

What Comes Next

The book is in its final stages before publication. If you want to know when it is out, subscribe to The Voice of User. I will announce it here first.

If you are a research leader who wants to talk through any of this before the book lands, my email is on the about page.