Designers know this feeling. Your work lives inside whatever tool made it—Figma, Miro, Framer—and when that tool changes its pricing, gets acquired, or shuts down, your files go with it. We’ve now accepted this as normal.

Dan Abramov argues it shouldn’t be. In a long post about the AT Protocol (the technology behind Bluesky), he starts with how files used to work on personal computers:

The files paradigm captures a real-world intuition about tools: what we make with a tool does not belong to the tool. A manuscript doesn’t stay inside the typewriter, a photo doesn’t stay inside the camera, and a song doesn’t stay in the microphone.

He takes that intuition and applies it to social computing. What if your posts, likes, and follows were files you owned instead of data locked inside Instagram or Twitter? Abramov calls this a “social filesystem” and walks through how the AT Protocol makes it real, from records and collections to identity and links, all building toward one idea:

Our memories, our thoughts, our designs should outlive the software we used to create them. An app-agnostic storage (the filesystem) enforces this separation.

That word “designs” jumped out at me. Abramov is talking about social data, but the same logic applies to creative work. The inversion he describes, where apps react to your data rather than owning it, is the opposite of how most design tools work today:

In this paradigm, apps are reactive to files. Every app’s database mostly becomes derived data—an app-specific cached materialized view of everybody’s folders.

One of the reasons I write content here on this blog as opposed to writing in a social network or even Substack—though my newsletter is on Substack, humans aren’t perfect—is because I want the control and ownership Abramov brings up.

The whole post is worth reading. Abramov makes the AT Protocol’s architecture feel inevitable rather than complicated, and his closing line is the one I keep thinking about: “An everything app tries to do everything. An everything ecosystem lets everything get done.”

Earlier I linked to Hardik Pandya’s piece on invisible work—the coordination, the docs, the one-on-ones that hold projects together but never show up in a performance review. Designers have their own version of this problem, and it’s getting worse.

Kai Wong, writing in his Data and Design Substack, puts it plainly. A design manager he interviewed told him:

“It’s always been a really hard thing for design to attribute their hard work to revenue… You can make the most amazingly satisfying user experience. But if you’re not bringing in any revenue out of that, you’re not going to have a job for very much longer. The company’s not going to succeed.”

That’s always been true, but AI made it urgent. When a PM can generate something that “looks okay” using an AI tool, the question is obvious: what do we need designers for? Wong’s answer is the strategic work—research, translation between user needs and business goals. The trouble is that this work is the hardest to see.

Wong’s practical advice is to stop presenting design decisions in design terms. Instead of explaining that Option A follows the Gestalt principle of proximity, say this:

“Option A reduces checkout from 5 to 3 steps, making it much easier for users to complete their purchase instead of abandoning their cart.”

You’re not asking “which looks better?” You’re showing that you understand the business problem and the user problem, and can predict outcomes based on behavioral patterns.

I left a comment on this article when it came out, asking how these techniques translate at the leadership level. It’s one thing to help individual designers frame their work in business terms. It’s another to make an entire design org’s contribution legible to the rest of the company. Product management talks to customers and GTM teams. Engineering delivers features. Design is in the messy middle making sense of it all—and that sense-making is exactly the kind of invisible work that’s hardest to put on a slide.

For as long as I’ve been in startups, execution speed has been the thing teams optimized for. The assumption was always that if you could just build faster, you’d win. That’s your moat. AI has mostly delivered on that promise—teams can now ship in weeks—see Claude Cowork—what used to take months. And the result is that a lot of teams are building the wrong things faster than ever.

Gale Robins, writing for UX Collective, opens with a scene I’ve lived through from both sides of the table:

I watched a talented software team present three major features they’d shipped on time, hitting all velocity metrics. When I asked, “What problem do these features solve?” silence followed. They could describe what they’d built and how they’d built it. But they couldn’t articulate why any of it mattered to customers.

Robins argues that judgment has replaced execution as the real constraint on product teams. And AI is making this worse, not better:

What once took six months of misguided effort now takes six weeks, or with AI, six days.

