My wife is a huge football fan—Kansas City Chiefs, if you must know—and I’m one too (go Niners!), but too a lesser degree. I just really hope the Seattle Seahawks don’t break out the super-ugly green highlighter-colored Action Green uniforms when they face off against the Patriots in Super Bowl LX.

Anyway, sports teams are some of the best examples of legacy brands, steeped in history, and with legions of literal fans. It interesting how legacy brands evolve—especially ones where the audience feels genuine ownership. And sports teams are the extreme case. Mess with a logo that fans have tattooed on their bodies, and you’ll hear about it.

Natalie Fear talked to several designers about what makes NFL logo updates succeed or fail. Paul Woods, president of AIGA Los Angeles:

The updates that work tend to be quieter. The Chargers’ continued refinement of their iconic bolt or the Vikings’ measured refinements show that evolution can be about better execution, not louder ideas. Improved proportions, stronger typography, and systems that scale across digital, broadcast, and physical environments matter more than novelty.

Better execution, not louder ideas. That’s the whole thing, really. The temptation with any redesign is to justify the effort by making the change visible. But visible change and meaningful improvement aren’t the same thing.

Woods again:

Appeasing fans does not mean standing still. It means understanding what they actually care about.

This applies well beyond sports branding. Any time you’re working on a product or brand that people have history with, the job isn’t to make your mark—it’s to make the thing better without breaking what already works.

Michael Vamosy, founder of DEFIANT LA, puts a finer point on the challenge:

Fans are much more forgiving of poor design choices from the past than they are of design improvements built for the future.

That asymmetry is worth sitting with. Nostalgia protects old mistakes. New work gets no such grace period.

I write everything in Markdown now. These link posts start in Obsidian, which stores them as .md files. When I rebuilt my blog with Astro, I moved from a database to plain Markdown files. It felt like going backwards—and also exactly right.

Anil Dash has written a lovely history of how John Gruber’s simple text format quietly became the infrastructure of the modern internet:

The trillion-dollar AI industry’s system for controlling their most advanced platforms is a plain text format one guy made up for his blog and then bounced off of a 17-year-old kid [Aaron Swartz] before sharing it with the world for free.

The format was released in 2004, the same year blogs went mainstream. Twenty years later, it’s everywhere—Google Docs, GitHub, Slack, Apple Notes, and every AI prompt you’ve ever written.

Dash’s larger point is about how the internet actually gets built:

Smart people think of good things that are crazy enough that they just might work, and then they give them away, over and over, until they slowly take over the world and make things better for everyone.

Worth a full read.

I’ve been licensing fonts for my entire career. Hundreds of them over the years, whether it was Adobe’s Font Folio, or fonts from Emigre, House Industries, T-26, or Grilli Type. I always assumed that when I paid for a font license, I was paying for something with clear intellectual property protection—like software or music.

Turns out that assumption might be wrong.

Matthew Butterick, a copyright litigator who also happens to be a type designer and author of the great reference, Practical Typography, lays out why digital fonts probably aren’t protected by U.S. copyright law:

Fonts have traditionally been excluded from U.S. copyright protection. This principle was judicially affirmed in the 1978 case Eltra Corp. v. Ringer (“typeface has never been considered entitled to copyright”).

The type industry has operated for decades on a workaround: register fonts as software programs rather than as typefaces. A 1998 case, Adobe v. Southern Software, seemed to validate this approach. But a recent ruling in Laatz v. Zazzle pokes holes in that reasoning. Butterick on the implications:

To those in the type industry who have staked a lot on the Adobe case, that last sentence might be a doozy. The Laatz court’s perspective debunks decades of wishful thinking about the breadth of the Adobe opinion. Under the Laatz view, unless you “created the software that produced the font programs”, you don’t fall within the scope of the Adobe ruling.

That distinction is wild. If you designed a typeface using FontLab or Glyphs—as most type designers do nowadays—you might not have the copyright protection you thought you had, because you didn’t write the software that generated the final font file.

Given all this legal uncertainty, how does Butterick run his own type foundry? He’s refreshingly pragmatic:

My business necessarily runs on something more akin to the honor system. I try to make nice fonts, price my licenses fairly, and thereby make internet strangers enthusiastic about sending me money rather than going to pirate websites. Enough of them do. My business continues.

