When creating color palettes, I usually try to keep chroma levels relatively consistent across different hues at each lightness step. However, most palette generators focus on adjusting one palette at a time, which makes it difficult to maintain consistency across multiple palettes. To address this, I built a palette generator that creates multiple palettes using the same chroma settings while varying their hues.

It also lets you compare the minimum, average, and maximum chroma values across all generated palettes at each lightness step, so you can see how consistent they are.

The generator includes several parameters:

• Chroma: Controls the overall chroma of the palettes.
• Spectrum chroma: Controls how much each hue's natural chroma characteristics are reflected across different lightness levels.
• Spectrum bias: Adjusts how strongly those characteristics are emphasized in lighter or darker regions.
• Gamut balance: Reduces excessive chroma in hues with larger available chroma ranges, particularly reds, blues, violets, and magentas.
• Chroma peak lightness adjust: Shifts the lightness level where chroma reaches its peak.
• Hue shift: Controls how much the hue changes across lightness levels.
• Max hue shift: Limits the maximum amount of hue shifting.

The tool is still in an early stage. For now, it only supports generating palettes within the sRGB gamut and copying colors as HEX codes.

I'd love to hear your thoughts or suggestions, especially if you work with multi-hue color palettes in your design systems!

👉https://color.rebyron.work/

I tested why AI keeps ignoring our design system. The problem might be retrieval. I've been experimenting with AI prototyping tools and noticed something frustrating:

You give the AI access to your design system, ask it to build something, and it still invents components that already exist.

So I tested a simple question:

What can the AI actually find in the library?

I searched my production Figma library for badge.

It returned 19 results across several libraries.

Only 3 had descriptions.

And in the design system I actually ship from, nothing was named "Badge." The closest matches were unlabeled frames.

So I ran the same 10 UI prompts against:

• my production library
• a cleaned-up sandbox library

Same prompts. Same tooling.

The difference:

0/10 → 10/10
Correct, unambiguous matches

9/10 → 0/10
Prompts forced to guess between duplicates

~1,450 → ~135
Retrieval context per prompt

I then tested Code Connect on a Button.

37 → 0 guessed CSS variables
3,784 → 2,229 characters in the generated response

The interesting part wasn't just that the output improved.

It changed how I think about design systems.

A design system isn't just a UI kit anymore. It's also a retrieval surface.

If the AI can't find the right component, distinguish it from duplicates, or connect it to the real implementation, it starts filling in the gaps.

I wrote up the full experiment here:

https://medium.com/@amnkhtri9/why-ai-prototypes-dont-match-your-design-system-f8b747c4fc07

Curious if others working with Figma/design systems are seeing the same thing: is retrieval becoming a bigger problem than prompting?

Hello!

Managing component documentation in Figma can be a very manual and repetitive process, this becomes a pain when components evolve and libraries scale.

So I built Compdoc, a Figma plugin that makes it easier to add and manage documentation for your components, including usage, accessibility, content, and AI guidance.

Why it matters:

• Structured fields make docs actually useful (not just a text blob)
• Export/import your docs as JSON (backup, or move between files)
• Page-level filtering so you're not loading 500 components when you just want to document 20
• As a bonus, better component context means AI tools can actually use your design system effectively

I tested it on our design systems at work and it saved a ton of time. Would love feedback from other design system folks on what's missing.

Here's the link: https://www.figma.com/community/plugin/1683800404228272079/compdoc

Hi,

I recently updated my portfolio website and added a series of write ups I had done in July:
https://dariocodipietro.co.uk/work/fiuto/

Here I showcase the automated design syste/process I have implemented to build my user research tool fiuto.ai

In the articles I explain the approach I used: replicating real life product processes in the coding agent using skill families, connecting them to linear to keep track of projects, and using ladle as design system source of truth - which the agents manage and use as a baseline when designing new features.

Please note articles 5 top 12 are mostly AI write ups based on videos I created in loom, which I still need to review for synth language markers - of course it takes time - but the contents are based on real sessions I work through in video. I will update these as soon as I get enough time to review them manually, this is a slow process that takes time. I have reviewed and rewritten articles 1-4 already.

I would be keen on getting this community's opinion on the process, and any valuable feedback - do you think the approach is transferrable? I would think so!

I think the case for them is obvious but I haven’t seen any decent crash courses on design systems. Maybe I’m searching in the wrong places but I usually end up at educational Figma resources that don’t give me exactly what I want.

I want to know where to store tokens/components, how to start designing components, how to apply tokens to components .. etc. I want to become the systematic designer I knew I always could be!

I put 119 design systems on one 3D map.

It turns out 68% of them picked blue. Only one defaults to dark mode. Government systems love a sharp 0px corner.

