331 posts tagged with “product design”

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.

Designer and writer MC Dean thinks most AI design demos are still asking the old workflow question: can the machine draw the screen I had in my head?

For Dean, that is too small. The useful shift is underneath it: if an agent is composing the interface, the designer’s job moves from final artifact to operating conditions.

Right now, in design teams everywhere, the same experiment is running. Someone feeds a prompt to Claude Design, or one of its cousins, and waits to see whether it can produce the screen they would have designed themselves. Some people are delighted. Some are frightened by how good it is. Some are disappointed in the results. A few are furious, and I understand why. When a machine can do in 10 seconds the thing you trained 10 years for, it’s annoying.

I want to move us off this question for now, because (nearly) all of us are asking it wrong.

Here is what we are really doing. We have been handed a tool that can grow an interface out of intent, something genuinely new in the world, and we are pointing it at the oldest task we know. Draw a fixed screen. Convert the canvas to code. Hand it down the line, faster and cleaner and with fewer late nights. Useful but look closely at what we are optimising for: We’ve been given something revolutionary, and we are using it to do old school design. A better-preserved version of the old way of doing things.

Dean’s line about “old school design” gets at the trap in a lot of canvas-to-code excitement. Faster handoff is useful, but it still treats the UI as the thing to preserve instead of the thing a system can produce when the context changes.

Dean again:

Canvas to code is a brilliant answer to a question that is already on its way out.

You can watch the whole industry racing to perfect it. Figma put an agent right on the canvas that generates and remixes and respects your design system, then made it possible to push those changes into a real codebase and open a pull request without ever leaving the file. It is clever work, and if your job today is getting a fixed design into fixed code, you should use it. Just notice what it is for. It is the most beautiful possible version of the handoff we have always done. It is the road getting smoother, right before it all changes.

Because here is where this is all heading, and it is so much more interesting than a faster mockup.

This is where designers have to be careful. If the interface becomes runtime output, then judgment has to live in components, constraints, refusal rules, and briefs the agent can actually use. The screen is still how the user experiences the product. It just stops being the primary thing designers hand over.

For a design team, that changes the evaluation. The first pass can be rough and still useful if it exposes which rules, components, and intentions are missing. The important artifact is the environment you can improve, not the individual screen you can rescue.

Dean on the method:

You stop finishing screens and start preparing materials. A set of components an agent can compose from, with the rules of combination written down: what sits next to what, how space behaves, which piece to use and when. Then you write your intentions in plain language, the way you would brief a thoughtful designer who is about to make a thousand small decisions without you in the room. How should this treat someone who is rushed. What does it never do, whatever happens. What should it feel like when the news on the screen is bad. You are not producing the outcome any more. You are designing the infrastructure, architecting the full experience, and curating the best outcomes.

Then you do the part that surprises people. You let it build, and you watch what comes back across many different moments. You correct the environment and the intentions, never the single screen. It is closer to coaching than to drawing. You train judgment into a system, and then you trust it in the places you will never get to enter.

You could start with one flow. Instead of designing the screen, write down everything an agent would need to know to design it well: the taste, the priorities, the hard refusals. Hand it over. Look at what it makes. Then resist every instinct to fix the pixels, and fix the instructions instead. That small discipline, correcting the brief rather than the output, is the whole new craft in miniature.

In designer and investor Soleio’s South Park Commons interview, Rasmus Andersson, creator of Inter and an early Figma designer, draws a useful distinction between software and type. Regular software decays fast; Andersson says that if he hasn’t touched something in two weeks, he usually trashes it and starts over. But a typeface can keep gaining value years later.

Andersson starts with how complex modern software is:

Today there’s just this towering complexity of making software, and for a very good reason, right? For like 15, maybe 20 years by now, our industry as a whole has been hyper-focused on scale because it’s just been an economic evolution that’s been out of this world. So it makes sense that we’ve been trading off and trading away things like shareware, concepts like that, and things like simplicity and ease for the ability to scale and for the ability to things at scale to actually work and break apart. But in the wake of all of that, which is great in so many ways, we’ve given up these things that are listed, and I feel like at least me and many people like me and who sort of are trained to build this thing, enjoy making software at a smaller scale.

That’s like a metaphor that I think can be helpful is imagine your room, apartment, house, whatever, your dwelling place. It’s probably different from the person next to you. And it’s not so that we go out and we buy the Apple apartment and all the furniture is there and everything is perfect and we can change the carpet, and that’s about it. That’s ridiculous, no one would do that. Yet that’s what people do with software.

Manufacturing software was professionalized and gentrified. The stack got so optimized for global products that it left less room for the small, personal, weird things people used to make for themselves.

Andersson’s Figma story keeps that from becoming nostalgia:

First off, something that was just amazing about working at Figma at the time was that there was just this culture of doing things differently. That was amazing. And every single individual who I worked with were just like, if that person went to start a company now and they put me with it, I’ll come. Every person was like that. Every person had an opinion about something that was really exciting.

Another thing that I think was so fascinating about how things were done at the time at Figma was this deep intention around everything and moving slow. But moving slow with many things in parallel, like staggered, right? So from the outside, Figma would ship something every month, maybe even more often than that. But internally, a person would work on one thing for one year. And sometimes at the end of that one year, it would just go into the bin and never ship. So that I think was really cool to see from the inside and then having a very different effect on the outside.

