I’ve seen this at every company past a certain size: you spot a disjointed UX problem across the product, you know what needs to happen, and then you spend three months in alignment meetings trying to get six teams to agree on a button style.

A recent piece from Laura Klein at Nielsen Norman Group examines why most product teams aren’t actually empowered, despite what the org chart claims. Klein on fragmentation:

When you have dozens of empowered teams, each optimizing its own metrics and building its own features, you get a product that feels like it was designed by dozens of different companies. One team’s area uses a modal dialog for confirmations. Another team uses an inline message. A third team navigates to a new page. The buttons say Submit in one place, Save in another, and Continue in a third. The tone of the microcopy varies wildly from formal to casual.

Users don’t see teams. They don’t see component boundaries. They just see a confusing, inconsistent product that seems to have been designed by people who never talked to each other, because, in a sense, it was.

Each team was empowered to make the best decisions for their area, and it did! But nobody was empowered to maintain coherence across the whole experience.

That last line is the whole problem. “Coherence,” as Klein calls it, is a design leadership responsibility, and it gets harder as AI lets individual teams ship faster without coordinating with each other. If every squad can generate production UI in hours instead of weeks, the fragmentation described here accelerates. Design systems become the only thing standing between your product and a Frankenstein experience.

The article is also sharp on what happens to PMs inside this dysfunction:

Picture a PM who spends 70% of her time in meetings coordinating with other teams, getting buy-in for a small change, negotiating priorities, trying to align roadmaps, escalating conflicts, chasing down dependencies, and attending working groups created to solve coordination problems. She spends a tiny fraction of her time with users. The rest is spent writing documents that explain her team’s work to other teams, updating roadmaps, reporting status, and attending planning meetings. She was hired to be a strategic product thinker, but she’s become a project manager, focused entirely on logistics and coordination.

I’ve watched this happen to PMs I’ve worked with. The coordination tax eats the strategic work. Marty Cagan calls this “product management theater”—a surplus of PMs who function as overpaid project managers. If AI compresses the engineering work but the coordination overhead stays the same, that ratio gets even more lopsided.

The fix is smaller teams with real ownership and strong design systems that enforce coherence without requiring 14 alignment meetings. But that requires organizational courage most companies don’t have.

My essay yesterday was about the mechanics of how product design is changing—designing in code, orchestrating AI agents, collapsing the Figma-to-production handoff. That piece got into specifics. This piece by Pavel Bukengolts, writing for UX Magazine, is about the mindset:

AI is changing the how — the tools, the workflows, the speed. But the why of UX? That’s timeless.

Bukengolts is right. UX as a discipline isn’t going anywhere. But I worry that articles like this—well-intentioned and directionally correct—give designers permission to keep doing exactly what they’re doing now. “Sharpen your critical thinking” and “be the conscience in the room” is good advice. It’s also the kind of advice that lets you nod along without changing anything about your Tuesday.

The article lists the skills designers need: critical thinking, systems thinking, AI literacy, ethical awareness, strategic communication. All valid. But none of that addresses what the actual production work looks like six months from now. Bukengolts again:

In a world where AI does the work, your value is knowing why it matters and who it affects.

I agree with this in principle. The problem is the gap between “UX matters” and “your current UX role is secure.” Those are very different statements. UX will absolutely matter in an AI-powered world—someone has to shape the experience, evaluate whether it actually works for people, catch the things the model gets wrong. But the number of people doing that work, and what the job requires of them, is changing fast. I wrote in my essay that junior designers who can’t critically assess AI-generated work will find their roles shrinking fast. The skill floor is rising. Saying “stay curious and principled” isn’t wrong, but it’s not enough.

The piece closes with reassurance:

Yes, this moment is big. Yes, you’ll need to adapt. But no, you are not obsolete.

I’d feel better about that line if the article spent more time on how to adapt—not in terms of thinking skills, but in terms of the actual work. Learn to design in code. Get comfortable directing AI agents. Understand your design system well enough to make it machine-readable. Those are the specific steps that will separate designers who thrive from designers who got the mindset right but missed the shift happening underneath them.

