Pratik Joglekar, writing for Smashing Magazine, on the core UX trap in AI products:

This is the risk at the heart of designing with AI today: probabilistic systems wrapped in deterministic interfaces. The AI offers a guess, the interface presents it as truth, and the user, or the organization, acts on it.

Humans are wired for deterministic thinking. We prefer to believe that past actions determine future outcomes. Flip a coin 999 times and get heads every time, the deterministic mind assumes the coin is rigged. The probabilistic mind accepts that the 1000th flip could still go either way. That second mindset is harder to hold onto, but it is exactly what designers need right now.

Products operate in complex, nonlinear environments, and AI is accelerating that complexity. When designers and product teams treat AI outputs as the answer rather than one of many possible answers, they build fragile experiences, and in some cases, like medical diagnostics or financial forecasting, genuinely dangerous ones.

That gap matters because the interface can make a confident-sounding answer look settled. The moment a chatbot, recommendation, risk score, or AI-generated summary hides the uncertainty behind the answer, it becomes a designed claim about how much the user should trust the system.

Joglekar’s practical advice is to treat the model as a signal generator, not a decision-maker:

What you receive is not truth. It is the most statistically likely outcome given the data available. Always ask whether past data meaningfully predicts future behavior. If additional context can improve the prediction, include it. Without context, the output is just one of many possible answers dressed up as the only one.

The trust piece lines up with a recurring AI product lesson: controllable over perfect beats confident and wrong. Joglekar again:

One of the hardest things for designers is making uncertainty understandable and actionable. When uncertainty is hidden, users treat AI outputs as facts. When it’s communicated clearly, trust increases.

Ranges, estimates, and confidence indicators go a long way. A delivery window of “Friday to Monday” tells the truth about variability without misleading anyone, whereas a specific timestamp that slips erodes trust every time. A face recognition feature that says “this looks like Pratik, is that right?” sets more honest expectations than one that just labels the photo with a name.

Communicating uncertainty does not weaken trust — it strengthens it. The goal is not to eliminate uncertainty but to design for it intelligently.

Every product has rooms users are not supposed to spend much time in. A 404 page is one. So is an empty project, empty folder, empty collection, empty dashboard, or empty search result.

Most teams treat these as edge cases. But edge cases are where brand voice has less room to hide.

Orlaith Wood, writing for The Subtext, makes the case through 404 pages:

I love 404 pages. Or more specifically, well-written 404 pages. I screenshot them and save them in a little folder on my desktop. Sometimes I actively seek them out.

Yes, I need to get out more.

A 404 page is the best test of a brand voice. It has to:

1. Admit something’s gone wrong
2. Convey useful information
3. Ideally not bore people to death

If a brand’s taken time to craft its 404 page, it tells me they care about my experience on their website – even the bits I’m not supposed to see. It shows commitment to a consistent brand voice. And consistency builds trust.

Consistency is hard. Brand voice can break all over the place. The companies with the shiniest ad copy are often the ones with the coldest and most corporate customer service comms, or small print. But a good brand voice should be able to flex to the functional. Microcopy, with a little creativity, can be a great conduit of voice.

That line about voice flexing to the functional is the bridge into product design. An empty state has the same basic constraints as a 404: something expected is missing, the user needs a next action, and the brand suddenly has to speak without sounding like a campaign.

It is one of those tiny surfaces where product strategy, UX writing, and brand all show up at once.

The best versions do not merely decorate blank space. They make the product feel considered at the exact moment the user has the least to do.

Wood on the no-joke version:

A 404 page doesn’t have to have a joke on it, if it doesn’t fit with the brand. That doesn’t mean it has to be mind-numbingly dull, like this afterthought from Visa:

The tragic broken image. The ominous dot dot dot. The shifting of blame. From one of the biggest brands in the world. Even ChatGPT could do better than this.

It doesn’t have to be that way. Global Payments could have fallen into the same dreary, robotic trap. Instead they’ve channelled their caring expert tone of voice to lift the mood.

That little ‘we’ll get you to where you’re going’ is subtle, but it’s a nice touch to ease a frustrating CX moment. (Full disclosure: I’m pretty sure my boss wrote this, so I’m basically just sucking up here.)

That distinction matters for empty states too. A B2B dashboard probably does not need a mascot or a punchline when there are no invoices, jobs, assets, or reports yet. It may need one calm sentence that explains what happened, one useful action, and a tone that feels like the rest of the product.

Wood on the brief:

If you have a website, take a look at your 404 page now. Is it missing a trick to channel your brand voice? If you can’t tell, maybe it’s a sign that your voice needs an overhaul, or that you’re missing one completely.

Writing error page copy is rarely in the creative brief. I think it should be. It’s important to show how a brand voice reacts when something goes wrong. Just as important, if not more so, than showing it on a tote bag, or a bus stop ad, or those fake billboards in Camden.

I’d put product empty states in the same brief: not as cute copy, but as one of the few places where voice, usefulness, and trust have to coexist in ten words or less.

Designers are used to thinking with their hands.

That sounds sentimental until you’ve spent time moving hierarchy and spacing around in a canvas. Some thinking happens because the thing on screen moves when your hand moves. It’s visual.

Quinn Keast, a designer writing in UX Collective, is getting at the cost that appears when that gestural loop becomes an instruction loop. He starts with the body, leaning on MIT design theorist Donald Schön:

Every tool becomes an extension of the user’s body. The user develops a spatial relationship with each tool.¹ In design school, we learned how to use pencils, pens, brushes, knives, and a whole bunch of materials and mediums before we were allowed to touch a computer. Mastery of one tool carries forward into other tools, but every tool has its own shape and movements that must be learned.

There’s a feedback loop where information comes back through your hands as you work and direct and change the course of creation. Schön describes this as “a conversation with the materials of a situation.”²

When the things you’re designing are themselves spatial — relationships of hierarchy and attention and movement — manipulating those things spatially is engaging with the problem directly, such that the moving is the thinking.⁴

This is why the “AI is faster” argument can feel too flat. Speed is one dimension. The other is the kind of attention the tool asks from you.

Keast’s distinction is not “old tools good, AI tools bad.” It is that the channel changed:

Big tool shifts have happened before, from the graphic designer’s drawing board to Photoshop, from hand-drafting to AutoCAD, even from Sketch to Figma. Each meant reskilling and churn and fatigue. You might argue these already introduced abstraction; the mouse is an abstraction of the pencil. But each still stayed continuous with the hand: I move, the proxy follows, and feedback still came through.⁵ The making-feel carried through each of these shifts, because the channel was still gesture.

