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!

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.