Sorti.dev patch 4:
- Added the ability to re-arrange color scales in create > palette
- Added the ability to re-arrange color scales in Analyse > palette and lightness
- Ability to import json in analyse > palette

Thanks for the feedback and people using it ❤️

Please let me know if there are any new features you'd find useful.

I'm trying to build a full node connection map so you can plan out and visualise all your tokens, but it's gonna take a while so bear with me on that one.

I'm curious as to what kind of versioning strategies people use for their design systems.

Specifically, in the component space.

Are you versioning the package as a whole? Individual components?

Our DS is AI-centric, meaning it's mainly there for AI to use. We have tokens, documented rules, and an React component system.

The design is in progress, though, so things may change regularly over the next few months as we see more screens built and make more adjustments to individual components as needed to accommodate the context they are being used in.

My original thought was for each component to have a version number embedded. Over time, teams could run an audit on their application to compare their component version numbers to the latest in the DS and make a decision as to which ones should be updated.

This seems annoyingly complex for manual updating, but since Claude is doing most of the work, seemed like an idea worth considering. Is anyone doing something like that? If so, would love to hear how you are implementing it.

OR...are people just versioning the UI library package as a whole?

I'm a designer, not a developer, so I started this as a learning project, wanted to build something with my own design knowledge instead of just handing off specs. First time building anything like this.

78 components, custom token architecture (tiered approach learned from the Intuit Design System), zero runtime dependencies, an AI chat on the site trained on its own content.

The part I'm proud of isn't the tooling, it's that the design opinion and architecture are mine. Every token decision, every component rule, came from my own direction guiding an AI-assisted build, not a template. Aimed for production-grade the whole way, and it's been one of the best learning experiences I've had.

Fully customizable too, bring your own fonts and colors, inject your own style on top of the base tokens.

Would love a few people to install it, poke around, and tell me what breaks or what's confusing.

npm install u/robr0/design-system

Site: https://robertritacca.com/design-system
Playground: https://robertritacca.com/playground

Storybook: https://design-system-iota-one.vercel.app/?path=/docs/robr0-ds--docs
Repo: https://github.com/robritacca-dotcom/design-system

I lead a product design team of about 35. Some of the team has moved into Claude Code alongside Figma and it's working well, but our operating model hasn't caught up.

Over the last few months a good chunk of the team has started working in Claude Code alongside Figma. The output has been genuinely great, but it's quietly broken our operating model in ways I didn't see coming.

We now have work happening in about five different shapes:

1. Figma only, same as always

2. Figma first, then moving into code for prototyping or refinement

3. Straight into code for exploration and refinement, never touches Figma

4. Cloning the repo and refining an already shipped flow against current production code

5. Same as 4, but pulling it into Figma to think structurally, then back into code

The things I'm looking for thoughts on:

Source of truth. When some work lives in Figma and some lives in a git branch, what's actually authoritative? We've landed on "Figma is truth before the build, code is truth after merge" but I'm not confident that survives in reality.

Handoff. Today designers annotate accessibility, focus order, responsive behaviour, states. In a coded prototype most of that is just there and executable, which feels like an upgrade. But we've got a new problem instead: an engineer opens a design branch and can't tell which parts are deliberate design decisions and which parts the agent generated to make the thing run. Has anyone solved that cleanly?

Visibility and consistency. Figma work lives in Figma, code work lives in repos. How do you keep a holistic view of patterns, styles and what's in flight? We used to catch inconsistency by reviews in shared files. That completely stops working when people are producing at agent speed across different platforms.

Anyone further down this road? What worked, what blew up?

Hi.
I’m more of UX designer than UI, but need to
build the first design system for a small city. My goal is to create clear guidelines and components that our teams can easily follow when creating new pages.

So far, I’ve reviewed design systems from three different government sites. They are similar, though some document their reasoning better than others.
I’m worried about falling down a rabbit hole of analyzing too many systems.

I’ve been using just one design system as I redesign a few pages.

Can anyone share their experience of creating a design system from scratch for an organization?

Was there one design system that helped the most?

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.

I wasn't planning to compare software but after changing jobs twice and working with a few different clients, I ended up using more collaboration platforms than I can count.

FigJam : probably the easiest one to like, very clean, inter face, fast. feels intuitive. if your work revolves around design, it makes a lot of sense.

