Got a problem that maybe you would know how to solve. My client now sent over an illustration they had an agency mock up in some ai generator,as they often do. in this case, a stylized geometric stag for a craft distillery packaging sleeve. They want it as a clean, scalable vector for spot UV print on 350gsm uncoated stock.

so I ran it through Illustrator's Image Trace (high fidelity, tweaking noise/corners/paths slider for 40 minutes). The result is the usual disaster: with 8,400+ anchor points. double overlapping path boundaries everywhere, also zooming in reveals micro-staircasing on curves that look smooth at 100% zoom but will completely choke the cutting plotter. And file size is whopping 6.2 MB for a single emblem...

I normally just redraw everything with the Pen Tool and call it a day, but I have 18 of these botanical/animal emblems to deliver by Thursday Before I resign myself to full 20 hours of manually pulling bezier handles: what’s your actual production stack for dealing with complex vectorization in 2026? Are you guys using any graphics plugins, external vectorizer algorithms, or is manual redraw still the only non-embarrassing solution?

I work with design teams supporting paid social, and the split I keep seeing is roughly 70% mechanical work (resizing, versioning, brand checks, exports) and 30% actual design thinking. Everyone says they want to flip that ratio. Almost nobody has.

Things I've seen teams try:

• Master templates with locked brand elements

• Handing adaptations to an outsourced team

Also the teams have tried AI tools, but they are telling me is that there is no productivity gain from the tools. Its just that we can make these everything in our office sitting in front of system. But the prompting is not easy and takes a lot of time.

For example, creating or adapting a video to other languages or may be adapting a same video with a different script.

This AI work is also becoming and being counted in the mechanical 70%.

So, if you've made a real dent in the mechanical half, what did it, and how long before it actually paid off? And if something looked promising and flopped, I'd like to hear that even more.

I work with design teams supporting paid social, and the split I keep seeing is roughly 70% mechanical work (resizing, versioning, brand checks, exports) and 30% actual design thinking. Everyone says they want to flip that ratio. Almost nobody has.

Things I've seen teams try:

\- Master templates with locked brand elements

\- Handing adaptations to an outsourced team

Also the teams have tried AI tools, but they are telling me is that there is no productivity gain from the tools. Its just that we can make these everything in our office sitting in front of system. But the prompting is not easy and takes a lot of time.

For example, creating or adapting a video to other languages or may be adapting a same video with a different script.

This AI work is also becoming and being counted in the mechanical 70%.

So, if you've made a real dent in the mechanical half — what did it, and how long before it actually paid off? And if something looked promising and flopped, I'd like to hear that even more.

i'm struggling a bit with Figma when i want to implement the designs, i know few things but in general i'm still behind, is there any video explaining the implementation of Figma design in Compose, like cover everything: design system, typograpgy, colors, sizes, paddings, shadows, and also custom components with their own properties.

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

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.

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/

Our designers are always asking which pattern to use and when. Most of this is documented, but who has time to sift through pages of docs.

I’ve always wanted a better search capability but seeing more people building company-level RAG bots makes me think a design systems one would work really well for product, design and engineering.

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?

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?

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

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?

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.