Looppanel helps researchers analyse interviews β€” faster.

Looppanel is a qualitative research tool: researchers upload interview recordings, the product transcribes them, and AI helps with note-taking, tagging, and insight generation. The premise is that the most painful part of UX research isn't the interviews β€” it's the analysis that comes after.

I joined as the product designer in mid-2022. Over the next two years I worked across the full product β€” onboarding, analysis flows, website, AI features β€” but the work I'm most proud of is the AI Insight Wizard, which launched in March 2025 after roughly 14 months of research, experimentation, and iteration.

This is the story of how it came to be.

We were losing deals because of AI perception β€” not AI capability.

In early 2024, a pattern kept appearing in our sales recordings and feedback calls. Prospects who had trialled the product would say some version of the same thing:

"We tried Looppanel, but we'll go with your competitor. Their AI features feel stronger."

What made this frustrating was that on paper, we had comparable AI features β€” sometimes more. We had auto-tagging, AI notes, and insight generation. But users didn't feel it.

To understand this properly, I did a structured win/loss analysis in January 2025 β€” pulling data from lost-deal calls, in-pipeline email threads, and trial feedback sessions across six companies. I also did a direct feature comparison against the competitor most often cited.

The pattern that emerged was clear: the gap wasn't in features β€” it was in the mental model. Our AI was built around the existing research workflow: upload β†’ tag β†’ generate insights β†’ write report. Step by step. Competitors were collapsing that into one: describe what you care about, get your answer.

Our approach

AI assists each step of the existing workflow β€” tagging, summarising, generating insights one at a time.

Technically capable. Felt like more work.
Competitor approach

Skip the steps. Tell the AI what you care about. Get a cited, structured answer directly from the transcripts.

Fewer features. Felt like magic.

We were busy perfecting the steps. They were perfecting the outcome.

I ran the analysis myself to feel the friction firsthand.

A "10x analysis" brainstorm in January 2024 was the starting point. But I didn't want to design a solution based on a whiteboard session. I needed to understand what analysis actually felt like at every step.

So I ran manual analyses on three live customer research studies, spending hours doing what our users did: reviewing transcripts, clustering themes, writing summaries, creating insight documents. I also spent weeks watching session recordings of users working through the product.

What I noticed:

  • Researchers wanted to feed the AI context β€” "here's what this study is about, here's what I care about most" β€” but there was nowhere to do that.
  • The hardest part wasn't generating insights. It was having confidence in them. Every AI output needed to be traceable back to something a real participant said.
  • Users weren't stuck on note-taking or tagging. They were stuck on the analysis-to-communication gap: getting from raw data to something they could share with their team.
  • The best sessions were when the researcher had a clear question. The worst were when they didn't, and the AI gave back generic themes.

This became the brief: build something where researchers can describe their study context and what they care about most, and get back a grounded, cited, shareable output.

I tested every competitor's AI β€” hands-on, project-by-project.

In March 2024, I spent time testing notably, qoqo, and Dovetail's analysis features with real research data. I wasn't just looking at screenshots β€” I was running actual projects through each tool to understand what the model could do, how the UX shaped the output, and where each fell short.

Notably
Strong structured output β€” templates drove the analysis. But rigid: if your question didn't fit a template, you were on your own.
Qoqo
Good at surface-level synthesis. Fast. But no citations β€” outputs felt assertive but unverifiable.
Dovetail
Polished analysis experience. Strong clustering. But still workflow-oriented β€” couldn't ask a direct question and get a direct answer.

The key insight from this exercise: none of them solved the context problem well. You couldn't tell the AI "this was a retention study, I care most about drop-off reasons in week two." The models were flying as blind as ours.

That gap β€” context-aware, cited, conversational analysis β€” became our opportunity. If we built something that let researchers set their context and ask follow-up questions, with every output backed by actual transcript quotes, we'd have something genuinely differentiated.

I wrote the prompts before I opened Figma.

Designing an AI feature requires understanding what the model can actually do. In February 2025, before working on visual designs, I spent a week experimenting with prompts directly in OpenAI Playground β€” testing them against real research data from our internal projects.

I was testing for several things: how much context the model needed to produce good output, what phrasing prevented over-generalisation, how to make the model respect frequency of evidence (not just presence), and how to keep outputs concise without losing nuance.

After multiple iterations, the core summary prompt looked like this:

// Summary generation prompt (v3 β€” final) Analyze qualitative user research data to provide an accurate, useful, and actionable summary of the study findings. The summary should be easy to read β€” someone with reading, comprehension, and attention difficulties should be able to comfortably comprehend it. The summary should: - Take into account "What I care the most about knowing" to structure content. - Talk only about what the interviewee/participant said, not the interviewer. - Consider the frequency of findings in terms of how many files/transcripts mention a topic β€” not how many times it came up in general. - Not include topics based on limited data. Only suggest things derived from multiple interviews. Put limited-data themes in a 'limited data' bucket. - Be in descending order of importance and frequency. - Use succinct bullet lists wherever possible. - Be short and concise. What I care the most about knowing: [user input] User study discussion guide: [DG] Interview transcripts: [transcripts]

The frequency rule was the most important detail. Without it, the model would surface a compelling quote mentioned once and treat it with the same weight as a pattern across ten interviews. Researchers hold themselves to evidentiary standards β€” the model had to too.

For follow-up questions, I also wrote a guardrail prompt to prevent the model from inventing answers when a question fell outside the transcript data:

// Follow-up guardrail prompt Answer the following solely drawing from the provided interview transcripts. If the ask is not relevant to the transcripts, reply with: "I couldn't find any information about that. Would you like to know anything else about your study?"

Treating prompts as design artefacts β€” iterating on them like prototypes, observing outputs like user tests β€” changed how I think about AI product design. The words you give the model shape the experience as much as the interface does.

