Radical
Pragmatism
On designing things that actually work,
for people who actually live in the real world.
My vision for the DMP design team
Written by
Tim Reerink, design at DMP
A personal manifesto for how I want us to design — and why it matters now.
What I am about to describe has a name: the tension between process-centric design and outcome-driven, product-led design. Most teams live somewhere in the middle without ever naming it. I want us to name it — because until we do, we cannot choose a side. This manifesto is that choice. It is not a critique of our craft. It is a call to protect it.
Part OneThe diamond needs room to breathe
The Double Diamond is not broken. Design thinking is not the enemy. These frameworks exist for a reason — they create space to understand before solving, to question assumptions before committing, to centre the human before the feature. When given the conditions they need, they work.
But here is the honest truth: we have rarely been given those conditions. We are handed initiatives that arrive pre-solutioned. We are brought in after the "what" has already been decided, and asked only to design the "how." We are working inside a waterfall rhythm while trying to run a discovery process — and then wondering why the diamond feels forced.
This is what I want us to name clearly — and then fight for. Not by abandoning the frameworks that serve us, but by demanding the conditions that let them work. Problem statements before solution briefs. Discovery time before delivery timelines. Design at the start of an initiative, not halfway through it. Our work should be judged by how users behave, how the product evolves, and how the team ships — never by how many diamonds we drew or how many workshops we ran.
Part TwoOwn the system like a product, not a library
A design system is not a trophy. It is not a sign of maturity. It is infrastructure — and like all infrastructure, it only has value when it is used. Ours has drifted into something else: a catalogue of aspirations, a missing app design system, and a component library too incomplete to be of real use to developers, tokens that document intent rather than reflect reality.
The shift I want us to make is a mental one. We stop thinking of the design system as a library we maintain and start treating it as a product we ship. That means usage metrics, not just completeness. Developer experience, not just design coverage. If a component is unused, we question it. If it slows the team down, we fix or remove it.
Wireframes, journeys, and component kits are means to an end, not trophies. Our real prototypes are releases. Our real design system is the one that lives in the code — and if it's not there, it's not done.
Part ThreeDesign lives in the app, not the studio
We are a product design team in an era where the dominant interface is a glass rectangle people carry in their pocket — held with one thumb, glanced at on the bus, used mid-conversation, trusted with real decisions. And yet our practice has remained rooted in big-canvas Figma flows, desktop-first thinking, and experiences designed for someone sitting at a desk with full attention.
This is the gap I want us to close. Not just by designing for smaller screens, but by taking deep ownership of what it means to live inside the app — layout, flows, microcopy, edge cases, polish, performance. Design does not end when the file is handed over. It ends when the experience is right in someone's hands.
Mobile is not a constraint. It is a discipline. And the moment you try to fit a real experience into four inches of screen, every unnecessary step, every unclear label, every deferred decision becomes visible. It is the best stress test we have. I want us to feel that pressure — and design through it.
Part FourThe stingray: a diamond built for the age of AI
The Double Diamond was designed in 2004 — before smartphones, before continuous deployment, before AI could generate a working prototype from a sentence. The Design Council has been rethinking it, and the model emerging is sometimes called the Stingray: a process that doesn't just diverge and converge twice, but accounts for the AI-augmented loop that now sits inside every phase of design work.
The Stingray acknowledges that discovery, definition, development and delivery are no longer clean sequential gates. AI compresses them. You can now go from a hunch to a testable interface in hours. Insight can feed directly into generation. Iteration cycles that once took weeks happen in a day. The shape of good design process has changed — and our mental model needs to catch up.
This does not make process less important. It makes it more important to be intentional. The risk is not that AI makes us lazy — it is that speed masks shallow thinking. The Stingray is a reminder that even in an AI-accelerated world, the hardest part is still asking the right question. Generating answers has never been easier. Generating the right question requires us more than ever.
Part FiveThe future of how we work: trios, prototypes, and vibe-coding
The idea of a small, cross-functional group working closely together is not new. But I want to be deliberate about what that actually means for us — because it is not always a designer, an engineer, and a PM. It could be a data analyst, a UX designer, and a developer. A PM, a researcher, and someone from operations. Whatever mix of people covers the right breadth of the product problem at hand. The composition matters less than the principle: small groups, shared ownership, the right spectrum of perspectives in the room. Not structured around handoffs, but around a question everyone is accountable for answering together.
For designers, this means something specific: we need to be fluent in the full language of the product, not just the visual layer. That includes being willing to prototype in code — not as a replacement for Figma, but as an additional tool for testing assumptions fast. Vibe-coding — using AI-assisted coding tools to sketch interactive ideas without deep engineering knowledge — is becoming a genuine design skill. The barrier between "I have this idea" and "here is something you can click" is collapsing. We should be on the right side of that collapse.
This is not about designers replacing engineers. It is about shortening the loop between thinking and testing. A designer who can spin up a rough interactive prototype in an afternoon, throw it in front of a user, and learn something real — that designer operates at a different speed than one who must wait for a sprint cycle to see their idea in motion.
Part SixThe skills we need now
This one requires honesty. The profile of a great product designer is shifting — and I would rather name that shift directly than let it become an uncomfortable undercurrent. We are not abandoning craft. We are expanding what craft means.
What I want to see in this team: strong UI skills — not just aesthetic taste, but precision. The kind of designer who understands spacing, hierarchy, motion, and interaction state at a level that makes engineers' lives easier and makes users' experiences feel considered. This is non-negotiable, and it is where we raise our bar first.
Alongside that: accessibility as a creative discipline, not a compliance checklist. The default AX solution — hard contrast outlines, blunt colour inversions, choppy UI patches bolted on at the end — is a failure of imagination, not a sign of rigour. I want our AX designers to push harder than that. To find patterns that meet the standard and look considered. To treat every accessibility constraint as a design challenge worth solving beautifully. The best accessible experiences are not the ones that sacrifice aesthetics for inclusion — they are the ones that prove the two were never in conflict.
And then the newer frontier: prompting skills and AI fluency. The ability to work with AI tools — not just as productivity shortcuts, but as creative and research partners. To write a prompt that generates a useful prototype. To use an AI to stress-test a user flow. To know when AI output is good enough and when it needs a human hand. This is not a specialist skill anymore. It is becoming table stakes.
The profile I am building toward: broad designers with deep AI interest. People who can move across product, visual, and research — and who use AI to go further in all three directions than they could alone.
The PrinciplesWhat radical pragmatism looks like in practice
Ship to learn, not to present
A prototype in someone's hands beats a week of internal debate. Wireframes and journeys are means, not trophies. Our true prototypes are releases. We gather real signal from real usage — and iterate from there. Done and learning beats polished and hypothetical.
Have an opinion
Designers who present three equal options and ask "which one do you like?" are outsourcing their judgment. We are here to recommend, advocate, and defend. We listen hard, then we decide. Alignment without a point of view is just noise.
Replace meetings with making
Every workshop and alignment session must have a clear outcome and a defined next step. If we cannot point to a concrete product change or new learning, we pause it. We default to doing, and use meetings only to unblock action. We protect time as if it were our own — because it is.
Design for the screen in the pocket first
Every experience we build should start on mobile and earn its way to larger surfaces. Constraints are clarifying. If it works at four inches, it will work everywhere. If it doesn't work at four inches, we haven't solved the problem yet.
Keep the system honest
A design system should reflect how we actually build — not how we imagined we would build. We audit ruthlessly. We remove what isn't used. We resist the urge to add "just in case." A smaller, honest system beats a large, aspirational one.
Fight for the right starting point
When we receive a solution brief, we ask for the problem behind it. When discovery is squeezed out, we make the case for why it matters. Good design process doesn't just happen — it has to be negotiated for, again and again, at the start of every initiative.
Prototype with whatever gets you there fastest
Figma when it fits. Code when it's faster. AI-generated when the question is rough. The tool is not the point — the learning is. If vibe-coding a scrappy interactive prototype gets real feedback in an afternoon, that is better design practice than a polished static deck reviewed in two weeks.
Grow toward the work that doesn't exist yet
Prompting, AI collaboration, accessibility-first thinking, cross-functional fluency — these are not extras. They are the direction the craft is moving. We invest in them deliberately, we share what we learn, and we build a team where deep curiosity about new tools is treated as a professional strength, not a distraction.
Part SevenGaps we need to fill
A manifesto without honesty is just a mood board. So let me be direct about what I see missing — not as a criticism of anyone on the team, but as a clear-eyed look at where we need to grow together.
The most pressing gap is deep visual and UI craft. There is a difference between someone who can use Figma and someone who obsesses over spacing, type scale, interaction states, and the feel of a transition. We need more of the latter. UI is not decoration — it is the layer where trust is built or lost in milliseconds, and right now we are not investing in it enough.
Alongside that: native mobile design as a dedicated skill. Designing for iOS and Android is not the same as making a desktop layout smaller. It requires understanding platform conventions, gesture patterns, safe areas, and the specific constraints of touch-first interfaces. This expertise does not exist strongly enough in the team today, and given our ambition to make app design a first-class practice, that has to change.
The third gap is one that barely existed as a discipline two years ago: conversational design — particularly for AI-driven chat interfaces. As our product integrates more AI, the ability to design the flow, tone, and structure of a conversation becomes as important as designing a screen. How does an AI respond when it doesn't know the answer? How do you onboard someone into a chat-based feature? How do you design for ambiguity? These are design problems, and we currently have limited experience with them.
Underneath all of this runs a single thread: AI tooling fluency. Not just using Copilot to write a summary or generating an image for a presentation. Real, working knowledge of how to integrate AI tools into a design practice — for research synthesis, for prototyping, for generating and testing interaction patterns, for keeping pace with a product that is moving fast. This is the upskilling moment for our entire team, and I want us to take it seriously and invest in it deliberately.
These gaps are not weaknesses to be embarrassed about. They are the agenda.
None of this means we stop caring about craft. Radical pragmatism is not an excuse for careless work — it is a higher standard. We don't worship any methodology. We care about what works here, now, for our users and our team. Theory is welcome — as long as it leads to better products and better experiences.
And this is not a solo act. Staying in the old ways is easy. Leaving them is not. So this is also a commitment to push upstream together — to ask for problem statements when we are handed solutions, to request discovery time when we are given deadlines, to make the case calmly and persistently that better conditions lead to better products.
We are not victims of our organisation. We are advocates inside it. We reward initiative over conformity, courage over comfort, and making over meeting. That is the kind of design team I want us to be.