Six days to build the wrong thing. The build cycle compressed but the thinking didn’t. Teams are still skipping the same discovery steps, still assuming they know what users want. They’re just doing it at a pace that makes the waste harder to catch.

Robins again:

AI doesn’t make bad judgment cheaper or less damaging — it just accelerates how quickly those judgment errors compound.

She illustrates this with a cascade example: a SaaS company interviews only enterprise clients despite SMBs making up 70% of revenue. That one bad call—who to talk to—ripples through problem framing, solution design, feature prioritization, and evidence interpretation, costing $315K over ten months. With AI-accelerated development, the same cascade plays out in five months at the same cost. You just fail twice as fast.

The article goes on to map 19 specific judgment points across the product discovery process. The framework itself is worth a read, but the underlying argument is the part I keep coming back to: as execution gets cheaper, the quality of your decisions is the only thing that scales.

I’ve watched this pattern play out more times than I can count: a team ships something genuinely better and users ignore it. They go back to the old thing. The spreadsheet. The manual process. And the team concludes that users “resist change,” which is the wrong diagnosis.

Tushar Deshmukh, writing for UX Magazine, frames it well:

Many teams assume users dislike change. In reality, users dislike cognitive disruption.

Deshmukh describes an enterprise team that built a predictive dashboard with dynamic tiles, smart filters, and smooth animations. It failed. Employees skipped it and went straight to the basic list view:

Not because the dashboard was bad. But because it disrupted 20 years of cognitive routine. The brain trusted the old list more than the new intelligence. When we merged both—familiar list first, followed by predictive insights—usage soared.

He tells a similar story about a logistics company that built an AI-powered route planner. Technically superior, visually polished, low adoption. Drivers had spent years building mental models around compass orientation, landmarks, and habitual map-reading patterns:

The AI’s “optimal route” felt psychologically incorrect. It was not wrong—it was unfamiliar. We added a simple “traditional route overlay,” showing older route patterns first. The AI suggestion was then followed as an enhancement. Adoption didn’t just improve—trust increased dramatically.

The fix was the same in both cases: layer the new on top of the familiar. Don’t replace the mental model—extend it. This is something I think about constantly as my team designs AI features into our product. The temptation is always to lead with the impressive new capability. But if users can’t find their footing in the interface, the capability doesn’t matter. Familiarity is the on-ramp.

Fitts’s Law is one of those design principles everyone learns in school and then quietly stops thinking about. Target size, target distance, movement time. It’s a mouse-and-cursor concept, and once you’ve internalized the basics—make buttons big, put them close—it fades into the background. But with AI and voice becoming primary interaction models, the principle matters again. The friction just moved.

Julian Scaff, writing for Bootcamp, traces Fitts’s Law from desktop GUIs through touch, spatial computing, voice, and neural interfaces. His argument is that the law didn’t become obsolete—it became metaphorical:

With voice interfaces, the notion of physical distance disappears altogether, yet the underlying cognitive pattern persists. When a user says, “Turn off the lights,” there’s no target to touch or point at, but there is still a form of interaction distance, the mental and temporal gap between intention and response. Misrecognition, latency, or unclear feedback increase this gap, introducing friction analogous to a small or distant button.

“Friction analogous to a small or distant button” is a useful way to think about what’s happening with AI interfaces right now. When a user stares at a blank text field and doesn’t know what to type, that’s distance. When an agent misinterprets a prompt and the user has to rephrase three times, that’s a tiny target. The physics changed but the math didn’t.

Scaff extends this into AI and neural interfaces, where the friction gets even harder to see:

Every layer of mediation, from neural decoding errors to AI misinterpretations, adds new forms of interaction friction. The task for designers will be to minimize these invisible distances, not spatial or manual, but semantic and affective, so that the path from intention to effect feels seamless, trustworthy, and humane.

He then describes what he calls a “semantic interface,” one that interprets intent rather than waiting for explicit commands:

A semantic interface understands the why behind a user’s action, interpreting intent through context, language, and behavior rather than waiting for explicit commands. It bridges gaps in understanding by aligning system logic with human mental models, anticipating needs, and communicating in ways that feel natural and legible.