That distinction matters in an AI tooling moment where output is getting cheap. Figma looked fast from the outside because slow, deliberate work was happening underneath. Speed at the surface depends on judgment below it.

On Inter:

One thing for sure is finding the right ratio between impact and effort. I think Inter is one of those things. Sure, I’ve spent like 10 years on it, and who knows how much of my time on it, right? So there’s a lot of effort behind it. But I think it’s one of those types of efforts that has a very disproportionate impact from the effort.

[…]

I gotta say though, something that is amazing about working at Typeface is, it’s something like, it’s almost like in the field of design, you might think about cars as a unique type of thing to design because it’s both like, and architecture’s a little bit like that too. It’s not strictly the sign as in signage for roads, right? It’s very technical and it’s not the sign as in expressing myself through art, like graphic design, like a poster, it’s somewhere magically in between.

And another aspect of it that’s kind of cool is that you can put in 10 minutes here and 10 hours there and they add up over time which I don’t think is true without a software because the rate of decay of any type of regular software is very high. Two weeks is my cutoff. If I have not worked on something for two weeks I have trashed it and start over but with a typeface like that decay is extremely extremely low, in some cases zero.

Alex Harper, writing for Web Designer Depot, describes the new baseline for web design work:

For decades, a significant portion of a web designer’s value was tied to the act of building: moving pixels in Figma, translating those pixels into CSS, ensuring the flexbox behaved, and troubleshooting why a specific button looked “off” in Safari.

But with the arrival of high-fidelity “Agentic UI” and the rise of what industry insiders are calling “Vibe Coding,” the barrier between a thought and a fully functional interface has effectively vanished.

Today, a founder can speak into a prompt—”Give me a high-end, minimalist FinTech landing page with a Swiss-style grid and a sense of ‘quiet luxury’ using deep emerald tones”—and receive a production-ready, accessible, and responsive site in seconds.

This is the AI design conversation with dollars attached. Once a small business owner can get a polished page for almost nothing, “pretty page” stops carrying much economic value.

Harper describes the commodity pressure as a loop:

The primary problem with Vibe Coding is that AI, by its very nature, is a statistical engine. It generates the most “probable” result based on your prompt. If you ask for a “Modern Minimalist” site, the AI isn’t going to innovate; it’s going to give you a composite of every modern minimalist site it has ever seen.

This creates a Feedback Loop of Averageness. 

1. Designers use AI to generate “vibey” layouts. 2. These layouts are published and become part of the web. 3. Future AI models are trained on these new layouts. 4. The aesthetic “mean” becomes tighter and tighter.

Designers have to take that feedback loop seriously. While the taste in the models are slowly getting better, AI nudges taste toward whatever the training set keeps rewarding. Notice a lot more serif fonts online recently?

That’s why “clean and professional” worries me less as a style than as a business model: if everyone gets the same acceptable answer for almost no money, the designer’s value moves into judgment, story, and constraints.

Harper adds:

To survive the Vibe Coding crisis, designers have to move away from the “Vibe” and toward the “Mechanism.”

If the “look” of a website is now a commodity, where does a designer provide value? The answer lies in the areas that AI still struggles to grasp: Nuance, Narrative, and Friction.

AI can create a page that looks like a brand, but it cannot yet build a page that feels like a story. Vibe Coding creates “scrollytelling” templates, but it doesn’t understand the emotional arc of a user journey. A human designer understands that a specific user might need to feel “uncomfortable” or “challenged” at a certain point in the flow to make a realization. AI only knows how to please.

An AI can generate a screen, but can it generate a philosophy? Designing a design system in 2026 isn’t about making components; it’s about defining the “Ethics of Interaction.” How does this brand handle data privacy through UI? How does it signal inclusivity without being performative? These are high-level strategic decisions that a “vibe” prompt cannot solve.

Cash App product designer Brad Wrage on moving design from handoff to production ownership:

Across this project, I personally merged 25 pull requests across three codebases — Android (14 PRs), iOS (8 PRs), and Server (3 PRs). As a designer.

And zooming out further — over the last two months, I personally authored ~45 PRs merged across 5 repos. As a product designer:

Wrage stayed accountable for the experience after Figma, across Android, iOS, and server. That is where the delay in a traditional handoff becomes obvious. It maps to Cash App’s org-speed bottleneck: building faster only matters if approvals, reviews, and deployment move with it.

Wrage describes the operational core:

This is where the traditional dynamic flips. Instead of filing bugs and waiting for engineering to prioritize them, I lead the charge — logging issues, kicking off fixes, and drive them to completion.

The process: visual feedback and bugs drop into a dedicated Slack channel. Builderbot — which intimately knows our codebase — picks them up and posts rapid fixes, often within minutes.

[…]

I pull the code down, test on a real device, reference my Figma file via MCP, and approve or adjust until it’s right. Every PR still gets a human review.

The guardrail is in that last sentence: code review remains part of the process. The result is a tighter loop between taste, implementation, and product judgment without removing engineering accountability.

Wrage’s phrase for that distance:

This is the inflection point. The designer isn’t on the sidelines filing tickets anymore — the designer is in the driver’s seat, leading the last mile to ship.

The last mile. The difference between “shipped” and “crafted.”

B. Prendergast revisits atomic design:

Atomic design is nearly ten years old. Brad Frost’s atoms, molecules, organisms hierarchy did something genuinely useful when it arrived: it gave teams a shared language for the idea that components are made of other components, all the way down. For a lot of people, including me, that was the conceptual unlock they needed to start building modular reusable front ends instead of pasting the same button in seventeen places. It worked. The industry absorbed it wholesale.

