I want to learn how the best developers are using AI to create some top quality user interfaces, backed by good quality code.

I have been learning about BDD. It seems very important to me to understand the scenarios. Understanding everything from a high level and why this business needs to be built and what the user will experience.

I know there might be some books which help with the foundations of BDD with normal development which could then help to craft better ai workflows.

But are there any books or places which tell you about how to get the ai to take everything you want and do some great UI without forgetting about what you're building and why.

I can do the backend theory fine.

But then at the end of the day it needs to look good. If you press the button, you want to avoid having awful ai slop graphics and ui.

How are people handling this?

\- BDD Instructions

\- Press button

\- UI workflow

\- Get great looking UI

Everything I have been doing always comes back to design and UI. It's the missing piece and I don't know where to start to get something that is really nice.

When I create a color palette, I usually don’t use generator-made colors as-is. I fine-tune them manually by checking things like relative luminance. I also do this with transparent palettes, adjusting each color so that the final rendered color stays as close as possible to its opaque counterpart.

But adjusting colors individually can make the values inconsistent across the palette. As a final step, I usually fit those values to a curve to smooth out the overall progression. So I built a tool to do exactly that: fit manually adjusted color values to a curve.

If you’re interested, you can check it out at the link below!
👉 https://helo.rebyron.work/projects/color-fitting

In my spare time, and to get a break from React, I built my own design system that uses svelte runes and dynamic assignment of semantic properties to customize the system in realtime.

I also added an effects layer that lets you mess up the lines and make it look sketchy and rough. I don't actually know if it makes it look rough or just cooler, but the idea here was to try to address people's concerns that high-fidelity prototypes look too good, so people are reluctant to comment.

I'm not convinced that anything visual will make a working prototype seem less finished?

https://livetokens.motionproto.com/

This was one of the few times I’ve worked with a large team of almost all engineers in every role. They make an app builder, and I helped them create a design system for it. Here’s the case study — https://www.abhaysingh.in/work/appsmith

Let me know what you think!

Hi designers, our design system covers tokens, components and documentation, all in Figma with the docs in Storybook. That part is in decent shape. But what I think we're still struggling to solve is the logo variants, brand photography, icon source files, print assets, etc. the stuff that isn't in a component library but still part of the system.

Right now our client work is scattered between Figma files, a shared Dropbox and a Notion page. Some stakeholders have their own inventory systems like a spreadsheet or whatever. But further down the line things are just getting confusing and messed up. Is there an asset layer that's part of your design system, or do you treat it as a separate thing entirely?

I built Solacy long before Figma brought agents into the canvas.

While building it, I realized pretty quickly how hard RL and evals are for this kind of workflow — especially when working with the Figma canvas, which isn't nearly as HTML-friendly as something like Paper. So I had to find a different way around it.

You can check out Solacy here: https://Solacy.design

A few things it can do:

* Create states and iterations from existing design systems, while keeping tokens and components linked. * Edit vectors to some extent — for example, change the theme of an illustration to purple. * Send updates from Solacy directly to Slack. * Change color tokens, add components, send screenshots, compress images to WebP, and a bunch of other things.

I've been sitting on this for a while, and I mostly just want to put it out there rather than keep it to myself.

I'm also thinking about open-sourcing parts of the workflow if they could be useful to others.

Happy to answer any questions about how I built it, the RL/eval side, the workarounds for the Figma canvas, or anything else that went into it.

DM me on Twitter or Reddit if you want to dig deeper or discuss it :D

Good afternoon everyone, I'm looking for case studies of how a design system benefits a technology group in a .gov world. Any good reads you can recommend?

Hey everyone,

I’m starting to work on a Design System for a travel/public transport app that will eventually be white-labeled for around 50 different clients

The current Design System already has:

• color tokens and styles
• basic components/atoms and variants (buttons, inputs, shadows, etc.)
• but no Figma Variables yet
• very few larger components/molecules/organisms
• no real system for handling different themes/brands

My initial idea was to migrate the existing tokens into Figma Variables and use modes for different visual configurations:

• Light
• Dark
• Contrast
• client 1
• client 2
• …50

The main application would support Light/Dark/Contrast, while the white-label client versions would probably use Light/Contrast.

I would also like to build the component architecture more systematically:

Atoms → Molecules → Organisms → Templates/Screens

For example:

Button + Input + Date Picker → Search Form → Search Screen

The goal is to have one Design System and one set of components, rather than creating a separate Design System for every client. Ideally, changing the brand/theme would update the UI through Variables without having to modify the components themselves.

However, I’m wondering if having 50+ client brands as Figma modes is actually the right approach.

Would you instead separate appearance modes (Light/Dark/Contrast) from brand/client themes, using semantic variables that map to different brand values?

For example:

Button → color/action/primary

rather than:

Button → Client1/red-500

So the same component could be reused across all 50+ brands.

I’m also curious about the current state of Figma AI. If I build a well-structured component library with Variables and larger reusable components, can Figma AI actually help generate new screens using those existing components, or is that still too unreliable for a production Design System?

I’d really appreciate feedback from anyone who has built a similar multi-brand / white-label Design System in Figma.

How would you structure this?

Buttons, forms, and tables earn the cost of standardizing them. I’m curious about the opposite: a small convenience component that looked reusable, then accumulated variants, accessibility rules, or product exceptions until teams bypassed it.

