The Last 20% and Who's Asking Why?
Everyone can build now. Almost nobody stops to ask if they should.
I watched a PM on my team ship a prototype last month that was genuinely impressive. They’d used Vercel’s v0 to go from a rough idea to a clickable, styled, reasonably well-structured interface in about three hours. The layout was clean. The hierarchy made sense. The components were pulled from our system correctly. It was maybe 80% of the way there.
But that last 20% wasn’t even the problem.
Yes, the spacing had no rhythm. The transitions were abrupt in places where the product needed to breathe. The microinteractions were flat. But those were surface problems. The deeper issue was that nobody had asked whether a prototype was even the right artifact to produce at that stage. The PM had made three assumptions about user intent that we hadn’t validated. They’d skipped past a critical question about whether this flow needed to exist at all, or whether the real problem was upstream in the information architecture. They’d built a beautiful answer to a question nobody had confirmed was worth asking.
That’s the part that stuck with me. Not the visual gaps. The thinking gaps.
I didn’t feel threatened watching this. I felt the weight of a new kind of responsibility I don’t think most of us have fully named yet.
Here’s what actually happened while we were all arguing about whether AI would replace designers: design production got democratized, but design judgment didn’t. Anyone can make something now. Almost nobody new learned how to think well about what should be made, why, and for whom. And that gap, between what’s possible to produce and what’s actually been thought through, is now the entire playing field for our profession.
Designers aren’t becoming obsolete. They’re becoming stewards. Responsible not just for the quality of their own output, but for cultivating rigorous thinking and taste across an entire organization. For building the systems, setting the standards, asking the uncomfortable questions, and teaching the eye that lets good work happen at scale, even when they’re not in the room.
This is harder, more important, and less understood than anything we’ve done before.
What actually happened (and what we got wrong about it)
The narrative we were sold went something like this: AI and better tools will free designers from the drudgery of production work. You’ll stop pushing pixels and start doing “strategy.” You’ll think bigger. You’ll finally have time for the important stuff.
That’s not what happened.
What actually happened is that everyone else started producing design artifacts. PMs prototyping in AI tools. Engineers vibe-coding frontends. Founders building entire v1 products without a designer touching them. Marketing teams assembling landing pages from templates and AI-generated layouts. The volume of design-like output in most organizations exploded, and designers got pulled into a new role that nobody formally defined or prepared them for: quality control for an organization that suddenly thinks it can design.
And I don’t just mean visual quality control. I mean the whole thing. The decisions about what to build. The assumptions baked into the user flows. The information architecture that nobody explicitly designed but that emerged from a series of expedient choices. The system model that users are now expected to understand because someone built a prototype and it “worked” in a demo.
I want to be honest about something. I’m using AI workflows daily. They’ve made me faster, more experimental, more willing to explore directions I wouldn’t have had time for before. I am not writing this from a position of resistance. But I’m also still figuring out what this looks like, both in my own practice and at the organizational level. There is no clean playbook for this. Anyone telling you they have it all figured out is selling you a course.
Here’s the distinction that matters: democratizing access to design tools is genuinely good. I believe that. More people being able to express ideas visually, to prototype, to test concepts quickly, that’s a net positive for how products get built. The problem isn’t access. The problem is the quiet conflation of access with competence. The assumption that because someone can produce a thing that looks like a designed product, they’ve done the work of design.
They haven’t. And the work of design was never just about the interface. It’s about the thinking that precedes the interface. The questions asked before a single pixel is placed. The systems that hold everything together underneath. The “wait, should we even be building this?” that saves a team three weeks of wasted effort.
The gap between “looks like design” and “is designed well” is where everything that matters about our craft actually lives. And that gap is not a visual gap. It’s a thinking gap.
Stewardship, not gatekeeping
I’m deliberate about the word “steward” because language shapes how we think about our roles, and the alternatives carry baggage we don’t need.
“Gatekeeper” implies hoarding, that you’re standing between other people and the work, deciding who gets to participate. That’s not the posture. It’s also not sustainable. You cannot be a bottleneck for every design decision in an organization that’s moving at AI speed and expect to survive, let alone thrive.
“Arbiter” is closer, but it’s too judicial. It suggests you’re ruling on what’s acceptable after the fact. That’s reactive, and reactive quality control is always too late.
Stewardship is different. A steward is responsible for the health of something larger than themselves. They don’t own it. They tend it. They’re thinking about what happens when they’re not there, not just what happens when they are.
In practice, this means you’re no longer designing every screen or defining every flow. You’re designing the conditions under which good design can happen without you in the room. And “good design” here means the full scope: good questions asked early, good system thinking applied throughout, good judgment about what to build and what not to, and yes, good visual and interaction quality at the surface. That’s a fundamentally different job, and it rests on three responsibilities.
First, you set the bar. Not implicitly, not vibes, not “I’ll know it when I see it.” Explicitly. What does “good” mean here, for this product, this team, this stage of company? And the bar isn’t just aesthetic. It includes rigor of thinking. It includes whether we validated assumptions before building. It includes whether the system model makes sense to a user who isn’t in our Slack channels. Can you articulate all of that in terms a non-designer can understand and act on? If you can’t, your bar doesn’t exist in any operational sense. It’s just your taste trapped inside your head, which is useful to no one when you’re not reviewing every output.
Second, you build the infrastructure. Design systems, component libraries, token architectures, interaction patterns, yes. But also: decision-making frameworks. Templates for how to think through a new feature before jumping to a prototype. Shared language for talking about user needs, system complexity, and information architecture. The infrastructure of design is not just a component library. It’s the entire scaffold of thinking tools that help an organization make good product decisions.
Third, and this is the one most people underinvest in, you teach the eye. And I mean “eye” broadly. You help non-designers develop enough judgment to self-correct before review. Not just visual judgment, but the instinct to ask “have we validated this assumption?” before building, the sense for when a flow is adding unnecessary complexity to the system, the awareness that a prototype is a hypothesis and not a solution. This is the highest-leverage thing a designer can do in 2026, and almost nobody is doing it systematically.
The uncomfortable part of stewardship is acceptance. Things will ship that you wouldn’t have designed yourself. The question you have to learn to ask isn’t “would I have done it this way?” It’s “does this clear the bar?” Those are very different questions, and learning to care about the second one more than the first is the emotional work of becoming a steward.
Designers have always been educators: this just raises the stakes
None of this is entirely new. Designers have been educators for as long as the profession has existed. We’ve always been the ones explaining why whitespace matters, why this interaction pattern is better than that one, why “just make the logo bigger” undermines the hierarchy we spent three weeks establishing. But we’ve also always been the ones asking “who is this for?” and “what problem are we actually solving?” and “have we talked to anyone who would use this?” Those questions are design work. They always have been.
What’s new is the scale. And the urgency. And the consequence of not doing it well.
The list of people who now need design fluency (not design skill, design fluency) has expanded dramatically. PMs are prototyping with AI before a designer ever sees the problem, often locking in structural and architectural decisions in the process. Engineers are making real-time design decisions in code because the system doesn’t have a component for their edge case and they need to ship by Thursday. Founders are building entire products through vibe coding, going from idea to deployed app without a single design file ever existing. Content and marketing teams are creating customer-facing experiences using templates and AI tools that give them enormous creative latitude with zero creative guidance.
All of these people are making design decisions whether we like it or not. And not just visual decisions. They’re making decisions about how systems work, how information is structured, what mental models users need to form, and what problems are worth solving. The question is whether they’re making those decisions well.
The educator’s job here isn’t to turn everyone into a designer. That’s neither possible nor desirable. It’s to raise the floor. To give people enough understanding of why things work: why this spacing creates calm and that spacing creates tension, yes, but also why this system model is intuitive and that one requires documentation, why this feature solves a validated need and that one is a solution in search of a problem, why shipping fast is good but shipping the wrong thing fast is expensive. The goal is for their instincts to improve over time. For them to start catching problems themselves, not just surface-level visual problems but structural and strategic ones, instead of needing you to catch every one.
I’ll take a stance here: I would rather work with a PM who asks “should we build this at all?” before prototyping than one who can execute a flawless Figma prototype of something nobody needs. The first person has judgment. The second person has a tool. Judgment scales. Tool proficiency doesn’t, especially when the tools change every six months.
Who gets the keys (and what kind of keys)
If stewardship is the frame and education is the method, the practical question becomes: who do you actually empower to make design decisions, and which decisions?
My answer is that this isn’t a democracy. It’s an architecture.
Not everyone should be making the same kinds of decisions. The person assembling a page from existing components is doing fundamentally different work than the person defining a new system-level interaction paradigm or rethinking how information flows through the product. Treating these as equivalent (”everyone’s a designer now!”) is how you end up with an incoherent product held together by duct tape and good intentions.
I think about this in tiers.
Tier one is free reign within the system. Anyone (PM, engineer, marketer, founder) can use established components, patterns, and templates as intended. They can compose existing pieces into new configurations. The system itself is the guardrail. If the system is well-designed, the output will be at least acceptable. This is where most empowerment should happen, and it’s where a strong design system pays for itself a hundred times over.
Tier two is guided exploration. Collaborators can propose new patterns, new flows, new ways of solving a problem. But before those proposals become precedent, before they ship and become the thing the next person references, they get a design conversation. Not a formal review. A real conversation. “Here’s what I’m thinking and why. Here are the assumptions I’m making. Does this track?” More on what that looks like in a minute.
Tier three requires a designer in the room from the start. Net-new system paradigms. Significant UX flows that set the template for how the product behaves going forward. Decisions that affect the underlying information architecture or system model. Brand-defining moments. Anything that establishes a new pattern rather than applying an existing one. And critically, anything where the problem itself hasn’t been validated yet. This isn’t gatekeeping. It’s recognizing that the more a decision creates precedent or reshapes the system, the more it needs design stewardship. Because precedent compounds. One “quick exception” that bypasses the system becomes the reference point for twenty more. One untested assumption baked into a flow becomes the foundation for an entire feature area. And suddenly you’re not iterating on a product. You’re untangling a mess.
The principle underneath all three tiers is simple: routine application of existing patterns? Go. You don’t need me. Inventing new ones, or making decisions that reshape the system? Let’s think together first. That boundary, between applying patterns and creating them, between building on validated ground and building on assumptions, is where stewardship lives.
Guardrails are a design problem, not a governance problem
Most organizations treat design guardrails like compliance. Rules to follow. Boxes to check. A style guide PDF that nobody has opened since onboarding. This fundamentally misunderstands what guardrails are for.
Guardrails should be designed with the same rigor, taste, and intentionality as the product itself. When they work, they don’t feel like constraints. They feel inevitable. Like of course this is how it should be. The best guardrails are the ones people follow without realizing they’re following anything.
Here are the guardrails I actually care about, ranked by how frequently they get ignored in practice.
Problem validation. Did anyone confirm this is the right thing to build before we started building it? This is a design guardrail, and it’s the one that gets skipped most often now that prototyping is nearly instant. The speed of production has made it dangerously easy to skip the thinking. When you can go from idea to prototype in two hours, the temptation to “just build it and see” is enormous. But a prototype is not validation. It’s a hypothesis rendered in pixels. Someone needs to be asking “why this, why now, for whom?” and that someone should be a designer, not because designers own that question exclusively, but because we’re trained to ask it and trained to be unsatisfied with hand-wavy answers.
System coherence. Does this new feature, flow, or pattern make the overall product more or less coherent? Not just visually, but structurally. Does it introduce a new mental model the user has to learn? Does it create a second way of doing something that already has a first way? Does it make the system harder to understand? These are the questions that compound silently. No individual decision feels like a big deal, but fifty of them in a row create a product that feels like it was designed by committee. Because it was.
Interaction quality. Motion, feedback, state transitions, microinteractions. This is the layer that separates “functional” from “feels good,” and it is almost never systematized well. Most design systems nail the static states (here’s what a button looks like, here’s what a card looks like) and completely punt on the dynamic ones. How does the button respond to a press? What happens in the 200 milliseconds between clicking “submit” and seeing a result? These details are invisible when they’re done right and painfully obvious when they’re done wrong.
Experiential coherence. Does this flow feel like it belongs in this product? Not visual consistency. Emotional consistency. The pace, the density, the amount of friction, the moments of delight or absence thereof. A product can be visually consistent and experientially incoherent if different teams are building flows with fundamentally different assumptions about how the user should feel.
Accessibility as a floor, not a feature. This should not require a designer to enforce. It should be baked into the system so deeply that building something inaccessible is harder than building something accessible. If accessibility is still a line item that gets negotiated during sprint planning, your system has failed at one of its most basic jobs.
Visual consistency. Yes, this matters. It’s also the easiest to systematize, which is why most design systems stop here. Colors, typography, spacing scales, component libraries. This is table stakes. Necessary but nowhere near sufficient.
Here’s my stance on all of this: if your guardrails can be reduced to a checklist, they’re not guarding the things that actually matter. The hardest and most important quality signals (does this feel right? have we thought this through? does this make the system better or worse?) require human judgment. That judgment is exactly what stewardship is for. You can automate a linter. You cannot automate taste. And you cannot automate the willingness to ask “should we be building this at all?”
What review actually needs to become
The way most design organizations handle review is broken, and the acceleration of AI tools is about to make it more broken.
The typical setup: a biweekly or weekly design review meeting. Someone presents their work. A group of people give feedback. The work is either “approved” or sent back with notes. It’s formal, it’s scheduled, it’s structured.
And it’s almost always too late.
When someone can go from idea to working prototype in an afternoon (which is the reality now for anyone using AI tools competently) a biweekly review cadence means the thing is already built and everyone is emotionally invested by the time feedback arrives. You’re not shaping work at that point. You’re negotiating with sunk cost. And worse, the structural decisions, the assumptions, the system-level implications, those all hardened days ago. You’re reviewing the paint job when the foundation is already poured.
My position is the opposite of what most people expect: we need more reviews, not fewer. But radically lighter. Radically more casual. Less “formal presentation” and more “hey, take a look at this.”
The shift I’m advocating for is from review as a gate to review as a continuous conversation about quality, about thinking, about whether we’re solving the right problems the right way. The goal is to catch drift early, before a questionable decision becomes load-bearing infrastructure that’s expensive and politically painful to undo. Small, frequent touchpoints beat big formal presentations every single time. A five-minute check-in is worth more than a forty-five-minute review meeting where half the room is multitasking and the other half is waiting for their turn to present.
This is where I’ll make a specific recommendation: build a Loom culture.
A three-minute async video walkthrough where someone shows what they built and narrates their thinking (”here’s what I made, here’s the problem I’m solving, here are the assumptions I’m working with, here’s where I’m not sure”) is worth more than most synchronous review sessions I’ve ever been part of.
It respects everyone’s time. The steward can watch it when they have the headspace to give thoughtful feedback, not when a calendar slot dictates. It creates a record of design decisions and rationale that’s searchable, shareable, and referenceable. That means new team members can watch these and learn how quality conversations happen on this team. That’s education happening passively, without anyone scheduling a workshop. And perhaps most importantly, it lowers the stakes. When review is a casual Loom and a few comments, people share work earlier. When it’s still rough. When it’s still malleable. When the assumptions can still be questioned without anyone feeling like their work is being torn apart.
What should these lighter reviews focus on? Not pixel perfection. Not “does this match the mockup.” The questions that matter at this cadence are: What problem are we solving and have we validated it? Does this create precedent we’re comfortable with? Is this making the system more coherent or less? Is the design system being used well or being worked around? Does this uphold the standard we’ve set? All of that, asked conversationally, not inquisitorially.
The bigger reframe here is that review shouldn’t feel like submitting work for approval. It should feel like showing a colleague what you’re cooking and getting their honest read. The best feedback loops I’ve been part of aren’t designer-reviews-non-designer. They’re mutual. The PM shares a Loom of their prototype and the thinking behind it. The designer responds with thoughts on both the solution and the problem framing, maybe with their own quick iteration. The engineer flags where the interaction breaks down in implementation or where the system model gets complicated. It’s a volley, not a tribunal. And that collaborative energy is what makes people want to share early and often, rather than hiding their work until it’s defensible.
This only works if there’s psychological safety and shared language. Which loops directly back to education. The more your team understands why things work, the more productive these quick exchanges become. The vocabulary gets richer. The feedback gets more precise. The trust deepens. And critically, the conversations start happening earlier in the process, before the prototype, at the “should we build this?” stage, which is where design involvement has always mattered most.
One more thing on this: when prototypes are arriving at AI speed (sometimes multiple variations in a single day) lightweight review isn’t a nice-to-have. It’s survival. You physically cannot do a formal crit for every AI-generated iteration. But you can create a culture where people instinctively share, get a quick read, and course-correct before things harden.
The one place I do believe in more structured review is what I’d call a pattern audit. Separate from the day-to-day Looms. Maybe monthly. This is where you zoom out and look at how patterns are being used across the product as a whole and whether the system is holding up. Not to evaluate individual work, but to check systemic health. Are workarounds accumulating somewhere? Are new pseudo-patterns emerging organically that should either be formalized into the system or killed before they spread? Are untested assumptions from early prototypes now calcified into features nobody questioned? This is where the stewardship lens is most valuable: not in the daily flow of work, but in the periodic assessment of whether the infrastructure you’ve built, both the components and the thinking frameworks, is actually holding.
The honest tensions I haven’t resolved
I want to be straightforward about the places where I don’t have clean answers. Not because uncertainty is fashionable, but because I think pretending to have this figured out is more dangerous than admitting you don’t.
Speed versus craft. AI workflows are genuinely faster. I’ve experienced it. I can explore more directions, iterate more quickly, and get to a strong solution in a fraction of the time it used to take. But some of what happens in the slower process is meaningful. The time spent sitting with a problem, the friction of working through a system on paper, the subconscious processing that happens between work sessions. I don’t fully understand what we lose when we compress that timeline. I suspect we lose some things that matter. I just can’t precisely name them yet.
Letting go versus quality. Every time I empower someone else to make a design decision, I accept that some percentage of outcomes will be worse than what I’d have done myself. That’s the deal. The question is whether the aggregate outcome (more work shipped, faster, with broader ownership and less bottlenecking) is worth the quality variance. My answer is usually yes. But not always. And the cases where it’s not are hard to predict in advance.
Teaching taste versus imposing it. There’s a line between educating someone’s eye and colonizing their judgment. I want the people I work with to develop their own sense of quality, informed by shared standards, sure, but ultimately their own. Not just a downloaded copy of my preferences. The difference between “I taught you to see” and “I taught you to see it my way” is subtle and I’m not always sure I land on the right side of it.
Asking hard questions versus slowing things down. “Should we build this?” is the most important question in product development. It’s also the most unwelcome one when everyone is excited and the prototype looks great. There’s a tension between being the person who insists on rigor and being the person who’s seen as blocking progress. I believe deeply that asking the question is the job. I also know that how and when you ask it matters as much as the question itself. I’m still calibrating.
Individual versus organizational. I’ve built personal AI workflows that make me meaningfully more effective. Going from personal practice to team-level adoption is a completely different problem. It involves culture, trust, tooling, process design, and organizational change management, and the gap between “I figured this out for myself” and “I’ve figured this out for a team of twenty” is enormous. I’m deep in the middle of that gap right now.
I share these tensions because I think the design community needs more of this kind of honesty. The takes that perform well online are the confident ones. The definitive frameworks. The “here’s exactly how to think about this” threads. But the truth is that we’re in a transitional period and the people doing the actual work know it’s messier than the thought leadership suggests.
What I’m betting on
Despite the unresolved tensions, I have strong convictions about where this is heading and what it demands of designers.
The designers who thrive in this next era will not be the most technically skilled producers. Production skill still matters. You need to be able to do the work to maintain credibility and to know what good looks like at the detail level. But production alone is no longer a differentiator when AI can get you to 80% in an afternoon.
The designers who thrive will be the ones who can think in systems and articulate that thinking in terms other people can act on. Who can build infrastructure (not just component libraries, but thinking frameworks) that scales their judgment without requiring their constant presence. Who can teach with patience and hold the bar with conviction at the same time, which is a genuinely difficult balance because those two impulses often pull in opposite directions. Who can sit with imperfect outcomes in service of broader empowerment without either losing their standards or losing their minds. And who are willing to ask the hard questions early, before the prototype exists, before everyone is invested, when the asking actually has the power to redirect.
This is a design leadership skill set. And I mean that regardless of whether you have “Lead” or “Senior” or “Principal” in your title. A mid-level designer who does these things well will have more impact than a design director who hoards craft and creates bottlenecks. The title doesn’t determine the posture.
The organizations that figure this out will have something their competitors can’t easily replicate. A coherence. A feeling. Not just visual polish, but the kind of product quality that comes from rigorous thinking at every level: where every feature solves a validated problem, every system decision is intentional, every interaction feels considered, and every edge case feels like someone cared. That quality won’t live in the component library. It’ll live in the culture. In how the team talks about quality, how they interrogate assumptions, how they review each other’s work, how they make decisions when no designer is looking.
That’s the moat. Not the Figma files. Not the design system documentation. The culture of taste and rigor that a designer-as-steward cultivated and that now sustains itself.
Stewardship is the work now
We spent the better part of a decade fighting for a seat at the table. Advocating for design’s value. Making the case that we belonged in the room where decisions were made.
We got the seat. Now the question is what we do with it.
The seat isn’t for making more mockups at a higher altitude. It isn’t for being the person who makes things pretty after the real decisions are made. And it isn’t for being the bottleneck who has to personally approve every visual choice before anything ships.
The seat is for shaping how an entire organization thinks about and pursues quality. For building the systems that encode good judgment, not just good aesthetics. For teaching the people around you to see what you see and ask what you’d ask. Not so they can replace you, but so the standard holds even when you’re stretched thin, on vacation, or focused on the next hard problem.
The best measure of a designer’s impact has never been the work they personally produced. That’s the craft ego talking, and I feel its pull as much as anyone. The real measure, the one that matters at scale, is the quality of thinking and making that happens when you’re not in the room.