But I think we can probably retire the metaphor now.

Brad Frost’s watershed atomic design concept solved a real communication problem. It helped designers and engineers talk about components as things that compose, not screens that get pasted together. The problem starts when a teaching metaphor becomes the operating model.

Prendergast describes the tax teams pay when that happens:

The problem I keep running into with teams over the years isn’t that they don’t understand atomic design. It’s that they’ve understood it too literally. They’ve set up their Figma and Storybook libraries with Atoms, Molecules, and Organisms sections. They’ve had the naming convention conversations. And then, reliably, they get stuck arguing about whether a card with an avatar and a label is a molecule or an organism. That conversation is a tax. It doesn’t produce better components. It produces friction, disagreements, and the occasional afternoon lost to taxonomy instead of building.

That’s the part I care about in design systems. A good library should make the useful path obvious: which pieces can be reused and which contracts they have to honor. If the library mostly teaches people to sort objects into clever buckets…well, that’s a distraction from the work.

Prendergast closes with the on-ramp caveat:

I’m not arguing against atomic design as an on-ramp. If someone on your team is new to component-based thinking, the atoms/molecules/organisms scaffold is still a powerful and reasonable way to introduce it. Use it. Just don’t park there. The abstraction to keep is composability. Components compose up from smaller components. There are no real required levels between the smallest useful unit and a whole page or view. Whether an intermediate component is a molecule or an organism is a naming problem, not a design problem. We can stop solving it now.

The real test of a design system isn’t whether every component sits neatly in the correct layer of a hierarchy. It’s whether people can understand it, trust it, use it, and extend it without breaking it.

Nobody ships a better product because they correctly identified a component as an organism instead of a molecule. Atomic design succeeded because it taught people to think in terms of composition. Components built from components. Small pieces combined into larger ones. Clear contracts. Predictable behaviour.

Everything else is bookkeeping.

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.

Jason Cyr, writing at The Human in the Loop, starts with the AI-design conversation’s taste claim and points to the work teams need before agents start producing anything:

There’s a popular narrative that design’s value in the age of AI is taste — the human eye that says “not that, this.” I think that undersells us. Taste matters. But what organizations actually need from design right now is clarity. The ability to wade through ambiguity, make invisible systems legible, and give teams something they can act on. That’s always been the real (often under-appreciated) superpower, and AI just made it an urgent need.

Cyr’s earlier piece on agentic-era design teams covered the move from making outputs to directing work. Here, he describes the coordination layer that had been hiding inside the old process:

The old product development process had shock absorbers we never realized. Meetings where people quietly aligned on things that were never written down. Hallway conversations that resolved ambiguity nobody had formally surfaced. Design reviews that were really translation sessions — designers decoding what product actually meant, engineers decoding what designers actually intended. PMs who held critical context in their heads and dispensed it as needed.

None of this was in any process document. It was human labour — invisible, unacknowledged — absorbing the ambiguity that the formal process couldn’t handle.

We called it process, but it was actually a buffer.

Cyr puts that clarity work inside design leadership:

Here’s the thing about this problem: it’s not a tooling gap. It’s not a project management gap. It’s a clarity gap.

Design earns its seat at the table when it moves beyond artifacts and starts shaping how a product organization delivers work. Not just the screens. Not just the system. The operating model itself — who decides what, when something is ready, how context travels, and what “good enough” means at each stage.

Fabrizia Ausiello, writing for UX Collective, uses Apple’s Liquid Glass transparency slider to ask who is supposed to make interface judgment calls:

Apple just introduced a transparency slider for its Liquid Glass UI — a control that lets users dial up or down the translucency of system elements. On the surface, it’s a thoughtful accessibility gesture (especially considering the criticism that Liquid Glass has accumulated), but in practice, it’s the manifestation of a deeper tension that designers have been circling for years: when you give users a knob, are you empowering them or just finishing your job somewhere more convenient?

Ausiello on the older design assumption that users shouldn’t have to make these calls:

For most of the history of digital product design, designers have been making decisions so users don’t have to. We studied, tested, iterated, and then shipped something that worked. Interface design is opinionated because it has to be.

It might sound arrogant, but it really isn’t, it’s simply part of the craft that’s baked into the role. The whole point of a well-designed system is that it removes cognitive load; the moment you ask a non-technical user to evaluate the “level of transparency” of their interface, you’ve already failed them because they don’t have a mental model for it, they just want to read their notifications.

I agree. As designers, we should be making this call. Ausiello turns the same question back on us:

If you work in digital product design, this moment is worth paying attention to for the precedent that it’s setting.

As AI takes over the execution layer — generating screens, producing variants, handling repetitive interface decisions — the value of a designer is shifting and the role that remains is the harder one: understanding the problem deeply enough to know which decisions shouldn’t be delegated at all.

Some things should be personalised, some should not, and knowing the difference, having the conviction to hold that line, is a skill needed and worth having. Dumping a slider in onboarding isn’t personalisation — it’s a designer who didn’t finish their job.

The future of adaptive interfaces is exciting, but getting there doesn’t mean abandoning judgment in the present. It should mean being more deliberate about which decisions belong to the system, which belong to the user, and which belong to you.

Interestingly, Ausiello also gives Apple an out. That maybe, Apple is playing the long game here and gathering data to make personalization more automatic in the future. The author again:

The reasoning goes roughly like this: we don’t need to commit to a specific default, because the AI will figure out the right setting for each user eventually. Siri will learn your preferences and you’ll just ask it to make things more readable and it’ll handle the rest. Seen from this perspective, the slider isn’t a UI failure, but rather an early, manual version of something that will eventually be automatic.

Honestly, I think it’s a bit of a stretch. Nice thought exercise though.

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.

Apple’s developer conference WWDC kicked off on Monday with a keynote. They announced various OS improvements, including refinements to Liquid Glass, and most importantly, a revamped AI strategy.

In the days leading up to the keynote, longtime Mac journalist Jason Snell wrote about building his first Mac app with Claude Code in just a couple of hours. We’ve heard this story before. We’ve been talking about it here for months. And yet, here’s a veteran technologist who’s just now discovering Claude Code’s power and building an app.

It’s easy to get caught up in the Silicon Valley AI hype bubble and think the whole world has changed and is using AI for everything. But no, that’s not actually the case.

Snell on what the experience actually required:

The process of building the app reinforced something I’ve been thinking about for quite a while: coding is a specific skill, but it’s only one part of a much larger process. Great developers aren’t necessarily great coders, though they can be. Apps must be envisioned, their specifications defined. The act of trying to describe an app to an AI coding engine is a clarifying one. The more you describe the app, the harder your brain has to work, because it’s always more complicated than you think it’s going to be. The decisions you make determine what the app comes to be. […]

Yup, tell me about it. Tell us product builders about it! The code was never the hard part.

Where I’d push back is on the optimism around it:

We now live in an era where, if you can dream an app, you can probably build it. Especially Mac utilities. And who cares more about native Mac software than Mac users? Certainly not those companies that gave up on Mac development and focused all their energies on giant cross-platform code bases to attract venture investment and big payouts.

Snell himself calls his app “ugly and incomplete” a paragraph earlier, so “if you can dream it, you can build it” is a bit of a stretch. The gap between a thing that runs and a thing you’d ship is where the real work lives: envisioning, deciding, refining.

And it’s a reminder of where the next barrier sits. Snell ends on the tooling:

Which brings me to a final point: Apple’s development tools, most notably Xcode, are nightmarish. My developer friends are used to them, but as someone who has never really used Xcode before, I was shocked at just how deeply unintuitive it is. As in, Claude would tell me to click on things, and I would have to reply, “I have no idea what that is or where it’s supposed to be.” And I’ve been a Mac user for a long time! I’ve gotten very good at intuiting where stuff is in a Mac interface.

[…]

While AI tools have made it more possible to build apps on Apple’s platforms, the developer tools themselves are still a formidable barrier. As the definition of “developer” changes, so, too, must the definition of developer tools.

I wholeheartedly agree with Snell that Xcode is a mess. For those like me who only open it on occasion, it’s baffling that Apple developers live with such a nutty application. Take a look at the best of Apple’s first-party apps like Keynote, Final Cut, or even Numbers, and Xcode is just…bizarre.

Apple did announce something at WWDC 2026 that was interesting—that nods to where they could go if they wanted to—users can ask Siri AI to vibecode Shortcuts and Safari extensions. Will have to see if that’s the seed for something.

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.

The line usually attributed to Einstein goes like this: “If I had an hour to solve a problem, I’d spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.” It is a warning against racing to the answer. Gale Robins, writing for UX Collective, makes the same case for product teams—then moves it one step earlier than Einstein did.

Her subject is the decision that rarely gets scheduled: whether a customer signal deserves discovery at all. She calls it Signal Evaluation, and she describes it bluntly:

Signal Evaluation is not a box to tick on the way to the real work. It is a filter, and a good filter is defined by what it keeps out. If most of what reaches your team makes it into discovery, the filter is not working; it is just a turnstile.

This is Einstein’s 55 minutes, relocated:

It is tempting to think discovery begins when you start talking to customers. It begins one step earlier, with the call to research this rather than something else. Every signal that reaches a team […] arrives carrying an implicit claim: this is worth your attention. Evaluating a signal is the act of testing that claim before you spend anything on it.

The difference she leans on is between a feature signal and a job signal:

The distinction that matters is whether the signal is about the customer’s job or about your product […]. “The export button is confusing” is a feature signal: it concerns your solution and usually warrants a quick fix rather than a discovery effort. “I cannot get my insights to my stakeholders” is a job signal: it is about what the customer is trying to accomplish, and it may hide an underserved need worth real investigation.

That is the trap Einstein was guarding against. The seductive request arrives pre-packaged as its own solution—add the widget, fix the button—and it is tempting precisely because it lets you skip the 55 minutes. Robins’s point is that a signal can be strong, genuine, and still aimed at the wrong job.

Here is where she goes past Einstein. His hour is already committed: he has a problem and is deciding how to spend time inside it. Robins is working a layer earlier. Her question is whether the signal has earned the hour in the first place. In her words, the skipped judgment is “whether to begin it at all.” Signal Evaluation is the gate before Einstein’s clock even starts.

AI is what makes that gate matter more now, not less.

AI can scan your entire feedback corpus, cluster signals by frequency, surface correlations with churn, and tell you in minutes that the widget request appeared in twenty-three of forty calls. That is genuinely useful and genuinely predictive: pattern-finding at a scale no human can match.

