A few weeks ago, while catching up with an old friend at a tech meetup, we realized we were experiencing something remarkably similar: something is shifting, and behind these new tools, people are gathering to understand what’s actually happening.
Looking past the hype around “tool obsession” as some kind of religion, I think what’s happening is somewhat bigger. With enough perspective, we can detect the beginning of something significant that might result in a paradigm shift: moving away from rigid methodologies toward more flexible approaches.
There are some observations we can’t ignore here. First, the pertinent and necessary presence of prompt engineering. Second, tools with agents, the management and refinement of skills, and MCP protocols that help connect or bridge worlds that have always been more distant. Third, the adaptability of professionals in accepting that the playbook is becoming outdated. Fourth, a deep reflection on daily practice and the need to constantly iterate on what we do. And finally, the need for agnostic tools that give us freedom without dragging us into platform wars or tribal allegiances where we gain little as professionals.
An ode to pragmatism
Far from wanting to tear everything down in some revolutionary impulse, I’d like to think about design processes by taking a step back: whether it’s double diamond, design thinking, sprint, lean UX, etc. All design methodologies have clear stages and different emphases on analysis, ideation, and subsequent validation. That structure isn’t coincidental. It’s a natural way to approach complex problems.
If you’ve made it this far, let me be clear: this is an invitation to pragmatism, but not the “go with the flow” kind that appeals to creativity or experience. I’m referring to something different: a deep understanding of the why behind processes, comprehension and self-evaluation of our daily practice, and an analysis of the nature of problems, understanding them as entities with their own character and personality to decode.
That character is shaped by a combination of procedures (or their absence), delivery rhythms, needs and their clarity, the level of collaboration, the professionals involved, the amount of available information and existing knowledge, as well as how encapsulated or diffuse the problem itself is.
The non-negotiables
To be able to design in the context of living problems, what I find non-negotiable are:
- Clear functional documentation. Without this, we’re building on sand.
- Agreeing on the stack from the start. Early technical decisions define the boundaries of what’s possible.
- Collaboration mechanisms that allow for quick validation. And also for sharp pivots when necessary.
- Clear sources of truth and well-defined decision ownership. Knowing who decided what eliminates unnecessary friction.
- Building environments of trust and playgrounds for experimentation. Safe spaces to fail fast.
- Maximum visibility and transparency with features and decisions. No one should have to guess what’s happening.
I think it’s crucial to use AI with absolute diligence and pragmatism throughout this entire process: having agents that help with scoping and extracting information from stakeholders, building processes for generating and indexing knowledge so it can be part of the contextual knowledge shared by the team, developing ways to build and validate concepts quickly.
Getting your hands dirty
Today’s designer is a builder and must have pragmatism in their DNA, knowing that connecting the dots remains their responsibility. They must break out of silos and the habit of “that’s how it’s always been done” as soon as possible. Build a new professional profile with fewer labels and more adaptability. In plain terms, this means getting your hands dirty: learning challenging things at a technical level, searching and researching is no longer optional. I know it’s uncomfortable at first, but once you experience better product discussions, you understand very clearly why.
A key quality of pragmatism is knowing and managing the technical, product, and UX debt that inevitably arises from building products on top of moving problems.
Because at the end of the day, it’s not about abandoning methodology. It’s understanding that the materials we work with and the essence of problems are changing. This means knowing the rules, discerning when to apply them, when to adapt them, and when to set them aside. It’s recognizing that the map is not the territory, that each problem has its own character, and that no one comes out of this process the same as they went in.