This connects to the current conversation about AI UX. The teams building chatbot-first products are, in Fitts’s terms, forcing users to cross enormous distances with tiny targets. Every blank prompt field with no guidance is a violation of the same principle that tells you to make a button bigger. We’ve known this for seventy years. We’re just ignoring it because the interface looks new.

For years, the thing that made designers valuable was the thing that was hardest to fake: the ability to look at a spreadsheet of requirements and turn it into something visual that made sense. That skill got people hired and got them a seat at the table. And now a PM with access to Lovable or Figma Make can produce something that looks close enough to pass.

Kai Wong interviewed 22 design leaders and heard the same thing from multiple directions. One Global UX Director described the moment it clicked for his team:

“A designer on my team had a Miro session with a PM — wireframes, sketches, the usual. Then the PM went to Stitch by Google and created designs that looked pretty good. To an untrained eye, it looked finished. It obviously worried the team.”

It should worry teams. Not because the PM did anything wrong, but because designers aren’t always starting from a blank canvas anymore. They’re inheriting AI-generated drafts from people who don’t know what’s wrong with them.

Wong puts the commoditization bluntly:

Our superpower hasn’t been taken away: it’s more like anyone can buy something similar at the store.

The skill isn’t gone. It’s just no longer rare enough to carry your career on its own. What fills the gap, Wong argues, is the ability to articulate why—why this layout works, why that one doesn’t. One CEO he interviewed put it this way:

“I want the person who’s designing the thing from the start to understand the full business context.”

This resonates with me as a design leader. The designers on my teams who are hardest to replace are the ones who can walk into a room and explain why something needs to change, and tie that explanation to a user need or a business outcome. AI can’t do that yet. And the people generating those 90%-done drafts definitely can’t.

Every few years, the industry latches onto an interaction paradigm and tries to make it the answer to everything. A decade ago it was “make it an app.” Now it’s “just make it a chat.” The chatbot-as-default impulse is strong right now, and it’s leading teams to ship worse experiences than what they’re replacing.

Katya Korovkina, writing for UX Collective, calls this “chatbot-first thinking” and lays out a convincing case for why it’s a trap:

Many of the tasks we deal with in our personal life and at work require rich, multi-modal interaction patterns that conversational interfaces simply cannot support.

She walks through a series of validating questions product teams should ask before defaulting to a conversational UI, and the one that stuck with me is about discoverability. The food ordering example is a good one—if you don’t know what you want, listening to a menu read aloud is objectively worse than scanning one visually. But the real issue is who chat-first interfaces actually serve:

Prompt-based products work best for the users who already know how to ask the right question.

Jakob Nielsen has written about this as the “articulation barrier,” and Korovkina cites the stat that nearly half the population in wealthy countries struggles with complex texts. We’re building interfaces that require clear, precise written communication from people who don’t have that skill. And we’re acting like that’s fine because the technology is impressive.

Korovkina also makes a practical point that gets overlooked. She describes using a ChatGPT agent to get a YouTube transcript — a task that takes four clicks with a dedicated tool — and watching the agent spend minutes crawling the web, hitting paywalls, and retrying failures:

When an LLM agent spends five minutes crawling the web, calling tools, retrying failures, reasoning through intermediate steps, it is running on energy-intensive infrastructure, contributing to real data-center load, energy usage, and CO₂ emissions. For a task that could be solved with less energy by a specialised service, this is computational overkill.

The question she lands on—“was AI the right tool for this task at all?”—is the one product teams keep skipping. Sometimes a button, a dropdown, and a confirmation screen is the better answer.

Back in September, when Trump announced America by Design and appointed Joe Gebbia as Chief Design Officer, I wrote that it was “yet another illustration of this administration’s incompetence.” The executive order came months after DOGE gutted 18F and the US Digital Service, the agencies that had spent a decade building the expertise Gebbia now claims to be inventing.

Mark Wilson, writing for Fast Company, spoke to a dozen government designers about how Gebbia’s tenure has played out. When Wilson asked Gebbia about USDS and 18F—whether he thought these groups were overrated and needed to be rebuilt—here’s what he said:

“Without knowing too much about the groups you mentioned, I do know that the air cover and the urgency around design is in a place it’s [never] been before.”

He doesn’t know much about them. The agencies his administration destroyed. The hundreds of designers recruited from Google, Amazon, and Facebook who fixed healthcare.gov and built the COVID test ordering system. He doesn’t know much about them.

Mikey Dickerson, who founded USDS, on the opportunity Gebbia inherited:

“He’s inheriting the blank check kind of environment… [so] according to the laws of physics, he should be able to get a lot done. But if the things that he’s allowed to do, or the things that he wants to do, are harmful, then he’ll be able to do a lot of harm in a really short amount of time.”

And what has Gebbia done with that blank check? He’s built promotional websites for Trump initiatives: trumpaccounts.gov, trumpcard.gov, trumprx.com. Paula Scher of Pentagram looked at the work:

“The gold card’s embarrassing. The typeface is hackneyed.”

But Scher’s real critique goes beyond aesthetics.

“You can’t talk about people losing their Medicare and have a slick website,” says Paula Scher. “It just doesn’t go.”

That’s the contradiction at the center of America by Design. You can’t strip food stamps, gut healthcare subsidies, and purge the word “disability” from government sites, then turn around and promise to make government services “delightful.” The design isn’t the problem. The policy is.

Scher puts it plainly:

“[Trump] wants to make it look like a business. It’s not a business. The government is a place that creates laws and programs for society—it’s not selling shit.”

Wilson’s piece is long and worth reading in full. There’s more on what USDS and 18F actually accomplished, and on the designers who watched their work get demolished by people who didn’t understand it.

Google’s design team is working on a hard problem: how do you create a visual identity for AI? It’s not a button or a menu. It doesn’t have a fixed set of functions. It’s a conversation partner that can do… well, a lot of things. That ambiguity is difficult to represent.

Daniel John, writing for Creative Bloq, reports on Google’s recent blog post about Gemini’s visual design:

“Consider designer Susan Kare, who pioneered the original Macintosh interface. Her icons weren’t just pixels; they were bridges between human understanding and machine logic. Gemini faces a similar challenge around accessibility, visibility, and alleviating potential concerns. What is Gemini’s equivalent of Kare’s smiling computer face?”

That’s a great question. Kare’s work on the original Mac made the computer feel approachable at a moment when most people had never touched one. She gave the machine a personality through icons that communicated function and friendliness at the same time. AI needs something similar: a visual language that builds trust while honestly representing what the technology can do.

Google’s answer? Gradients. They offer “an amorphous, adaptable approach,” one that “inspires a sense of discoverability.”

They think they’ve nailed it. I don’t think they did.

To their credit, Google seems to sense the comparison is a stretch. John quotes the Google blog again:

“Gradients might be much more about energy than ‘objectness,’ like Kare’s illustrations (a trash can is a thing, a gradient is a vibe), but they infuse a spirit and directionality into Gemini.”

Kare’s icons worked because they mapped to concrete actions and mental models people already had. A trash can means delete. A folder means storage. A smiling Mac means this thing is friendly and working. Gradients don’t map to anything. They just look nice. They’re aesthetic, not communicative. John’s word to describe them, “vibe” is right. Will a user pick up on the subtleties of a concentrated gradient versus a diffuse one?

The design challenge Google identified is real. But gradients aren’t the Kare equivalent. They’re not ownable nor iconic (pun intended). They’re a placeholder until someone figures out what is.

Daniel Kennett dug out his old Mac Pro to revisit Aperture, the photo app Apple discontinued in 2015:

It’s hard to overstate quite how revolutionary and smooth this flow is until you had it for multiple years before having it taken away. Nothing on the market—even over a decade later—is this good at meeting you where you are and not interrupting your flow.

Kennett’s observation: Aperture came to you. Most software makes you go to it. You could edit a photo right on the map view, or while laying out a book page. No separate editing mode. Press H for the adjustments HUD, make your changes, done.

The cruel twist was Apple suggesting Photos as a replacement. Ten years later, photographers are still grumbling about it in comment sections.