If building is cheap and the real bottleneck is knowing what to build, interface design faces the same squeeze. Nielsen Norman Group’s annual State of UX report argues that UI is no longer a differentiator.

Kate Moran, Raluca Budiu, and Sarah Gibbons, writing for Nielsen Norman Group:

UI is still important, but it’ll gradually become less of a differentiator. Equating UX with UI today doesn’t just mislabel our work — it can lead to the mistaken conclusion that UX is becoming irrelevant, simply because the interface is becoming less central.

Design systems standardized the components. AI-mediated interactions now sit on top of the interface itself. The screen matters less when users talk to an agent instead of navigating pages. The report lays out where that leaves designers:

As AI-powered design tools improve, the power of standardization will be amplified and anyone will be able to make a decent-looking UI (at least from a distance). If you’re just slapping together components from a design system, you’re already replaceable by AI. What isn’t easy to automate? Curated taste, research-informed contextual understanding, critical thinking, and careful judgment.

The whole report is worth reading. The thread through all of it—job market, AI fatigue, UI commodification—is that surface-level work won’t survive leaner teams and stronger scrutiny. The value is in depth.

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

One of the most interesting things about design systems is how many of them are public—maybe not open source, but public so that we can all learn from them.

The earliest truly public, documented design systems showed up in the early 2010s. There isn’t a single “first,” but a few set the tone. GOV.UK published openly and became the public‑sector benchmark. Google’s Material landed in 2014 with a comprehensive spec. Salesforce’s Lightning started surfacing around 2013–2014 and matured mid‑decade. IBM’s Carbon followed soon after. Earlier frameworks like Bootstrap and Foundation (2011) acted like de facto systems for many teams, but they weren’t a company’s product design system made public.

PJ Onori says that public design systems are a “marketplace of ideas.”

Public design systems have lifted all boats in the harbor. Most design system teams do the rounds to see how other teams have tackled problems. Every system that raises bar puts healthy pressure on others to meet or exceed it. This shared ecosystem may be the most important facet of the design systems practice.

Onori also says that there may be a growing trend to shut down public design systems:

There’s a growing trend to close down public systems. Funny enough, the first thing I did when I left Pinterest was clone the Gestalt repo. I had this spidey sense it wouldn’t be around forever. Yes, their web codebase is still open source, but the docs have gone private. That one stung. Gestalt wasn’t the first design system to be public. It wasn’t the best one either. But it’s hat was in the ring–and that’s what mattered.

But that’s only one design system, right? Sadly, I’m hearing more chatting about mounting pressure to privatize their systems.

This is an incredibly shitty idea.

Why? Because that’s how we all learn from each other. That’s how something like the Component Gallery can exist as a resource for all of us.

Open design systems are the library for people wanting to get into design systems. They’re a free resource to expand their understanding. There’s no college of design systems. Bootcamps exist, but they’re bootcamps–and I’ll leave it at that. The generation who shaped design systems didn’t create universities–they built libraries. Those libraries can train the next generation once people like me age out. When the libraries go, so does the transfer of knowledge.

I’ve linked to a footer gallery, a navbar gallery, and now to round us out, here is a full-on Component Gallery. Web developer Iain Bean has been maintaining this library since 2019.

Bean writes in the about page:

The original idea for this site came from A Pattern Language2, a 1977 book focused on architecture, building and planning, which describes over 250 ‘patterns’: forms which fit specific contexts, or to put it another way, solutions to design problems. Examples include: ‘Beer hall’, ‘Positive outdoor space’ and ‘Light on two sides of every room’.

Whereas the book focuses on the physical world, my original aim with this site is was focus on those patterns that appear on the web; these often borrow the word ‘pattern’ (see Patterns on the GOV.UK design system), but are more commonly called components, hence ‘the component gallery’ — unlike a component library, most of these components aren’t ready to use off-the-shelf, but they’ll hopefully inspire you to design your own solution to the problem you’re working to solve.

So if you ever need a reference for how different design systems handle certain components (e.g., combobox, segmented control, or toast ), this is your site.

