How Which? scaled Problem Framing from a one-day training to a core decision-making practice

January 6, 2019
Dana Vetan

A case study from Which?, the UK's independent consumer champion, on how Problem Framing went from something their UX team was "winging" to a method embedded across the entire organization — and the specific decisions that made it stick.

If you're evaluating whether to invest in Problem Framing or Design Sprint training for your teams, this story gives you the honest account of what adoption actually looks like — the entry point, the scaling challenges, and what three years of deliberate investment produced.

The assumption most teams make

When organizations bring in a one-day training, there's usually an optimistic hope attached to it: that something will shift, teams will adopt the method, and things will work differently afterward.

That hope is reasonable. And it's also where most capability-building investments quietly disappoint.

The training lands well. People leave with sticky notes and insights. A few weeks later, the method is sitting in someone's Notion page alongside the sprint template nobody has opened since Q2.

The mistake is common and understandable. Teams treat a one-day workshop as the intervention, when in practice it's only the opening condition.

Which? figured this out — not all at once, but through a series of honest decisions about what it would actually take to make the method useful. The story is worth following closely.

Before Design Sprint Academy: "We were kind of winging it"

Which? — the UK's independent consumer champion known for product testing, investigative journalism, and consumer rights advocacy — didn't arrive at Problem Framing through a formal procurement process or a top-down mandate.

Rick Lipkit, Head of UX Design and Research, describes how it started: his team had been interested in Design Sprints and design thinking for some time. A couple of years before connecting with Design Sprint Academy, they attempted a problem framing session around their Trusted Trader service. It worked reasonably well. But as Rick puts it, they were winging it.

About a year later, they tried to run a full five-day Design Sprint around Black Friday. It was a significant undertaking, and it surfaced something important: they needed more structured support. That's when they found Design Sprint Academy.

The entry point was a Design Sprint Training program — not a one-day Problem Framing session. But what quickly became clear was that Problem Framing was often the more immediately useful tool for where Which? actually was.

The real problem they were trying to solve

Drew Shepard, User Experience Design Lead at Which?, describes the situation their team was in before Problem Framing became a structured practice.

Teams kept arriving with requests. Not problems — requests. Solutions-in-waiting, framed as asks: "Can you help us build this?" "We need a sprint on this." The UX team needed a way to filter those incoming requests and, where necessary, push back.

Problem Framing gave them that. As Drew explains, they could go through the process and say: "Maybe this isn't the thing we should be working on. Maybe we can pivot and work on something else to make a bigger impact."

Which? is a massive research organization. They probably knew about most consumer issues. But knowing which problems were worth focusing on to create the biggest impact — that was the harder question. Problem Framing helped answer it.

This context matters, because it explains why Problem Framing spread beyond the UX team. The challenge of knowing where to focus, and how to get diverse stakeholders aligned before committing resources, isn't a UX problem. It's an organizational one.

Where they actually used it

Once Problem Framing had proven its value in product and discovery work, Which? started applying it in situations that had nothing to do with UX in the conventional sense:

Setting OKRs — using Problem Framing to sharpen objectives and key results for teams and across the business as a whole, ensuring that goals were grounded in real problems rather than inherited assumptions.

Developing large-scale product visions — bringing cross-functional stakeholders through the process at the strategic initiative level, before any direction was committed to.

Program kickoffs — using Problem Framing at the start of major programs to align teams on what they were actually trying to achieve, and why, before work began.

This breadth of application is significant. It means Problem Framing stopped being a method the UX team used on discovery projects and became a tool for strategic alignment across the organization — with different departments, different seniority levels, and different types of decisions.

The three outcomes they measured

When asked how they measured the benefits of Problem Framing, Drew described three distinct and interconnected gains:

Focus. In an organization dealing with a broad range of consumer issues, identifying where to concentrate effort is critical. Problem Framing gave Which? a way to distill a large volume of ideas and incoming requests into a targeted set of initiatives. Defining the problem clearly meant resources went toward areas with the most potential impact.

