Flink Hub App · 2026 · Senior Product Designer

Designing the research process itself

An AI-augmented system that handles coordination so you can focus on insight

Project details are under NDA, so this case covers the methodology and leaves the product out.

Outcome & Impact

  • 8 interviews recruited, briefed, and scheduled in under a week, alongside regular product work

  • Every interview and debrief was recorded and fully traceable back to exact user quotes

  • The PM used the research findings to write the initial PRD drafts directly

  • The workflow was designed to be packaged as a reusable Claude skill for the broader team

Solo designer. No researcher.

I was the only designer on Flink’s internal Hub App, and that included running product research for a team with no dedicated researcher. Over time I had developed and refined my own research framework. I wanted to see how much of it could be systematized and automated with AI.

A new product initiative let me test that. The project was an internal tool for warehouse shelf configuration, an area that had existed only as CSV imports and developer-side code changes. It had no user-facing interface and no design involvement until then.

The overhead before the insight

Running research as a solo designer in an engineering-heavy team comes with a lot of overhead. Before a single interview begins, you have to identify the right people, recruit them across a busy organization, brief your collaborators, and prepare for each conversation.

Research as a system

A research process is a system with inputs, outputs, and handoffs at every step. Most of the overhead comes from the coordination and information retrieval around the thinking, and AI handles those tasks well.

The question I worked from was which parts of the research system Claude could operate, so that I could focus on the parts that need human judgment.

Full pipeline overview of the AI-augmented research operations system

Building the System

The system came together in roughly a week, built alongside interview preparation as part of the same work. Each piece was added when a real need came up.

Briefing and Scoping

I started the way I always do, by filling out my research briefing template with the project context, hypotheses, and goals. The next step was new. I created a Claude project and loaded it with the company documentation related to the initiative, including product specs, previous research, and internal strategy docs. With that context, Claude could act as a thinking partner for the project.

Identifying the Right People

I already had a clear sense of the kinds of people I needed to talk to. To speed up the cross-reference, I gave Claude the PM’s session notes and asked it to map who was most involved in the initiative and who the real end users were.

Claude surfaced around 15 people and gave its reasoning for each one. I checked each selection against that reasoning and 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 about their role, their day-to-day responsibilities, and how they used the product.

Claude then wrote a brief for each interviewee covering who they were, what their workflow looked like, and what angle they might bring. Using those briefs, I drafted a recruitment message for each person and sent it through Slack.

Preparing Collaborators

I recruited PMs and designers to join the interviews as timestamp markers. Sessions were recorded and transcribed, so each collaborator only had to mark the moment something important happened, which let us find it in the transcript later.

Once each collaborator confirmed, Claude added them to the calendar event, scheduled a debrief session right after the interview, and sent them an interview guide covering the session format and the interviewee. Claude also sent a condensed reminder with that day’s participant brief 24 hours before each interview.

During the Interviews and Debrief

Sessions ran about 30 minutes over Google Meet and were recorded and transcribed by Gemini. Collaborators marked timestamps when something stood out, such as a surprising answer, a tension, or a quote worth returning to.

Right after each session I ran a short debrief with the collaborator while the conversation was still fresh, and recorded that too. Both transcripts went into the same folder, ready for synthesis.

Synthesis

With both transcripts in hand, I asked Claude to surface research nuggets, meaning quotable insights drawn from what was actually said, anonymized and tagged by theme.

The nuggets went into a table in Confluence, linked to the research project page. People could reference them independently, and Claude could read them in later work.

Findings and Output

From the nuggets I compiled a findings document and built two presentations in Google Slides. A Claude skill configured to match Flink’s slide format and visual style generated them, and I reviewed and refined them by hand.

The detailed version went on the research page in Confluence. The anonymized version went to Flink’s product Slack channel, so the whole product organization could see the research. The PM used the findings to write the initial PRD drafts.

What became possible

I had thought of the interviewee briefs and the collaborator guide before. As the only designer running research solo, the investment never seemed worth it. With Claude the work shrank to review. The output was ready in minutes and I only had to check that 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.

Confidence in the quotes stood out across every session, because every interview and every debrief was recorded and transcribed. Every insight I presented traced back to exactly what a user said, which changed how I presented findings and how much the team trusted them.

More broadly, it showed that research operations can be designed with the same rigor as a product feature, with clear inputs, defined outputs, and AI operating the coordination layer so human judgment stays on what matters.