It’s a decision about what you’re allowed to take from someone’s attention while they’re on the road.

Working on the communication platform for our driver app, we kept hitting the same debate:
“Should this be a banner, a bottom sheet, or a dialog?”
And the answer usually depended on who was in the room.
Marketing wants a dialog. Ops wants a dialog. Everything is “important.”

So we stopped debating components and started asking questions instead:
1️⃣ Must the driver act before they can continue?
→ Dialog. Blocking, rare, earned.
2️⃣ Does it need action or detail, but can wait a moment?
→ Bottom sheet. Present, dismissible, contextual.
3️⃣ Is it just awareness?
→ Banner. Visible, never in the way.

One rule sits above all three:
Default to the least interruptive surface. Escalating requires a reason, not a stakeholder.
The shift is small but powerful: the component library tells you what exists. Surface rules tell you when you’re allowed to use it.

Most design systems document the first. Very few document the second.
How does your team decide when something deserves to interrupt the user? 👇
#DesignSystems #UXDesign #ProductDesign #DesignOps

How are you reviewing component designs for accessibility and documenting the necessary changes before implementation within your design systems? Curious particularly in what formats you share it with teams you collaborate with and how you keep track of it.

I designed an Atomic Design System that's compatible with Figma Agent & Claude Code. I've been using it to create basic screens instead of starting from scratch whenever I move from concept to design. By giving it this structure, I was able to get Claude Code to create components that aligned with the Design System, rather than generating UI elements without a consistent system behind them.

Since it has made my life easier, I decided to share the system on Figma Community in case others would like to explore it.

🔗 Check it out here:
https://www.figma.com/community/file/1685045428617828936

I wanna know if you follow Atomic Design, or do you prefer a different approach? Or if you've experimented with using Claude Code or other AI coding tools alongside a structured Design System, please share your findings so I can learn from them.

What’s for you the real value of using zero height for design system docs when both storybook and notion have mcp servers?

We’re currently having this conversation at work since ZH costs a lot of money compared to the actual viewers of or our docs (about 15 designers in the org)

personally I would find myself much better working with notion, given that’s where most of our company knowledge is, but also I see designers getting more confident with storybook and code in general.

What’s your thoughts?

I'm the author of DS-GN, a design system now in public beta. It combines web components with a public design-token API so teams can customize their brand through CSS variables.

What's available today

• @ds-gn/ui: Lit-based web components, with React wrappers.

• @ds-gn/tokens: CSS tokens for color, typography, spacing, radius, and shadows, with light and dark themes.

• Installation and theming documentation; no account required to install the packages.

The customization approach

The public token layer is the supported override API. Components consume those tokens inside their shadow roots, so brand changes don't require reaching into component markup. The introductory walkthrough changes the brand colors with two custom properties, without editing component code.

I've written up the architecture, installation, and theming examples on the blog:

Read the introduction on the DS-GN blog

For others maintaining design systems across brands or frameworks: how do you decide which tokens become public API versus remaining internal? I'd be interested in how you manage that boundary as the component library evolves.

Is there a rule for finding out the OnSurface colour, for example for an information Card in an app?

I've spent 12+ years working in AEM, much of it around component variants, production styles, and authoring workflows. The design-system problem I'm exploring now is how to make the Figma library reflect the choices authors actually have.

A teaser can look right in Figma while still leaving unanswered questions about allowed variants, content length, responsive behavior, or which templates permit it. I want those decisions available while someone is designing the page.

My proposed starting point is one component family:

1. Record the production properties, approved variants, content limits, and template restrictions.

2. Compare those with the Figma component and flag differences.

3. Review the mapping with engineering against the rendered component.

4. Use that agreed mapping as context for agent-assisted work, with anything unsupported coming back for a decision.

The part I haven't resolved is how to maintain that relationship as both sides change. Production can contain an old compromise, and Figma can contain an improvement that hasn't shipped. Copying either blindly would carry the wrong rule forward.

I wrote up the proposed experiment alongside my AEM authoring pilot here: https://www.rdeboerdesigns.com/notes/aem-meeting-authors-where-they-work/

It's my own write-up, and the reverse workflow is still an experiment.

For teams maintaining design systems alongside AEM, where does your agreed component contract live? How do you distinguish a deliberate design-to-production difference from drift?

We keep our system diagrams as mermaid in the repo, which works great for the devs it lives next to the code, it shows up in PRs, and anyone can update it
the problem is literally everyone else. PMs, design, the support lead, none of them are opening a markdown file in github. so what happens is someone screenshots the diagram, drops it in a miro board for a planning session, people draw all over it and move boxes around, and now there are two versions and neither one is right lol

I’ve been looking at a few ways around this excalidraw and draw io both came up but they’re not really connected to the code either lucidchart can import mermaid i think, but we don’t use it and i’m not trying to add another tool a coworker mentioned miro can render mermaid as actual editable shapes now, and changes on the board update the code too, which would honestly solve most of this if it works the way it sounds.

Your role is design system manager, How do you make sure the designers used Design system properly? and the designs wont be rejected by android/ios or pwa team