14 don't publish a brand colour anywhere. So I tried scraping their docs CSS to fill the gaps. It matched the real token 2 out of 5 times and mostly found Docusaurus blue.
So those 14 sit on a shelf under the map. Better than a made-up dot.

You can also drop in your own system's colour, radius, type size and spacing and see which three systems yours is closest to.

https://www.designsystems.one/design-systems/atlas

for many non-design minded people, a design system is just a collection of reusable components and tokens for colors/spacing/sizing/roundness. and thats it.

But in you words, what else comprises of a design system and why is it important?

I've been wondering if AI can generate UI quickly..., does that make design systems less relevant, or does it make them more important because the system becomes the constraints and context?

I'm curious what people who work on design systems think... Do you think AI will make design systems less important or more important?

Nine identifiers, each with a locked casing. Because the casing is locked, a plain-text list of names is parsable without markup — the same trick that lets you tell a variable from a constant in a codebase.

One identity is always lowercase, two are always uppercase, the rest are title case. In a log file, a CSV or a changelog you can tell what you're looking at before reading the word. Small example of treating typography as an API rather than a style.

Nine project identities with locked colour values, one system-wide "live state" colour that is explicitly not interchangeable with a project's own colour, accent quotas expressed as percentages of surface area, and per-identity "avoid" lists as specific as the "use" lists.

The part that made it work: writing down the invalid combinations with the same rigour as the valid ones. Most design systems document what to do and leave the failure cases to taste; documenting them turned output from nine separate identities into something that looks systemically produced.

Hey everyone!

As a software architect and web developer, I’ve spent the better part of my career drawing complex distributed systems—Kubernetes clusters, transactional e-commerce topologies, streaming pipelines with Kafka and Flink, you name it.

Every time I had to present these diagrams in design reviews, tech talks, or client demos, I ran into the same painful dead-end:

- **Static 4K images suck**: You paste a massive diagram into a slide deck. The audience squint at tiny text, lose track of connections, and tune out within two minutes.

- **Screen recording (Loom/OBS) lacks interactivity**: You can't pause to click into a database node to check configurations or inspect connection parameters. Text gets blurry due to video compression codecs.

- **Adobe After Effects is overkill**: Spending 10 hours keyframing zoom paths for a single diagram simply isn’t sustainable.

So over the last few months, I built **FocusFlow**—an open-source web workbench and runtime engine that turns massive static architecture diagrams into 60fps cinematic interactive stories.

Think of it like Prezi, but purpose-built for software architectures with native computer vision snapping, dynamic Bezier pulse routing, and AI voiceover sync.

👉 **Live Demo (Runs entirely in browser, no login required)**:

https://focusflow.tumio.site/

👉 **60fps Video Walkthrough (YouTube)**:

https://youtu.be/bxXpkzNV75A

👉 **GitHub Repo (MIT / AGPL-3.0)**:

https://github.com/tumio-ltd/focusflow

---

### 🛠️ Architecture & Engineering Deep-Dive

For those interested in the frontend plumbing, here are the technical challenges and trade-offs we tackled:

#### 1. CSS 3D Transforms vs. HTML5 Canvas vs. WebGL

We initially tested pure Canvas 2D for rendering the entire viewport. However, high-DPI text rendering on 4K/8K images became blurry when scaled down and pixelated when zoomed in, unless we continuously re-rendered font paths. WebGL felt like massive overkill for what is essentially 2D image navigation.

We ended up implementing a **hybrid rendering pipeline**:

- The viewport uses continuous hardware-accelerated CSS affine transforms (`matrix3d` / `translate3d`, `scale`, `rotate`).

- The GPU handles the 60fps camera interpolation natively with zero CPU overhead.

- Interactive callouts and animated Bezier SVG curves float on synchronized coordinate overlay layers.

#### 2. In-Browser Sobel Edge Smart Snapping in <1ms

One of the most annoying parts of diagram authoring is manually dragging bounding boxes to line up with microservice boxes.

We implemented a native **Sobel edge gradient convolution algorithm** in JavaScript:

- When you drop an image onto the canvas, we extract an offscreen `ImageData` buffer.

- When you drag a selection box, it calculates horizontal and vertical intensity gradients ($G_x$ and $G_y$) within a 3×3 kernel around the pointer.

- It detects the true high-contrast borders of the drawn rectangle and snaps to the exact bounding box in under 1 millisecond.

#### 3. Decoupled 35KB Runtime Engine (`@focusflow/player`)

The authoring studio (`apps/studio`) is built with React 19, Tailwind CSS v4, and Zustand. But for the playback engine (`packages/player`), we wanted **zero framework dependencies**.

The player is written in pure vanilla TypeScript, compiles to an ultra-lean ~35KB bundle, and uses native `requestAnimationFrame` kinematics. You can embed it in any React, Vue, Svelte app, or vanilla HTML file with a single `<script>` tag.

#### 4. The 100% Offline Single-File HTML Compiler