The agent is the first shift that moves the making out of gesture and into language. I no longer manipulate a proxy whose movements mirror my own; I describe an outcome, and hand off the specifics to a system that decides them. The change is from gesture to instruction. It’s not another kind of canvas or another kind of pencil, but rather handing the pencil to an assistant and describing what you want the pencil to do.

That matters for design-to-code work because the thing we’re judging is no longer just the screen. Agents are good at producing a testable surface, but they can hide decisions that a canvas would have forced into view.

I appreciate that Keast doesn’t turn this into nostalgia for Figma. Keast brings in chemist and philosopher Michael Polanyi to name the cost of turning tacit judgment into language:

The act of prompting forces you to articulate into language what the hand knew without speaking — and, as Polanyi observed, “we know more than we can tell,” so that articulation is always incomplete.⁶

Making-feel is generative, where the thinking happens in the producing. Result-feel is evaluative, where I react to the result and how it feels to use. It’s no less engaged, but it’s a different type of engagement.

There’s two questions in my tiredness, and they have different answers.

If it’s a mismatch, in reaching for the agent when the problem wanted the canvas, will that fade, as I learn which problems belong to which layer, and prompting becomes a more well-worn tool?

Or is it a permanent cost, the tax that comes of translating tacit knowing into explicit instruction, of forcing what the hand knew into spoken words, every time, even when the agent is the right tool? That cost wouldn’t fade with skill, because it’s inherent to the tool itself.

I think it’s both — and it’s the latter that I keep thinking about.

For designers working with agents, the question is where prompting helps and where the work still needs the hand in the loop. Which I’d argue is still at the beginning.

Tony Le separates a usability problem from a clarity problem before the team starts redesigning screens:

A usability problem is when the user understands the promise but struggles to complete a task.

A clarity problem is when the user never forms a confident mental model in the first place.

They hesitate. They guess. They bounce. Not because the UI is hard, but because the product is not making a clear argument.

Le’s example shows the distinction in practice:

A few years back, I worked with a company building an internal SaaS product, something they planned to launch within about a year.

They did a lot of things right early on. They invested in research. They poured real money into development, easily in the five-figure range. The team was shipping.

Then onboarding came up.

The owner tried to use the product and got stuck.

Instead of treating that moment like a signal to test the build, align on how the system worked, and validate the onboarding path, the conclusion was immediate.

This is a UX and UI problem.

So the team did what teams often do under pressure. They rebuilt.

They revamped the system once.

Then they revamped it again.

And after all that effort, the real issue came into focus. The UI was not broken. The product lacked a shared, plain language model of how it worked. Key concepts were obvious to the people building it, but not obvious to the person trying to onboard into it. So when onboarding started, confusion showed up as hesitation and wrong clicks, and the team assumed the interface was the culprit. They revamped the system twice, only to learn the real fix was clarity, clearer concepts, clearer naming, and a clearer first win.

That is the part teams miss. The stuck user is real, so the design critique feels real too. But if the product has not made a clear argument, every screen-level fix is downstream of the wrong problem.

I see this most often in products that have accumulated internal language. The team knows what a feature is for because they have lived with the roadmap, the sales narrative, the customer calls, and the implementation details. A new user gets none of that. They get a label, a blank state, a primary button, and maybe a tour.

So clarity is not just better copy. It is the product choosing what it is asking the user to understand first. The interface can make that choice visible, but it cannot make the choice for you.

Amber Bouabdallah, writing in UX Collective, gets at the learning problem lots of designers are facing in this AI transition: the tools don’t produce one shared path toward competence.

Bouabdallah draws the line between deterministic software training and relational AI practice here:

Traditional software training works because the tools are deterministic. You learn where the buttons are, what the shortcuts do, how the system behaves when you click the thing. Mastery, in that world, converges — everyone arrives at roughly the same competence, following roughly the same path, and you can write a training deck for it. Mastery means knowing the tool’s correct use.

AI tools break that definition. Maggie Appleton — designer and anthropologist, now at GitHub Next — gave a talk in 2023 called “Squish Meets Structure” about designing products with language models, and the line from it that I love is her description of the magic-input box: it has “no affordances,” “no knobs or door handles.” The interface, she writes, “offloads a ton of cognitive labour to the user.” There is no correct use to learn. The tool meets you where you are. Which means what you bring to it — your instincts, your mental models, your accumulated taste, your willingness to iterate, your custom claude.md files — is the tool, as much as the model is.

So mastery hasn’t disappeared. It has shifted. With deterministic software, mastering the tool meant converging on its logic. With AI tools, mastering one means the opposite: learning to bend it toward your logic. Tailoring it to how you already want to work. Mastering an AI tool is the craft of making it amplify the specific strengths and experience you bring — so the work that comes out is sharper, and unmistakably yours. That kind of mastery is real, and hard-won, and worth teaching toward. It is just personal rather than universal. Divergent rather than convergent. Everyone’s version of it should look different, because everyone’s version is built out of a different person.

Her Salesforce examples keep that from becoming an abstract tool-training claim:

Six months in, Ningdan and I had designed for tool adoption and accidentally created conditions for something more intimate. Seeing each other work. Seeing the specific choices someone makes when the tool doesn’t behave, the workarounds they’ve invented, the mental models they’ve constructed to make sense of something genuinely new. A window into someone’s thinking — and into how each person was mastering these tools in a shape no one else’s would match.

And once you can see the thinking, you can see the worry too. Amanda Harris, a User Experience Architect on our team, named a tension directly in the post-mortem: “I worry that we’ll lose the exploratory aspects of finding what’s wrong with an idea by jumping so quickly into hi-fi prototyping.” That’s not resistance to new tools. That’s a designer protecting something she knows matters. Hearing it voiced — in a room where everyone is nominally learning the same things — is only possible in a setting small enough and safe enough for honest uncertainty.

The anxiety designers are feeling is a signal, not a weakness.

And Bouabdallah closes by naming the training layer her team actually designed:

The tools will keep changing. They will keep arriving faster than any module can be written, any best practice can be documented, any official curriculum can ratify. It is tempting to treat the peer layer as a bridge — something to lean on until the real training arrives. But the real training is not coming, because there is no fixed competence to train people toward. As long as the tools keep moving, the peer layer isn’t the bridge. It’s the ground.

