A research mentor that argues back
How I used AI to teach research, not automate it.
TL;DR
IBM had more products that needed research than researchers to do it, and about a third of the 30+ designers I support were already running their own studies. Hiring would have been slow and still wouldn’t have covered everything, and what the designers were missing was someone senior to guide them and push back on their choices. Like a lot of researchers, I was opposed to AI in research at first. But I thought about what my team needed and asked a different question: could AI help them do better research, rather than do it for them? So I built Dr. Morgan, an AI research mentor that shows you what it’s seeing, asks the questions a senior researcher would, and explains why. About 40 designers, researchers, and PMs use it now, which frees me up for the questions that shape what we build next.
What I built
Meet Dr. Morgan
Dr. Morgan acts as a senior UX research mentor. It lives inside the AI assistants IBM teams already use (IBM Bob and Copilot). It isn’t tied to any one product: you tell it what you’re working on, so any team at IBM can use it.
Dr. Morgan is an assistant first. In coach mode, the default, it points out what it’s seeing in your plan, notes, or data, then asks you questions so you do the thinking while it guides you. If you want it to draft something, like a plan or a script, you can switch to draft mode, but only after certain questions have been answered, and then it reviews that draft with you to the same standard. Its advice comes from the research books I trust most (Hall, Portigal, Fitzpatrick, Braun and Clarke, Saldaña, Sauro and Lewis). One rule sits above the rest: a confident wrong answer is worse than an honest “I don’t know.”
One mentor, six kinds of help
It covers six situations, from picking the best method given your constraints to analyzing interviews and identifying themes with a critical sounding board. It moves between them mid-conversation, because real studies don’t happen in order (research is messy!). When the findings are done, it can turn them into a readout deck or a report, but only with evidence the findings already contain.
Checking is a different job from doing
One set of agents writes, and a separate set checks. Keeping them separate keeps the checks independent, so a checker is less likely to repeat the same error the writer made. Each checker looks for one kind of problem, like a made-up quote or a finding that doesn’t answer the research question. None of them can edit what they check, since a checker that rewrites its input ends up grading its own homework.
Not every problem is equal, though. Anything untrue, unsupported, or unsafe gets fixed before it goes anywhere. Anything accurate but worth a second look gets a flag and stays in. That matters, because a surprising finding is often the best part of a study, and I don’t want anyone cutting it just to pass a check.
Where a person still decides
In draft mode, when Dr. Morgan analyzes interviews for you, it stops after grouping the data and asks you to approve the themes before going any further. No AI checker handles that step, because one AI grading another AI’s themes is a second opinion with the same blind spots. It also asks people to review what it produced and sign off that they did. None of this makes the process perfect, and it shouldn’t be treated that way. Good AI use still requires a critical thinker.
The big picture
More than a hiring problem
The team came to me with a staffing problem, and it was one, but it was also a research skills problem. Designers were already running studies. They just didn’t have the training or support to do it well, and hiring would have been slow, expensive, and capped at whatever one more researcher could cover. So I built them a teacher that also walks through the work with them. Every study a designer runs well puts more evidence behind the product, and it frees me up for the bigger picture: what the team needs next, and which questions set direction.
What I almost missed
Two mistakes I caught
My first version gave step-by-step instructions: do this, then this, then this. When I tested it with designers, they followed the steps and still wrote leading interview questions and cherry-picked their analysis. The steps were fine. What they didn’t explain was why each step exists, so I rewrote them to explain the reasoning. The old instruction said “write an unbiased question.” The new one says “here’s the bias in this question, and here’s why the answer won’t tell you anything.” In a way, that’s the whole difference between a junior and a senior researcher, and it’s what made the mentor act like a senior one.
The second mistake was in the checking. I built a test set of findings with problems planted in them on purpose and ran my checkers against it. The privacy check ran last, which sounded harmless until I traced it through. Anything that failed an earlier check never reached the privacy check, so a participant’s name could survive a whole round of revisions with nobody looking for it. Every checker worked fine on its own. The problem was the order, and I was the one who set it, so privacy runs first now.
Impact