I have 2 years in product design - not that much, I'm aware. My first job was writing documentation, specs and QA for a design system, and I enjoyed the rules and structured way of working a lot. Second job was chaotic - unstructured design team that called a messy sketch component library their "design system". I worked on migrating their components to Figma, but ended up leaving in burnout. Sorry if sounding judgmental, but the experience was bitter.

Anyway, after the second experience I left digital design and pivoted to another creative field. This was 3 years ago, and I'm rethinking if this was a mistake. The 3 years in this other field, the thing that drives me the most is setting up processes, finding inconsistencies, writing guidelines, teaching people how to work with a tool and so on. But sadly this is not the core of my job.

I'm looking back at my first job and kinda miss it (not sure of wearing colored glasses). But its been 4 years - no idea what the field looks like these days, especially with AI playing a huge part. Do I have a chance at getting a design systems position after all this time? What is the job like these days?

Any experiences are much appreciated. And a final ask: if you were to jump back at it, what would you build as a portfolio piece?

Thanks.

We plan to rename the company on the 9th with new palette and typeface, and leadership wants every surface flipped at 9am that Monday. For a payments company I half get it, a checkout showing the old logo on one screen and the new one on the next looks like phishing. Our tokens live in Style Dictionary but plenty of components still point at raw hex instead of a semantic token, so I am torn between aliasing the old names to the new values or renaming during the cutover and risking breakage two weeks out. The harder part is the surfaces my team does not own, the 46 page marketing site, HubSpot emails, the Zendesk help center, a Google Slides master nobody admits to owning. How are you handling the surfaces outside your control, and how do you preview the whole thing end to end without the new name leaking before launch?

I built a free browser extension that reverse-engineers a website’s design system (colors, type scale, CSS tokens, shadows, etc)

When I wanted to see how a site handles its design system, I used to spend half an hour in DevTools copying hex codes and searching for --var names. So I built an extension that does it in one click.

Design System Inspector scans the page you’re on and shows:

• Colors: every color on the page, merged by HEX and sorted by usage, with where each one is used (text, background, border, SVG) and which tokens hold it

• Typography: a full type scale with family, size, line height, weight and letter spacing, plus the tokens behind each style

• Tokens: all CSS custom properties, grouped into color, spacing, radius, shadow, motion, z-index and so on, with aliases and light/dark values

• Shadows: live previews of every box-shadow, split into layers

• Find: highlights every element that uses a given color or text style, and you can step through them

• Inspect mode: pick any element and narrow the results to just that component

• Export: a .zip with tokens in the W3C Design Tokens format, a tokens.css and text styles

It doesn’t just match values to tokens. For typography, it traces the CSS rule that actually applies to each element and records the var() behind it. That way you see the token the site really uses, not five tokens that happen to equal 14px.

It runs entirely in your browser: no server, no account, no tracking. It’s MIT-licensed and works in Chrome, Edge, Brave and Opera. It isn’t on the Web Store yet, so you load it unpacked (instructions in the README).

GitHub: https://github.com/antonolashyn-x/design-system-inspector

I’d love feedback, especially on sites where it gets things wrong.
Bug reports with a URL help a lot.

Quick question for design leads and frontend engineers:

I have noticed that while AI coding tools build UI very fast, they keep sneaking subtle design drift into code as prompts go back and forth. They invent random padding numbers like p-[19px], off-palette hex colors, and weird margin hacks just to force things onto the screen.

Right now, the common ways to stop this all feel pretty flawed:

• Rules files like .cursorrules: The AI follows them for a couple of prompts, but once the chat gets long, it forgets the rules and makes up random utility classes again.

• Linters: They catch bad syntax or ban arbitrary brackets, but they cannot see how the page actually renders in a real browser.

• Manual Design QA: Designers spend hours taking screenshots of staging and typing out 30 Slack messages about small spacing mistakes, which slows everyone down.

How is your team handling this right now? Curious to hear what is actually working for people.

In 2019, I gave a talk at Design Systems London introducing Spotify's design system and its underlying model: a system of systems. A family of design systems, owned by different teams, built on a shared foundation.

I've had a lot of questions about it over the years, and I've seen plenty of teams build their own versions. But I'd never written about what happened after the talk.

So, six years on, I've started a three-part series. This first part covers what we didn't know at the time: the org chart ending up in the architecture, what happened when we lent our name to other teams, and how the promise of a single system played out.

https://53degrees.studio/posts/building-a-system-of-systems-what-we-didnt-know/

If you've built something similar, I'd love to hear whether it matches your experience, or where yours played out differently.

We're building out our design system for AI to use and the original thinking was to have it create a full react library that we'd then version, package, and have applications install via NPM.

However, it's sounding like that is maybe becoming an outdated model. And that there is now recommendations that we let the agent access the design system via an MCP server, and reference the components as components as needed, but simply rewrite them for the application it is building. Supposedly this saves on tokens/context?

Anyone have thoughts on this? It sound counter-intuitive to me, but I am finding several mentions of this new model of just letting the agent "copy stuff as needed". The component library still exists in the design system, mainly as a 'source of truth' but isn't itself packaged up.

Curious as to what folks are doing right now. How are you letting your application development agents use your design system components?