Stijn and Garifalia are Digital transformation practitioners at thewave.tech. We sat down with both of them to talk about one of the most persistent tensions in modern project delivery: how to integrate human-centered design into the fast-paced reality of agile.

Let's start with a question for both of you. When you're in a room with a new client team, what's the first misconception you usually have to clear up?

Stijn:

That Design Thinking and agile are two separate things fighting for space on the agenda. Teams often think they have to choose — 'we're an agile shop, we don't have time for all that discovery stuff.' But that's a false choice. Agile tells you how to deliver. Design Thinking tells you what to deliver. You need both.

Garifalia:

Mine is slightly different — it's the idea that Design Thinking is something you do once, at the start of a project, in a two-day workshop, and then you're done. In reality it's a mindset that should thread through the entire delivery. The tools change depending on where you are, but the underlying discipline — staying connected to the user, questioning your assumptions, testing before you commit — that never stops.

Stijn, you work a lot with PMs and delivery leads. What's the business case you make for investing time in Design Thinking before inception?

Stijn:

I don't sell it as a design methodology. I sell it as risk reduction. The question I ask is this: what does it cost your organization if you build something perfectly — on time, on budget, clean code — and nobody uses it? Usually that question lands hard, because everyone in the room has lived that scenario.  The business case is simple. Fixing a wrong assumption during a two-week research sprint costs almost nothing. Fixing it after three months of development is enormously expensive — in rework, in sunk cost, in team morale. Design Thinking moves the correction upstream, to where it's cheap.

And the benefits extend beyond user experience. When teams validate problems before committing to solutions, they’re far more likely to achieve the business outcomes they’re targeting — whether that’s increased adoption, higher conversion, reduced operational effort, or stronger customer retention.

And the output is concrete: by the time a project reaches inception, you have personas grounded in real research, a journey map that shows where the real friction is, a Design Brief that captures the problem clearly, and a backlog that reflects actual user needs rather than internal assumptions. Inception becomes an alignment session instead of a scope war.

Garifalia, you focus a lot on the empathy phase — the research. Why does that part get skipped so often, in your experience?

Garifalia:

Because it doesn't look like progress. Sitting with users, asking open questions, mapping what you hear onto an affinity diagram — none of that produces a ticket, a story point, or a deliverable that goes into a status report. Organizations reward motion, and empathy work is quiet.  There's also a confidence problem. The more experienced a team is in their domain, the more convinced they are that they already know the user. And they're right that they know a lot. But familiarity breeds assumption. The things you think you know without checking — those are your biggest risk. What I try to show teams is that five user interviews, done well, can change the entire direction of a project in two weeks. That's not slow. That's the most leveraged two weeks in the project timeline.

What does a well-integrated Design Thinking and agile process actually look like? Walk us through it.

Stijn:

The model we use is a shifted pre-inception phase. Before the project formally enters the delivery pipeline, you run a focused Design Thinking sprint — typically two to four weeks.

The objective isn’t to complete discovery once and for all. It’s to create enough confidence, evidence, and alignment to start delivery in the right direction.

That's where the empathy work happens, the synthesis, the problem framing.  The output is a Design Brief: who you're solving for, what the core challenge is, what the constraints are, and how you'll measure success. That brief becomes the foundation for inception. Your epics flow from it. Your sprint goals connect back to it.

From there, discovery doesn’t stop. Teams continue validating assumptions, testing concepts, and learning from user behaviour throughout delivery.

Garifalia:

And within delivery, Design Thinking doesn't disappear — it adapts. In sprint zero, you're validating concepts with low-fidelity prototypes. In the sprints themselves, you're testing with real users, not just running UAT with internal stakeholders.

The delivery process should include regular validation with real users, not as a nice-to-have, but as a core mechanism for reducing uncertainty and learning quickly.

The definition of done should include 'tested with real users' — not as a nice-to-have, but as a hard criterion.  The Double Diamond framework is useful here: the first diamond is the pre-inception work — understand the problem, define the challenge. The second diamond runs alongside agile delivery — generate solutions, test, refine.

And it’s important to remember that human-centred design isn’t only about desirability. The strongest solutions sit at the intersection of user needs, business viability, and technical feasibility.

When you see it that way, the two methods aren't fighting for space. They're sequenced.

What about teams that are already mid-delivery and realize something's off? Is it too late?

Garifalia:

It's never too late, but you have to be honest about what you're doing. You're not running a full process — you're doing a targeted intervention.  The most common one is what I call a Define reset. It usually happens when stakeholders keep changing requirements, or when user testing starts producing consistently negative results, or when the team realizes they're building the right feature for the wrong user. You pause, run a focused synthesis session using whatever research you have, and reframe the challenge. It's messier than building it in from the start. But it's far better than continuing to sprint toward a destination nobody actually wants.

Stijn:

From a delivery perspective, the earlier you catch it the better — obviously. But even mid-project, a half-day workshop where you revisit the problem statement, pressure-test your personas, and re-examine your journey map can unlock significant clarity. I've seen teams gain more alignment in three hours of structured problem framing than in three weeks of backlog refinement.

You both train BAs and PMs specifically. Why that audience?

Stijn:

Because they're the people closest to the problem definition. PMs decide what goes into the sprint. BAs translate business needs into requirements. If those two roles have a strong Design Thinking foundation, the quality of the entire delivery improves upstream. You don't need to retrain every developer — you need the people who shape the work to ask better questions before the work begins.

Garifalia:

And honestly, Design Thinking is a natural evolution of what good BAs already do. Requirements elicitation is empathy work. Stakeholder mapping is empathy work. The difference is that Design Thinking gives you a richer toolkit and a more explicit commitment to the end user — not just the sponsor, not just the business owner, but the person who will actually use the thing you're building.

Last question. What do you wish more teams understood about this approach?

Garifalia:

That it's not about post-its. I say that half-jokingly, but it matters. Design Thinking has an image problem in some circles — people associate it with colourful workshops and creativity exercises that feel disconnected from delivery reality. In practice, it's one of the most rigorous things you can do. It's about replacing assumption with evidence, and doing that systematically before you commit to a solution.

Stijn:

For me, it's that we're not asking teams to slow down. We're asking them to aim better. The goal is the same — deliver value, fast. Design Thinking just makes sure you're running in the right direction before you hit full speed.

And once delivery starts, it helps you keep checking whether you’re still heading toward the right destination.

Stijn and Garifalia are consultants at thewave.tech.

Have you tried integrating Design Thinking into your agile process? What worked, what didn't? Share your experience in the comments.