👯
Avoiding expensive mistakes through inclusive design reviews
March, 2026
There’s been a sudden and noticeable shift in how product teams create ideas. Almost overnight, anyone with a bit of AI magic can produce something that looks real — a skill that was once the domain of designers.
Engineers, PMs, even customers can now spin up interfaces in minutes, generate user flows, and ship something directly in code without ever opening Figma. That speed is exciting. It’s empowering. And while a little terrifying, it’s something we should lean into.
But there’s a discomfort that’s worth discussing.
When work is created quickly and in isolation — even with the best intent — it tends to only solve the immediate problem, but not always the system around it. Over time, those small, local decisions start to add up. Products become fragmented, inconsistent, confusing. Patterns diverge, UI becomes harder to maintain, UX starts to feel “off”. Eventually teams slow down… even though everyone feels like they’re moving quickly.
AI brings a new player to this game. But the problem itself isn’t new — every product at scale runs into this. Fortunately there’s been a simple and long-standing mechanism that world-class product teams rely on to manage it:
Design review!
Not novel, not my invention — design review (or critique) has been a part of successful product teams for as long as design has existed as a discipline. I’ve attended approximately 50,000 of them. For those who aren’t familiar, it’s not a checkpoint. Not gatekeeping, nor red-tape approval — but instead a moment where ideas are simply shaped and refined in the open.
And it’ not a fight. I’ve worked in environments where “sparring” is normalized, and I can’t overstate how divisive and counterproductive that becomes. The best reviews don’t feel like critique at all — they feel like conversation. Honest, vulnerable, friendly and respectful. Dare I say it… fun.
It’s a process worth re-visiting in 2026 — because for the first time, it’s no longer just relevant to designers.
The processDirect link
Usually once or twice a week, designers from across a business come together to share work — sometimes rough ideas, sometimes fully formed solutions, sometimes just a question that needs pressure-testing. What matters isn’t the format or polish of what’s brought in. It’s the act of putting the thinking, workings, assumptions and direction in front of others which brings the value.
When done well, something amazing happens. An idea that made perfect sense in isolation gets seen in the context of everything else. It gets shaped by how a product already behaves, what other teams are building, what has been recently learned through research, and what an organization is striving to become over time. This often shows up as “yes… and” thinking — building on ideas rather than shutting them down — and is what makes good work great.
Another misconception worth addressing: design reviews don’t typically add cost — they move cost earlier, where it’s cheaper. Without them, the same questions still show up… just later — usually once something has already been built and needs to be reworked. This is the principle behind effective collaboration: early and often. To ensure that cost burden isn’t deferred, a design review invites questions like:
🎯 What is the purpose of this idea?
✂️ Can it be simplified for v1?
🌱 Can this be extended on in the future?
🧭 Does this align with our principles and values?
⚠️ What are the edge-cases (no data, too much data, error etc)?
🚀 How do we market, onboard and upsell it?
💰 What does success look like?
🏗️ Does this build towards a shared vision?
➡️ What’s next?
In that discussion, work always gets better.
Where the real magic happens
Sometimes that’s all a designer needs to keep going. Sometimes it creates enough confidence to move straight to execution. And often — this is the important part — it leads to less. Less surface area, less ambiguity, less to maintain.
This is one of the biggest benefits of sharing ideas outside a siloed team environment — it forces us to ask harder questions early. Reviews tackle “is this introducing something new we’ll need to support forever?”. More often than not, that leads to consolidation — reusing existing patterns instead of creating new ones.
And when something new is necessary, it’s done deliberately. Teams work through how new objects fit into the broader system — whether that means evolving patterns, updating design systems, or working closely with engineering to understand tradeoffs. Nothing new is created in isolation… and nothing new is created lightly. Because everything we introduce becomes something we have to carry forward — like a mouth to feed 🌱
Importantly, almost passively, the review process results in people understanding each other’s work much better — not just what’s being built, but why. That shared understanding reduces the need for re-explaining, re-aligning, and rediscovering context later. And that’s where teams start to move faster for real, not just feel like they are. It’s what regularly produces those “Ah-ha!” moments, where everything just clicks.
Great outcomes don’t come from multiple designers co-designing in real time (we rarely do that), or from taste-based critique. Instead they come from shared clarity, simplicity, and confidence. That’s what produces momentum. And it’s what design review consistently produces.
The futureDirect link
What’s changed overnight is not the need for this process — it’s who can participate in creating the work, and who benefits from the process.
In the past, designers were often the only ones producing product concepts. Now, anyone can. And while that increases entropy, more ideas is always a good thing. But those ideas still have weight. They still introduce patterns, still affect how a product behaves, still carry long-term consequences and costs — which means they deserve the same level of scrutiny.
Whether something starts as a sketch, a Figma file, a block of code, an AI-generated prototype or even just a rough idea (a lot of our best conversations start with “this isn’t quite right, but just imagine…”) — if it’s shaping what we ship, it benefits from being part of this conversation. Not to slow things down, or enforce ownership — but as a way to make sure teams are building something that holds together — not just right now, but over time.
Skipping this step doesn’t remove cost — it just hands it to someone else later. Sometimes the customer, often the business… occasionally engineering, but eventually everyone pays.
So this moment doesn’t call for new processes or more rules — it offers opportunity to make sure product decisions are properly reviewed, regardless of how they’re created. Because the outcome has already proven to be successful.