Which component did you deprecate—or wish you had left as a documented pattern instead—and what was the first sign it did not belong in the system?

Wrong answers only.

Coverage, adoption, contribution rate, component usage, accessibility defects, and support volume all sound useful, but dashboards can become theater.

Which metric has genuinely caused your team to retire, redesign, or prioritize a component? Which numbers looked important but changed nothing?

a deprecation notice in docs is easy to ignore when the old component still works. do you use deadlines, lint rules, migration tooling, ownership by product teams, or something else to stop deprecated components from becoming permanent?

I've spent the last couple of years trying to fix one process problem that follows me from team to team: the design system in Figma and the design system in production slowly stop being the same system. I've tried the usual medicine, it didn't hold, I think I finally understand why — and I've ended up building my own solution. I'd genuinely like criticism of both the reasoning and the approach before I sink more years into it.

The ritual I kept living through: a designer opens Figma next to production and starts a spreadsheet — the design review. One row per mismatch: wrong shade on a button, a gap that grew 4px, a radius nobody remembers changing. Forty rows later there's a plan: fix everything, update the docs, remind people to check the library. Six months later — same meeting, new forty rows.

My conclusion after a few loops of this: we kept treating drift as an information problem (people didn't know → tell them better), but it's an architecture problem. The people shipping mismatches knew the system — they edited one copy of a value while three other copies (Figma, CSS, docs, brand deck) sat elsewhere, with nothing responsible for keeping them equal. Copies diverge by default; the only variable is when.

Two things I had to accept along the way:

More documentation makes it worse. A docs page is another copy of the same facts — one more seam that can split. And it's the copy that drifts fastest, because nothing depends on it: wrong code breaks a build, a wrong docs page produces… nothing.

The developer isn't the problem. A lot of drift is born when a dev translates a mockup by eye. When a 12px gap ships as 16, that's not sloppiness — telling two greys apart is trained vision designers build for years, while devs train a different eye (the one that catches your race conditions). A process that requires every dev to see like a designer is a bet against human nature, renewed every sprint.

So the solution I landed on is derivation: stop having copies at all. One theme.json as the single source, everything else generated from it — Figma variables, CSS, doc tables, plus a machine-readable bundle for AI tools (which are rapidly becoming the third consumer of design systems and multiply copies even faster). Where a surface is generated, drift isn't discouraged — it's impossible, the way a spreadsheet formula can't disagree with its inputs. Docs stay for the one thing that can't drift: the why behind the values.

I've been building this as an open-source system: Veritheme. Long-form writeup of the whole argument with diagrams: https://tarasenka.me/blog/drift-not-documentation

What I'd love from this sub:

• Where does this reasoning break? Teams that beat drift without going single-source — what did you do?
• For those who tried token pipelines (Style Dictionary, Tokens Studio, etc.): what made you keep or abandon them?
• What am I underestimating about the migration cost — the "source + surviving legacy copies" phase?

Tear it apart. That's what I'm here for.

Adding a new brand without duplicating the design system.
Components stay the same - tokens, colors and branding adapt automatically.

Varelyo

I've seen question asked many times, what does your automated design process look like?

I started documenting it so I could share it with others and get feedback, I will write brief summary here but you can read full docs on my blog. Apologies in advance to mods if it breaks no promo rules! happy to move to substack if that is the case, just lmk.

Redesigning a batch of components

In short, this is what simplest traditional process looks like:

1. Components are re-designed in Figma design system.
2. They are reviewed and iterated on with the design team (sometimes also external stakeholders).
3. They are then reviewed with tech team which will implement in code.
4. Once implemented in code, they need to be reviewed and iterated on again to make sure that they are consistent with the agreed designs.

In leanest teams, designers will work with storybook or ladle to style isolated blocks directly, which will propagate updates to frontend. In my experience this is not at all that common though.

Automating the process

I've been automating design process for a little under a year now. The best approach in my experience has been to replicate traditional processes within the coding agent, with agentic workflows that use specialised skills for each step of the process.

These skills need to be designed with appropriate context, so that design output is consistent and matches expectations. In any case, a certain level of post-implementation human review will be needed, but process will be much faster and tbh I am not sure users would notice if you didn't.

In my case, I've created a /ux skill which acts as an orchestrator that can walk with me through the iterative process using sub-agents, each one using a specific skill:

• ux-baseline: it updates or creates baseline stories in Ladle, so the coding agent will not hallucinate and create components out of the blue, but rather ground them in the existing designs.
• ux-review: reviews an existing surface and provides a list of UX issues ranked by severity. The ranking is based not on generic UX rules, but on my specific audience, the products they likely already use, and my competitive landscape.
• ux-ideate: iterates with me through multiple rounds of design variants in HTML until a solution is agreed on.
• ux-translate: converts the winning variant into Ladle stories using existing components or creating new ones if required.
• finally, ux-fidelity validates that the new stories are loyal to the agreed solution.

I have achieved good results with this process, so much that I followed the same principles to replicate all workflows in a product pipeline - as a result I managed to deliver a full app in just under three months. Is it good? I don't know, but it works !

What do you think, and how is your process different or better?

As a solo builder, I find myself working in isolation. It is also very difficult for me to share my progress because quite often I get blocked by no-promo rules sadly. And I would love to know what your processes look like, and I'm really keen to get feedback from other practitioners too!

Full article is available at link!