The design process is one of the first things any aspiring UX designer encounters: a clear framework for moving a product from problem to solution, usually illustrated as five stages, a diamond, or a cycle. Define, research, design, validate, iterate. It is taught with care, presented with authority, and has become one of the most universally recognised elements of the discipline.

Somewhere along the way, however, the process shifted from being a guide to being the point. The diagram moved from scaffolding for thinking to a credential in its own right, and that shift is where things start to go wrong.

In practice, experienced designers rarely follow the process in the way it is drawn; some projects move quickly to prototyping because the problem space is already well understood, whilst others spend far longer in discovery than the framework suggests  - because the brief is unclear, the user territory is unfamiliar, or the assumptions beneath the project have not yet been examined. The diagram accommodates none of this variation, which is fine, because it was never meant to. It was always a scaffold for thinking, not a set of instructions.

Tell me about your process is not helpful… Pick a project you're proud of, and let's talk about the process you used on that. - Jared Spool

The distinction is worth sitting with: not the process in the abstract, but the process on a specific problem, shaped by specific constraints and specific users.

The mythology of method

What is worth examining is how thoroughly the design process has been packaged and institutionalised  - in bootcamps, in job descriptions, in the standard UX interview question: “Walk me through your process.” The question implies that a designer’s value lies in the consistency of their method rather than in the quality of their thinking, which gets the relationship between the two almost exactly backwards.

A team can follow the double diamond with great discipline and still ship something that nobody uses; a designer can compress or skip stages based on what they already know and still arrive at exactly the right answer. What separates effective design from ineffective design is not adherence to a framework, it’s judgement  -  and judgement is developed through practice, not through compliance.

UX is not about the process, it's not about the tools. It's about YOU, the person learning and knowing how, and when to use them. - Tony Moura

Adaptability as craft

What develops in experienced designers over time is less a better process and more a finer sense of when the process applies, and in what form. They understand what goes wrong when discovery is skipped on an unfamiliar problem; they also recognise when additional research is producing diminishing returns, and when it is time to move. Neither of those things is written into a framework - both are the product of having got it wrong, and having paid attention.

This is precisely what Spool is pointing toward when he redirects the question from "your process" to "a project you're proud of." The interesting thinking isn't in the methodology itself; it is in the decisions made within it, around it, and sometimes in spite of it. The designer who holds the framework loosely - who can adapt the process to the shape of the problem rather than shaping the problem to fit the process - is simply doing more sophisticated work.

A fixed approach to the design process does not just limit creativity, it limits relevance; because the problems we are asked to solve change, the conditions around each differ, and no two projects will ever demand exactly the same response.

In summary

At its most useful, the design process is a way of thinking about the shape of a problem before we try to solve it; it provides orientation, a shared language, and a structure for involving the right people at the right moments. These are genuinely valuable things.

But the work itself - the decisions made, the assumptions challenged, the moments where we circle back three steps because something in testing changed the picture entirely - happens in the space the framework does not reach. As designers, holding the process loosely may be one of the more underrated skills we can develop; not discarding it, but understanding it well enough to adapt it, question it, and occasionally set it aside when the problem at hand has outgrown the diagram.