But notice what AI cannot do in that example. It can tell you the signal is strong. It cannot tell you the signal is pointing at the wrong job. That judgment, that “more widgets” is really “I cannot see what matters,” and that building the literal request might make things worse, is meaning-making, not pattern-matching.

Fulya Lisa Neubert, writing for the Slack Design blog, starts with a familiar design handoff problem:

For most of my design career, Figma was where the real work happened. I’d design screens, build prototypes, then hand off the designs for someone else to build. If something felt slightly wrong in production, we’d go back and forth trying to articulate what “it should feel like” in words. This process worked well enough, but there was always a gap between what I could show in a static design tool and what someone would actually experience in the product.

The piece gets concrete when Neubert moves from screens to Slack search. She points to a kind of interaction where static prototypes can suggest the flow, but can’t prove whether the experience works under someone’s hands:

The search experience in Slack is a deeply keyboard-driven feature: typing states, focus management, the way content scrolls and reflows as you interact. These are things you can sketch in Figma and even prototype to a degree, but a Figma prototype can’t tell you whether the focus ring moves correctly between elements when you press tab, or whether a scrolling gradient feels right as content overflows. You need to actually use it.

I don’t read this as an argument that designers need to become frontend engineers. Neubert came in with the basics and figured it out:

I came into this with basic HTML and CSS — enough to roughly understand what I was looking at, but not enough to write it myself. That turned out to matter less than I expected. The first time I described a focus interaction in plain language and had a prototype working in minutes, I stopped thinking of code as someone else’s territory. […]

My setup is fairly straightforward. Cursor is my main environment. I use Figma’s MCP integration to pull in components I’ve already designed and Slack’s design tokens, so I don’t have to rebuild spacing, color, and type from scratch every time. I tried working directly in Slack’s codebase — years of accumulated complexity that made every small change feel like a bigger undertaking than it needed to be. […]

The Figma integration matters because the prototype isn’t starting from a blank toy environment. It pulls real components and tokens into a lighter workspace, which makes the thing shareable without pretending to be production. For Slack search, that means the team can review behavior instead of debating screenshots.

Neubert is also clear about the tax:

AI also doesn’t always preserve what you’ve already built. You prompt it to change one thing, and it quietly breaks something else. If you’re not testing after every turn, you won’t notice until you’re sharing the prototype with someone — or worse, presenting it — and that’s when you realize something’s broken.

That is the right caution. AI changes the distance between intent and working behavior, but it doesn’t remove verification. If anything, it makes the habit of testing after every small change part of the design process itself.

Dan Carey leads product at Anthropic Labs, the team behind Claude Code and Claude Design. In a talk on how a three-person team shipped Claude Design in ten weeks, he describes what happened to everyone else after their engineers got fast:

And so once Claude Code took off, the bottleneck moved. The bottleneck moved from building the feature to figuring out the right things to be building for your users, in a lot of cases. So the option was either skip those early steps, just try and decide on the fly, and potentially build the wrong thing really fast, or try to find ways for the rest of us to speed up. So our designers, our PMs, were having trouble keeping up. We needed our own accelerator tool.

Carey just relocated the bottleneck onto the exact work designers and PMs own: figuring out what’s worth building. That’s product discovery becoming the real constraint. When building gets cheap, what’s left to get right is the decision about what to build at all.

How does the team make that call? Not by writing it down:

So we like to use prototypes because documents are imprecise. It’s so easy for two people to look at the same doc and have two different products in mind about what the experience should be. […] Prototypes are more concrete, more visceral. They let you get hands on with the thing and really feel the experience yourself.

They skipped the PRD and the vision docs entirely. A working prototype immediately aligns people, and it doubles as the discovery tool: you build the rough thing to find out what the right thing is.

And it helped that the team was small enough to skip coordination entirely. Here’s Carey:

Everyone on the team does everything. The engineers talk to users, PMs write code, designers do data analysis. All of these things are enabled in part with Claude. And the lines between the roles on this team, they have essentially dissolved at this point. You do have your specialization, you do have the unique perspective and diversity that you bring to a team, but at any moment, any one of these people on this team can talk to 10 users, you can realize what the underlying problem is, you can design a solution to it, you can ship it to users, you can listen for feedback, you can keep iterating solo if you need to.

On Carey’s team, the designer who spots the problem also builds the solution and ships it. That’s the kind of role a lot of designers are now being asked to grow into, and it looks less like a handoff between specialists than one person carrying an idea from problem to finished screen.

Speed doesn’t guarantee you build the right thing, though, and Carey is candid about the team’s misses. They built a set of advanced, fine-grained controls for power users. A few vocal testers loved them—I know I would have. But the usage showed everyone else hated them, and the team pulled the controls in a week. Two lessons came out of it:

So this taught us a couple of things. One, this taught us that we should be a tool that lifts the level of craft for everybody, not just the ceiling on power users. It also taught us that we want to be as open as possible, because there will be users that we never meet the full needs of. There’s going to be some power user out there who wants to do something very specific that we’re not going to support. And that’s what convinced us that we wanted this to be a very open tool. That’s why if you export from it, you get HTML, CSS, JavaScript.

I don’t think the Ferrari Luce is ugly. It’s just off-brand. Way off-brand.

I was quoted in Fast Company recently on brand refreshes, and the advice that keeps coming back for me is that brand work has to carry what people already believe about the company. That’s why the Jaguar logo rebrand and the Cracker Barrel blowback had the same shape. The object can be fine in isolation; the reaction is to what it asks people to forget.

