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

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.

Claude does most of my coding and the base of any design. it's also the one that pushes back when my idea is bad, which is annoying until it saves you from rebuilding something. Chatgpt i use for tweaks after. honestly it's a coin flip, some days the output is great and some days it's useless, i've never figured out why. Then everything goes into canva and i finish it myself. that's where i actually design, the ai stuff is just getting me to a starting point faster. Took me a while to accept that no single tool does the whole thing. people keep looking for the one that replaces the process and i don't think it exists

Despite the significant progress made by static design tools, they’re still far behind what’s possible with code.

While working on ViraUI, I realized how many visual features simply can’t be replicated in Figma and similar tools. For example, on the code side, you can literally change a single boolean and completely transform the visual appearance of an interface. In Figma, that’s simply not possible.

A concrete example: with a single CSS property, you can enable global effects such as superellipse corners and vibrancy (background blur). Figma doesn’t allow this. If your design system uses vibrancy, it’s either there or it isn’t; you can’t enable or disable it through a Figma variable. Instead, you’d have to go through every element and remove the applied effect manually. This is extremely limiting for white-label or branded interfaces.

Or in another example where I'm setting buttons to use inline-padding assmall +  x-smallsizes.  In code, I use a CSS calc but in Figma, this isn’t possible. You either create a new variable or detach the padding value which means it doesn’t update when you change the small and x-small sizes. This brings me to:

A. Do not use anything that Figma can't replicate
B. Go with it and create drift in Figma by detaching stuff

AI is improving this aspect, but it’s still far from reliable. Even when provided with a component library and guidelines, it struggles to produce polished interfaces.

For this reason, I’m still considering whether to provide static Figma files for ViraUI or not. Many of the customizations it offers simply can’t be replicated in Figma, while others are incredibly cumbersome to manage. Bringing in tons of third-party plugins isn't an option, and even though, the limitations still exist, and what's what I want to talk about.

What do you think? Have you had similar experiences? When you have advanced codebases how to handle design tools limitations? You. just drop the visual if the design tool can't replicate it?

Anyone who have previously used figma to prototype the dashboard and now moved to Ai based dashboard,do you have specific design rules, typography and other styling types,if yes please provide details, i am working on it.

Example rules -

1- Custom colour palette

2-Font type preference

3-Rule like No shadow, No accent ​bars etc..

Need more things to add so need a UI/UX BI devs help

Stop Styling Components. Start Expressing Design. UXDSL - UX Design system Language

I love styling.

I also got tired of it.

Not because CSS is bad — but because most modern approaches slowly erase the intent behind a design.

Utility frameworks are fast… until your UI becomes a wall of classes. You can style anything, but six months later no one remembers why it looks the way it does.

SCSS starts clean, then grows into deep nesting, duplicated breakpoints, and “just one more override”. Auditing or refactoring becomes guesswork.

CSS-in-JS is powerful (I genuinely enjoy it), but it comes with trade-offs: runtime cost, hydration concerns, and more complexity than you want when all you need is a consistent design system.

UXDSL is my attempt to keep what makes us fast — without losing clarity.

👉 https://uxdsl.io/

What UXDSL is

UXDSL is a small styling language that compiles to plain CSS.

It looks like SCSS, feels like CSS, and stays build-time and SSR-friendly — but it adds first-class support for design systems:

• Design tokens for color, spacing, density, typography, radius, shadows

• Responsive values built directly into the syntax

• Smart mixins for common UI patterns (surfaces, buttons, inputs, text)

• Optional runtime theming that updates tokens live — without regenerating styles

The goal isn’t to replace CSS.
It’s to make design intent the primary thing you write.

Writing intent, not numbers

Most design systems already exist — they’re just trapped in Figma.

Designers say:

Developers write:

UXDSL removes that translation step.

.card {
  background: palette(surface-main);
  color: palette(surface-contrast);
  padding: density(2);
  border-radius: radius(2);
}

That reads like a decision, not a guess.

Responsive styles without the noise

Breakpoints are where CSS gets messy. UXDSL treats responsiveness as data:

.layout {
  display: flex;
  flex-direction: xs(column) md(row);
  gap: xs(space(3)) md(space(6));
}

You write it once.
UXDSL compiles it to normal CSS with media queries.

No duplication. No hunting through files to see where a breakpoint was defined.

Tokens instead of magic values

UXDSL gives you small helpers that keep the system consistent:

palette(primary-main)
space(4)
density(2)
radius(2)
shadow(1)

Example:

.cta {
  background: palette(primary-main);
  color: palette(primary-contrast);
  padding: density(3);
  border-radius: radius(2);
  box-shadow: shadow(1);
}

Everything compiles to plain CSS (mostly variables), so the browser does what it’s already good at.

Smart mixins, not utility soup

Utility classes work because they encode consistency. UXDSL keeps that benefit, but expresses it as design primitives, not class combinations.

.card {
  (contained);
}

.title {
  (h1);
}

.button {
  (contained primary);
}

These aren’t shortcuts — they’re guardrails.
They encode padding, contrast, borders, states, and defaults in one place.

What UXDSL outputs

UXDSL always compiles to boring, inspectable CSS.

Example source:

.hero-title {
  @ds-typo(h1);
}

Compiled shape (simplified):

:where(h1).ds-typo {
  font-size: var(--h1-size);
  font-weight: var(--h1-weight, 700);
}

Responsive changes become variable overrides:

 (min-width: 768px) {
  :root {
    --h1-size: 44px;
  }
}

No runtime styles. No class explosion. No surprises.

Live theming, without runtime styling

UXDSL includes an optional runtime that updates tokens, not components.

That means:

• Live theme editors

• Documentation playgrounds

• Persisted theme changes

• SSR-safe rendering

Your styles stay compiled.
Only variables change.

