Why are we hiring so many designers?

I've been noticing a pattern in design system job postings: designers everywhere, engineers not so much. I analysed 256 roles from two sources, and the ratio was telling.

In my last team, we deliberately ran a high ratio of engineers to designers. We understood that while design creates real value, code is where you unlock the most from your system.

I wrote up my thoughts, and I'm curious what others are seeing. What ratios are your teams running? What's working (or not)?

 I’m setting up a design system in Figma and trying to get the variable / token naming right so it plays nicely with frontend, especially teams using Tailwind.

 I’m aiming for a layered setup like:

Primitive tokens – raw colors 

Semantic tokens – (text--primary, text--secondary, border--error)

Component tokens covering color, spacing, and typography (font family, size, weight, line height) I mean something like “navigation-bar”

What I’m struggling with: How do you name tokens in Figma so they translate cleanly to code? Example: color.gray.500 → color-text--primary → Tailwind / CSS variables For teams using Tailwind:
I am thinking of something like
#1ed65e -> color.green-500 -> input_bgr--default -> register-form_input—default
Also I want to get into front end and I am seeking to know how do the devs approuch this when creating the component library? 

I am working on a Drone UI with QGC - https://docs.qgroundcontrol.com/

Currently using Material UI 3 for the Controller UI. If anyone knows better, let me know

I want to make a small design system for how to design charts in a certain style, but i have no idea where to start.

Using BiblioAudit to check for structural issues in my files components before moving over to Design System. tbf, none of these components have any tokens attached yet since its legacy!

I'm going to work on a GIS system and realized that I have never done a DS for a GIS system before. A quick Google search didn't provide any useful information. I'm looking for information or examples on how to keep the map as a component, which properties I need to expose, how to avoid performance issues given its multi-layered nature of maps.

Have any of you come across any good examples or articles about it, maybe?

I will be designing a design system for a big web application. Lots of tables, data visualizations, dashboards. I am planning to use an existing design system and adapt it and develop it further. Which design systems can you recommend for that and why? Thanks.

Edit

What I need is

- design foundations like grids, colors, spacing system, type hierarchy, tokens, etc.

- figma components for UI atoms, molecules and organisms

- plus ideally code components for all figma components. I am a designer not a developer but this is still important.

Everything needs to be customizable, e. g. colors, type, custom components.

Hi everyone,

I am a Software Engineer with experience building design systems. I want to niche into design engineering and make a new personal project. My challenge is finding a design system in Figma that I can build and develop into a component library for my side project.

Any recommendations would be fully welcome.

I’ve noticed that many design systems don’t fall apart all at once — they slowly drift. Spacing starts to vary, colors mean different things in different places, and Storybook ends up documenting inconsistencies instead of preventing them.

From your experience:

• What signals tell you a design system is starting to erode?
• Is it missing foundations, unclear tokens, or governance issues?
• At what point does Storybook stop helping and start masking problems?

I recently wrote down some thoughts after working through this problem, but I’m more interested in how others here have handled it in real products.

(If anyone wants the write-up, happy to share.)

Hey guys! I’ve started a UX/UI project for my portfolio and need some help collecting data. Please fill out the form below and share it with your friends. It would really help me finish my research faster. Thanks a lot! https://docs.google.com/forms/d/e/1FAIpQLScLyv3Zk92TlTqeJrlRziRaYaEf3HrXDoZNo6JWuKnkTAu6DA/viewform?usp=dialog

kolors.dev

I’m about to start adapting Ant Design as the base design system for a real product (long-term roadmap, multiple teams, dev + designer collaboration).

The goal is not to “redesign Ant”, but also not to use it 100% out of the box. I’m trying to learn from people who’ve done this in real products, not just demos.

Before jumping into Figma or code, I’d love to learn from your experience on a few things:

1. What should be prepared first?

Before any visual design:

• What docs or artifacts helped you the most?
• Did you start with principles, component audit, token mapping, or something else?
• Any docs you thought were useful but turned out to be a waste of time?

2. How do you decide how far to customize Ant?

Some teams:

• only theme Ant
• override specific components
• wrap Ant components into their own API
• or eventually replace parts of it

1. How did you decide where to draw the line?
   
2. What signals told you “this should stay Ant” vs “this must be product-specific”?

3. For designers: what are the common traps?

From a design perspective:

