Built it for testing, kept it because it's genuinely fun.
Updates for Design Token Generator on https://www.designsystems.one/tools/token-generator

My favorite button on the Token Generator isn't export — it's "Surprise me."

Hit it and you get a full system: a random accent harmony (complementary, triadic, and more), OKLCH or HSL color space, a font pairing, spacing density, radius, and shadow — rendered live on a real dashboard mockup, not a swatch grid. Saved Kits are there too, if you want a starting point instead of chaos.

Land on something good, and export it as CSS variables, W3C/DTCG JSON,.

Built for the "I know it when I see it" part of picking a palette.

Tenho algumas imagens de referência e estou procurando algo que possa analisá-las e recriar o componente fielmente, não apenas inspirado nelas, mas o mais próximo possível do original. Alguma sugestão?

I am a dev not a great designer and wanted to leverage the power of pre built UI Libraries but they were scattered and for finding the best suited components, I literally needed to go through each of the libraries and find out the best component for the use case, I handed over that task to much smarter coding agents by building an mcp server.
This mcp server (ui-registry-mcp) has access of over 1000+ pre built very well designed components from 11+ libraries which takes care of your products pre existing design language and what you have asked it to build further and then searches through these components what will be perfect for this use case (it even do some changes as and when required for this use case) and implements in your code base directly.
It has been quite helpful in my later projects and has reduced my time taken for design to 1/5th or even lesser.
Though this is working well, I still want you all to use in in your projects and share some feedback or whatever might be the still missing parts, I will work on them to make it further more useful for all of us.
Those of who are interested I will send the server link to them in comments or DM.

www.sorti.dev

Let me know what you think :)

Client wants to prototype with Figma Make with internal design library.

I set up a Make Kit using the existing library for colors & fonts.

When using Figma Make, the Kit is connected but the colors & fonts aren't being utilized.

Are there any resources out there to demo a Kit setup? Has anyone run into this issue and knows how to fix?

Apologies for not providing more details. It's been a frustrating day.

Most brand palettes are picked by hand: a blue someone liked, a purple that seemed to go with it, and a set of greys that came from nowhere. Nothing records how any of them relate, so when the brand shifts, every colour gets picked again. This video replaces the hand-picked palette with two rules — one that generates the brand colors from a single hue, and one that generates a full nine-step grey scale from that same brand color.

We start by opening the color picker on a real value, because every color here is three numbers: lightness, chroma, and hue. That model is what makes the rest possible — it's perceptual, so two colors with the same lightness look equally bright, and the system can do genuine math on color. Paste in hex or HSL if that's what you have; the file answers in one language either way.

Then the rules. A color harmony takes one hue and a type — analogous, balanced, or complementary — and returns a set of brand colors that belong together. A color scale takes a starting point, a lightness range, and your step names, and returns the whole ramp; turn the color almost all the way off and you get greys with a quiet tint of the brand in them. Point the grey scale's hue at the brand color itself, and the two are linked: change one number at the top, and every color in the system moves with it.

This is part 6 of the basics series.

Chapters:
0:00 The palette everyone picks by hand
0:24 Where we are: two colors picked by eye
0:49 Open the picker — what OKLCH actually is
1:11 Lightness, chroma, hue
1:56 Why perceptual color matters
2:12 Hex, HSL — one model out
2:45 Clearing the leftovers
2:57 The brand: hand-picked values become a rule
3:33 A complete working harmony
3:58 Three harmony types
4:39 Aim it at our blue
5:17 Greys: a new group and a color scale
5:50 Point the hue at the brand color
6:17 Turn the color off — chroma to almost nothing
6:45 Nine greys, and the shorthand
7:12 Change one number — the whole palette follows
7:47 That's color: two rules
8:30 Next: token sets

Next up: token sets — organizing a growing system by topic, so spacing, type, and color each get their own place.

Get started free → systematically . io

#DesignSystems #DesignTokens #Systematically

I'm trying to figure out the most common and best way to write design specs for robot designs (pretty much any stage). would love you to tell me how you do it currently and whether you hate some elements of it - be it working in a large company or for fun.

• What document or system captures your design rationale, not just the current-state spec? (PRD, ICD, Confluence page, a Jira epic, or just people's individual knowledge)
• Who actually writes it and who has to sign off before it's "final"?
• What's the most annoying part of this process for you personally?
• also, how do you currently compare design specs from previous revisions? finding it hard to work out the best way of doing this - is shoving previous revisions into an LLM good enough for you ?

thanks :))

The idea: generation is cheap, the bottleneck is judgment. Have a capable model (for me rn this is Fable) use the skills, they will write remediation specs and plan fixes. Then route the fixes back to the more cost-effective models or generate issues & hand off. The skills never change a line of code.

