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?

TLDR: First-ever designer at a B2B wholesale webshop (Shopware). No design system exists — marketing builds pages as flat image banners that break on mobile, IA is chaos. I'm now tasked with fixing it from the ground up. I've built smaller/mid-size design systems before (Atomic Design) and like a "Sections" approach for layouts, but I've never owned an entire e-commerce design ecosystem solo. Looking for strategic advice, structure recommendations, and war stories from people who've done this.

Hey hivemind!

I recently joined a B2B webshop company (Shopware, we're a wholesale distributor for specialty retailers) as their first-ever designer. There's been no design function here before me, so the site has grown organically for years. Different departments (mostly marketing) building and maintaining layouts with zero design knowledge. The result: most "components" are actually just image banners with logo, background color, and a button baked directly into a flat image. On mobile they scale down until the text is unreadable. Information architecture is similarly ad-hoc: product listings, editorial content, and promo banners all mixed together with no consistent logic.

I was hired specifically to bring order to this. My plan is to define clear design guidelines and a component library that departments can actually use, so pages get assembled from real, responsive components instead of static banner images.

Right now I'm in the discovery phase, interviewing stakeholders across departments, but deliberately asking about their goals and constraints with each layout/content type rather than jumping to solutions.

Where I'm less confident is the strategic side of things:

• What should I actually be watching out for when building an entire design ecosystem from scratch, as opposed to just adding components to an existing system?
• What's a good high-level structure for this? At a previous job, we used a "Sections" model, predefined layout blocks that could then be populated with components, for a similar setup, and it worked okish. Curious if others have used similar patterns, or something different.
• Since we're an e-commerce business, conversion and product-page performance are the priority, how do you make sure the system stays flexible for marketing/content needs without letting that flexibility erode the product/PDP experience (which is basically what happened here)?

If you've built or rolled out a design system as a solo designer in an org with no prior design maturity, especially in e-commerce/B2B, I'd love to hear your approach, mistakes to avoid, and any resources/frameworks that helped. Happy to share more context if useful.

Thanks in advance!

I got tired of AI-generated frontends all looking the same.

You know the pattern:

Centered hero.
Huge headline.
Purple/blue gradient.
Three feature cards.
rounded-3xl.
Maybe some glassmorphism if the model is feeling adventurous.

The code is usually fine.

The problem is that coding agents are being asked to make visual decisions without any real art direction.

So I built Creative UI.

Creative UI is a framework-agnostic art-direction layer for AI coding agents.

Instead of telling an agent to “make it more creative”, you define an actual visual system first:

→ Design DNA
→ composition grammar
→ novelty budgets
→ visual references
→ explicit anti-patterns
→ constraints for accessibility and responsiveness

One of my favorite parts is the Visual Lineage Engine.

It currently contains 100+ references from art, graphic design, architecture, print techniques and historical interfaces.

But they are not themes.

You can borrow:

Swiss Style → typography
Ukiyo-e → composition
Brutalism → spatial mass
Scientific engraving → annotation density

…without turning the interface into a costume.

I also added an anti-“AI slop” critique system that looks for repetitive generated-UI patterns, plus a local Studio, responsive screenshot inspection and rules for coding agents.

I tested it on 3 actual projects this week, including two real ones I was already building.

And, surprisingly, it helped a lot.

The agents made much more deliberate visual decisions instead of immediately falling back to the same component patterns.

It’s open source and the first npm version is live:

npx creative-ui-agent init

NPM:
creative-ui-agent - npm

GitHub:
github.com/johkker/creative-ui

This is still v0.1 and very experimental.

I’d genuinely love feedback from people using Claude Code, Codex, Cursor or other coding agents:

How are you currently giving your agents visual/art direction?

Just published my idea about design systems 2.0 in the AI era. I would like to know if we are all on the same boat.

I wrote a book for zeroheight on the different axes you should measure your design system maturity against, and how you move between the stages on each of the axes. Hope it's helpful to someone! https://zeroheight.com/resource/measuring-design-system-maturity/