I love this piece in The Pudding by Michelle Pera-McGhee, where she breaks down what motifs are and how they’re used in musicals. Using audio samples from Wicked, Les Miserables, and Hamilton, it’s a fun, interactive—sound on!—essay.

Music is always telling a story, but here that is quite literal. This is especially true in musicals like Les Misérables or Hamilton where the entire story is told through song, with little to no dialogue. These musicals rely on motifs to create structure and meaning, to help tell the story.

…

So a motif doesn’t just exist, it represents something. This creates a musical storytelling shortcut: when the audience hears a motif, that something is evoked. The audience can feel this information even if they can’t consciously perceive how it’s being delivered.

If you think about it, motifs are the design systems of musicals.

Pera-McGhee lists out the different use cases and techniques for motifs:

• Representing a character with a recurring musical idea, often updated as the character evolves.
• Representing an abstract idea (love, struggle, hope) via leitmotifs that recur across scenes.
• Creating emotional layers by repeating the same motif in contrasting contexts (joy vs. grief).
• Weaving multiple motifs together at key structural moments (end-of-act ensembles like “One Day More” and “Non-Stop”).

I’m also reminded of this excellent video about the motifs in Hamilton.

Designer and front-end dev Ondřej Konečný has a lovely presentation of his book collection.

My favorites that I’ve read include:

• Creative Selection by Ken Kocienda (my review)
• Grid Systems in Graphic Design by Josef Müller-Brockmann
• Steve Jobs by Walter Isaacson
• Don’t Make Me Think by Steve Krug
• Responsive Web Design by Ethan Marcotte

(h/t Jeffrey Zeldman)

Ryan Feigenbaum created a fun Teenage Engineering-inspired color palette generator he calls “ColorPalette Pro.” Back in 2023, he was experimenting with programatic palette generation. But he didn’t like his work, calling the resulting palettes “gross, with luminosity all over the place, clashing colors, and garish combinations.”

So Feigenbaum went back to the drawing board:

That set off a deep dive into color theory, reading various articles and books like Josef Albers’ Interaction of Color (1963), understanding color space better, all of which coincided with an explosion of new color methods and technical support on the web.

These frustrations and browser improvements culminated in a realization and an app.

Here he is, demoing his app:

It’s interesting to me that Figma had to have a separate conference and set of announcements focused on design systems. In some sense it’s an indicator of how big and mature this part of design has become.

A few highlights from my point-of-view…

Slots seems to solve one of those small UX paper cuts—those niggly inconveniences that we just lived with. But this is a big deal. You’ll be able to add layers within component instances without breaking the connection to your design system. No more pre-building hidden list items or forcing designers to detach components. Pretty advanced stuff.

On the code front, they’re making Code Connect actually approachable with a new UI that connects directly to GitHub and uses AI to map components. The Figma MCP server is out of beta and now supports design system guidelines—meaning your agentic coding tools can actually respect your design standards. Can’t wait to try these.

For teams like mine that are using Make, you’ll be able to pull in design systems through two routes: Make kits (generate React and CSS from Figma libraries) or npm package imports (bring in your existing code components). This is the part where AI-assisted design doesn’t have to mean throwing pixelcraft out the window.

Design systems have always been about maintaining quality at scale. These updates are very welcomed.

As a follow-up to our previous item on Claude Code, here’s an article by Nick Babich who gives us three ways product designers can use Claude to code.

Remember that Anthropic’s Claude has been the leading LLM for coding for a while now.

Noah Davis writing in Web Designer Depot, says aloud what I’d thought—but never wrote down—before AI, templates started to kill creativity in web design.

If you’re wondering why the web feels dead, lifeless, or like you’re stuck in a scrolling Groundhog Day of “hero image, tagline, three icons, CTA,” it’s not because AI hallucinated its way into the design department.

It’s because we templatified creativity into submission!

We used to design websites like we were crafting digital homes—custom woodwork, strange hallways, surprise color choices, even weird sound effects if you dared. Each one had quirks. A personality. A soul.