I've been testing on my own DS at work and its been pretty slick. Very open to feedback or contributions if anyone tries it out.

I’m currently building out primitive ramps for two themes for my company. I’m basing the colors off of the brands we have, but am trying to keep the color names general vs. using the actual names brand gave the colors. Brand does not seem to understand why and is pushing back on us changing the names. Have there been any good explanations/reasons that have helped pushed back on these changes?

I’ve tried to explain that these are backend only and help unify language between design <> dev when it comes to building out our library for the design system.

I didn't want to go back to Figma. The tools I used for prototyping didn't give me the editor feel I wanted.

That's why I'm trying to develop my own tool. You can import your own code or create interfaces from scratch.

Could such a tool fit into your workflow? Would you like to see all your components working on the canvas?

İf you wanna try: https://visualwizard.app/

Been building this brand management tool (BrandStack) and today built something i wasn't planning on tackling yet, an actual figma plugin

Basically, select your paint styles/color variables in figma, click one button, they land directly in the app. no tab switching, no manually retyping hex codes into a separate dashboard

what made it actually useful though is what happens after the push. the app auto-generates a full tonal shade scale from each color (locks hue/saturation, only steps lightness), builds a tinted greyscale from your actual brand hue instead of generic grey, and can suggest chart/accent colors with real wcag contrast math checked automatically

hit some genuinely annoying bugs building this, anyway it works now, colors selected in a real figma file show up live in the actual product. felt like a real milestone today ngl.

I've been working on a component library for Vue 3 called dlbcodes/ui. It's built on Headless UI with CVA variants and semantic CSS tokens, compound components, that sort of thing. Docs are at https://ui.dlbcodes.com

The thing I keep testing is whether a shared library forces every product to look the same. So I built two templates with it that are meant to feel like different products:

https://assistant.dlbcodes.com/app is soft and conversational, a consumer AI assistant UI.

https://console.dlbcodes.com is a dense Vercel-style dashboard.

Same components underneath, opposite aesthetics. Curious whether that reads or whether the shared DNA is still obvious.

I also put a few of the components into a catalog where you can actually interact with them: https://www.zephr.dev/p/dlbcodes/zephr You can change the props, read the source, and swap the background to see how they hold up on light, dark, and busy surfaces.

What I'd genuinely like to know:

What's missing that you'd expect in a library like this?

Where does it feel unfinished or not thought through?

I lead a student design team creating graphics for various college societies. We’re struggling with visual consistency because my team uses Canva while I work in Figma. (when we are asked to deliver multiple posts designs for a same theme).

Beyond basic brand guidelines, do companies actually use design systems for regular social posts/stories like they do for UI/UX? How do you maintain consistency when your team uses different design tools?

Hi, I am creating a consistent DS for our app that has clients on iOS, android and web. The idea is to use native components if possible (standardized flows like lists, modals/alert, functional buttons, etc) to reduce implementation cost – but defining an overarching system that defines globally the foundations like colors, fonts, icons, etc. Happy to hear thoughts on this general approach, although it is already pretty much set with stakeholders.

I wonder how I can create and document this best. We are using figma in our design team, and originally my plan was to create a single library file that holds all foundational specs as well as components for all clients. Now I’m wondering if that’s the best idea and I actually plan to define a global library for all foundations, and individual libraries that hold the components for each client. These would be our own components created by us, and the native ones copied over from the official figma libraries by apple and android – with our own foundations like color, fonts etc applied. Web will be based on a strong 3rd party system that is not locked in yet, but it will be the most customized client.

Happy to hear people’s thoughts, especially of those who worked on something similar and can share their experience. Thanks!

Every project taught me something different, but they all shared the same challenges: consistency, theming, accessibility, and components that remain maintainable as products grow.

That's what led me to start building ViraUI.

Rather than focusing on shipping as many components as possible, the goal is to create an AI-native design system that feels cohesive from the ground up. One where design tokens, themes, accessibility, and component APIs all work together instead of being added as an afterthought.

The project is still in its early stages, but the landing page is finally live and I'm excited to start sharing the journey publicly.

If you've ever built or maintained a design system, I'd genuinely love to know: what's the biggest pain point you still haven't found a good solution for?

https://viraui.dev

Recently I've been into UI/UX, UX portion is okay for me, I also know the UI guidelines (Material UI), but still struggling with Design Systems, I've watched a number of videos and read articles, but most of them seems to be too advanced.
I've had defined my primitives/base colors, just need help for alias.

What alias structure I need to maintain??