Alignment. With diverse departments and goals, getting stakeholders moving in the same direction was a recurring challenge. Problem Framing sessions brought different perspectives together and built a shared understanding of what the team was trying to solve. That alignment didn't just last through the session — it influenced how teams collaborated and made decisions afterward.

Innovation. By thoroughly understanding and defining a problem before jumping to solutions, teams were better equipped to think creatively. The process encouraged looking at challenges from multiple angles and questioning assumptions. The innovation it produced was grounded — because it was rooted in real consumer problems, not in creative ideation for its own sake.

What the three-year investment looked like

Over the years following that initial engagement, Which? deepened their investment across three distinct programs:

Problem Framing Training — run repeatedly across product, research, and design teams. The goal wasn't to expose as many people as possible to a new concept. It was to build fluency across enough of the organization that the method could survive context-switching, team changes, and the pressure of a live decision.

Design Sprint Training — helping teams move from a well-defined problem into rapid prototyping and real-world testing. Problem Framing decides what's worth solving. The Design Sprint validates how to solve it. The two methods work in sequence, and Which? invested in both.

Advanced Facilitation Training — the step most organizations stop short of. Which? didn't want to rely on external facilitation indefinitely. They wanted trained internal facilitators who could run sessions themselves, adapting the method to real organizational challenges without bringing in outside support every time.

That three-layer investment is what made the difference between a method a few people know and a method an organization uses.

How it actually scaled

The spread of Problem Framing across Which? didn't happen through a formal rollout program. It happened through visibility and demonstrated value.

Once a handful of successful sessions had taken place — sometimes in glass-fronted rooms or open spaces where other teams could see the work in progress — other departments started paying attention. Curiosity spread organically. Advocacy teams, commercial groups, and strategic planning functions started asking whether Problem Framing could work for their challenges too.

The answer, consistently, was yes. But scaling created its own constraint: facilitator capacity. As interest grew, managing demand required ensuring there were enough trained internal facilitators and that the right stakeholders were aligned for each session.

This is where the Advanced Facilitation Training investment paid off directly. Building internal facilitation capability meant the method could scale without creating a permanent dependency on external support.

Lessons from the people who ran it

Rick and Drew shared several things they'd tell organizations just starting with Problem Framing:

✅ Flexibility in scheduling matters more than you think. Sticking rigidly to consecutive days made it harder to get the right people in the room. Spreading sessions out to match participants' availability — while ensuring key stakeholders could attend — produced better outcomes than forcing a standard format.

✅ Getting the right people in the room is non-negotiable. The mix matters: senior leaders, subject matter experts, and people who will be hands-on with implementing solutions. Without that balance, the session produces insight without ownership.

✅ Senior leaders need to be deliberate about their role. Depending on the context, they might participate as facilitators, decision-makers, or contributors. That role affects the dynamics and outcomes of the session significantly. Defaulting to "participant" without thinking it through is a missed opportunity.

✅ Internal facilitators need to understand their boundaries. They should facilitate the process without taking ownership of the project. Maintaining that distinction keeps the focus on the group's collective input and preserves the objectivity that makes the method work.

✅ Problem Framing improves with practice. The first sessions are harder. The method becomes more useful as teams grow more familiar with it. Organizations that expect immediate mastery usually give up too early.

What this means if you're building internal capability

The Which? story isn't exceptional because of what happened in the first training. The initial engagement worked — but most good trainings work, at least in the room.

What made this exceptional was the sequence of decisions that followed: to keep going, to invest in facilitation training, to apply the method beyond its obvious home in UX and product, and to build internal capacity rather than maintaining external dependency.

There's a practical question that most Directors and Heads of Innovation, Design, or L&D eventually face:

Are we buying a method for right now, or are we building something our teams can use independently, at scale, without depending on the same external partner every quarter?

Which? answered that question over three years. The distance between "we were winging it" and "it's part of how the organization works" was a series of deliberate investments — not a single transformative moment.

That's how a method becomes a practice.

For a deep dive, watch our fire side conversation with Rick and Drew.

Interested in building this kind of capability inside your organization?

Let's talk about what a multi-program path could look like for your teams.

Let's talk →