My Design Process, Evolving With AI - 1

Part 1: Research
When a problem signal showed up, I used to run the whole process alone. I'd prepare the interview or survey, conduct it, transcribe it, and summarize the insights myself, start to finish.
That's changed a lot in the AI era, but not evenly. One thing hasn't moved at all: which data to look at, and how to interpret it, is still entirely mine, not AI's. Deciding which angle or segment of quantitative data actually reveals the real cause requires context on the project and domain judgment built up over time, and that's not something AI can substitute for. If you just ask AI to "find the problem in this data," it will surface surface-level patterns readily enough, but it has no sense of whether that pattern is a real signal or just noise. That judgment call is where I still start every research phase, before anything gets handed off to AI.
The real shift happened somewhere else: in how I research qualitative data.
Preparing the interview facilitation
Once I've clearly defined what insight I'm trying to get, AI drafts a strong first version of the question list.
Why: If the goal is clear, working backward from it to structure questions is a fairly patterned task, so AI does it well. But if the goal itself is wrong, no amount of good questions fixes that, so defining the goal stays mine.
Prompt example: "We want to understand why sales reps take so long to [approve a completed quote before sending it to the customer]. Specifically, we want to understand [what reps are actually checking for during that review, beyond what's listed in our approval checklist]. Based on this goal, write a 30-minute user interview guide with a warm-up, core questions, and candidate follow-ups. Avoid leading questions, and make sure the questions dig into the why behind their behaviour, not just what they did, for example, why they double-check certain line items but not others."
Analysing the data
Summarising insights from open-ended survey responses or interview transcripts goes to AI.
For large volumes, I cross-check across GPT, Claude, and Gemini instead of relying on one.
Why: Reading dozens of transcripts and manually tagging recurring themes is pure labor time, which AI can absorb. But different models tend to emphasize different themes in the same data, so trusting a single model's summary risks accepting a biased read without knowing it. Cross-checking reduces that risk.
Prompt example: "Here are 8 user interview transcripts about [feature]. List the recurring pain points ranked by frequency, and quote the statements that support each one. Don't add your own interpretation, only what's grounded in the quotes."
Why I still sit in on interviews
I still join most interviews myself, asking follow-up questions live and reading the context and nuance of the conversation.
I compare AI-generated findings against what I observed directly, to check whether the interpretation drifted from context or missed something.
Why: Insights users reveal through behaviour rather than words, like a cursor hesitating over a button during a screen share, never show up in a transcript. That only gets caught by being in the room, and no AI summary replaces it.
AI's role here isn't to interpret the insight, it's to turn insight I've already reached into a format I can share cleanly with the team.
Prompt example: "Turn my interview observation notes into a script for a team-facing report. Structure it as three key findings, the evidence for each, and suggested next actions. Don't change my interpretation or conclusions, just restructure them."
Looking back at this stretch of the process, the shift isn't that AI took research away from me, it's that it took the parts that were pure labor and left me with more time for the parts that actually require judgment: knowing which data matters, sitting in the room to catch what a transcript can't, and making sure a summary reflects what I actually saw. That's the trade I'd make every time.
Next up in this series: how that same shift plays out in ideation, where the problem isn't too little output anymore, it's too much of it, and figuring out what to do with all of it.