There’s a design principle I return to often: if everything is emphasized, nothing is. Bold every word in a paragraph and you’ve just made regular text harder to read. Highlight every line in a document and you’ve defeated the purpose of highlighting.

Nikita Prokopov applies this to Apple’s macOS Tahoe, which adds icons to nearly every menu item:

Perhaps counter-intuitively, adding an icon to everything is exactly the wrong thing to do. To stand out, things need to be different. But if everything has an icon, nothing stands out.

The whole article is a detailed teardown of the icon choices—inconsistent metaphors, icons reused for unrelated actions, details too small to parse at 12×12 effective pixels. But the core problem isn’t execution. It’s the premise.

Prokopov again:

It’s delusional to think that there’s a good icon for every action if you think hard enough. There isn’t. It’s a lost battle from the start.

What makes this such a burn is that Apple knew better. Prokopov pulls from the 1992 Macintosh Human Interface Guidelines, which warned that poorly used icons become “unpleasant, distracting, illegible, messy, cluttered, confusing, frustrating.” Thirty-two years later, Apple built exactly that.

This applies beyond icons. Any time you’re tempted to apply something universally—color, motion, badges, labels—ask whether you’re helping users find what matters or just adding visual noise. Emphasis only works through contrast.

When I worked at LEVEL Studios (which became Rosetta) in the early 2010s, we had a whole group dedicated to icon design. It was small but incredibly talented and led by Jon Delman, a master of this craft. And yes, Jon and team designed icons for Apple.

Those glory days are long gone and the icons coming out of Cupertino these days are pedestrian, to put it gently. The best observation about Apple’s icon decline comes from Héliographe, via John Gruber:

If you put the Apple icons in reverse it looks like the portfolio of someone getting really really good at icon design.

Posted by @heliographe.studio on Threads

Seven Pages icons from newest to oldest, each one more artistically interesting than the last. The original is exquisite. The current one is a squircle with a pen on it.

This is even more cringe-inducing when you keep in mind something Gruber recalls from a product briefing with Jony Ive years ago:

Apple didn’t change things just for the sake of changing them. That Apple was insistent on only changing things if the change made things better. And that this was difficult, at times, because the urge to do something that looks new and different is strong, especially in tech.

Apple’s hardware team still operates this way. An M5 MacBook Pro looks like an M1 MacBook Pro. An Apple Watch Series 11 is hard to distinguish from a Series 0. These designs don’t change because they’re excellent.

The software team lost that discipline somewhere. Gruber again:

I know a lot of talented UI designers and a lot of insightful UI critics. All of them agree that MacOS’s UI has gotten drastically worse over the last 10 years, in ways that seem so obviously worse that it boggles the mind how it happened.

The icons are just the most visible symptom. The confidence to not change something—to trust that the current design is still the best design—requires knowing the difference between familiarity and complacency. Somewhere along the way, Apple’s software designers stopped being able to tell.

I spent all of last week linking to articles that say designers need to be more strategic. I still stand by that. But that doesn’t mean we shouldn’t understand the technical side of things.

Benhur Senabathi, writing for UX Collective, shipped 3 apps and 15+ working prototypes in 2025 using Claude Code and Cursor. His takeaway:

I didn’t learn to code this year. I learned to orchestrate. The difference matters. Coding is about syntax. Orchestration is about intent, systems, and knowing what ‘done’ looks like. Designers have been doing that for years. The tools finally caught up.

The skills that make someone good at design—defining outcomes, anticipating edge cases, communicating intent to people who don’t share your context—are exactly what AI-assisted building requires.

Senabathi again:

Prompting well isn’t about knowing to code. It’s about articulating the ‘what’ and ‘why’ clearly enough that the AI can handle the ‘how.’

This echoes how Boris Cherny uses Claude Code. Cherny runs 10-15 parallel sessions, treating AI as capacity to orchestrate rather than a tool to use. Same insight, different vantage point: Cherny from engineering, Senabathi from design.

One of my favorite parts of shipping a product is finding out how people actually use it. Not how we intended them to use it—how they bend it, repurpose it, surprise us with it. That’s when you learn what you really built.