I don’t have a strong opinion on the legal questions here—I’m not a lawyer or a type designer. But as someone who’s spent a lot of money on fonts over the years, I find it fascinating that the whole edifice might be built on shakier ground than any of us realized. And yes, I absolutely want to support the type designers who sweat the details by giving them cash money.

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.

Brand guidelines have always been a compromise. You document the rules—colors, typography, spacing, logo usage—and hope people follow them. They don’t, or they follow the letter while missing the spirit. Every designer who’s inherited a brand system knows the drift: assets that are technically on-brand but feel wrong, or interpretations that stretch “flexibility” past recognition.

Luke Wroblewski is pointing at something different:

Design projects used to end when “final” assets were sent over to a client. If more assets were needed, the client would work with the same designer again or use brand guidelines to guide the work of others. But with today’s AI software development tools, there’s a third option: custom tools that create assets on demand, with brand guidelines encoded directly in.

The key word is encoded. Not documented. Not explained in a PDF that someone skims once. Built into software that enforces the rules automatically.

Wroblewski again:

So instead of handing over static assets and static guidelines, designers can deliver custom software. Tools that let clients create their own on-brand assets whenever they need them.

That is a super interesting way of looking at it.

He built a proof of concept—the LukeW Character Maker—where an LLM rewrites user requests to align with brand style before the image model generates anything. The guidelines aren’t a reference document; they’re guardrails in the code.

This isn’t purely theoretical. When Pentagram designed Performance.gov in 2024, they delivered a library of 1,500 AI-generated icons that any federal agency could use going forward. Paula Scher defended the approach by calling it “self-sustaining”—the deliverable wasn’t a fixed set of illustrations but a system that could produce more:

The problem that’s plagued government publishing is the inability to put together a program because of the interference of different people with different ideas. This solved that.

I think this is an interesting glimpse into the future. Brand guidelines might have software with them. I can even see a day where AI can generate new design system components based on guidelines.

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.

When I managed over 40 creatives at a digital agency, the hardest part wasn’t the work itself—it was resource allocation. Who’s got bandwidth? Who’s blocked waiting on feedback? Who’s deep in something and shouldn’t be interrupted? You learn to think of your team not as individuals you assign tasks to, but as capacity you orchestrate.

I was reminded of that when I read about Boris Cherny’s approach to Claude Code. Cherny is a Staff Engineer at Anthropic who helped build Claude Code. Karo Zieminski, writing in her Product with Attitude Substack, breaks down how Cherny actually uses his own tool:

He keeps ~10–15 concurrent Claude Code sessions alive: 5 in terminal (tabbed, numbered, with OS notifications). 5–10 in the browser. Plus mobile sessions he starts in the morning and checks in on later. He hands off sessions between environments and sometimes teleports them back and forth.

Zieminski’s analysis is sharp:

Boris doesn’t see AI as a tool you use, but as a capacity you schedule. He’s distributing cognition like compute: allocate it, queue it, keep it hot, switch contexts only when value is ready. The bottleneck isn’t generation; it’s attention allocation.

Most people treat AI assistants like a single very smart coworker. You give it a task, wait for the answer, evaluate, iterate. Cherny treats Claude like a team—multiple parallel workers, each holding different context, each making progress while he’s focused elsewhere.

Zieminski again:

Each session is a separate worker with its own context, not a single assistant that must hold everything. The “fleet” approach is basically: don’t make one brain do all jobs; run many partial brains.

I’ve been using Claude Code for months, but mostly one session at a time. Reading this, I realize I’ve been thinking too small. The parallel session model is about working efficiently. Start a research task in one session, let it run while you code in another, check back when it’s ready.

Looks like the new skill on the block is orchestration.

I started my career in print. I remember specifying designs in fractional inches and points, and expecting the printed piece to match the comp exactly. When I moved to the web in the late ’90s, I brought that same expectation with me because that’s how we worked back then. Our Photoshop files were precise. But if we’re being honest—that the web is an interactive, quickly malleable medium—that expectation is misplaced. I’ve long since changed my mind, of course.