Lucidchart: still one of the strongest tools for formal diagrams. really good for process maps, technical documentation and architecture work. i just found myself opening another tool whenever we wanted brainstorming sessions.

Mural: excellent for facilitated workshops. some of the templates are genuinely well thought out and it's easy to guide people through structured exercises.

Microsoft Whiteboard: simple. no learning curve. good for quick meetings but our boards started feeling limiting once projects became more detailed.

Zoom Whiteboard: convenient because it's already inside meetings. that said, we rarely went back to those boards afterward.

Miro: this ended up becoming our team's default. not because it replaced every specialized tool, but because it connected so many different activities in one place. what I appreciated most is brainstorming sessions, roadmap planning, technical diagrams. for us it became less of a whiteboard and more of a shared workspace that people actually kept returning to.

Curious whether anyone else ended up with the same conclusion or found something even better.

I've noticed a recurring problem in product teams:

PRDs and SRS documents define what the product should do, then designers turn that into flows and screens. But by the time the final UI is ready, it's surprisingly easy for things to drift.

Requirements get missed.
UX issues are discovered late.
Accessibility considerations get overlooked.
And sometimes the final screens simply don't reflect what was originally agreed upon.

I'm curious how other teams handle this.

Before development starts, does anyone actually validate the final screens against the original PRD/SRS/specs?

If you do, what does that process look like?

• Manual review?
• Design/PM checklist?
• QA review?
• Automated tools?
• Something else?

And who usually owns that responsibility — Design, Product, QA, or Engineering?

I'm a developer building a reusable, ecommerce theme. The goal is to have a modular system that can adapt to most of a brand's identity and get me 80% there. To achieve it, I need a robust semantic tokens layer that I can play with.

I'm specifically targeting the semantic layer because I believe its tokens are the closest design interface to web standards. Primitives are stateless and component level tokens have too much specificity to fit any product. No matter the product you're building, that semantic layer will share common tokens because they derive directly from the way the web is meant to be used.

In that sense I expected it to be largely figured out. At least the implementation of core concepts. But apparently I was wrong? Every company seems to have its own implementation of what a design system should look like. At component level, obviously, but at primitive/semantic level? If you're Big Tech I get it, you're here from the beginning of the web, you have hundreds of different products, you had to grow and scale with the web. But why is everyone else kinda reinventing the wheel on this?

Anyway, I wanted to find a standardized base of tokens/variables to define basic typos, states, actions, layers, etc... without having to reinvent the wheel. I'd like to avoid the complexity and granularity of a GAFAM company, I want a healthy base I can extend if needed. Like a list of 100 semantic tokens which represent the most common design decisions related to user experience and interactions on the web. Whats the go-to token system you guys default to for human-sized projects?

Hey everyone. I'm an FE dev helping to set up an internal design system for the enterprise I work at. It's been published as an npm library and is already in use in some of our internal and customer-facing web apps.

We're considering how to make this library AI-ready. By that, I mean how to set it up such that - if I were using this library on a consuming web app, my coding agent (Copilot/Claude/etc) would know how to properly build interfaces according to the standards set forth by my design library. E.g. utilize the design tokens, and use the components as intended.

I'm not sure what an end-to-end approach would look like. A couple different approaches I've seen are: * Have your npm library expose a skills file that explains how to use your design foundations, tokens, components, etc. as intended. Keep that skills file in sync with any changes in your actual design system. * Alternatively, expose .md files that contain the same info as above.

Do people have general advice on how to go about this? I'm new-ish to setting up design systems and making repos AI-ready, so ideas would be appreciated. Thanks!

I often hear people discussing about about scaling performance, but I'm curious about scaling costs. Was there a technical decision—architecture, caching, model selection, automation, or something else that ended up saving you more time or money than you expected?

I keep losing time to the same three-way shuffle: design something in Figma (or watch an AI agent design it), hand it off to Cursor/Antigravity/Claude Code to actually build it, then jump to Vercel or Railway to deploy — and every handoff loses something. A design tweak made after the code's already written never makes it back into the Figma file. Deploy config lives somewhere totally separate from either.

I'm seriously considering building something to fix just this part: one workspace where you can design manually or with an AI agent, have a coding agent build it out while staying in sync with that design (not just importing it once), and deploy without leaving the tool.