We did design how designers master AI. We just found that mastery wasn’t what we thought it would be. Not a competence everyone arrives at, but a practice each person builds — bending a generic tool toward their own strengths, their own experience, their own way of working, until the work it helps them make is sharper and theirs.

Nicole Alexandra Michaelis, catalogs the job titles opening up as AI takes over the production work. Titles like “AI Design Consultant” (aka forward deployed designer), “Agentic UX Architect,” and “Trust Designer.”

These new titles are flashy, as she says, and I’m wary of crazy titles as I believe “designer” is a good catch-all. Michaelis seems to agree:

The “Product Designer” used to be the top of the crop, working with content designers, motion designers, UI designers, service designers, and more. But all of these titles had one thing in common: deeply strategic design thinking. While product design was often treated as the most T-shaped profile amongst designers, I always believed any (good) designer could shift in and out of skills and ways of working quickly, independent of their specific title.

The constant she identifies—deeply strategic design thinking—is the job; the titles are what we print on the business card in any given season. I’ve watched these labels multiply over the years, and the strong designers always moved between them regardless of title.

Take the Trust Designer:

The Trust Designer focuses entirely on transparency. They translate complex cryptographic or algorithmic verification into instant, split-second visual signals. They design the metadata tags, watermark indicators, and explainability mechanisms that show consumers exactly why an AI recommended a specific product or how a piece of media was verified.

The work here is genuinely needed. Translating something invisible—verification, provenance—into a split-second signal a human can trust is design at its core, not pixel-pushing. This is the part worth taking seriously, regardless of what we call the person doing it, or that it’s its own full-time job.

Michaelis again:

Ultimately, this shift is incredibly empowering for the creative community. The lesson of the AI age isn’t “learn to code or get replaced.” It is that design is moving away from the mechanics of pixel production and shifting heavily toward cognitive psychology, systems thinking, and business orchestration. And I would argue, most of us loved that part of the work most anyway.

She’s right about where the work is heading, and the only thing I’d watch is the title proliferation. The strategic judgment underneath is the same craft it’s always been, whatever we end up calling it.

The AI job grief piece was about what happens when old roles stop feeling stable. Sarah Gibbons, writing for Nielsen Norman Group, gets at the next question: what are we actually supposed to call the new work?

When someone says “AI design,” everyone in the room pictures something different.

One person is thinking about using AI to generate component variations for a design system. Another is designing a chat interface. A third is structuring data so an AI agent can parse it. A fourth is defining an LLM’s behavior.

They all fall under “AI design” but they are not the same work.

I see this in job postings, LinkedIn posts, and conference talks. Someone says, “We need to figure out our AI design strategy,” and every person at the table nods — while imagining a completely different thing. Six months later, everyone’s frustrated because the “AI-design initiative” was not what they expected. 

The conversation around AI and design is forking. What used to be a single (admittedly vague) topic has split into at least four distinct orientations. Each one focuses on a different type of design work, sits in different organizational structures, and uses different definitions of what “good” looks like. Most teams are staffed for only one of these orientations, confused about which one they’re doing, or trying to dance between all of them without realizing it.

Gibbons’s agent-facing category moves the taxonomy beyond the human interface:

This one is going to feel like a departure from user experience. Stay with me.

In this type of work, you design content, data, or interactions that AI agents (not humans) will read, parse, or act on. You’re building the infrastructure that autonomous systems navigate. If AI agents are the self-driving cars, you’re designing the roads, the signage, and the lane markings. AI agents are your users.

That might mean structuring product data so a shopping agent can compare options on behalf of a user, writing instructions that an AI assistant will follow, or optimizing content for AI search and discovery instead of (or in addition to) human search and discovery.

Some of this infrastructure won’t even be human-readable. A road sign designed for AI-controlled vehicles might encode information in ways no human driver could parse — data transmitted via radio or embedded in nonvisible parts of the spectrum. The “user” of that sign is an agent, and the design constraints are entirely different.

This is the orientation most design teams are still ignoring, but mostly because many organizations don’t have anyone explicitly responsible for how AI agents experience their product. Which means it’s either not happening, or it’s happening by accident inside an engineering team with no design input.

Designing for AI agents matters because it involves design decisions. What data gets exposed? How is it structured? What can an agent do versus what requires human confirmation? These shape the end-user experience just as much as any interface, they’re just one layer removed.

She then ties that category shift to the market for design expertise:

Understanding which type of AI design you’re building expertise in matters because the market is moving fast. Right now,  few designers have deep experience across multiple orientations. However, this window won’t stay open for long. Within a year, many more designers will have meaningful AI experience. Those who build depth in a specific direction now will have a significant advantage over those who stay broadly “AI-adjacent.”

Here’s where the field is right now:

Most designers today are using AI as a tool in their workflow. A growing number are designing AI products and features. Very few are designing for AI agents or designing the AI itself.

The demand for those last two is growing. The supply of designers who understand them barely exists. So, if you’re a designer, its an opportunity gap that’s widening.

Mozilla.ai’s Alejandro Gonzalez asks a useful question for designers working through agent-native software: what is the agent actually editing in the first place?

He starts with Claude Design but the piece is really about the old software contract underneath most productivity tools:

Most human-computer interaction has been built around two patterns: issuing commands (typing, clicking, speaking) and manipulating representations (dragging, resizing, arranging, formatting). Every productivity tool ever built is designed around one or both of those. The keyboard, the mouse, the touchscreen. That is the full vocabulary. The interface and the product were, for practical purposes, the same thing.

This is a useful distinction for designers because it doesn’t treat UI as decoration. It treats UI as a historical compromise: the thing humans needed in order to reach the state underneath. Agents put pressure on that compromise because they don’t need the same surface.

Gonzalez is careful about the transition, though:

This is useful. More than useful, it is probably necessary. The world already runs on existing software. Companies have years of organizational knowledge embedded in Gmail, Slack, Jira, Salesforce, Notion. If agents are going to be helpful today, they need to work inside that world.

That is the bridge.

But the bridge is not the destination. Agents using existing apps help bring AI into the current software stack. Apps built for agents may change the shape of the stack itself.

And there is something more valuable in that process than just short-term utility. Watching where agents struggle with existing interfaces, where the translation between intent and UI operation is most painful, is probably the most honest way to find where the structural opportunity is. The friction is the signal.

The agent failing to use a legacy screen isn’t only a product bug; it may be a map of where the product’s abstraction is wrong. For design teams, that shifts the work from polishing the path through a tool to naming the real object of work.

Gonzalez’s product-strategy example makes that abstraction concrete:

The source of truth for a product strategy is not the slide deck, the roadmap doc, the ticket board, or the dashboard. It is the strategy itself: the goals, the bets, the risks, the owners, the metrics, the decisions. Everything else is a view. The memo, the board deck, the launch checklist, the customer brief are renderings of the same underlying object, shaped for different audiences.

A product launch is not a Notion doc, a Linear project, a slide deck, and a dashboard. It is a product launch.

In Gonzalez’s framing, the deliverable is no longer the deck, the board, or the dashboard. The durable thing is the structured model that can be rendered, checked, diffed, approved, and exported.

That is the part that changes the designer’s job. If the source of truth is a structured object instead of a visible artifact, then design has to specify the object: its fields, constraints, permissions, states, failure modes, and views. The screen becomes one projection among many. A human may need a deck, an agent may need a schema, a manager may need a dashboard, and the system needs a versioned record of what changed. Those are not separate products if they are all renderings of the same underlying thing.

Gonzalez closes by keeping the old tools in the frame:

The old tools will not vanish quickly. They have distribution, habits, enterprise contracts, file compatibility, and decades of user training on their side. But the center of gravity moves. The work happens in the agent-native system. The legacy app receives the export.

I do not think this transition will be clean. The old world will remain around us for a long time. People will still export PowerPoint files, update spreadsheets, paste things into email, and manage work through tools that were designed before any of this existed.

But that feels increasingly like a transitional phase.

The more interesting future is not only agents operating apps. It is applications designed so agents, humans, and existing tools can all work with the same underlying objects.

Not because every app disappears but because the source of truth may move.

Jakob Nielsen starts from OpenAI’s new $4 billion consulting arm and its acquihire of 150 Forward Deployed Engineers, the kind who embed with a client instead of building from headquarters. His argument is that they solve the wrong level of the problem: you can speed up the work without changing it. The missing counterpart he proposes is the Forward Deployed Designer.

Nielsen draws the line between faster individual work and a faster business:

With AI, the old workflows must no longer be treated as the design brief; they must be questioned at the root. AI is, in fact, a great productivity enhancer even when used in the traditional way to increase the efficiency of individual employees performing the same tasks as always, just faster and better. A paralegal can summarize a legal brief in seconds; a junior developer can write boilerplate code instantly; a digital marketer can generate campaign copy with a single prompt. We can typically improve that employee’s performance on those specific rote tasks by roughly 40%.

But at the company-wide level, such local productivity gains rarely translate into substantial profit gains and shareholder value. When you have a long chain of steps and optimize only a few, the delay simply shifts to the remaining steps, which will dominate the overall time to solve the underlying problem.

Nielsen again:

Once AI removes the cognitive bottleneck, a different bottleneck appears: authority. The limiting question becomes not “Can the system know what to do?” but “Is the system allowed to do it?” AI-native workflow design must therefore redesign decision rights, escalation rules, audit trails, and accountability boundaries. Otherwise, the organization merely replaces slow human cognition with fast machine recommendations waiting for the same old human permission structure.

Taras Bakusevych closes his walkthrough of ten dying UI patterns on the heuristic that matters:

Execution UI: Interfaces that help humans perform deterministic work — entering data, configuring rules, following process steps, executing repetitive operations. 🟠 Shrinking. As AI automates execution, these surfaces lose their reason to exist.

Judgment UI: Interfaces that help humans evaluate, guide, and correct work done by machines — reviewing outputs, verifying changes, understanding reasoning, intervening at exceptions. 🟢 Growing. As AI takes on more autonomous work, humans need better surfaces to supervise it.

The supervision problem is what Jakob Nielsen called evaluability—the new central UX metric—and Bakusevych is doing the screen-by-screen translation. Every pattern in his list gets re-examined under one question: is this surface helping the human do the work, or helping the human check the work?

The HubSpot quote flow makes the friction concrete:

Creating a single sales quote in HubSpot requires navigating seven sequential screens. The rep manually selects the contact, adds company details, configures line items, chooses signature options, sets payment terms, picks a template, and previews the result — before a single quote reaches the buyer. Each step assumes the system doesn’t know information it already has in the CRM.

Bakusevych’s replacement gives the rep a different role: review what Shopify Sidekick assembled, correct what’s wrong, ship.

That’s the test he leaves you with. Open one screen in your product and ask which job it’s doing. If it’s interrogating the user for context the system could have inferred, it’s on the shrinking side.

Nathan Beck, a product designer in Amsterdam, opens his essay with the title “The death of design” and an immediate retraction: “LOL only jk design still alive.” Then he spends a few thousand words on why, walking through what AI tools actually do to a working designer’s day and what they conspicuously do not do.

The pivot quote is buried two-thirds in:

If you call yourself a designer and—be honest with yourself—the bulk of your role has been the production of flat pictures of user interfaces, then I’m sorry to break it to you, but you are not designing. You are styling.

That line is the whole post compressed. Beck is not arguing that AI threatens designers. He is arguing that AI threatens styling, and that a lot of people who call themselves designers have been styling for a decade and are now discovering that the part of the job AI is good at was the part they were doing.

What’s left over, in Beck’s telling, is the reflective work: the thing that happens during design, not in the final file. He quotes Kaari Saarinen on output isn’t design:

In the same way that one writes in order to understand what one is writing, one designs in order to understand what one is designing. As Kaari Saarinen explains, “Working visually keeps me close to the problem and is slow enough [sic] gives me time to think while I work. Moving things around, testing relationships, and refining structure is not separate from the thinking. It is part of how clarity emerges.”

This is the part the “designers are cooked” discourse misses. The understanding accumulated while making the Figma file was the asset all along. The file was the receipt.

Beck has a second argument running underneath the first: AI output, on its own, is aesthetically average. He quotes Nick Foster’s Dezeen piece on what software feels like after a decade of optimization:

The apps I use to hire plumbers look and feel remarkably similar to those I use to watch skiers do backflips. Every brand feels the same, every function feels the same, every interaction feels optimised, streamlined and joyless. By any measure, these pieces of software are miracles of engineering and triumphs of logic, yet they feel profoundly underwhelming to live with.

A designer who only ever produced flat pictures of those interfaces has been replaceable by a model for a while now. The judgment about which of those generic outputs should ship and which should be thrown out and rebuilt is the part no model has managed yet.

Beck closes:

However, I am cautiously optimistic that as we weather this historical conjuncture, and machine intelligence loses its sparkly aura, and weekend vibe coders increasingly learn how substantial the gap is between a prototype and a product, the role of design, however it is redefined, will be just as essential as it ever was.

That unsexy gap is the whole game. Greg Kozakiewicz updated the old construction line: we used to confuse the drawing with the building; now we confuse the prototype with the product. The demo works on a good laptop with someone who knows what the app is supposed to do. The product has to work for the user who doesn’t. Closing that gap is the orchestration job—defining the thresholds and deciding what the system should refuse to do—and when the weekend demos lose their shine.

The terminal’s return as a serious surface for new tools (Claude Code, Codex, Omarchy) has mostly been read as a developer aesthetic story. Alcides Fonseca reads it as the receipt for thirty years of GUI toolkit churn. He walks the platforms one by one (Windows, Linux, macOS), then through Electron, then through the failed restarts (Google’s Flutter UI, Zed’s GPUI), and ends on TUIs as the place developers go when none of the layers above hold up.

Fonseca on macOS:

Apple used to be a one-book religion. Apple’s Human Interface Guidelines used to be cited by every User Interface course over the world. Xerox PARC and Apple were the two institutions that studied what it means to have a good human interface. Fast forward a few decades, and Apple is doing the best worst it can to break all the guidelines and consistency it was known for.

This isn’t a nostalgia complaint. Fonseca lists the live breaks (Fitts’ law getting ignored, the Tahoe window-resizing saga that didn’t stay fixed, the icons cluttering Apple menus) and treats them as the same class of failure as Microsoft’s WinForms-WPF-Silverlight-WinUI-MAUI parade. The mechanism differs but the outcome is the same: the platform stops being a place a designer can rely on.

Fonseca on Electron:

Looking at my dock, I have 8 native apps (text mate and macOS system utilities) and 6 electron apps (Slack, Discord, Mattermost, VScode, Cursor, Plexampp). And that’s from someone who really wishes he could avoid having any electron app at all. […] These are actions that should be the same across every macOS application, and even if there are shortcuts, they are not announced in the menus.

The dock count is the right way to measure it. RAM is the visible cost of Electron; the invisible cost is that every Electron app becomes its own little keyboard regime, with shortcuts that often don’t match the rest of the system and aren’t announced in menus when they do exist. Fonseca’s Cursor example (can you keyboard from the agent panel to the agent list and archive an item) is the kind of question any pre-Electron Mac app would have answered yes to. Most Electron apps answer maybe, with a shortcut their vendor invented.

His prescription that follows (make HCI mandatory in CS curricula, fail student projects with bad UIs, push OS vendors to invest in toolkits developers want to use) is correct in shape and probably wrong about leverage. Students aren’t the bottleneck. Apple and Microsoft have already read Norman. TUIs are back because the platforms quit, and the curriculum can’t fix that.

Fonseca’s diagnosis is right. The prescription is narrower. The TUI escape hatch works for developers because their work is text. Designers don’t get the same exit when the canvas is the medium itself.

Bonus: Speaking of TUIs, TUIStudio is a macOS app for designing terminal UIs, just like Figma!

Alex Dapunt, VP Design and Brand at Moonfare, opens with a research session in which a senior client laid out exactly what to build next, with the roadmap, rationale, and feature list ready inside a minute. The client was wrong, Dapunt writes, but not because he was stupid. He was wrong because he had been asked the wrong question and his instinct was to answer it anyway.

The smarter your users, the more convincing their wrong answers. A user says they want ice cream. While they say they want ice cream, what they need is to cool down. Their body wants sugar. It’s hot. There’s a memory somewhere in there, a summer ritual, something cold in their hand. The want closes off options. The need opens them. Take “I want ice cream” at face value and you sell them ice cream. Understand the need and you can sell them a popsicle, a cold drink, air conditioning, a swim in the sea.

The want-versus-need split is older than this piece. Dapunt credits Jared Spool for it. The part Dapunt adds is about who tends to give you the worst version of a want. He argues the failure intensifies in premium and B2B contexts, where the people you most want to talk to are the people most trained to produce confident answers under pressure.

The Moonfare client wasn’t an outlier. I think a lot about why this happens. Part of the answer, I think, is that the people we were interviewing had been trained, explicitly, to produce answers. At Bain, where I spent time earlier in my career, the core discipline is what’s called the answer-first approach, or the A1. You lead with the answer. Then you work backwards. […] It’s a disastrous way to sit in a research session as a user. An executive trained that way walks in and the instinct takes over. They feel the absence of an answer as pressure. They want to be useful. They want to look smart. They give you the A1, and it’s precise and articulate because producing precise articulate answers is what they are paid to do.

Dapunt’s observation about ambiguity is worth carrying into the next interview transcript you read. When a regular user says “I dunno, maybe?” he argues, the fuzziness is signal that the question is wrong. The executive doesn’t give you that signal, so you have to know to discount the clarity.

Dapunt then turns the same lens on metrics. His version of the metrics-as-avoidance failure mode is more specific: the wrong moment, not just the wrong number.

At Moonfare we tracked logins. More logins looks good on a dashboard. Looks like engagement. But private equity is a 5-to-10 year product. For most of that time nothing is supposed to happen. […] The right moment isn’t a platform question. It’s a life question. When does this person have cashflow? When’s bonus season? What does their portfolio look like right now, and is there a product we offer that fits the gap? The real need isn’t log in more. It’s be present when a decision is being made. Five well-timed touchpoints in a year beat fifty random ones.

The piece closes on the part of research practice that gets least attention.

Research is intake. You take it in. You synthesise. Then someone has to make the call and own it. […] In practice I’ve watched it produce three biases averaged into a consensus nobody owns. Someone has to own the interpretation. It can be a researcher, a designer, a founder, a PM. But it’s one person’s job, and it comes with the accountability for the call that follows. The alternative is research-as-stalling.

Dapunt is careful here. He likes continuous discovery, he likes the product trio in theory, and he is not making a contrarian case against any of it. His point is narrower. A team can run all the right research rituals and still end up with a process whose actual function is to ensure no single person has to take responsibility for being wrong.

Nick Babich on agents in UX Planet. A useful pair to his earlier writeup on Claude skills, since the two words get used interchangeably and they are not the same thing. Babich opens with the plain-language version:

Think of an AI agent as a program you run when you need to solve a particular problem in design. For example, you can create an AI agent that helps you with usability testing, code review, UI/UX audit, etc.