Karo Zieminski, writing for Product with Attitude, captures a great example of this in her breakdown of Anthropic’s Cowork launch. She quotes Anthropic engineer Boris Cherny:

Since we launched Claude Code, we saw people using it for all sorts of non-coding work: conducting vacation research, creating slide presentations, organizing emails, cancelling subscriptions, retrieving wedding photos from hard drives, tracking plant growth, and controlling ovens.

Controlling ovens. I love it. Users took a coding tool and turned it into a general-purpose assistant because that’s what they needed it to be.

Simon Willison had already spotted this:

Claude Code is a general agent disguised as a developer tool. What it really needs is a UI that doesn’t involve the terminal and a name that doesn’t scare away non-developers.

That’s exactly what Anthropic shipped in Cowork. Same engine, new packaging, name that doesn’t say “developers only.”

This is the beauty of what we do. Once you create something, it’s really up to users to show you how it should be used. Your job is to pay attention—and have the humility to build what the behavior is asking for, not what your roadmap says.

Nice mini-site from the Figma showcasing the “iconic interactions” of the last 20 years. It explores how software has become inseparable from how we think and connect—and how AI is accelerating that shift toward adaptive, conversational interfaces. Made with Figma Make, of course.

Every designer has noticed that specific seafoam green in photos of mid-century control rooms. It shows up in nuclear plants, NASA mission control, old hospitals. Wasn’t the hospital in 1975’s One Flew Over the Cuckoo’s Nest that color? It’s too consistent to be coincidence.

Beth Mathews traced the origin back to color theorist Faber Birren, who consulted for DuPont and created the industrial color safety codes still in use today. His reasoning:

“The importance of color in factories is first to control brightness in the general field of view for an efficient seeing condition. Interiors can then be conditioned for emotional pleasure and interest, using warm, cool, or luminous hues as working conditions suggest. Color should be functional and not merely decorative.”

Color should be functional and not merely decorative. These weren’t aesthetic choices—they were human factors engineering decisions, made in environments where one mistake could be catastrophic. The seafoam green was specifically chosen to reduce visual fatigue. Kinda cool.

“Taste” gets invoked constantly in conversations about what AI can’t replace. But it’s often left undefined—a hand-wave toward something ineffable that separates good work from average work.

Yan Liu offers a working definition:

Product taste is the ability to quickly recognize whether something is high quality or not.

That’s useful because it frames taste as judgment, not aesthetics. Can you tell if a feature addresses a real problem? Can you sense what’s off about an AI-generated PRD even when it’s formatted correctly? Can you distinguish short-term growth tactics from long-term product health?

Liu cites Rick Rubin’s formula:

Great taste = Sensitivity × Standards

Sensitivity is how finely you perceive—noticing friction, asking why a screen exists, catching the moment something feels wrong. Standards are your internal reference system for what “good” actually looks like. Both can be trained.

This connects to something Dan Ramsden wrote in his piece on design’s value in product organizations: “taste without a rationale is just an opinion.” Liu’s framework gives taste a rationale. It’s not magic. It’s pattern recognition built through deliberate exposure and reflection.

The closing line is the one that sticks:

The real gap won’t be between those who use AI well and those who don’t. It will be between those who already know what “good” looks like before they ever open an AI tool.

If design’s value isn’t execution—and AI is making that argument harder to resist—then what is it? Dan Ramsden offers a framework I find useful.

He breaks thinking into three types: deduction (drawing conclusions from data), induction (building predictions from patterns), and abduction—generating something new. Design’s unique contribution is abductive thinking:

When we use deduction, we discover users dropping off during a registration flow. Induction might tell us why. Abduction would help us imagine new flows to fix it.

Product managers excel at sense-making (aka “Why?”). Engineers build the thing. Design makes the difference—moving from “what is” to “what could be.”

On AI and the temptation to retreat to “creativity” or “taste” as design’s moat, Ramsden is skeptical:

Some might argue that it comes down to “taste”. I don’t think that’s quite right — taste without a rationale is just an opinion. I think designers are describers.