Abigail Bassett, writing for The Verge, gets at that with Ferrari’s first EV:

“The reaction illustrates how intrinsically the brand identity, expectations, and design are tied together,” Derek Jenkins, the SVP of Design and Brand at Lucid, told The Verge. “I can see a couple of things in the exterior design that still reference the brand. The taillights for one, the red color option, and finally, the logo. Everything else — proportions, lack of visual agility, even the expression of performance — is missing from the exterior. The face of the car isn’t identifiable… It’s a mismatch with the brand.”

Identity isn’t the badge at the end. It’s the set of expectations the badge has trained you to bring. Ferrari can make an EV. But if the only recognizable Ferrari parts are the color, taillights, and logo, then the product is borrowing equity it isn’t paying back.

Bassett also gets to the LoveFrom question: Ferrari hired LoveFrom, Jony Ive’s design firm, and the firm’s product-design strengths don’t automatically transfer to automotive design.

As Raphael Zammit, chair of transportation design at the College for Creative Studies in Michigan, explained, industrial design and automotive design are two very different disciplines, and the skills from one do not consistently translate to the other. Ive’s Apple iPhone design made the physical phone disappear, Zammit said, and was “100 percent appropriate for a digital communication device that you hold in your hand.” But a Ferrari is not an iPhone.

Ferrari’s decision to hire LoveFrom was a choice with a built-in logic, Zammit argued. “Ive is a brand,” he said. “When you hire Brad Pitt, you expect to get Brad Pitt.” The interior of the Luce has been praised for its blend of analog and digital touchpoints. But the interior language would likely be much more at home in a small premium city car, he added, such as a Fiat 500 or a Cinquecento, not a supercar that retails for half a million dollars.

I do love the interior, as it screams consideration on every surface. But Zammit’s distinction is right: the iPhone’s best trick was making the object recede behind the software. Ferrari is nearly the opposite problem. The object is the story.

Zammit again, on the exterior:

Among automotive designers, the criticism is no less blunt. “It is brutally bland, actually. It really does look as if it was designed by AI. It’s like a mathematical averaging of many different themes,” Zammit said, adding that, “it’s almost alarmingly vacant of identity.”

There’s a lot that critics hate about the Luce. The stance and proportions, for example, are all wrong for Ferrari, which is known for its lithe and aggressive lines. The front end of the vehicle is generic, even with the air vent over the front glass (a video of executives showing the car to Pope Leo demonstrates that you can pass your entire arm through it).

“It’s not a sports car, it’s not a city electric, and it’s not really luxury,” Zammit said. “It seems like they might have gotten a little bit snowed or oversold by LoveFrom… The strategy is very muddy, because of what they’re doing versus what they’re saying on different parts of the vehicle.”

“Alarmingly vacant of identity” is brutal because it separates competent surface from brand truth. There are plenty of bland cars in the world. There aren’t supposed to be bland Ferraris.

Bassett closes the loop in the piece’s final section:

Ferrari’s whole cultural function, as a signal, a provocation, an investment, depends on being unmistakably true to itself, its heritage, and, most importantly, its design.

When you remove the engine, the most emotionally resonant element in Ferrari’s history, you have to replace it with something compelling, Zammit points out, and the Luce’s design doesn’t do that.

Despite the design flop, Zammit was careful to separate it from the brand’s long-term health, calling it “a bit of a stumble, both in concept and in execution,” but said Ferrari had too strong a record to be permanently damaged.

One thing is clear in the face of all the negative coverage: In trying to signal a new era for Ferrari, the Luce has made everyone suddenly more interested in the old one.

That’s what makes the Luce a brand-design story, not just a car-design story. The Luce may turn out to be strategically useful for Ferrari. But the design problem is simple: it asks the bolted-on badge to do too much of the work.

David Pierce, writing for The Verge, dates the inflection precisely: late 2025, when an update to Claude Code crossed the line from “surprising when it worked” to “surprising when it didn’t.” That’s the moment vibe coding stopped being a demo and started being a tool ordinary people could actually use.

In late 2025, an update to Anthropic’s Claude model turned its Claude Code tool from a code generator that was surprising if it worked to one that was surprising when it didn’t. Suddenly, all you needed was $20 a month and a half-formed idea, and an AI model could build you functional software. If you could explain what wasn’t working, Claude Code could probably fix it. Andrej Karpathy, an educator and researcher who was on OpenAI’s founding team, had called this new behavior “vibe coding.” Suddenly the vibes were off the charts.

The reliability threshold matters more than the headline number. Twenty dollars a month was already true. What changed is that the output stopped breaking when you asked it to do something real. That’s what made the personal software lineage—from HyperCard in 1987 through Lee Robinson’s essay, the home-cooked-app idea, micro-apps, and fleeting apps—turn from a niche aesthetic into something a normal person could actually do over a weekend.

Pierce documents his own version of that weekend: building Timetable, abandoning it, building Spring and forgetting what it did, getting stuck on Twilio bills. The realization that pulls him out of the loop is the one that’s worth dwelling on:

What saved my efforts was the realization that personal software doesn’t have to be built from scratch. Knowledgeable developers might be newly capable home cooks, but the rest of us are more like customers at Chipotle. We don’t make the food, we don’t even really assemble it, but we get to decide what goes where and how it’s served to us. For most of us, the future of software is not building our own Excel from scratch, it’s using the models to build spreadsheets wildly more capable than we could create ourselves. It’s building the Chrome extension for your favorite app that is really only missing a Chrome extension. It’s tweaking the way things look to suit your exact taste and needs.