A program you run is the right mental model. A skill, the way Babich described it in his earlier piece, is a recipe: a markdown file Claude reaches for when a task matches. An agent is what runs once Claude has the recipe in hand. It carries state across steps, picks tools, reports back.

Babich’s four attributes of a well-designed agent get at that distinction without saying it out loud:

1. Good clarity (intent alignment). A strong agent understands what success looks like, not just the task. This understanding helps it translate vague prompts into clear objectives.
2. Context awareness. Good agents maintain and use context effectively. Not only do they remember previous steps, constraints, and user preferences (which is well-expected behavior nowadays), but they also adapt output based on the environment (tools, data, stage of workflow).
3. Tool orchestration. Agents can perform the workflow autonomously and they have the ability to use the right tools for a task at hand is what makes an agent so powerful. Well-crafted agents can chain tools together into workflows, and they don’t overuse tools when simple reasoning is enough.
4. Explainability (transparent reasoning). When you interact with an AI agent, you need to understand why something happened. Thus, an AI agent should provide a rationale behind decisions surface assumptions, and trade-offs.

Context awareness and tool orchestration are what separate an agent from a prompt template. A skill can ship intent alignment and explainability in plain markdown, but state across steps and the ability to chain tools require a runtime. That’s why Babich’s specs include Boundaries sections and “When Not To Use It” blocks: a stateful, tool-using program needs guardrails that a one-shot prompt does not.

If you haven’t built one yet, his five specs—Research Synthesizer, Competitor Intelligence, Problem Definition, Idea Generation, UX Flow Designer—are a clean starter pack. Pick the one closest to a workflow you already do by hand, and notice how much of the spec is about what the agent will not do.

Karri Saarinen, Linear’s co-founder, calls out the confusion that most of the new design tooling is built on top of:

Design keeps being misunderstood in our industry. New tools keep promising to generate interfaces faster, move words to product instantly, or collapse design directly into code. The assumption behind them is clear: that design is the act of producing. That is the misunderstanding. The hard part of design is rarely generating the form. It is understanding the problem well enough to know what and how something should exist at all.

What I appreciate about Saarinen’s argument is that he doesn’t stop at the diagnosis. He reaches for Christopher Alexander’s Notes on the Synthesis of Form and recovers a vocabulary term the industry has been missing:

Christopher Alexander came closer than anyone to naming this clearly. In Notes on the Synthesis of Form, he describes design as the search for a good fit between a form and its context. Context, in his sense, is not a background condition. It is the full set of forces that make a problem what it is: human needs, technical constraints, conflicting requirements, habits, edge cases, and relationships that are easy to miss until you spend time with them. Bad design appears where those forces remain unresolved. Good design appears where those misfits have been worked through carefully.

Context as forces, not background. The current generation of prompt-to-code tools, including Lovable, Figma Make, and Claude Design, is very good at producing a plausible form against a thin slice of context. Saarinen describes the symptom directly:

You can already see the result in products that look polished, ambitious, and impressive at first glance, but begin to unravel the moment you actually use them. They feel brittle, poorly integrated, and full of decisions that were never fully worked through. The form is there. The fit is not.

That same bottleneck shows up on the workflow side: production speeds up, judgment doesn’t.

Saarinen’s closer:

The risk is mistaking generated form for solved problems.

That is the mistake to watch for, in your own work and on your team. Design is what happens when someone takes the time to understand the forces and works the misfits out of the form.

Matt Zieger built jobsdata.ai as a weekend project, with the stated goal of being “a single place that synthesizes what we actually know about AI’s impact on economic opportunity.” The site breaks every occupation into its component tasks, then prices the AI compute cost to do one hour of each task and compares it against the human wage. The result is a per-task crossover year: the point when AI gets cheaper than the human at that work. “Evidence Over Narrative,” as Zieger puts it.

The UX designer report opens directly:

If you’re an ux designer, this is worth taking seriously. But it’s not too late to get ahead of it.

We’ll be honest with you: a lot of the individual tasks in your job are things AI can already do, and that’s accelerating. But there are real reasons not to panic: when technology has made this kind of work cheaper in the past, people ended up wanting more of it, not less. There’s good reason to think that pattern will hold here too. Your field also tends to adopt new technology faster than most, so it’s worth paying attention now.

Double down on the parts of your work that take real judgment and experience. As AI handles more of the straightforward stuff, demand for what you do will likely grow.

Obviously, I’ve been pro-AI on this blog, actively trying to understand and figure out how it’s affecting UX design and how to use it for leverage instead of being replaced by it. In Silicon Valley and tech companies everywhere, including BuildOps, we’re racing to incorporate AI into our daily work to increase velocity, and adding it to our products to stay relevant.

Nilay Patel, in a Decoder monologue, lays out the polling that should rattle anyone shipping AI products:

There’s that NBC News poll showing AI with worse favorables than ICE, and only a little bit above the war in Iran and Democrats generally. That’s what the nearly two-thirds of respondents saying they’d used ChatGPT or Copilot in the last month. Quinnipiac just found that over half of Americans think AI will do more harm than good. Well, more than 80% of people were either very concerned or somewhat concerned about the technology. Only 35% of people were excited about it. And poll after poll shows that Gen Z uses AI the most and has the most negative feelings about it. A recent Gallup poll found that only 18% of Gen Z was hopeful about AI, down from an already bad 27% last year. At the same time, anger is growing. 31% of those Gen Z respondents said they feel angry about AI, up from 22% last year.

The killer detail is buried halfway through. The Gen Z curve is striking: heaviest users, and yet the fastest to sour. Anger is up nine points in a year. These aren’t non-users reacting to coverage. They’re the daily customers, and the answer is no. Sam Altman has called this AI’s marketing problem. The polling rebuts him: public exposure has grown, public favor has not.

Patel’s title line:

Regular people don’t see the opportunity to write code as an opportunity at all. The people do not yearn for automation. I’m a full-on smart home sicko. The lights and shades and climate controls of this house are automated in dozens of ways, but huge companies like Apple and Google and Amazon have struggled for over a decade now to make regular care about smart home automation, and they just don’t. AI isn’t gonna fix that.

Patel grounds the title in his own smart-home enthusiasm, and the comparison clicks because the failure pattern is identical: decade-plus of effort, billions in marketing, working products, and persistent indifference. Apple, Google, and Amazon ran that experiment. AI will not crack a problem that smart-home automation hasn’t.