Web developer Amit Sheen, writing for Smashing Magazine, articulates the problem with “pixel perfect” better than I’ve seen anyone do it:

When a designer asks for a “pixel-perfect” implementation, what are they actually asking for? Is it the colors, the spacing, the typography, the borders, the alignment, the shadows, the interactions? Take a moment to think about it. If your answer is “everything”, then you’ve just identified the core issue… When we say “make it pixel perfect,” we aren’t giving a directive; we’re expressing a feeling.

According to Sheen, “pixel perfect” sounds like a specification but functions as a vibe. It tells the developer nothing actionable.

He traces the problem back to print’s influence on early web design:

In the print industry, perfection was absolute. Once a design was sent to the press, every dot of ink had a fixed, unchangeable position on a physical page. When designers transitioned to the early web, they brought this “printed page” mentality with them. The goal was simple: The website must be an exact, pixel-for-pixel replica of the static mockup created in design applications like Photoshop and QuarkXPress.

Sheen doesn’t just tear down the old model. He offers replacement language. Instead of demanding “pixel perfect,” teams should ask for things like “visually consistent with the design system” or “preserves proportions and alignment logic.” These phrases describe actual requirements rather than feelings.

Sheen again, addressing designers directly:

When you hand over a design, don’t give us a fixed width, but a set of rules. Tell us what should stretch, what should stay fixed, and what should happen when the content inevitably overflows. Your “perfection” lies in the logic you define, not the pixels you draw.

I’m certain advanced designers and design teams know all of the above already. I just appreciated Sheen’s historical take. A Figma file is a hypothesis, a picture of what to build. The browser is the truth.

I became an associate creative director (ACD) in 2005, ten years after I started working professionally. I was hired by the digital agency Organic into that role. I remembered struggling mightily with trusting my team to do the work. In my previous job as an art director, I hated it when my ACD or CD would go into my files after I’d gone home and just redo stuff. I didn’t do that, but it was very difficult to fight the urge or to avoid designing my own direction. (I failed on the latter.) That’s an intrinsic problem.

Sometimes, the issue is extrinsic, especially when you’re promoted into a leadership role from being an individual contributor (IC). The transition is a struggle. You get promoted because you were great at the work, and then the organization keeps pulling you back to do the work instead of leading at the level your new role demands.

Sabina Nawaz, writing for Harvard Business Review, explains why promotions grant potential but not always permission:

Research shows many midlevel and senior leaders still spend a disproportionate amount of time on tactical work rather than enterprise leadership. In my coaching work with senior leaders, I’ve found that while promotions provide the potential to lead strategically, they don’t always grant permission to do so. To gain that, you must do the hidden (and harder) work of redefining how you think, behave, and interact within the system.

That phrase, “potential but not permission,” is the whole problem in four words. You have the title, but the org’s muscle memory keeps treating you like your old self.

Nawaz identifies a common culprit: bosses who can’t let go of their former role:

Because the SVP had personally run my client’s division for years, he struggled to let go of intervening in the VP’s work. Six months into the transition, the SVP was still reviewing every decision, overriding calls, and re-engaging in tactical discussions he no longer needed to oversee. While he explained his involvement as giving feedback and advice, he was “overhelping,” a seemingly benign act that research suggests can ultimately erode trust, autonomy, and performance.

I’ve watched this pattern derail design organizations. A new creative director gets promoted, but the VP who used to hold that role keeps jumping into design reviews, redlining layouts, second-guessing type choices. The CD never develops their own judgment because their boss never leaves the room.

Nawaz’s advice for breaking the cycle is direct:

Take a quick glance at your calendar and ask yourself if it still reflects the activities, information flow, and ownership items of your prior role. Just as you need your boss to step back to empower you, you must redesign where you spend your time and which decisions to let your team fully own.

Your calendar doesn’t lie. If it’s packed with the same meetings you attended before your promotion, you haven’t actually made the transition. You’ve just added a new title to your old job.

Really cool interactive playground by designer Braz De Pina to create and remix futuristic interfaces—you know, that stuff you see on sci-fi shows and movies.

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.

The data from Lenny’s Newsletter’s AI productivity survey showed PMs ranking prototyping as their #2 use case for AI, ahead of designers. Here’s what that looks like in practice.