Most coverage of vibe coding implies the future is everyone becoming a one-person engineering team. Pierce’s actual claim is narrower and more useful: like ordering a Chipotle burrito, you’re picking ingredients and toppings, not running the kitchen. The point is not to replace Notion or Obsidian or Todoist. It’s to bend them an inch closer to how you actually work.

My whole publishing workflow for this blog switched from Payload CMS to a custom admin UI and now a custom Obsidian plugin.

Which brings the conversation to where Pierce lands it: taste.

In this new world, the most important thing you’ll need is taste. Not objectively good taste, necessarily, so much as a keen sense of your own. You need to be like Rick Rubin, the famous music producer, who once told 60 Minutes that what made him successful was not any particular technical ability, but “the confidence I have in my taste, and my ability to express what I feel.” Rubin practices that art with A-list celebrities; you need to be able to do it with AI. Otherwise, you’ll land in what Lovin calls “doom loops,” telling your chatbot only what you don’t like and counting on the model to be the creative one. That way lies madness — and bad software.

Yan Liu’s working definition of taste cites the same Rubin formula—sensitivity times standards—and that’s the part of Pierce’s argument that designers should sit with. The $20 vibe-coder has the tool. What they often don’t have is the trained eye to know when Claude’s purple gradient is wrong, or why the icon looks like a butthole instead of a planner. Pierce learned this the hard way and concluded, sensibly, that he didn’t have opinions about databases but did have opinions about typefaces. That’s the right diagnosis. It also undersells what designers actually do—Raj Nandan Sharma’s warning about taste-as-end-of-pipeline selection is the other half of this. If designers don’t show up as authors here—shaping what gets generated, not just thumbs-upping it after the fact—the personal software era will produce a lot of bespoke purple gradients and not much else.

Gess Puglielli, writing on LinkedIn, argues that the speed of AI interface generation has revealed something other than a new tool. It has revealed that a lot of companies were never working from a real definition of design:

But interfaces were never the real value of design. They were just the artefacts left behind. The output. The visible layer of a much deeper process involving human behaviour, systems thinking, psychology, usability, strategy, communication, emotion, culture and invention. Design was never about moving pixels around a canvas. Design is how humans shape the world around them.

Jakob Nielsen made an adjacent argument about the shift from artifact production to intent shaping. Puglielli is pointing at something sharper. Nielsen describes a shift in what designers do; Puglielli says the shift has exposed a category of companies that mistook the artifact for the work in the first place.

The diagnostic part is what stayed with me:

In many organisations, designers were already being treated like production software long before generative AI arrived. The process often looked something like this: Product defines requirements. Engineering defines constraints. Leadership defines strategy. Then design is invited in to “make it look good.” At that point, the designer has already been removed from the act of designing. They’ve become decorators of predetermined decisions.

This is what makes “AI replaced our designers” make sense inside certain rooms and sound absurd inside others. If your design function had already been narrowed to ticket-taking execution, AI can replicate execution. Karri Saarinen pointed at the same misunderstanding when he wrote that the hard part of design is understanding the problem well enough to know what should exist at all. Puglielli’s contribution is the corollary: the companies that don’t know that won’t notice it’s missing when it gets cut.

Puglielli argues what AI isn’t good at:

AI can generate screens. It cannot independently define meaningful problems worth solving. It cannot deeply understand cultural nuance, emotional context or human contradiction in the way experienced designers can. It cannot navigate organisational politics, align competing stakeholder priorities, recognise ethical implications or identify latent human needs before users themselves can articulate them.

Most importantly, it cannot care. And care matters more than the industry likes to admit.

Care is the right word for designers and a weak word for industry, because businesses don’t pay for care. They pay for the outputs care produces—taste, the ability to see a problem before it’s named, and the thing we call judgment.

The headline says it all: “Uber president says AI spending is getting ‘harder to justify.’”

Jess Weatherbed, writing in The Verge:

After reportedly exhausting its annual AI budget just four months into 2026, Uber is now questioning whether it’s actually seeing meaningful returns on its investments. In an interview with Rapid Response, Uber president and chief operating officer Andrew Macdonald said the company isn’t seeing a connection between rising token consumption for Claude Code and more useful features being delivered to consumers.

“That link is not there yet, right? I think maybe implicitly there is more that is getting shipped, but it’s very hard to draw a line between one of those stats and, ‘Okay, now we’re actually producing 25 percent more useful consumer features,’” said Macdonald. “I think over the coming quarters and years, maybe that will become clearer, but I think today it’s hard, even if some of the underlying metrics are trending in a really astronomical direction.”

Two quick thoughts. First, engineering—and by extension, product and design—velocity gains like 2x, 3x, or 10x show up in the output. They aren’t showing up directly in the outcomes. Getting to a design faster doesn’t mean you designed the right thing.

Second, we haven’t redesigned the factory floor yet. It’s a metaphor I’m borrowing from Tommy Geoco. When factories converted from steam power to electricity in the 1880s, they swapped out the engines and did nothing else. The floor plan and workflow didn’t change. For three decades, output barely moved. Only when companies redesigned their factories and process around the new technology did they see an increase in output.