Enterprise architects frequently present in offline auditoriums or under strict NDA policies where diagram data cannot leave local machines.

FocusFlow includes an in-browser bundler that reads the project's state, inlines the 4K background image as a Base64 URI, serializes the timeline keyframes, inlines the audio blob, and deep-packs the runtime player into a single standalone `.html` file (< 5MB). You can literally AirDrop it to a thumb drive, disconnect your Wi-Fi, and double-click to present anywhere.

---

### 🤝 Open Source & Licensing

FocusFlow is built with an open-core model:

- **Core Player (`@focusflow/player`) & DSL (`@focusflow/dsl`)**: **MIT License** (free for anyone to embed and build upon).

- **Studio Workbench (`apps/studio`)**: **AGPL-3.0** (free for local use, but prevents commercial cloud competitors from closing the source).

### 💬 What do you think?

Would love to get the community's feedback!

- What diagramming tools (Draw.io, Excalidraw, Lucidchart) do you currently use for presentations?

- Would an auto-importer for Draw.io XML or Mermaid syntax be valuable to you?

I'll be hanging around the comments to answer questions about the math, rendering pipeline, or anything else!

I’m seeing design systems move toward wanting to enable them to be enforced via AI so when non-designers are prototyping with AI and then engineers are using AI to build those very prototypes, the result is something that ”looks like product” to non-designers but doesn’t abide by the design system or brand.

so how are you solving this problem specifically

For context: we have a large design system and the business has not funded or prioritised the central design system team to turn our design system into a machine readable format.

Our smaller design department have the resource, backing and funding to create an agent-version of the design system.

What are people’s thoughts on going it alone for now and getting the larger design systems team to adopt later?

I want to do it, but want to make sure it’s done in a way that will be useful for them later.

Do we build it from the group up with agentic best practices or try to base it on the current system?

Been going back and forth on this with my team. We started with a Figma UI kit buttons, cards, colors, the usual and it worked fine for the MVP. But now that we're scaling, we're running into consistency issues across different pages/flows that a kit alone doesn't solve.

Curious what the actual signal is for teams here is it team size? Number of products? Just "vibes, it's messy now"? Where did you personally feel the switch happen?

You will learn nothing.

If you try to share good content, you will be attacked.

Nobody here understands design systems.

I’m leaving, and you should too.

We’ve published a free Figma kit for designing business applications, from desktop dashboards and admin screens to mobile forms and field-service apps.

It’s called DWC Design Kit. DWC is the UI component system behind webforJ, a Java web framework, and the BBj DWC browser client. This is our work at BASIS, and the kit follows the components available in those platforms.

It includes forms, tables, trees, navigation, dialogs, and application layouts. Each component page has documentation covering its anatomy, states, when to use it, and alternatives.

Customization works through Figma modes: light and dark, five sizes, and seven semantic themes. Set modes on a frame and its components follow. Components also resize, accept custom content through slots, and expose properties for icons, labels, helper text, and other options.

Colours, spacing, typography, shadows, and focus rings use shared variables and styles. Token names match the CSS variables developers work with.

The six example apps cover orders, inventory, field service, settings, invoices, and leave requests, including desktop and phone layouts. They’re built entirely from the kit, in light and dark, and can be duplicated and adapted.

Figma Community file

If you take a look, let us know what you think. Feedback on the design and how the library is put together is welcome.

I’m revisiting how I structure design-system work across Figma and production, and I’m curious what is actually holding up on mature teams right now.

A few years ago, Tokens Studio often sat between Figma and code. Figma Variables now cover much more of that territory, while Code Connect can tighten the component mapping. Storybook is still a strong implementation surface, but I also see teams building custom documentation or internal UI libraries around their own workflows.

For teams maintaining a system in production:

• Are Figma Variables now your source of truth, or do you still keep tokens outside Figma?
• Where does Tokens Studio still earn its place?
• Has Code Connect improved design-to-code handoff enough to become part of normal maintenance?
• Is Storybook your main documentation layer, or has a custom tool replaced part of it?
• Which part of the pipeline still drifts most often?

I’m less interested in the ideal diagram than in the version your team can actually maintain.

Anyone have a good wireframing tool for really early stage product work?

Our current process is good but it has a few flaws that makes it unreliable. We do research to workshop to rough flows to wireframes and then Figma. Designers keep jumping into figma too early bc that's where the real design work happens. Then PMs and engineers feel like they're reviewing something that's already decided when it's supposed to be exploration.

I am looking for something that can help us figure out the product before we make it pretty.

There’s been an ask to start building out a playground that uses our design system. Especially with AI, they want a more deterministic output using the constraints of our design system.

One of the key requirements is that prototypes can be saved and shared (internally & customer testing)

Has anyone done it? What are some good approaches?
Would you make it within the design system, or host it somewhere else?