Originally presented at Design Thinking Basics, UX Lunch and Learn Series
There is a conversation that happens in almost every organization I have worked in, and it goes something like this: the developers are doing Agile, the designers are doing Design Thinking, and neither group fully understands what the other is doing or why it matters to them. The result is a product organization that is very good at shipping things fast and less good at shipping the right things.
That is a feature factory. And it is what happens when you treat Agile as a developer methodology instead of a whole-team practice.
They Are Not The Same Thing. That Is The Point.
Design Thinking and Agile are not competing frameworks. They are sequential ones, and understanding where each one starts and stops is what makes both of them work.
Design Thinking is for the beginning of the problem. It is how you figure out what to build and why. It is fluid, exploratory, and deliberately unstructured because the goal is to surface the right problem before anyone writes a line of code or adds a ticket to a backlog. The end product of Design Thinking is not software. It is clarity. A prototype, a hypothesis, a shared understanding of what the user actually needs and why what you were planning to build might not have been it.
Agile is for after you have that clarity. It is how you build the right thing efficiently, iteratively, and with enough structure that a cross-functional team can move in the same direction at the same time. The end product of Agile is tangible, working software shipped to real users.
Neither one works well without the other. Agile without Design Thinking upstream is a feature factory: fast, efficient, and pointed in whatever direction the loudest stakeholder was facing last quarter. Design Thinking without Agile downstream is a research exercise that never ships. You need both, in order, with the whole team involved in both.
The Whole Team. Not Just the Developers.
This is where most organizations get it wrong. Agile gets handed to the engineering team as a delivery mechanism, and Design Thinking gets handed to UX as a research methodology, and the two groups work in parallel rather than in sequence. Sprints start before the problem is defined. Backlogs get groomed before anyone has talked to a user. Designers are asked to produce high-fidelity mockups for features that have not been validated because the sprint starts Monday.
Agile was never meant to be a developer-only practice. The whole point of a balanced team is that product, design, engineering, and whoever else is relevant to the problem are moving together. When design is upstream and engineering is downstream and they are not talking, you are not doing Agile. You are doing waterfall with standups.
What This Actually Looks Like
Design Thinking gives you the problem worth solving. You empathize with users to understand what is actually frustrating them, not what you assume is frustrating them. You define the problem precisely enough that everyone on the team agrees on what they are trying to solve. You ideate without constraints, prototype quickly, and test before you build anything real. That process is messy and nonlinear and it is supposed to be.
Then Agile takes over. Now you have a validated direction, a hypothesis worth building toward, and a team that understands why they are building what they are building. Sprints have context. Backlog items have user stories that mean something. The thing you ship in your MVP is the thing you actually tested, not the thing someone guessed at in a requirements document.
The comparison is straightforward. Design Thinking: problem-solving and innovation, applied at the beginning of an initiative, fluid and exploratory, produces a prototype or validated hypothesis. Agile: efficient product delivery, applied after the team has a clear direction, structured and formal, produces working software shipped to users.
Different tools. Different phases. Same goal: building something that actually works for the people who have to use it.
The Question Worth Asking
The next time your team starts a sprint, ask whether the problem being solved was validated before it hit the backlog. Ask whether the people building the feature understand who it is for and why it matters to them. Ask whether design had a seat at the table before the tickets were written.
If the answer to any of those is no, you are not moving fast. You are moving in a direction. Those are not the same thing.
Amber Hansford is a Director of UX based in Atlanta. She has spent 15 years leading design organizations and facilitating Design Thinking workshops for product teams that thought they already knew what they were building. She writes about design leadership, DesignOps, and building teams that actually work.