I appreciate that distinction. Taste without rationale is just preference. Design’s value is translating ideas through increasing levels of fidelity—from sketch to prototype to tested solution—validating along the way.

His definition of design in a product context:

Design is a set of structured processes to translate intent into experiments.

That’s a working definition I can use. It positions design not as the source of ideas (those can come from anywhere, including AI), but as the discipline that manages ideas through validation. The value isn’t in generating the concept—it’s in making it real while managing risk.

This piece cites my own research on the collapse of entry-level design hiring, but it goes further—arguing that AI didn’t cause the crisis. It exposed one that’s been building for over a decade.

Dolphia, writing for UX Collective:

We told designers they didn’t need technical knowledge. Then we eliminated their jobs when they couldn’t influence technical decisions. That’s not inclusion. That’s malpractice.

The diagnosis is correct. The design industry spent years telling practitioners they didn’t need to understand implementation. And now those same designers can’t evaluate AI-generated output, can’t participate in architecture discussions, can’t advocate effectively when technical decisions are being made.

Dolphia’s evidence is damning. When Figma Sites launched, it generated 210 WCAG accessibility violations on demo sites—and designers couldn’t catch it because they didn’t know what to look for:

The paradox crystalizes: tools marketed as democratization require more technical knowledge than traditional workflows, not less.

Where I’d add nuance: the answer isn’t “designers should learn to code.” It’s that designers need to understand the medium they’re designing for. There’s a difference between writing production code and understanding what code does, between implementing a database schema and knowing why data models influence user workflows.

I’ve been rebuilding my own site with AI assistance for over a year now. I can’t write JavaScript from scratch. But I understand enough about static site generation, database trade-offs, and performance constraints to make informed architectural decisions and direct AI effectively. That’s the kind of technical literacy that matters—not syntax, but systems thinking.

In “From Craft to Curation,” I argued that design value is shifting from execution to direction. Dolphia’s piece is the corollary: you can’t provide direction if you don’t understand what you’re directing.

Previously, I linked to Doug O’Laughlin’s piece arguing that UIs are becoming worthless—that AI agents, not humans, will be the primary consumers of software. It’s a provocative claim, and as a designer, I’ve been chewing on it.

Jeff Veen offers the counterpoint. Veen—a design veteran who cofounded Typekit and led products at Adobe—argues that an agentic future doesn’t diminish design. It clarifies it:

An agentic future elevates design into pure strategy, which is what the best designers have wanted all along. Crafting a great user experience is impossible if the way in which the business expresses its capabilities is muddied, vague or deceptive.

This is a more optimistic take than O’Laughlin’s, but it’s rooted in the same observation: when agents strip applications down to their primitives—APIs, CLI commands, raw capabilities, (plus data structures, I’d argue)—what’s left is the truth of what a business actually does.

Veen’s framing through responsive design is useful. Remember “mobile first”? The constraint of the small screen forced organizations to figure out what actually mattered. Everything else was cruft. Veen again:

We came to realize that responsive design wasn’t just about layouts, it was about forcing organizations to confront what actually mattered.

Agentic workflows do the same thing, but more radically. If your product can only be expressed through its API, there’s no hiding behind a slick dashboard or clever microcopy.

His closing question is great:

If an agent used your product tomorrow, what truths would it uncover about your organization?

For designers, this is the strategic challenge. The interface layer may become ephemeral—generated on the fly, tailored to the user, disposable. But someone still has to define what the product is. That’s design work. It’s just not pixel work.

The rise of micro apps describes what’s happening from the bottom up—regular people building their own tools instead of buying software. But there’s a top-down story too: the structural obsolescence of traditional software companies.

Doug O’Laughlin makes the case using a hardware analogy—the memory hierarchy. AI agents are fast, ephemeral memory (like DRAM), while traditional software companies need to become persistent storage (like NAND, or ROM if you’re old school like me). The implication:

Human-oriented consumption software will likely become obsolete. All horizontal software companies oriented at human-based consumption are obsolete.

That’s a bold claim. O’Laughlin goes further:

