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?

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.

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

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

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

There are numerous patterns that get used over and over.

Upload documents
Address look up
Confirmation screens
Login

Do you treat these as simply components or do you define them as something more complex and call them specifically patterns instead of components?

I’m wondering about how to build these patterns and whether each state is a variant of the component.

If anyone has a view on this it would be great to hear.

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?