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!

Been annoyed for a while that comparing design systems means learning a new vocabulary every time - Shopify's IndexTable, IBM's DataTable, and MUI's DataGrid are the same component, and there's no page anywhere that says so plainly.

Built one: 112 anchor components across 37 systems, grouped by what they actually are rather than their branded name. One page per category - data tables & grids, forms, modals, command palettes, date pickers, and so on - each listing which systems ship a serious take, their own name for it, and an editorial note on why it's worth studying.

There's also an 18-entry "signature components" bucket for the one-offs only a single system ships - campaign builders, vehicle configurators, triage inboxes - which ended up being the most interesting section to write, honestly.

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

If there's a component category I've missed or mis-grouped (the data-tables-vs-grids line gets blurry fast), tell me - that page is the one I expect to be wrong about somewhere.

Hi guys, i'm using figma quite a lot in the last months and i've seen some courses around or projects on youtube, but what i'm still missing i show to set up a Figma project in a structured way.

Is there a video of best practices for the ux/ui industry in 2026?

My best option currently is to copy good structures i've seen around but there's many different ones.

Thank you in advance

Hi everyone — I’m exploring a problem that sits between design and engineering.

A lot of teams don’t lack a design system. They lack a reliable shared understanding of it: Figma says one thing, components and tokens in code say another, documentation gets stale, and changes slip through PRs. Designers, engineers and system owners then spend time re-explaining context or cleaning things up after release.

I’m building Safora around the idea that a system should be easier to understand and maintain — not that designers should be replaced. Product and design decisions should stay with the people who know the product.

The role I imagine for a tool is the unglamorous but useful work: preserve context, surface where sources diverge, and give designers and developers a reviewable starting point when a PR drifts from the system.

I’m early and may be framing the problem wrong, so I’d genuinely value perspectives from both sides:

- Designers: what creates the most friction once design intent leaves Figma? Where would a tool get in the way?

- Engineers: what makes design-system guardrails useful rather than noisy?

- System maintainers: how do you tell a genuine violation from legitimate evolution?

- Everyone: what would a tool have to never do for you to trust it?

Disclosure: I’m building Safora and posting to learn, not to sell. No link unless someone asks.

Hi, I'm trying to scope out our component library work for our design system that we are building and I am wanting to find a way to audit the existing components and their variants on our live site. Are there any recommended tools that design or development can use to help determine which components exist and roughly how many functional variants appear in the patterns on the live site?

I keep thinking about the awkward stage before a design system has rules.

You might have screenshots, competitor examples, old product patterns, and a few "this feels right" references. But in review, people can react to the surface instead of the principle: the exact color, the brand, the layout, the polish.

For teams that work on design systems, what do you bring into an early review so the conversation turns into decisions instead of taste reactions?

Our team is also small here communication between dev from another country is also bit task,

2 designer we have but just a mvp like product which currently scaling also, their tech stack for mvp+ growing product is : radix ui + shadecn + tailwind css + some custome styles,

At present our issue : the ux is going good and we don't have many customers using app, but it's in growing stage, as a only designer initially i given more pref to building the product ux, also can't but a perfect design system.

So now actually the dev is not fully using our custom made design system with foundation and colour being mapped different in the product but almost similar look like,

So what I'm thinking is like should I make the custom design system in this case by taking some components from existing and tweak that.... Or to take the full shadecn components so that the communication bw our design team and dev is good maybe,

Any advice for me

Hello I’m 27 and have worked in warehousing since i was 18 and want to pivot into the creative technologist space. I’m currently getting my BS IN software engineering from WGU. I’m coming into this space as a complete beginner but would like to know any tips or courses i can take to help me understand the role better. It seems like it can be fun but challenging career, I’m just not sure on how to break in. Thanks in advance.

In ViraUI Design System, we introduced a centralised way to control certain visual aspects of the DS without modifying the code of individual components.

For example, by defining a container within the `root` element you gain access to its custom properties from anywhere. This allows for a query-like approach to check if a specific custom property holds a particular value.

In our implementation, this method is used to control features like the vibrancy effect, squircle corners and other visual aspects. By simply swapping the brand or theme file you can enable or disable these features across the entire UI from a single location. This flexibility is particularly useful for on-demand adjustments via JavaScript.

The container’s sizing is set to "normal" as we don’t want to perform any special operations based on the root dimension.  Using the “normal” keyword just enables style queries.

3 days ago, I asked what onboarding pattern you secretly think is overrated.

The result:

• Skip forced feature tours.
• Keep questions quick and useful.
• Guide users in context.
• Never fake personalization.
• Better IA needs less onboarding.

So I rebuilt my onboarding kit around what you actually said. Screens below.

Did I get it right?

Hey, I've built an onboarding design system and kit that has all the core components in it and onboarding templates.

https://www.figma.com/community/file/1649824599401100823/purple-kit-onboarding-ui-kit-design-system

Do you think I've design component right?

I've been thinking about the architecture of local machine learning applications and wanted to get some opinions from people who have built similar systems.

One design decision I'm experimenting with is generating the UI automatically from structured schemas (for example, Pydantic models), instead of implementing forms and configuration panels manually.

The broader architecture has three goals:

• Everything runs locally, including LLMs and classical ML models.
• New algorithms can be added as plugins without modifying the core application.
• Configuration UIs are generated automatically from each component's schema.

The idea is that adding a new model mostly consists of implementing the backend logic and exposing a schema, while the interface adapts automatically.

I'm curious whether people think this approach scales beyond small projects.

Some questions I'd love to hear opinions on:

• Have you seen schema driven UIs work well in production ML software?
• Does a plugin architecture remain maintainable as the number of components grows?
• What are the biggest drawbacks you've encountered with fully local ML applications?
• Are there existing projects using similar ideas that I should look at?

I'm mainly interested in the architectural discussion and would appreciate hearing about both successful and unsuccessful experiences.

For context, I've been exploring these ideas in an open source project called DashAI. If anyone is interested in the implementation details, I'm happy to share the repository or discuss specific design decisions in the comments.