John Gruber connects the same dissonance to the Mos Eisley cantina from Star Wars. Luke walks in with C-3PO and R2-D2. The bartender, Wuher, barks: “We don’t serve their kind here. Your droids. They’ll have to wait outside.” Gruber:

As a kid, I didn’t get it. Why would you not want droids? Star Wars made robots seem so real, so fun. Why would you ban them? That scene has stuck with me for my entire life. I didn’t get why, but I understood what it meant about that galaxy: the underclass deeply resented droids.

Gruber leaves the question open. He says he didn’t get why the droids weren’t welcome. The cantina’s animosity wasn’t arbitrary. Mos Eisley sits in the Outer Rim, where droid armies killed millions and occupied worlds during the Clone Wars. After the war, droids became a subjugated worker class across the galaxy, and Outer Rim spots like Mos Eisley held the line hardest. Wuher’s verdict comes from experience.

That’s the parallel for AI. Public distrust is earned. People have lived with AI overviews getting facts wrong and feeds drowning in slop, while every product asks them to bend a little more toward the database. Patel:

And so the tech industry is rushing forward to put AI everywhere at enormous cost, energy, emissions, manufacturing capacity, the ability to buy RAM locked into the narrow framework of software brain, without realizing they are also asking people to be fundamentally less human. And then they’re sitting around, wondering why everyone hates them. I don’t think a couple haircuts are gonna fix it.

As an industry, we need to continue to show the value of AI by being truly useful, not just market it.

I’ve been pro-prototype: PMs replacing PRDs, designers prototyping interactions in code. Pavel Samsonov, writing at Product Picnic, aims at exactly that position. He opens by borrowing a distinction from Andy Polaine:

Demos and prototypes sit on a continuum, but I consider demos something to help you show a concept to other people in a form that looks and feels like the real thing. Prototypes are things you create to test something you don’t know until you build and test it.

Correct distinction. A demo succeeds on stakeholder approval; a prototype succeeds on learning. Both artifacts can be interactive and polished. What separates them is what counts as success. Samsonov on what happens when teams conflate them:

The only thing these demos are helping you test is whether your stakeholder likes what they see (the first loop) and as soon as they say “yes,” it becomes good enough to ship. Whether that second loop (releases go out, measurements come in) ever gets tracked or not is not something I’d be willing to put money on. Because once the demo is productionized, it goes from the realm of delivery velocity (which gets you shoutouts and promotions) into the realm of maintenance (which tends to be ignored even as it eats up more than half of the team’s bandwidth).

AI makes it easier to produce both, and Samsonov’s read on what happens when teams use the speedup wrong:

Shoving out more prototypes is not a heuristic for success; it is a heuristic for failure because it shows that you don’t know what you are trying to learn.

Agreed. Samsonov goes further:

This is exactly why AI-generated prototypes are not working, and have not helped anyone do anything ever. Some have accused me of going too far with this assertion, but I stand by it, because it is rooted in the very nature of what a prototype is (and is not), and what makes it successful (or does not).

Here’s where I differ. Brian Lovin’s Notion prototype playground exists because static mocks enforce golden-path thinking. The playground surfaces the messy middle of AI chat: follow-ups and latency changes no one mocks up. Édouard Wautier’s Dust team prototypes state changes and motion Figma can’t show. Figma PMs ran five user interviews in two days off an AI-built prototype, which is a textbook closed second loop. All three count as prototype work.

Samsonov’s diagnosis is right. His absolute stance is, well, too absolute. AI-generated prototypes haven’t helped anyone only if you assume they’re all demos, which is exactly what the distinction he just drew tells us not to assume.

In my previous item, I linked to a post by Adi Leviim who made the case against chat as the AI interface default, reading the 2024 wave of GUI retrofits AI labs shipped—Canvas, Artifacts, Projects, Computer Use, Deep Research—as the industry admitting a text box alone wasn’t enough. Matt Webb, writing on Interconnected, wants every service to ship a CLI instead. Both arguments are about text. They look like they contradict. They don’t. Webb’s case for going headless:

It’s pretty clear that apps and services are all going to have to go headless: that is, they will have to provide access and tools for personal AI agents without any of the visual UI that us humans use today. […] Why? Because using personal AIs is a better experience for users than using services directly (honestly); and headless services are quicker and more dependable for the personal AIs than having them click round a GUI with a bot-controlled mouse.

Webb’s CLI sits on the agent-to-service layer. Leviim’s retrofits sit on the human-to-agent layer. The text on one side is a protocol for machines. The text on the other is a user writing out intent in sentences. Both are text, but the role is different. Webb makes the split explicit when he turns to what it means for design:

So from a usability perspective I see front-end as somewhat sacrificial. AI agents will drive straight through it; users will encounter it only once or twice; it will be customised or personalised; all that work on optimising user journeys doesn’t matter any more. But from a vibe perspective, services are not fungible. […] Understanding that a service is for you is 50% an unconscious process - we call it brand - and I look forward to front-end design for apps and services optimising for brand rather than ease of use.

Interesting, right? Webb believes that the need for human-facing UI and therefore user journeys will be less. He’s designing for an agent-first world.

Webb, goes on…

If I were a bank, I would be releasing a hardened CLI tool like yesterday. There is so much to figure out: […] How does adjacency work? My bank gives me a current account in exchange for putting a “hey, get a loan!” button on the app home screen. How do you make offers to an agent?

The agent becomes the surface designers have to figure out.

Every major AI lab spent 2024 bolting GUI surfaces onto chat: Canvas, Artifacts, Projects, Computer Use, Deep Research. That’s seven retrofits across three AI firms in twelve months. Adi Leviim, writing for UX Collective, reads that wave as the industry conceding in public what designers have been saying since Amelia Wattenberger’s 2023 essay on why chatbots aren’t the future of interfaces. His setup for why the default took hold:

Open any AI product launched in the last three years. Ignore the model, the logo, the branding. You will find the same interface: a text input at the bottom of the screen, a send button, and a scrollback of alternating messages. This is not a random convergence. It is the interface that fell out of what large language models could do on day one: pattern-match on text. In 2022 we had a new capability and no time to design around it, so we shipped what was fastest to build and called it conversational AI. Three years later, the fastest thing to build has become the thing everyone builds. That is how defaults calcify.

The lag between Wattenberger’s essay and the retrofit wave was three years. Leviim counts the retrofits as evidence the rectangle was always going to need help:

Calling this progress is charitable. It is the industry discovering, retrofit by retrofit, that a text box alone cannot hold a meaningful creative surface. You cannot edit a thousand-line document by asking the bot to re-output it with “line 312 changed to X”. You cannot iterate on a design by describing it. You cannot plan a research project without seeing the plan. The moment the task has a structured output, the chat box becomes the wrong place to work, and the vendors put a canvas, a side panel, an editor, a workspace, or a planner next to it.

“Retrofit by retrofit” is the phrase that carries his argument. Each retrofit is a clickable, scrollable, draggable pattern the chat box had removed. The AI labs are rebuilding what 2015-era UI already had.

Leviim continues, separating intent from chat:

Expressing intent does not require prose. A date picker expresses temporal intent more precisely than any sentence. A pair of sliders expresses a tradeoff more legibly than a paragraph. A file upload expresses “work on this thing” without ambiguity. Every one of these is intent-based. None of them is chat. The chat box is one possible implementation of the paradigm, and by all accessible evidence it is a low-resolution one.

Jakob Nielsen’s 2023 essay, “AI: First New UI Paradigm in 60 Years,” treated chat as the way to express intent. Leviim agrees intent-based interaction is the shift. He argues chat is the wrong way to express it. Date pickers, sliders, file uploads are all intent surfaces, and none of them is chat. Which is where the design work goes next:

the good AI UX work of the next three years will be distributed across a thousand of those scoped surfaces rather than concentrated in one generalized text field.

That’s the brief for anyone designing AI products.

Showing stakeholders prototypes is often a high-wire act. Back in the old days, that’s why we showed wireframes prior to high-fidelity comps, or mockups. But now with tools like Lovable or even Claude Design, where the prototype demos really well, it’s easy to mistake it for a product that is shippable. The stakeholder in the room could easily say “ship it.”

That used to be where the Figma-to-code handoff became visible. Now it’s invisible. Greg Kozakiewicz, writing on LinkedIn, wants designers to see it again. He updates an old construction-industry line for the AI era:

We used to confuse the drawing with the building. Now we confuse the prototype with the product. A working prototype also accepts everything. It will let you register, log in, fill out a form, submit something. It all works. In the demo. On a good laptop. With a fast connection. With someone who knows what they’re doing and what the app is supposed to do.

The design-to-code gap didn’t vanish when AI made prototypes interactive. It went underground. Now it shows up as a stakeholder saying “looks great, let’s ship it” to something that couldn’t survive real data or production constraints. Kozakiewicz puts a number on it:

AI gets you to about 60%. A solid, reasonable, generic 60%. The layout makes sense. The flow is logical. The copy is clear enough. It looks like a product that works. And for a lot of people, especially people making decisions about budgets and timelines, 60% looks like 90%. Because the last time they saw a prototype, it was a static Figma file with “Lorem ipsum” everywhere.

The designer’s role is widening at both ends of the product stack. Earlier, I linked to a post by Chad Johnson arguing designers gain influence by moving upstream: becoming orientation devices for the team, shaping the problem before it gets named. Daniel Mitev, writing for UX Collective, argues designers gain authorship by moving downstream, into the code:

The industry has been asking whether designers should code for over a decade. It was always the wrong question, or at least the wrong framing. It implied the barrier was technical: that designers lacked something fundamental, something that required years of study to acquire. Learn TypeScript. Understand the DOM. Earn your way across the divide. That wasn’t the barrier.

Mitev’s argument comes down to access. AI tooling compresses the translation layer and returns authorship to the designer:

What AI tooling gives back is authorship over the surface layer — the part users actually touch. A designer can now open the codebase, adjust how an element behaves, change how a transition feels, and verify the output against their own intent in real time. The easing curve gets set by the person who decided what it should feel like. The hover state gets defined by the person who thought through why it matters. That work no longer requires an interpreter.

He points at Alan’s “Everyone Can Build” initiative—283 pull requests shipped by non-engineers over two quarters, each merged after engineering review—as evidence it’s already happening.

Johnson and Mitev aren’t in conflict. They’re describing the same shift from opposite ends. The interpreters at the top of the product stack—PMs who owned problem framing and prioritization—are compressing. The interpreters at the bottom—frontend engineers translating intent into code—are compressing too. Both jobs return to the designer who understood the intent first.

The role widens. Some designers will gravitate to one end or the other. The designers who stretch the full range—orientation work and authorship—are working the widest version of the job.

Two podcast conversations with frontier-lab design leaders on what designing at an AI lab looks like day-to-day. I previously linked to Lenny Rachitsky’s interview with Jenny Wen, head of design for Claude, where she described a redistribution of designer hours: less mocking, more pairing with engineers, a sliver of direct implementation. The activities themselves still look like design.

Ian Silber, head of product design at OpenAI, on Michael Riddering’s Dive Club, describes work that doesn’t fit the same list:

Designers working on this are hopefully spending a lot less time in Figma or whatever tool you use to draw pixels, and more time really thinking about how you interact with this thing, and the fact that the model really is the core product.

Silber’s concrete example is onboarding. Instead of building a first-run tutorial, his team shapes what the model already knows about the person:

We have this super intelligent model that could probably do a much better job trying to understand what this person’s goals are […] We’re really stripping back a lot of what you might traditionally do and trying to say, “Well, actually […] let’s think about like how we should give this context to the model that this person is brand new and they might need some handholding.”

The traditional response adds UI around the problem. Silber’s team takes it out and gives the model enough context to meet the user where they are.

That kind of work needs its own scaffolding, and OpenAI is building it:

We have a whole system called the Dynamic User Interface Library, which allows us to design things that the model can then interpret.

Primitives the model composes at runtime, shaped by system prompts and context rather than drawn flow by flow. Wen is describing a redistribution of designer hours inside activities that still look recognizable. Silber is describing activities that don’t quite have names yet. And yes, that is still design.

The gap between an AI-produced prototype and a shippable product has a shape. Most of us assume it’s the visual 20%: the polish AI output drifts on. Chad Johnson’s case is that the 20% is the trivial part, and the real gap sits upstream of everything visible.

Chad Johnson, writing in his newsletter:

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.

That lines up with what I’ve been calling C+ out of the box: artifacts that read well and seem credible until you apply critical thinking. Johnson gets specific about what’s actually missing, and none of it is visual: the assumption nobody validated, the upstream question nobody asked. The interface was fine. The thinking was absent from the (probably) AI-generated PRD.

Johnson again:

…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.

Judgment still takes years to build, and no tool compresses that.

The last 20% is rarely the gap that matters. The first question—should we build this?—almost always is. Very few teams have the muscle to ask it.