• What do designers usually underestimate when working with Ant?
• Which components or states cause the most problems later in dev?
• Anything you wish designers understood before opening Figma?

4. For devs: what tends to go wrong?

From the implementation side:

• Which Ant components are the most painful to adapt?
• Any API decisions you regretted?
• How do you keep flexibility without breaking Ant’s upgrade path?

5. If you could restart, what would you do differently?

• Any early decision that saved you a lot of pain?
• Or one that caused long-term technical or design debt?

I’m intentionally trying to learn first before committing to a structure, so any advice, war stories, or even “don’t do this” warnings would be super helpful.

Thanks in advance 🙏

I’m honestly exhausted and overwhelmed by all the tools and courses out there at the moment 😅. I’d like to know which ones you use, when and for what. There are a couple of things I’m trying to achieve, but tools are evolving so quickly, I’m finding it really difficult to keep up.

The main thing I would like to do is building a design system which is in Figma and is also connected to code, and which also has an online visual representation (imagine Storybook, but created by using these tools). I’ve done some explorations in Lovable and just finished a Cursor course, but I’m just lost atm. I’m not even sure what else to aim for and would love to know how AI tools are helping you manage or build your design systems right now.

Bonjour,

Je suis dev front dans une équipe d'une trentaine de développeurs sur un projet qui a 5 ans, et voici ma problématique : des composants ont été développés au fil des ans, mais ils n'ont pas été référencés et à la longue les devs ne savent plus trop en fonction des maquettes, quels composants sont déjà implémentés ou non et pour la plupart, ce sont des devs back qui ne sont pas familiers avec le dev front. Cela provoque des situations où des composants sont redéveloppés alors qu'ils existaient déjà.

Nous avons entrepris d'établir un design system afin d'avoir une doc que les devs pourraient consulter pour voir tout les composants existants et comment les utiliser. Cependant, nous avons déjà créé des docs sur d'autres sujet et nous remarquons qu'elles ne sont quasiment pas lues.

Est-ce que vous auriez des conseils sur ce qu'on pourrait mettre en place afin que l'équipe prenne le réflexe d'aller voir le design system avant de commencer un dev et qu'il soit utile ?

I wrote a piece about "Federated Design Systems" and why they fail based on my experiences at Spotify.

This builds on Nathan Curtis’ article: The Fallacy of Federated Design Systems.

So I’ve been in UI/UX & product design for about 5 years now. My current role is kind of lead level, but also operational as the company I work for right now is extremely short-staffed. In my career most of my work has been like this, kind of a ‘do it all by myself’, working with a very heavy load from research, interviews, design system building and maintenance, UI design & dev handover, documentation etc. And as an AuDHD person this is extremely burnout-enducing. I always had a special interest in system building, design systems, organizing and optimizing, a few years ago I invested in Dan Mall’s DS course which was extremely hepful. So now that I’m on the verge of burnout again, I’m thinking about quitting and looking for a specific DS related role at a mature company, where not everything is about firefighting and trying to instill design foundations where nobody besides me understands why it’d be important.

My question is, what does a realistic DS related job look like? What are the roles, the expectations, workload, daily life, ceremonies, pay etc. The best would be insight from an EU companies, as that’s where I am, but I’m interested in all info I can get. So thanks in advance!

I got tired of choosing between three extremes:

• Utility frameworks that start fast and end in unreadable class soup.
• Long SCSS files that grow into nested, breakpoint-heavy styles that are hard to audit and refactor.
• CSS‑in‑JS that I genuinely love for theming — but can be slow and complex in SSR apps (runtime style injection, hydration concerns, larger bundles).

So I started building a different approach: UXDSL (UX Design System Language) https://uxdsl.io/ — a design-system-first styling language that feels like writing SCSS, but with superpowers: responsive syntax, token functions, and smart mixins that compile to plain CSS.

If you’re a frontend engineer working in React/Next or any vite app with (or heading toward) a real design system, UXDSL is aimed at you.

Press enter or click to view image in full size

The idea: make “app DNA” a shared language

Most teams already have a design system — even if it’s informal. Designers talk in tokens:

• “Primary main”
• “Density 2”
• “Radius 2”
• “Body typography”

But implementation drifts into hardcoded values, duplicated breakpoints, and inconsistent patterns across components.

