Research Enablement · 2026
Standing up a research practice on Apple TV
Four designers on Apple TV's enterprise tools were each running their own research with limited shared framework or common tools. I built those, with a process to go with them, using the AI skills my team had already governed, and proved it on a concept test for a new rights management platform. Six findings went into the next design round and the designer who moderated kept the skills.
01 — ProblemFour designers, four ways of doing research
No researcher had worked in this space before, and the designers had not waited for one. Four of them each covered a different product and each ran their own research, with limited shared framework or common tools.
The design was already moving. The design lead had built a clickable prototype with AI, informed by an earlier contextual inquiry, and the product team wanted their picture of the business process checked against real users. Three things shaped what I could set up:
So the useful question was never what I could find for this team. It was what they could keep doing once I moved on.
The bet
I could run one good study for them, or leave them with a way to keep running their own. Only the second one survives me moving to the next thing, so the study had to double as training.
02 — RoleWrote the study, someone else ran it
I wrote the plan, the session guide and the findings report, with AI doing the mechanical work to keep us light and lean. A second designer moderated the sessions, deliberately not the design lead who had built the prototype. Coaching her through facilitation was the point rather than a convenience: she wanted the tools for her own research afterwards, and she got them.
03 — ApproachDid our picture of the process match the work?
The product team had documented the business process and wanted it checked. That made the process the subject of the study and the prototype the instrument for getting at it, rather than the other way round.
Two rules held the whole thing together:
The planning and synthesis skills drafted and clustered. I decided what the findings were. Before any of it reached a participant, I ran synthetic users against the same prototype to see what a walkthrough would catch on its own.
Only one of the 22 was a defect worth fixing first. The rest were predictions the sessions could check.
Running it first was cheap insurance. A stale record or a mislabelled button is findable without a participant, and finding one in a session costs an hour I cannot get back.
How the synthetic pass worked
Then four real sessions
Moderated concept testing with a clickable prototype, four participants recruited through the product owner. Each session opened on the documented business process so participants could mark where their own work diverged from it, then moved to the prototype. The product team sat in as observers, which turned out to matter more than the findings did.
04 — FindingsSix findings from four sessions
The last of them is what the product team had asked us to check, and not the answer they expected.
What the walkthrough could not see
The synthetic run had produced 22 findings before anyone sat down with a participant, eight from the sales persona and fourteen from the legal one. Set against the findings report:
The split held all the way through. The two personas it ran as were the roles the design already assumed, so the broadest of the six was never available to it. Synthetic testing is only as good as the persona you can describe, and as a first pass over the low hanging fruit it earned its place, as long as someone with domain knowledge reads the output and catches what it invents.
05 — ImpactTen recommendations, and a process question
Ten recommendations went to the team, split into strategic, near term and quick wins, each tied to the findings behind it. The business process gaps went over as change management work rather than design work, which is not what the team expected to be handed.
What it left behind
06 — EvidenceSelected artifacts
The plan and guide, the findings report, and both synthetic walkthroughs. Complete documents rather than excerpts, but redacted: product and workflow names are generalized, colleagues appear as their function, and the interface screenshots are blurred.
07 — ReflectionHaving a researcher was new, and that was the work
Having a researcher in this program space was new for the product team, designers, and stakeholders. There was some skepticism, and there were learning curves, but involving them as observers in the interviews really opened the product manager's eyes to how enlightening research can be.
The team was already adopting AI, so it made sense to pilot our research AI skills with this study. Since it was a small study, the AI skills melded perfectly to assist in generating an approach and conducting synthesis, all with my oversight. The designer who helped facilitate appreciated the extra tools to help her own research in the future, while the product team was excited to get insightful findings about the business process, especially the need for change management as they introduce a new rights management process.
Daniel Farooqi · Staff UX Researcher · Product and team names generalized for confidentiality.