Faster workflows, better UIs, and smoother integrations will all become worthless, while persistent information, a la an API, will become extremely valuable.

As a designer, this is where I start paying close attention. The argument is that if AI agents become the primary consumers of software—not humans—then the entire discipline of UI design is in question. O’Laughlin names names:

Figma could be significantly disrupted if UIs, as a concept humans create for other humans, were to disappear.

I’m not ready to declare UIs dead. People still want direct manipulation, visual feedback, and the ability to see what they’re doing. But the shift O’Laughlin describes is real: software’s value is migrating from presentation to data. The interface becomes ephemeral—generated on the fly, tailored to the task—while the source of truth persists.

This is what I was getting at in my HyperCard essay: the tools we build tomorrow won’t look like the apps we buy today. They’ll be temporary, personal, and assembled by AI from underlying APIs and data. The SaaS companies that survive will be the ones who make their data accessible to agents, not the ones with the prettiest dashboards.

I’ve spent a lot of my product design career pushing for metrics—proving ROI, showing impact, making the case for design in business terms. But I’ve also seen how metrics become the goal rather than a signal pointing toward the goal. When the number goes up, we celebrate. When it doesn’t, we tweak the collection process. Meanwhile, the user becomes secondary. Last week’s big idea was around metrics, this piece piles on.

Pavel Samsonov calls this out:

Managers can only justify their place in value chains by inventing metrics for those they manage to make it look like they are managing.

I’ve sat in meetings where we debated which numbers to report to leadership—not which work to prioritize for users. The metrics become theater. So-called “vanity metrics” that always go up and to the right.

But here’s where Pavel goes somewhere unexpected. He doesn’t let designers off the hook either:

Defining success by a metric of beauty offers a useful kind of vagueness, one that NDS seems to hide behind despite the slow loading times or unnavigability that seem to define their output; you can argue with slow loading times or difficulty finding a form, but you cannot meaningfully argue with “beautiful.”

“Taste” and “beauty” are just another avoidance strategy. That’s a direct challenge to the design discourse that’s been dominant lately—the return to craft, the elevation of aesthetic judgment. Pavel’s saying it’s the same disease, different symptom. Both metrics obsession and taste obsession are ways to avoid the ambiguity of actually defining user success.

So what’s the alternative? Pavel again:

Fundamentally, the work of design is intentionally improving conditions under uncertainty. The process necessarily involves a lot of arguments over the definition and parameters of “improvement”, but the primary barrier to better is definitely not how long it takes to make artifacts.

The work is the argument. The work is facing the ambiguity rather than hiding behind numbers or aesthetics. Neither Figma velocity nor visual polish is a substitute for the uncomfortable conversation about what “better” actually means for the people using your product.

“I want my MTV!” That is the line that many music artists spoke to camera in a famous campaign by George Lois to get fans to call their cable companies to ask for MTV. It worked.

While MTV’s international music-only channels went off the air at the end of 2025, its US channels still exist. They’re just not all-music all the time like it was in the 1980s.

That’s where MTV Rewind comes in. It’s a virtual TV where you can relive MTV programming as it was. Built by an artist going by FlexasaurusRex, it’s an archive of Day 1 programming, and then different channels (YouTube playlists) to shuffle through the different shows, including 120 Minutes.

How do we know what we designed is working as intended? We measure. Vitaly Friedman shares something called the TARS framework to measure the impact of features.

We need UX metrics to understand and improve user experience. What I love most about TARS is that it’s a neat way to connect customers’ usage and customers’ experience with relevant product metrics.

Here’s TARS in a nutshell:

• Target Audience (%): Measures the percentage of all product users who have the specific problem that a feature aims to solve.
• Adoption (%): Tracks the percentage of the target audience that successfully and meaningfully engages with the feature.
• Retention (%): Assesses how many users who adopted the feature continue to use it repeatedly over time.
• Satisfaction Score (CES): Gauges the level of satisfaction, specifically how easy it was for retained users to solve their problem after using the feature.

Friedman has more details in the article, including how to use TARS to measure how well a feature is performing for your intended target audience.