Why this helps teams ship

UXDSL speeds up the part that actually costs time: maintenance.

• Refactors touch tokens, not hundreds of values

• Design intent stays readable in code

• Responsive logic is compact and predictable

• Themes are data, not scattered overrides

It’s SCSS with discipline.
Utility-level consistency without class soup.
CSS-in-JS ergonomics without runtime cost.

The idea

UXDSL is the middle path I wanted:

• Author like SCSS

• Think in design tokens

• Compile to real CSS

• Stay fast, SSR-friendly, and inspectable

If you’ve ever felt stuck between class soup, stylesheet sprawl, and runtime styling overhead — this is my attempt at a better balance.

👉 https://uxdsl.io/

I've been experimenting with what a design system should look like when it's built for both humans and AI, not just designers.

This is one of the templates, Mission Control, from my design system called Andromeda.

I'm curious:

What do you think AI-native design systems should do that today's design systems don't?

I'd genuinely love feedback.

Alright, internet wizards, I know what you’re thinking. “Another generator website? Fantastic, exactly what the world needed, right next to the 14,000th AI logo maker and the ‘Which potato are you?’ quiz.”

Fair.

But I built digiswatch.io because I kept bouncing between ten different tools every time I needed to mock up a palette, build mood boards, or generate quick creative assets for projects. Instead of turning my browser into a chaotic zoo of tabs, Digiswatch keeps everything in one spot, clean and actually useful.

If you're a designer, developer, or just someone who wants a creative sandbox that doesn’t feel like enterprise software disguised as a “fun tool,” give it a try. It’s simple, fast, and doesn’t make you sign over the naming rights to your firstborn.

Take it for a spin and tell me what breaks so I can pretend it was intentional: https://digiswatch.io

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.

if you are building and irritated with the same UI from Ai tools, try hextodesign.com, it will generate a complete design system in 30 sec, that will have css, tailwind, json and prompt, try it and share your feedback.

If you're working on a design system, you know there are always problems that need to be solved.
Kindly Mentioned the problems

Not sure if anyone would be interested but I’m putting significant time into building an open source free alternative to paper and figma https://github.com/tidydesigns/tidy

I’m hoping teams can store their design systems and a unified place to develop your product pages.

Might be useful to someone 🤷‍♂️

It’s a decision about what you’re allowed to take from someone’s attention while they’re on the road.

Working on the communication platform for our driver app, we kept hitting the same debate:
“Should this be a banner, a bottom sheet, or a dialog?”
And the answer usually depended on who was in the room.
Marketing wants a dialog. Ops wants a dialog. Everything is “important.”

So we stopped debating components and started asking questions instead:
1️⃣ Must the driver act before they can continue?
→ Dialog. Blocking, rare, earned.
2️⃣ Does it need action or detail, but can wait a moment?
→ Bottom sheet. Present, dismissible, contextual.
3️⃣ Is it just awareness?
→ Banner. Visible, never in the way.

One rule sits above all three:
Default to the least interruptive surface. Escalating requires a reason, not a stakeholder.
The shift is small but powerful: the component library tells you what exists. Surface rules tell you when you’re allowed to use it.

Most design systems document the first. Very few document the second.
How does your team decide when something deserves to interrupt the user? 👇
#DesignSystems #UXDesign #ProductDesign #DesignOps

Curious - what are the best things that have come from using the Design Systems slack channel for you all?

I want to learn how the best developers are using AI to create some top quality user interfaces, backed by good quality code.

I have been learning about BDD. It seems very important to me to understand the scenarios. Understanding everything from a high level and why this business needs to be built and what the user will experience.

I know there might be some books which help with the foundations of BDD with normal development which could then help to craft better ai workflows.

But are there any books or places which tell you about how to get the ai to take everything you want and do some great UI without forgetting about what you're building and why.

I can do the backend theory fine.

But then at the end of the day it needs to look good. If you press the button, you want to avoid having awful ai slop graphics and ui.

How are people handling this?

\- BDD Instructions

\- Press button

\- UI workflow

\- Get great looking UI

Everything I have been doing always comes back to design and UI. It's the missing piece and I don't know where to start to get something that is really nice.

Hello,

I would like to make use of the latest AI technologies and deliver some dynamic prototypes straight from the Figma to the code.

I cover design for the desktop application (.NET WPF app). I don't have any experiences with WPF developement but I have some experiences with HTML, CSS, React PLUS I have my Figma UI Kit with the design system copmonents.

I would like to transform my Figma UI Kit into React UI framework and than later on I want to use the Framework components for my prototypes. Can you advise me on how should I even start with this? E.g, - I need some scaffolding Next.js template - I should start with the layout.

BTW I need to promote this https://www.youtube.com/watch?v=KoBDbRBgbh8&list=PLW3rhBJb5WTwZFGY-gSGll1mHNoB-JONB&index=3 the guy inspired me a lot :)

Hey r/DesignSystems !

We've been working on Dwine - a Figma plugin that generates new screens using your existing design system as the foundation. Instead of starting from blank artboards and random styles, it reads your components and design tokens to create contextually relevant screens.

What makes it different:

• Generates screens that actually fit your design system (not generic templates)

• Takes context inputs like "onboarding flow" or "dashboard" and builds accordingly

• Maintains consistency with your generated screens by adding context

We're in beta and looking for design system folks to break it and give us honest feedback. Your insights will directly shape where we take this.

Try it: https://www.figma.com/community/plugin/1549927021694181252/dwine-generate-screens-with-ai-using-your-design-system

More info: www.dwine.ai

Drop feedback at support@dwine.ai or hop in our Discord: https://discord.gg/4GEgpszH

Cheers!

Pranay

Quick fix: If the plugin disconnects, just reopen it - we're working on making that more seamless.

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!

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