When I was coming up as a designer in the late 1990s and early 2000s, one of my favorite projects was designing Pixar.com. The animation studio’s soul—and by extension the soul I’d imbue into the website—was story. The way this manifest was a linear approach to the site, similar to a slideshow, to tell the story of each of their films.

And as the web design industry grew, and everyone needed and wanted a website, from Fortune 500s to the local barber shop, access to well-designed websites was made possible via templates.

Let’s be real: clients aren’t asking for design anymore. They’re asking for “a site like this.” You know the one. It looks clean. It has animations. It scrolls smoothly. It’s “modern.” Which, in 2025, is just a euphemism for “I want what everyone else has so I don’t have to think.”

Templates didn’t just streamline web development. They rewired what people expect a website to be.

Why hire a designer when you can drop your brand colors into a no-code template, plug in some Lottie files, and call it a day? The end result isn’t bad. It’s worse than bad. It’s forgettable.

Davis ends his rant with a call to action: “If you want design to live, stop feeding the template machine. Build weird stuff. Ugly stuff. Confusing stuff. Human stuff.”

I will admit that I’d not heard of this website until I came across this article. Playing around with Perfectly Imperfect myself, I find it to be the strange web Brutalist manifestation of MySpace for the Gen Z generation.

Sudi Jama, writing for It’s Nice That:

Talking about the design for Perfectly Imperfect’s social site pi.fyi, on the other hand, Tyler says: “The design calls back to an era where algorithms didn’t dominate your day-to-day experience on the internet.” Tyler rejects the homogenisation of web design and decided to swerve Perfectly Imperfect into a lane of its own, inspired by the early internet aesthetics of “solid but saturated colours, lack of texture, MS Paint-style airbrushing, and a singular broadcast-style aesthetic”, Brent David Freaney tells us. Brent’s studio Special Offer collaborated with Tyler to bring the best parts of early internet’s visuality, whilst still creating something that belongs in 2025. Some fun facts: Pi.fyi’s colour system was modelled from 1990s McDonald’s brand and style guidelines, and the spray paint logo was inspired by an old Teenage Fanclub band t-shirt Tyler got on eBay.

The platform thrives in the chaos, all born from its visible human touch. “A lot of the core pages that users spend time on (the home page, profiles, etc) are designed to look more like a magazine than a social site.” The visuals are deliberately flat, featuring few animations, in order to let the design cut through. The mixture of a home page presented as acting front page, with editorial content, user posts, profiles adorned in large image paired with bold bordered text, and written content pouring from the right side of the screen. Tyler says: “It’s this approach that’s led us to calling Perfectly Imperfect a ‘social magazine’.” Tyler is inspired by the likes of Index Mag, MySpace, and i-D, among others – all boundary-pushing platforms which hold a cultural authority.

Brad Frost, of atomic design fame, wrote a history of themeable UIs as part of a deep dive into design tokens. He writes, “Design tokens may be the latest incarnation, but software creators have been creating themeable user interfaces for quite a long time!”

About Mario and Luigi from Super Mario Bros.:

It’s wild that two of the most iconic characters in the history of pop culture — red-clad Mario and green-clad Luigi — are themeable UI elements born from pragmatic ingenuity to overcome technological challenges. Freaking amazing.

Luke Wroblewski, writing in his blog:

Across several of our companies, software development teams are now “out ahead” of design. To be more specific, collaborating with AI agents (like Augment Code) allows software developers to move from concept to working code 10x faster. This means new features become code at a fast and furious pace.

When software is coded this way, however, it (currently at least) lacks UX refinement and thoughtful integration into the structure and purpose of a product. This is the work that designers used to do upfront but now need to “clean up” afterward. It’s like the development process got flipped around. Designers used to draw up features with mockups and prototypes, then engineers would have to clean them up to ship them. Now engineers can code features so fast that designers are ones going back and cleaning them up.

This is what I’ve been secretly afraid of. That we would go back to the times when designers were called in to do cleanup. Wroblewski says:

Instead of waiting for months, you can start playing with working features and ideas within hours. This allows everyone, whether designer or engineer, an opportunity to learn what works and what doesn’t. At its core rapid iteration improves software and the build, use/test, learn, repeat loop just flipped, it didn’t go away.