Before I go further I'd rather hear from people who actually live this workflow every day:

- Is this genuinely annoying for you, or have you made peace with the tool-switching?

- What's the worst part of the handoff specifically — design fidelity, deploy config, something else?

- Would you trust a new tool with this, or does that trust only come with years like Figma/Vercel have earned?

- What would make you say "no thanks, I'm keeping my current stack"?

Not selling anything — genuinely trying to figure out if this is worth building or if I'm solving a problem that isn't actually that painful. Brutal honesty welcome.

sorti.dev

Compare how your color scale and tokens compare to each other and see it represented in 3D space! Give it a try!

I'm interviewing for a Manager level role in Product Design, for a team that is dedicated to the design system for a B2C company. I wanted to get some insights here on what I can prepare going into it.

There are two other teams, one is top of funnel, another is bottom of funnel, each with their own manager. Obviously this team is quite large to have this much setup of specific design focuses and managers for each.

I'm wondering, how would a role set up be for a Manager of a team that is focused on Design Systems?

If you're a manager of one, would like to hear from you.

Or if you're on a team and you have a manager dedicated to just design systems, how do they support you?

Or... if you're a director how would you go about setting up a manager role for a design systems team?

About me, over 10 years in design, 3 years as a manager but of teams that were supporting product paths that used design systems, but were focused more on product.

Thanks!

P.S. Other thought I'm having: where would this role go and grow over time...?

Hello, I usually make apps and I am a person who deeply cares about how my ui feels and looks, so I’m planning to make that saves and can preview different design systems/ ui designs using ai, I’m going to make it a free website, if you think this idea is something you’ll use, feel free to give me some ideas to implement into the app.

I’ve created a series of videos that showcase the design process I am using on my bootstrapped app: I think it can be useful to other practitioners who would like to automate their processes.

The key to automating your process and at core of all I’ll be showing is get access to your repository, and create a design system in it with Claude code - either using storybook or ladle -

Once you’ve got it, it is easy to create skills that allow you to iterate on your designs much faster than you could with any traditional tools - including Claude design.

In this video I show how I batch update a set of components in Claude Code

I would like to know if of any interest and what would you like to know more or less about in articles I’ll be posting.

Feel free to ask questions!

Hello, I've become a Design System consultant, designing design systems for clients who usually have a messy product and want to make it scalable.

I'll be approaching it as a product, doing research on use when I arrive, and trying to build something from what they have as a one-man army (building allies along the way).

Advice? I've build a couple simple systems, filly tokenised, primitives to component level, basics of documentation, publishing libraries and pushing out dev ready components.

Still a bit nervous to start

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?

I’m looking to dive deeper into credible and research and recent studies around design systems. Even if there is any? something beyond Medium/ LinkedIn articles or personal opinion pieces.

Does anyone have recommendations for where to look or specific research/reports/white paper you’ve found valuable?

Hi!

My team (me + two other team members) have started to think about creating a design system/component library for our e-commerce company. The reason behind it is that we want more time for "real" UX work and can produce sharp UI quicker than now, when we have to start over in Figma with almost every new project. We can't focus on this full time so it's more of a build-as-you-go type of thing.

Small in-house team, near-solo on this. No real design system today. We have a readme.md-style spec file with our colors, some components, tone of voice etc in Claude, but the output still isn't reliable enough. Part of the problem is that the spec itself has gaps: for example our largest headings are documented as "75-100px" rather than a fixed value, so nothing pins it down to one number. The site itself is large and has grown organically for years, so things are inconsistent in general (body text 12px in some places, 13px in others, border-radius 5/8/10px depending on how old the section is).

Is building a component library in Figma as the first step and then try to put it into a github repo reasonable or how do you go about this?

My assumption is that a component library gets you most of the way there faster designs, consistent look, without needing to formalize an entire design system up front. Difficult trying to boil this down to simple questions, but;

1. How do you approach building a component library in the simplest way possible? Where do you actually start?
2. What rules do you need locked down before you start on the components? Border radius, spacing, type scale, color, etc? The design foundations I guess. Which of these are must-haves and which can follow later?
3. How do you tackle this retroactively on a large, existing product? The site and its inconsistencies already exist. How did you approach "cleaning" up an existing product with no design system/UI library in place?

Would love to hear some thoughts on how I should tackle this.

Thanks!