Summary: Most design teams debate how much structure they need, but they are asking the wrong question. The real question is what kind of structure — and for whom. This article breaks down the difference between process and framework, explains why team maturity determines which one you actually need, and outlines the failure modes that appear when organisations get the balance wrong.
There is a version of this conversation that happens in almost every design team at some point. Someone proposes adding more structure — a clearer review stage, a defined handover format, a checklist before anything moves to production. And somewhere in the room, someone pushes back. Too much process, they say. We’ll slow everything down. We hired good people. Let them work.
Both sides are right. That is what makes it a genuinely hard problem.
The misunderstanding underneath the debate
Most teams conflate two things that are actually distinct: process and framework. They use the words interchangeably, as if more structure just means more of the same thing. But they solve different problems, and confusing them leads to either over-engineering teams that don’t need it, or under-supporting teams that do.
A framework defines direction. It tells you what matters, what to prioritise, and how to think about the work. It gives designers a model — a way of seeing problems that shapes how they approach them, even when the specific situation is new. A good framework produces consistent thinking without prescribing consistent steps.
Process defines execution. It tells you how to do something, in what order, with what outputs, reviewed by whom. It is a mechanism for making a sequence of decisions reliably, without relying on any one person to carry that reliability in their head.
Simplified: a framework tells you what. Process tells you how.
Why this distinction matters in practice
I have spent a significant amount of time building both — designing processes for teams that needed structure, and stripping structure back in environments where it was creating friction without adding value. What I noticed is that the right answer is almost always determined by one thing: the quality and experience level of the team you are working with.
In a strong, experienced team, a well-chosen framework is usually enough. The designers understand the problem space. They have the judgment to navigate ambiguity. They know when to escalate, when to push back, and when to make a call. Process in that environment tends to get in the way — it adds steps that experienced people already perform implicitly, and it creates the impression that the organisation doesn’t trust the people it hired.
In a team that is still developing — where experience is uneven, where designers are learning what good looks like, or where the organisation itself is still figuring out how design works — a framework alone is not sufficient. Without process, newer designers have no scaffolding. The work becomes inconsistent not because people aren’t trying, but because judgment takes time to build. Process, in that context, is not bureaucracy. It is the structure that allows less experienced practitioners to produce reliable work while they are still developing the instincts that will eventually replace it.
This is the part that needs to be said carefully: process supports people who are still building capability. It is not a permanent condition or a reflection of someone’s ceiling. It is a temporary scaffold. The goal is always to reach the point where the framework is enough.
The failure modes on both sides
Teams that run only on process without a strong framework underneath tend to produce work that is consistent but shallow. Everyone follows the steps. The outputs land on time. But nobody is asking whether the steps are pointed at the right problem. Process without framework is compliance without direction.
Teams that run only on framework without adequate process tend to be highly dependent on specific individuals. The work is strong when the right people are involved and inconsistent when they are not. Judgment doesn’t transfer easily. What one designer considers obvious, another considers optional. Framework without process is vision without reliability.
The organisations that get this right treat the two as a calibration problem, not a one-time decision. As the team matures, the balance shifts. Process gets lighter. The framework does more of the work. The goal is not to eliminate structure — it is to make sure the structure you have is the right kind for the team you actually have, not the team you wish you had.
The question worth asking
Most design leaders, when they think about team development, focus on skills — research capability, craft quality, systems thinking. Those matter. But the structural question underneath is just as important: does this team need more direction, or more scaffolding? Are they constrained by unclear thinking, or by unclear process?
The answer changes what you build. And building the wrong one — process for a team that needs vision, or framework for a team that needs support — makes everything harder than it needs to be.
More articles on Medium
More articles on Linkedin
