UX research for product teams.
A one-day in-house programme on choosing the right method, running it well, and getting the findings acted on. Built around a real decision your team faces.
Strong on craft, thin upstream of it.
The commonest shape we are called into: a mature design system, confident UI work, and nobody checking whether the thing being built is the right thing.
- •Product teams who commission research, or who have to do it themselves between everything else.
- •Teams with a strong design system and no research practice sitting upstream of it.
- •Designers who can run a session but keep watching the findings get ignored.
- •Teams where AI has made synthesis fast and nobody is sure how far to trust it.
From a worry to a decision people act on.
Run against a real question of yours, not a case study.
Starting from the decision, not the method
Work backwards from what the team has to decide, so the research has somewhere to land.
→ the decision your next study has to serve, written downTurning a vague worry into a testable question
Separate assumptions from facts, then turn the riskiest assumption into something you can actually check.
→ your assumptions sorted, riskiest firstChoosing a method you can afford
Interviews, concept tests, usability sessions, surveys and analytics: what each one can and cannot tell you.
→ a method chosen for your real question, with the trade-off namedRunning a session without leading the witness
How to ask, when to shut up, and the questions that quietly produce the answer you wanted.
→ a discussion guide for your study, written in the roomMaking sense of what you heard
Affinity mapping a real transcript, and using AI for synthesis without letting it invent a theme.
→ a synthesised set of findings from real materialGetting the findings acted on
The part most teams skip. How to present research so it changes a roadmap rather than filling a deck.
→ a one-page write-up aimed at the people who decideA study in progress, not a reading list.
- •A research question tied to a decision your team actually has to make.
- •A discussion guide for that study, written during the day.
- •Findings synthesised from real material, not a worked example.
- •A one-page way of reporting research that the rest of the business will read.
Before you enquire.
Do we need a researcher on the team already?
No. The day is built for teams that have no researcher, or one researcher and more questions than they can answer. If you do have a research practice, say so when you enquire and we will pitch the day further up.
Do we work on a real question or a worked example?
A real one. We ask in advance for a decision your team is facing, and the guide, the session and the synthesis all run against that. Teams leave with work in progress rather than notes.
Where does AI fit?
Mostly in synthesis and in first drafts of guides and write-ups, and we teach both. We are equally direct about the limits: a model will happily produce a confident theme from six transcripts that do not support it, so the day includes how to check its work rather than just how to prompt it.
Can it be combined with other in-house days?
Yes, and it often is. It pairs most naturally with complex journeys, because research tells you where a journey breaks, and with UX strategy, because a finding only matters if the organisation acts on it.
What results have your clients seen?
We do not know, and we will not invent a number. No client has ever given us before and after outcome data, so we hold none for any engagement. What we can tell you is who we have taught, what the day contains, and who delivers it. Judge it on the curriculum and ask us to walk your team through it first.
Enquire about this programme.
Tell us the decision you need answered, who would be in the room, and your preferred timing. We'll get back to you within 2 business days.