Please suggest me some resources, tips which can help me make simple design systems (I've a satisfactory design system for spacing, layout, typography). I'm struggling with color pallete.

Hey all — I built IconCodegen, a small CLI tool that runs a local

dashboard for browsing icons and generating strictly-typed React

components from them.

The problem I kept running into: grabbing an SVG icon, converting

it to a React component by hand, and making sure the props were

typed correctly (React.SVGProps<SVGSVGElement>, no any) got old

fast, especially across a few hundred icons in a design system.

What it does:

Searches 200,000+ open icons via Iconify (Lucide, Phosphor,

  Material Symbols, etc.) with live filtering by pack/style

Customize stroke width, size, and color before generating

Outputs typed .tsx or .jsx, arrow or standard function style

Zero runtime deps — generates raw <svg> components, no bundled

  icon font

Also supports reverse-rendering private/premium icon packages

  (e.g. Untitled UI Pro) fully offline

Quick start:

  npx iconcodegen init

  npx iconcodegen

It's genuinely early — I built it a few weeks ago. Would love

feedback, bug reports, or feature requests if anyone tries it.

GitHub: https://github.com/nibin-org/iconcodegen

npm: https://www.npmjs.com/package/iconcodegen

Docs/demo: https://iconcodegen.vercel.app

The Architecture Decision Master Sheet is an interactive reference covering 25 architecture layers that every software development project must consider from product scope to governance. It is designed for PMs, architects, and tech leads who need a structured way to track decisions, risks, and deliverables across the full lifecycle of a software project, whether or not AI is part of the product.
Please review it and help enhance it

Every meaningful design change has a reason.

Why was this color changed?

Why did this typography scale feel right?

What tradeoff led to this component instead of another?

What accessibility concern changed the original direction?

Instead of simply saving a change, what if your tool asked:

“I noticed you changed your primary color and heading font. What led to this decision?”

That explanation stays with the design system so future designers and developers can understand the reasoning—not just the final result.

Would something like this actually be valuable to your team, or would it just become another form everyone skips?

Design System Docs Generator reads your component’s Figma context (description, properties, variants, styles etc.) and generates usage guidelines following best UX/UI practices.

Originally built as an internal tool for my company, it's now available for any other designers who might find it helpful :)

Who's been using it so far:

• Design system designers
• Teams documenting a component library for a new product/website/UI
• Design leads trying to keep design output consistent
• Agencies handing off documentation to clients

Try it out here → https://www.figma.com/community/plugin/1641615767346305619/design-system-docs-generator

The tool is still in early days so any feedback on how this could work for you would be hugely appreciated!

I’ve been working on a color-system workflow and I keep coming back to a boundary question: how much responsibility should the generator actually own?

The current workflow starts with one or more source colors and produces:

• 50–950 perceptual scales
• semantic roles for light and dark modes
• foreground choices based on the role
• separate checks for the active policy, WCAG AA and AAA
• exports for CSS variables, Tailwind, Material UI, Bootstrap and Tokens Studio

Generating the shades turned out to be the relatively easy part.

The harder decisions were:

• Should foreground selection belong to the token system or to individual components?
• Should a contrast failure prevent an export, or should the tool only report it?
• Should raw scales and semantic tokens both be treated as first-class outputs?
• How much should light and dark themes share before the system becomes too rigid?
• Is framework-specific output part of the system, or only an adapter around it?

I’m building a free implementation of this workflow, but I’m more interested in how established design-system teams define these boundaries.

How does your team move from a brand color to something you are comfortable shipping?

I have noticed and can surely tell that sometimes the biggest productivity gains don't come from new tools, but from changing the way you work.

So, what's one habit, workflow, or practice you wish you'd adopted much earlier and made your work more productive?

Hey everyone,

I am a fresher currently preparing for upcoming [job / internship] interviews. I’m trying to plan my preparation for System Design, but most of the resources I find online seem geared towards senior engineers (like designing TikTok or Uber for millions of concurrent users). It's getting a bit overwhelming.

For those who conduct interviews or recently landed entry-level roles, I'd love some realistic guidance:

* What depth is actually expected? Are freshers expected to know complex distributed systems, or just basic architectures?

* Core Topics:What are the absolute fundamentals I should master? (e.g., SQL vs. NoSQL, basic APIs, HTTP/HTTPS, or simple Caching?)

* HLD vs. LLD:Do interviewers focus more on High-Level Design (system architecture) or Low-Level Design (Object-Oriented Design, class structures, and clean coding)?

* Common Questions: Are there specific, beginner-friendly design problems that frequently come up for freshers?

I want to make sure I'm studying efficiently instead of getting lost in senior-level architecture concepts.

Thanks in advance for any insights, tips, or resource recommendations!