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.

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.