From Interviews to Decisions: Lessons from IDEO and frog

Interview notes need to lead to a decision someone can test. Published IDEO.org and frog methods help make that connection.

You can finish a set of interviews with pages of notes and several possible directions. I start by separating what people said from what we think it means. Then we can choose the next test.

How do you turn user interviews into product decisions?

It depends on what remains unclear. If the notes are scattered, compare and organise the observations. If the need is understood, frame alternative ways to address it. If a concept looks promising, test its assumptions and delivery requirements. Keep the original evidence accessible throughout, so the team can challenge the interpretation.

I am using public teaching material, checked as of October 2026. These methods explain activities we can adapt. They tell us less about how either firm runs a particular engagement.

What can you take from IDEO and IDEO.org?

IDEO's process page describes a flexible movement from framing a question through research and synthesis to testing ideas. It allows teams to revisit earlier work.

The Design Kit method cards come from IDEO.org. I use them here because they explain the work between collecting notes and deciding what to prototype.

I adapt those methods into the following steps:

1. Share observations while the interviews are fresh. Record what was said separately from your impressions.
2. Group related material and compare the accounts. Look for patterns that help explain the problem.
3. Write an insight that describes the need. Keep the proposed solution separate so other options remain available.
4. Turn the insight into a question that supports different answers. Use that question to choose what to explore.

These steps draw on sharing findings, finding themes, and creating insight statements.

Take a hypothetical onboarding service. Applicants send their documents, then wonder what happens next. I describe that uncertainty before suggesting a feature. An AI chatbot is already a solution choice.

The How Might We method helps keep a question focused while permitting different solutions. Ask how to help applicants understand what happens after submitting documents.

Now we can compare a status page with clearer confirmation. AI is another option if the questions need interpretation. The question gives us room to test which approach helps.

What does frog add to the delivery decision?

frog's Collective Action Toolkit guide describes activities for groups to define shared goals and act together.

Its original toolkit includes preparing interviews and comparing what people saw and heard. These are workshop methods. Their purpose is teaching workshop activities, rather than validating research coverage.

The Value Map guidance connects a measurable goal to delivery channels and resources. It brings the practical dependencies into the discussion.

Back to onboarding. A status page needs accurate information, and someone has to keep it current. If the records are stale, the applicant still has reason to wonder what is happening.

I bring the records owner into that discussion before implementation. What can they maintain? What makes a status change? Those answers can change the feature we are about to specify.

What does a published frog example show?

In Differentiating on Delight, frog describes research with a car-repair and oil-change chain. Customers were uneasy about whether maintenance was necessary and whether the work happened.

The design let customers see workshop activity from the waiting area. A concern from the research led to a physical service change. The article leaves its business effect unmeasured.

The same publication reports that 53% of 500 surveyed North American shoppers were entirely satisfied with their latest shopping experience. That survey concerned apparel and related shopping. It was separate from the repair-chain research.

As of October 2026, the published account remains available. Its survey result cannot establish that any particular product needs changing. Nor does the repair example establish a general return from interviews.

I take a practical point from that example. The team responded to a trust problem by making the work visible. I want that range of options open before writing software requirements.

How do you keep the evidence visible during synthesis?

I give each observation a source reference. Interpretation goes in a separate field. That makes it easier to check where the participant's account ends and our explanation begins.

When a theme starts looking convincing, I check the material that disagrees. Are we looking at another situation? Or does our explanation need work? Keep the disagreement available for review.

Also distinguish today's experience from a proposed one. IDEO.org's Journey Map card begins with a seed concept and helps choose prototypes. A concept map describes a possibility that still needs testing.

For today's service, I build the map from research and mark uncertain steps. A workshop can help expose assumptions. We still have to investigate them.

A tidy diagram can look convincing in a presentation. I keep the evidence close enough for someone to inspect. They should be able to challenge the explanation before it becomes a requirement.

What should the team decide before the session ends?

Choose a specific next test and name who will run it before the session ends. State which assumption it addresses and what result would change the direction.

For onboarding, I test whether an accurate status explanation answers the applicant's concern. I also check whether the operating team can maintain it. We need both answers before committing.

Use Before the PRD for the wider sequence, and The Journey Map Is a Decision Tool for a working map.

We carry that reasoning into Requirements and Iterative development through the process. See the available offers, or book a call if you have findings that need a clear next step.

I want the session to end with a test someone owns. That is how the notes start changing the product.

What else should you know about using these methods?

Are IDEO and IDEO.org the same source?

Attribute the Design Kit method cards to IDEO.org. IDEO also publishes its own process material. Name the publication behind the method you use.

How do interview notes become an insight?

Group related observations and explain the need behind the pattern. Preserve source references and check contradictory cases before choosing a direction.

Can a workshop validate a user journey?

A workshop can organise evidence or propose a future experience. Validate important claims about today's work with participant accounts and evidence of behaviour.

Does every discovery need a large design workshop?

Use the smallest working format that lets the team inspect the evidence and choose a test. The methods can inform a document or working session.