Process · AI Systems · Research
Designing the research process itself
An AI-augmented system that handles coordination so you can focus on insight
Flink Hub App · 2024–2025 · Senior Product Designer
Project details are under NDA. This case focuses on the methodology — not on the product.
Solo designer. No researcher.
As the sole designer on Flink’s internal Hub App, I was responsible for running product research across a team with no dedicated researcher. I had an existing research framework I’d developed and refined over time, but I wanted to understand how much of it could be systematized, automated, and made more efficient with AI.
A new product initiative gave me the opportunity to find out. The project was an internal tool for warehouse shelf configuration, a product area that had existed purely as CSV imports and developer-side code changes, with no user-facing interface and no design involvement until this point.
The overhead before the insight
Running research as a solo designer inside an engineering-heavy team creates a specific kind of friction. The work is valuable, but the overhead is high: identifying the right people to talk to, recruiting them across a busy organization, briefing collaborators, and preparing for each conversation all happen before a single interview begins.
Research as a system
A research process isn’t just a methodology. It’s a system with inputs, outputs, and handoffs at every step. Most of the overhead in research comes not from the thinking, but from the coordination and information retrieval surrounding it. Those are exactly the kinds of tasks AI handles well.
The question wasn’t “can Claude help with research?” It was: which parts of the research system can Claude operate, so I can focus on the parts that require human judgment?
Image placeholder — research_ops_system.svg (full pipeline overview)
Building the System
The system was assembled in roughly a week, built alongside interview preparation, not as a separate project. Each component emerged in response to a real need as it appeared.
Briefing and Scoping
I started as I always do: filling out my research briefing template with the project context, hypotheses, and goals. What changed was what came next.
I created a Claude project loaded with all available company documentation related to the initiative: product specs, previous research, internal strategy docs. This gave Claude enough context to be a genuine thinking partner, not just a text processor.
Identifying the Right People
I had a clear sense of the kinds of people I needed to talk to. I used Claude to accelerate the cross-reference: fed it the PM’s session notes and asked it to map who was most involved in the initiative and who the real end-users of the product were.
Claude surfaced around 15 people, including its reasoning for each one. That rationale let me do a quick sanity check on each selection before moving forward. I narrowed the list to 8: a mix of end users, one team lead, and two developers who had been managing shelf configuration directly in the codebase.
Recruitment
For each person, I asked Claude to pull context from Slack and our Confluence wiki: their role, their day-to-day responsibilities, and how they interacted with the product.
From that, Claude generated a brief for each interviewee covering who they were, what their workflow looked like, and what angle they might bring to the conversation. I drafted a recruitment message for each person using that context and sent it through Slack.
Preparing Collaborators
I recruited PMs and designers to join the interviews as timestamp markers. Since sessions would be recorded and transcribed, their job wasn’t to take notes. It was to mark the exact moment something important happened, so we could locate it in the transcript later.
Once each collaborator confirmed, Claude added them to the calendar event, scheduled a debrief session immediately after the interview, and sent them an interview guide with context on the session format and the interviewee. 24 hours before each interview, Claude sent a condensed reminder with the brief for that day’s participant.
During the Interviews and Debrief
Sessions ran for about 30 minutes over Google Meet, recorded and transcribed by Gemini. Collaborators marked timestamps when something stood out: a surprising answer, a tension, a quote worth returning to.
Immediately after each session I ran a short debrief with the collaborator while the conversation was still fresh. That discussion was also recorded. Both transcripts went into the same folder, ready for synthesis.
Synthesis
With both transcripts available, I asked Claude to surface research nuggets: quotable insights drawn from what was actually said, anonymized and tagged by theme.
The nuggets were stored as a table in Confluence, linked to the research project page, so they could be referenced independently and consumed by Claude in later work. The format made the findings both navigable for people and machine-readable for future synthesis.
Findings and Output
From the nuggets, I compiled a findings document and built two presentations in Google Slides, generated with a Claude skill configured to match Flink’s slide format and visual style, then reviewed and refined by hand.
The detailed version was published on the research page in Confluence. The anonymized version was posted in Flink’s product Slack channel, making the research visible across the entire product organization. The PM used the findings to write the initial PRD drafts.
What became possible
Things like the interviewee briefs and the collaborator guide were ideas I’d had before. As the only designer running research solo, the investment had never felt worth it. With Claude, the effort collapsed to review. The output was there in minutes; I just needed to make sure it was accurate.
The next step was to package this workflow into a reusable Claude skill, so other designers could run research the same way without building the system from scratch each time.
One thing stood out across every session: confidence in the quotes. Because every interview and every debrief was recorded and transcribed, every insight I presented could be traced back to exactly what a user said. That traceability changed how I presented findings and how much the team trusted what I was showing them.
More broadly, it proved that research operations can be designed with the same rigor as a product feature: clear inputs, defined outputs, and AI operating the coordination layer so that human judgment stays focused on what actually matters.