We haven’t quite figured this out as an industry or discipline yet. As I’ve written previously, it’s foggy but the shape is unmistakable. The answer is out there.

The artifact-to-intent argument has been working its way through design writing for a while now. What Jakob Nielsen adds to it, writing in UX Tigers, is a name for the failure mode that comes with the territory:

We used to accumulate design debt when teams shipped inconsistent components or patched over poor flows. Now we will accumulate intent debt: undocumented assumptions, vague brand guidance, missing escalation rules, untested agent permissions, and research insights that never become usable by the systems doing the work. Intent debt will be harder to see than visual inconsistency, but it will be more damaging because it compounds invisibly through every generated output.

Nielsen’s prior writing on intent-based UX argued that evaluation has become the new bottleneck for the user. A chat completes the task in seconds, and you spend the next half hour checking whether it actually did what you meant. Intent debt extends that bottleneck to the organization. The team ships ten variants in an afternoon, and nobody can tell which ones violated a brand rule that was never written down, or bypassed an escalation path that only lived in a senior designer’s head.

Nielsen puts the failure plainly:

The new danger is that AI will produce many adequate screens that all seem defensible in isolation and incoherent in aggregate. Mediocrity will arrive well-dressed. The designer’s role is to prevent the organization from drowning in plausible options.

Which is why the design system has to grow up:

The design system thus stops being a component library and becomes an operating system for taste. Tokens, components, and usage rules are only the visible layer. Underneath must be a deeper set of instructions about brand behavior, interaction philosophy, accessibility standards, motion logic, content tone, escalation patterns, and product judgment. The system must know not only which button to use, but when not to add a button at all.

Developer Mark Anthony Cianfrani has argued that LLMs finally let us ship the reasoning behind a token alongside the token. Nielsen draws the consequence of skipping that work: a weak design system in the AI era becomes an active liability. Agents will faithfully build with whatever’s encoded, and faithfully invent the rest.

Michael Riddering brings Tommy Geoco on Dive Club fresh off field visits to Vercel, Perplexity, Metalab, Ramp, and Snowflake. Geoco and his team are making a documentary after roughly 200 conversations with designers and design leaders this year. The survey finding he leads with is the one I would have least expected: designers who have moved more of their work into AI-assisted prototyping are also more satisfied with their workflows. The hierarchy of who is actually doing that work is the part worth sitting with:

The number one thing that stood out to me was that designers who are currently vibe coding are more satisfied with their workflows. […] And I did not expect that. […] People seem to dig it in this survey. […] It’s the people who are currently doing the majority of their workflow on vibe coding activities. It’s design engineers. That makes sense. Lead principals. [After that] it’s non-designer roles, which might be students and researchers. Then it’s managers. And then it’s your general junior mid-level IC. And that part was fascinating that managers are doing more than junior and mid-level ICs. Either things are trickling down and people are experimenting and then they’re going to pass learnings down, which is kind of what we’ve seen on location. But it also might mean that like some managers or teams haven’t yet made room for the rest of the team.

Design engineers and leads at the top is unsurprising. Managers above juniors and mid-levels is the inversion, and remains basically unchanged from two years ago when Geoco’s 2024 survey found the same thing.

Leadership-IC Divide. Leaders adopt AI at a higher rate (29.0%) than ICs (19.9%)

So what’s the read? Geoco gives it the generous read first—learnings cascading down—and then concedes the other possibility: some teams haven’t made room for the rest of the team. Riddering puts it more bluntly: “I’m looking at a bunch of junior and mid designers that are getting cut out of the process.”

The other finding is that 59% of designers have built their own tool for their workflow. The example Geoco brings back from Vercel makes the builder-mode shift concrete:

When I went over to Vercel, they had this brand designer, who had never coded before. And now was vibe coding a tool. Their marketing team would put out blog posts. And they were like, “Why does the design team need to create the OG blog post cards for every page? That’s not a good use of [their time].” So he built a tool that just allowed them to insert any sort of images. And it just already had all of the branding and the sizing baked in. And they just roll these [tools] out quickly. And I’m like, that just became a tool, an internal tool. That’s cool. And so because it was really interesting that they started referring to him as a brand engineer… And I’m like, okay, that kind of qualifies it actually.

A designer who had never coded solves an actual marketing-team problem, ships the tool, and the role title arrives after the work. That is how the next batch of “blank engineer” titles is going to land. Riddering then describes how the orchestrator pattern works in his own day-to-day, offering a concrete account of the workflow I have been writing about as orchestration from a working designer:

Part of me is almost slightly self-conscious about it. But I do the vast, vast majority of my messy explorations with AI now. I feel like I have made the jump to the quote unquote creative director where I’m just working with AI to show me a certain thing 50 different ways. And then I’m pulling the pieces that I like and then combining them again. And finally I get to somewhere where I’m like, yep, that’s good. And then I take that from paper, run it through cloud code, and now it exists on localhost. And then I will sweat the details and actually do the precision designing in code, which is, that’s crazy, man. That’s a very, very different workflow than I’ve done at any point in my career.

The orchestrator gap is opening where I thought it would. What I did not account for is who is getting invited into that work first. The data Geoco surfaces points to leads, managers, and design engineers getting more chances to build with AI than junior and mid-level ICs.

Here’s a hypothesis I’ll put out there: leads are more used to directing. I’m personally comfortable with orchestrating, being the editor because I’ve been a creative director and leader for so long. The loop is right there: frame, review, direct.