Two versions. One team conversation. One direction.

On February 17, 2025, I shared two design directions with the team.

Version 1 β€” Lite

AI Summary with limited iteration

A lightweight chat experience: input what you care about, get a summary, regenerate with more context. No templates, no follow-ups. Fast to build, lower risk.

The bet: researchers just want the summary. Everything else is distraction.

Version 2 β€” Full

AI templates with follow-up questions

A richer experience: choose a template (Summary, Pain Points, Recommendations), input study context, get output, then ask up to five follow-up questions. The AI remembers the conversation.

The bet: the value isn't the first output β€” it's the ability to drill down. A summary is a starting point, not an ending point.

The team discussion that followed sharpened the direction. One teammate's reaction: "ability to iterate in certain ways is more valuable than multiple templates." Another pointed out that citations β€” every output backed by a clip from the recording β€” were the trust layer that would make the difference.

"Every citation is a video clip. I want an easy way to copy the summary with Looppanel clip links attached."
β€” From the product sync

We aligned on V2 as the direction, but scoped the first release carefully: start with summary generation only, ship follow-ups, defer citations to the next iteration (they required significant backend work β€” a hybrid search + verification pass for each claim). The feature would be called the AI Insight Wizard.

Six-step flow: open the AI tab, choose a template, enter what you care most about, get a summary from transcripts, ask up to five follow-ups, edit instructions to start a fresh chat
The v1 flow, from opening the AI tab to follow-up questions
Illustration of the wizard screen with context input, evidence-weighted summary and follow-up box
The summary view: each finding is weighted by how many interviews mention it, and thin evidence goes into a "limited data" section (illustration)

The design included several decisions worth noting:

I tested the staging build end-to-end before every release.

Once engineering shared the first staging build on March 10, 2025, I started testing it immediately β€” not just for bugs, but for the experience. Did it actually feel like the thing we designed? Did the AI output hold up on real projects?

I tested the full flow on two projects end-to-end. The summary generation worked. But I found a prompt issue in the follow-up flow: the model was answering questions that had nothing to do with the research data β€” it would just invent a response. I wrote a fix in real-time directly on staging and shared it with the engineer:

// Tested on staging β€” this phrasing prevented hallucinations // while still being helpful for relevant follow-ups Answer the following solely drawing from the provided interview transcripts. If the ask is not relevant to the transcripts, then reply with "I couldn't find any information about that. Would like to know anything else about your study?"

The rest of the build feedback covered UI, UX, and edge cases:

This kind of close involvement in build QA β€” not just reviewing screens but testing the actual product β€” meant issues were caught before they reached users, and the shipped experience was significantly closer to the intended design.

Shipped on March 18, 2025.

The AI Insight Wizard went live in production on March 18, 2025 β€” named and analytics-tracked under "AI Insights Wizard" from March 21. Here's what shipped in v1:

Core flow
AI tab inside a project β†’ template card β†’ "What I care most about knowing" input (600 chars) β†’ AI-generated summary from transcripts
Follow-ups
Up to 5 follow-up questions per conversation β€” the model uses the transcript + summary context to answer
Limits
30 conversations per workspace Β· 5 follow-ups per conversation Β· Projects must have <20 audio/video files
UX details
Edit AI instructions (prefilled modal) Β· Copy response Β· Suggested queries Β· "AI generated" disclaimer Β· Feature flag for a controlled rollout
Mar 18 β†’ Apr 7
Wizard launched (Mar 18) Β· analytics added (Mar 21) Β· second template shipped: "Identify Pain Points" (Apr 7)
Aug 2025
Citations proof of concept merged β€” the trust layer that was always planned, finally built five months after launch once the context architecture was ready
Deferred from v1
Citations Β· Pain Points / Recommendations / Answers templates Β· Disable chat on project updates Β· Versioning per template

Within three months of launch, the AI Wizard was winning the kinds of deals we had been losing. Market sentiment shifted. Where users once said "your AI isn't at par," they started saying "Looppanel's AI is the best in the market."

πŸš€
3 wks
From launch to the second template
πŸ“ˆ
14 mo
From first signal to launch
⏱
Hours β†’ Mins
Synthesis time for research teams

What this project taught me about designing with AI.

The most unusual part of this project was that design work started at the command line, not in Figma. Writing and testing prompts before drawing a single screen forced a different kind of thinking: what does the model need to produce a good outcome? What does the user need to feel confident in that outcome? Those questions shaped everything downstream.

Running the analysis myself β€” on real user projects, for weeks β€” gave me a kind of empathy I couldn't have got from user interviews alone. I felt the cognitive load of moving between transcript, tagging, and insight generation. I understood why people gave up halfway. That experience directly shaped the product decision to collapse the workflow.

The win/loss analysis was also a reminder that sometimes the most valuable design input isn't a usability session β€” it's a sales call. The pattern of why we were losing deals became the clearest possible brief for what to build.

What I learned

  • Prompts are design artefacts. The words you give the model shape the experience as much as the interface. Iterate on them like prototypes.
  • Do the thing yourself. Running analysis on real user projects gave me insights I couldn't have got from observation alone. The best research brief sometimes comes from lived experience of the problem.
  • Win/loss calls are a design input. The clearest possible brief came from understanding exactly why we were losing deals β€” not from a workshop.
  • Trust is the product. Citations weren't a nice-to-have β€” they were the thing that would make researchers actually trust and use the output. We deferred them for v1, but they were always the north star.
  • Scope to ship, not to impress. V1 shipped one template and five follow-ups. That was enough to prove the concept and start winning deals. The instinct to wait until everything is built is the enemy of learning.

"Designing AI isn't about replacing the researcher β€”
it's about giving them something they'd trust enough to actually use."