Yeah, or the feature will get shipped this way and be stuck this way because startups move fast and move on.

My take is that as designers, we need to meet the moment and figure out how to build design systems and best practices into the agentic workflows our developer counterparts are using.

Read past some of the hyperbole in this piece by Andy Budd. I do think the message is sound.

If you’re working at a fast-growth tech startup, you’re probably already feeling the pressure. Execs want more output with fewer people. Product and engineering are experimenting with AI tooling. And you’re being asked to move faster than ever — with less clarity on what the team should even own.

I will admit that I personally feel this pressure too. Albeit, not from my employer but from the chatter in our industry. I’m observing the younger companies experiment with the process, collapsing roles, and expanding responsilities.

As AI eats into the production layer, the traditional boundaries between design and engineering are starting to dissolve. Many of the tasks once owned by design will soon be handled by others — or by machines.

Time will tell when this becomes widespread. I think designers will be asked to ship more code. And PMs and engineers may ship small design tweaks.

The reality is, we’ll likely need fewer designers overall. But the ones we do need will be more specialised, more senior, and more strategically valuable than ever before.

You’ll want AI-literate, full-stack designers — people who are comfortable working across the entire product surface, from UX to code, and from interface to infrastructure. Designers who can navigate ambiguity, embrace new tooling, and confidently operate in the blurred space between design and engineering.

I don’t know if I agree with the fewer number of designers. At least not in the near-term. The more AI is embedded into app experiences, the trend—I predict—will go in the opposite direction. The term “AI as material“ has been floating around for a few months, but I think its meaning will morph. AI will be the new UI, and thus we need designers to help define those experiences.

Crazy. Methinks there’s a non-zero chance that someone at v0 read my article and decided to give us designers the control we want.

Can’t wait to try it out.

I’ve been very interested in finding tools to close the design-to-code gap. Martina Sartor writing in UX Planet articulates why that is so important:

After fifteen years hopping between design systems, dev stand-ups, and last-minute launch scrambles, I’m convinced design-to-dev QA is still one of the most underestimated bottlenecks in digital product work. We pour weeks into meticulous Figma files, yet the last mile between mock-up and production code keeps tripping us up.

This is an honest autopsy of why QA hurts and how teams can start healing it — today — without buying more software (though new approaches are brewing).

When you’re building a SaaS app, I believe it’s important to understand the building blocks, or objects, in your app. What are they? How do they relate to each other? Should those relationships be peer-to-peer or parent-child? Early in my tenure at BuildOps, I mentioned this way of thinking to one of my designers and they pointed me to Object-Oriented UX (OOUX), a methodology pioneered by Sophia Prater.

Mateusz Litarowicz writes:

Object-Oriented UX is a way of thinking about design, introduced and popularized by Sophia Prater. It assumes that instead of starting with specific screens or user flows, we begin by identifying the objects that should exist in the system, their attributes, the relationships between them, and the actions users can take on those objects. Only after this stage do we move on to designing user flows and wireframes.

To be honest, I’d long thought this way, ever since my days at Razorfish when our UX director Marisa Gallagher talked about how every website is built around a core unit, or object. At the time, she used Netflix as an example—it’s centered around the movie. CRMs, CMSes, LMSes, etc. are all object-based.

Anyway, I think Litarowicz writes a great primer for OOUX. The other—and frankly more important, IMHO—advantage to thinking this way, especially for a web app, is because your developers think this way too.

Related to my earlier post today about Arc’s novelty tax, here’s an essay by DOC, a tribute to consistency.

Leveraging known, established UX patterns and sticking to them prevent users from having to learn net-new interactions and build net-new mental models every time they engage with a new product.

But, as Josh Miller wrote in the aforementioned post, “New interfaces start from familiar ones.” DOC’s essay uses jazz as a metaphor:

Consistency is about making room for differentiation. Think about a jazz session: the band starts from a known scale, rhythm. One musician breaks through, improvising on top of that pattern for a few minutes before joining the band again. The band, the audience, everyone knows what is happening, when it starts and when it ends, because the foundation of it all is a consistent melody.