Figma is now teaching PMs to build prototypes instead of writing PRDs. Using Figma Make, product managers can go from idea to interactive prototype without waiting on design. Emma Webster writing in Figma’s blog:

By turning early directions into interactive, high-fidelity prototypes, you can more easily explore multiple concepts and take ideas further. Instead of spending time writing documentation that may not capture the nuances of a product, prototypes enable you to show, rather than tell.

The piece walks through how Figma’s own PMs use Make for exploration, validation, and decision-making. One PM prototyped a feature flow and ran five user interviews—all within two days. Another used it to workshop scrolling behavior options that were “almost impossible to describe” in words.

The closing is direct about what this means for roles:

In this new landscape, the PMs who thrive will be those who embrace real-time iteration, moving fluidly across traditional role boundaries.

“Traditional role boundaries” being design’s territory.

This isn’t a threat if designers are already operating upstream—defining what to build, not just how it looks. But if your value proposition is “I make the mockups,” PMs now have tools to do that themselves.

The optimistic case for designers in an AI-driven world is that design becomes strategy—defining what to build, not just how it looks. But are designers actually making that shift?

Noam Segal and Lenny Rachitsky, writing for Lenny’s Newsletter, share results from a survey of 1,750 tech workers. The headline is that AI is “overdelivering”—55% say it exceeded expectations, and most report saving at least half a day per week. But the findings by role tell a different story for designers:

Designers are seeing the fewest benefits. Only 45% report a positive ROI (compared with 78% of founders), and 31% report that AI has fallen below expectations, triple the rate among founders.

Meanwhile, founders are using AI to think—for decision support, product ideation, and strategy. They treat it as a thought partner, not a production tool. And product managers are building prototypes themselves:

Compare prototyping: PMs have it at #2 (19.8%), while designers have it at #4 (13.2%). AI is unlocking skills for PMs outside of their core work, whereas designers aren’t seeing the marginal improvement benefits from AI doing their core work.

The survey found that AI helps designers with work around design—research synthesis, copy, ideation—but visual design ranks #8 at just 3.3%. As Segal puts it:

AI is helping designers with everything around design, but pushing pixels remains stubbornly human.

This is the gap. The strategic future is available, but designers aren’t capturing it at the same rate as other roles. The question is why—and what to do about it.

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.

Almost a year ago, I linked to Lee Robinson’s essay “Personal Software” and later explored why we need a HyperCard for the AI era. The thesis: people would stop searching the App Store and start building what they need. Disposable tools for personal problems.

That future is arriving. Dominic-Madori Davis, writing for TechCrunch, documents the trend:

It is a new era of app creation that is sometimes called micro apps, personal apps, or fleeting apps because they are intended to be used only by the creator (or the creator plus a select few other people) and only for as long as the creator wants to keep the app. They are not intended for wide distribution or sale.

What I find compelling here is the word “fleeting.” We’ve been conditioned to think of software as permanent infrastructure—something you buy, maintain, and eventually migrate away from. But these micro apps are disposable by design. One founder built a gaming app for his family to play over the holidays, then shut it down when vacation ended. That’s not a failed product. That’s software that did exactly what it needed to do.

Howard University professor Legand L. Burge III frames it well:

It’s similar to how trends on social media appear and then fade away. But now, [it’s] software itself.

The examples in the piece range from practical (an allergy tracker, a parking ticket auto-payer) to whimsical (a “vice tracker” for monitoring weekend hookah consumption). But the one that stuck with me was the software engineer who built his friend a heart palpitation logger so she could show her doctor her symptoms. That’s software as a favor. Software as care.

Christina Melas-Kyriazi from Bain Capital Ventures offers what I think is the most useful framing:

It’s really going to fill the gap between the spreadsheet and a full-fledged product.

This is exactly right. For years, spreadsheets have been the place where non-developers build their own tools—janky, functional, held together with VLOOKUP formulas and conditional formatting. Micro apps are the evolution of that impulse, but with real interfaces and actual logic.

The quality concerns are real—bugs, security flaws, apps that only their creator can debug. But for personal tools that handle personal problems, “good enough for one” is genuinely good enough.