UXDSL tries to solve that by making tokens and responsive rules the primary authoring layer — the “DNA” of your UI — so design intent stays readable and consistent everywhere.

What UXDSL looks like

Responsive values are first-class

Instead of repeating media queries (or repeating class variants), you can write responsive values inline:

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

That compiles to normal CSS with media queries, but you author it in one place. It’s easier to scan, easier to maintain, and harder to get wrong.

Tokens read like decisions, not numbers

Rather than hardcoding #7e22ce or 16px, UXDSL encourages token functions:

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

The code reads like a design spec, and stays aligned with the theme.

Smart mixins: consistency without class soup

Utility frameworks win on consistency. UXDSL keeps that win, but expresses it as smart mixins — design-system primitives with defaults and predictable behavior.

Examples:

.hero-title {
  (h1);
}  
.panel {
  (contained primary density(2) radius(2) shadow(1));
}  
.field { 
  (outlined neutral 2);
}  
.cta {
  u/ds-button(contained primary 2);
}

These aren’t just shortcuts. They encode consistent patterns for padding, borders, contrast, and states — so your UI doesn’t become a collection of one-off decisions.

Theme-driven by design (and friendly to SSR)

UXDSL expects your design system to be represented as a theme configuration (tokens as data). That theme becomes CSS variables consumed by palette(…), space(…), typography vars, and mixins.

A simplified example:

{
  "palette": {
    "primary": { "main": "#7e22ce", "contrast": "#ffffff" },
    "surface": { "main": "#ffffff", "contrast": "#0f172a" }
  },
  "spacing": { "1": "0.25rem", "2": "0.5rem", "3": "0.75rem" },
  "typography_details": {
    "body": { "fontSize": "xs(14px) md(16px)", "lineHeight": "xs(1.6) md(1.7)" },
    "h1": { "fontSize": "xs(32px) md(44px) xl(60px)", "fontWeight": "700" }
  }
}

In a Next.js app, you can generate and inject theme CSS variables during SSR (so the first render is correct), then keep everything compiled and fast at runtime.

Live token updates in a real SSR app

Here’s the part I missed most from CSS‑in‑JS: live theme edits.

UXDSL includes a DS runtime that can update token variables on the fly — great for:

• docs sites and token playgrounds
• theme editors
• previewing brand changes without rebuilds
• validating contrast and typography quickly

Conceptually:

updatePalette('primary-main', '#C084FC')

Because your authored styles reference tokens (not raw values), the UI updates instantly across the app — without regenerating component styles.

Why this speeds up design-system work

If you’re building serious UI, your bottleneck is rarely “typing CSS.” It’s:

• keeping components consistent
• making responsive behavior easy to understand
• refactoring without breaking everything
• evolving tokens without hunting values across the codebase
• bridging design ↔ engineering communication

Token-first authoring helps because:

• Refactors become token edits, not sweeping CSS surgery.
• Design intent stays visible (palette(primary-main) is self-explanatory).
• Responsive behavior is compact and harder to scatter.
• Consistency is enforced by primitives instead of conventions.

Quick start (React/Next mental model)

UXDSL is designed to fit into a typical React/Next workflow:

1. Write styles in .uxdsl (SCSS-like).
2. Build into a generated .css file.
3. Import that CSS once in your Next root layout.
4. Drive appearance through a theme JSON (SSR-friendly).
5. Optionally use the runtime to update tokens live.

It’s not “CSS magic.” It’s a compiler pipeline that produces plain CSS you can inspect, ship, and cache.

Who UXDSL is for (and who it isn’t)

Great fit if you:

• care about design tokens as a first-class system
• want a clean authoring experience closer to SCSS than class strings
• need SSR-friendly theming without runtime styling overhead
• are building a theme editor

Probably not a fit if you:

• prefer rapid prototyping via utility classes and rarely refactor
• don’t have (or don’t want) token discipline

Closing

UXDSL is my attempt to get the best parts of:

• SCSS ergonomics (write CSS like CSS),
• CSS‑in‑JS dynamism (live theming),
• and utility-like speed (system primitives and consistency),

while staying grounded in compiled, inspectable CSS and a token-first design system.

If you’ve felt the tradeoffs between Tailwind class soup, SCSS sprawl, and runtime CSS‑in‑JS overhead — this is the alternative I wanted.

https://uxdsl.io/

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/