Andrew Muir Wood on what happens when one person can research, design, and build—and the discipline that keeps fast work pointed at the right question.
.png)
Research used to move in a relay. Researchers ran studies and wrote findings. Designers turned findings into mockups. Engineers turned mockups into something real. Every handoff lost a little signal and added a little time.
So what happens when the relay disappears, when one person can research, design, and build the thing? Few people are better placed to answer that than Andrew Muir Wood.
Dr. Andrew Muir Wood runs Muir Wood & Co, a boutique research and strategy consultancy in London that’s worked with Deliveroo, Condé Nast, Mozilla, and Tesco. With a PhD from Cambridge in design and product evolution and a background in product design engineering, he’s spent years sitting in more than one of those seats at once.
“I’ve always been a bit of a creative generalist, and a multitasker. The startup world suited my way of working, because the job description changes every three months.”
I recently sat down with Andrew for a wide-ranging conversation about what actually changes when AI collapses those three roles into one.
The discussion was full of practical examples, from rebuilding a client’s website in Claude Code to priming prototypes with real customer data before a stakeholder meeting. We’ve pulled out the main themes below, and you can watch the full conversation here.
Andrew started by describing how the shape of his work has changed. His projects have moved from product teams toward marketing and the buying journey.
“Five years ago, almost all the work we were doing was product discovery, working with product development teams. Whereas now, the majority of the work is more with marketing teams. It’s more like buyer discovery.”
That means understanding the deeper problems that customers are struggling with, which lead them to decide to make a change, then begin the messy journey of researching and buying products or services. Visual artefacts are a great way to get people thinking and talking about these inner thought processes, but they can also be a distraction if they aren’t created thoughtfully.
The bigger change is what Andrew can now do about it. Because he can build, he no longer tests whatever artifact a client hands him. He rebuilds it with AI.
Below are the themes that came up most across the conversation, each with a practical way to put it to work.
That limitation showed up on a recent project. His client was a mid-sized ecommerce company with no researchers on staff and no design system. They handed Andrew two static wireframes and asked the familiar question: can you see if people like this?
He rebuilt their site instead.
“Why don’t I just see if I can rip their website into Claude Code and actually just rebuild what they’re trying to do, but in an actual interactive prototype that is based on code?”
He changed the navigation, the layout, and the wording one piece at a time, so each change could be tested against the current site or a competitor rather than judged on its own.
“A lot of the time when we get given a PDF or a JPEG, you just get given it and told, test if people like this. So, compared to what? It’s so subjective, and there’s nothing to compare to.”
Try this: Next time you’re handed a static JPEG and asked “do people like it?”, rebuild it as a working prototype and change one variable at a time, the wording, then the layout, then the value on offer. Test each against what exists today, so people are choosing between two real things instead of reacting to one.
“It was overdelivering for this project, but it’s going to give us better insights. I’ve got more confidence in the data coming off the back of testing these prototypes rather than just a JPEG, which should produce a clearer ROI.”
Andrew has found that AI speeds up parts of his process, like pulling quotes and clustering. That leaves him with a choice about what to do with the time it gives back.
“You’ve got two choices. You just do it faster, or you do more. Maybe do some of the analysis that you would never have had time or budget for.”
His rule of thumb is about quality not quantity:
“It used to take a day to make a prototype, and now you can do it in two minutes. But why don’t we take an hour and make it really good?”
Andrew saw the cost of skipping that discipline at a talk by a product leader from a travel company: they built a sandbox which allowed anyone in the company to build a prototype on a real design system and live data.
“There were 400 prototypes in there. How are you going to decide which one you take forward? That goes back to the human problems we’ve always had around deciding what to work on next.”
Try this: When a task that used to take a day now takes two minutes, don’t pocket the time. Put it back into the work. Take the hour and make the prototype good enough that nothing on screen distracts from the question you’re asking.
We often encounter senior stakeholders that are fixated on an idea and now with AI they can even prototype it themselves. This is making a lot of product people nervous, but Andrew doesn’t think it’s all that bad, because prototyping is thinking.
His L-shaped sofa story makes the same point. Sketch a room and the sofa always looks smaller than it turns out to be.
“When I measure my living room and start shopping for L-shaped sofas, in my sketch the sofa takes up a lot less space in the room than the reality.”
On a pre-launch edtech project, discovery turned up a clear sequence of jobs families face during a stage of their kids’ education. Andrew built a working prototype from that data, then added a hidden screen that primed each session with a real family’s details. The synthesis under the prototype was ordinary qualitative work.
“The analysis is fairly traditional. It’s all of the affinity mapping, clustering, building journey maps, understanding different personas from trade-offs.”
The prototype was intended for further testing on real families, but when he showed it to the founders, it changed the conversation. They started answering hard questions about their own model, like how they’d resource it and what they could charge.
“It became an artifact not just for testing on customers, but also for testing on the stakeholders, to get a higher level of conversation from them.”
Andrew has a name for why a concrete artifact changes the dynamic, borrowed from research on collaboration.
“There’s this concept of boundary objects. If you criticize a picture or a prototype or a mockup, you’re not criticizing the person, you’re just criticizing the object.”
Force the idea into a real prototype and the trade-offs you’d glossed over show up. The artifact gets the vision out of a leader’s head and into something everyone can poke at.
Try this: Use rapid prototypes as a way of engaging stakeholders to understand the implications and tradeoffs of their ideas.
Andrew’s sharpest warning is about restraint. Being able to ship an interface doesn’t mean an interface is what the question needs.
“We misconstrue people being able to use something as people needing it.”
Sometimes a rougher artifact gets you a better answer.
“Maybe we should be showing the customer a storyboard or a page out of a calendar, something a bit more abstract.”
Try this: Before you build UI, get clear on what you’re trying to learn. If the question is whether the need is real, a storyboard or a single calendar page often surfaces it faster than a polished screen, and without anchoring people on the interface.
How to make a call when you revise a prototype partway through and your participants end up split across versions? Andrew separates small fixes from full rewrites.
“If you’ve done two or three interviews and you spot something that’s such a howling issue with your prototype, and you have an opportunity to remove that, then we can go one step further and see what the other problems are. What I don’t suggest is making a complete revision of the entire prototype. It would make sense to do that as part of another sprint.”
Now that a single prompt can change everything mid-session, the discipline to stay on course matters more. Harri reached for a flight analogy: one degree off course over 60 miles leaves you a mile from where you meant to land. Reconnecting the prototype to the original research and the business goal is the small correction that keeps a fast project pointed at the right place.
Try this: If two or three sessions keep hitting the same obvious obstacle, fix that one thing so you can see what’s behind it. Leave any larger redesign for the next round of research, with a fresh set of participants.
Andrew was wary of Claude Code at first.
“I was a bit afraid of it. All the demos of Claude Code are in the terminal. And then I realized you don’t have to be writing code to be using Claude Code.”
His first use was pointing it at a pile of markdown files his team kept in Obsidian. The prototyping came later, once he was comfortable. His working model for AI is deliberately humble.
“There’s an old analogy of treating AI like a junior employee. My analogy is treating them like a useless cousin. The best place to start is to go and look at three other projects we did that are similar, and copy and paste from there. AI is a much better copy-and-paster than a human, because it changes all of it. It doesn’t miss anything.”
For Andrew, the feedback loop has no ego in it, and the instructions he writes for the tool double as a guide for people.
“You can give infinite amounts of feedback to Claude Code without it calling HR and saying you’re constantly critical of it. Its own instructions actually become great instructions for a person doing the same thing.”
Try this: Point AI at a few past projects that resemble the one you’re starting and ask it to adapt your discussion guide or recruitment profile from them. Correct it as many times as it takes, then keep the instructions you wrote as a playbook for next time.
In Andrew’s view, when anyone can build, the edge moves to judgment: knowing what’s worth making, and what “finished” looks like.
“We still need to know what looks good, or what looks finished. That website has nothing jarring on it that makes it look sketchy.”
Then enough technical grounding to talk to the people who ship.
“Having a general concept of what’s possible and the architecture of things under the hood means you can have more meaningful conversations with technical stakeholders. What’s GitHub? Why is CSS in a different file? These are unknown unknowns to people who haven’t dabbled.”
And the habit of teaching yourself skills that used to belong to other teams.
“A lot of people are editing videos now. As a researcher, making shorter videos and snippets is very powerful if you can make good video.”
His suggestion for a first real attempt:
“Have a go at rebuilding your website, your client’s website, or a competitor’s website in Claude Code, Replit, or Lovable, and see how it goes. It’s a great brief because it’s a very closed brief, and you can see if you got it right or not.”
Andrew goes deeper on all of this in the recording. Watch on-demand here.
Connect with Andrew on LinkedIn and check out his London research masterclasses, soon to be online.
Great Question is an all-in-one UX research platform that helps teams recruit participants and run any research method, then build a repository that puts real customer evidence into every decision. You can stay up to date with all our live events here.
Harri is Chief of Staff at Great Question and a former qualitative researcher at Meta. Harri works across strategy and operations, and regularly hosts conversations with research, design, and product leaders about how AI is changing the way teams understand their customers.
.png)
.png)
.png)
