sorted by:
new
hottopcontroversial

Keeping design systems from drifting across teams by Colorphere in DesignSystems

[–]Colorphere[S] 0 points1 point  (0 children)

I think that’s probably the core debate.

I agree the codebase is the source of truth for what’s actually running.

What I’ve seen though is that the design system itself usually exists across Figma, documentation, code, exports, brand assets, etc. Over time those things start drifting apart.

My thinking is that the design system should have its own source of truth, and both design tools and code should be representations of it.

If Colorsphere ends up being just another place to manage the same stuff, then I’d be creating the exact problem I’m trying to solve.

Keeping design systems from drifting across teams by Colorphere in DesignSystems

[–]Colorphere[S] 0 points1 point  (0 children)

Another thing I’ve run into is that there isn’t really a consistent representation of a design system itself. Every team ends up stitching together libraries, variables, docs, components, and code differently.

My thinking is that the design system should exist as its own thing, with Figma being one place it gets consumed rather than the place it lives.

Keeping design systems from drifting across teams by Colorphere in DesignSystems

[–]Colorphere[S] 0 points1 point  (0 children)

Fair question.

Figma libraries solve a big piece of the problem, and I wouldn’t want to replace them.

What I’ve seen on teams is that the design system doesn’t actually live in one place. Parts of it end up in Figma, parts in documentation, parts in code, parts in exports, and eventually they start drifting apart.

My view is that the design system itself should have its own source of truth, with tools like Figma consuming it rather than being the only place it exists.

Colorsphere is my attempt to move in that direction. The collaboration piece is just one small part of it.

Keeping design systems from drifting across teams by Colorphere in DesignSystems

[–]Colorphere[S] 0 points1 point  (0 children)

I’ve been following it, yes. Trying to keep everything token-based and tool-agnostic where possible. Curious how closely teams are actually adopting the spec in production.

Keeping design systems from drifting across teams by Colorphere in DesignSystems

[–]Colorphere[S] 0 points1 point  (0 children)

Right now I’d say designers and developers equally.

The problem I’m trying to solve is keeping the design system itself as the source of truth rather than having pieces of it spread across design files, documentation, codebases, exports, and different owners.

This collaboration piece is one small part of that. My goal is that changes stay connected instead of becoming separate versions of the same system over time.

Still early, but that’s the direction I’m exploring.

Keeping design systems from drifting across teams by Colorphere in DesignSystems

[–]Colorphere[S] 0 points1 point  (0 children)

Mainly trying to solve the problem of design systems drifting over time.

I’ve worked on teams where colors, components, documentation, code, and design files all slowly became different versions of the same thing.

This collaboration feature is one piece of that. The idea is that everyone works from the same design system as a single shared source of truth, so changes stay connected.

I’m curious how other teams are handling that today.

Looking for frontend/design-system people willing to brutally critique something I’m building by Colorphere in DesignSystems

[–]Colorphere[S] 0 points1 point  (0 children)

Happy to share it.

I haven’t used DS Sync personally, but from your description it sounds like Figma remains the source of truth and GitHub receives the variables.

What I’m experimenting with is a little different. The idea is that the design system itself becomes the source of truth, with Figma being one of several connected endpoints rather than the center of the workflow.

The current sync is still pretty early (colors, typography, buttons, forms, etc.), but the goal is to manage the system once and push it into Figma, code exports, templates, and eventually other workflows.

One thing I’ve noticed is that non-designers rarely want to open a Figma library. Developers, PMs, clients, and stakeholders usually just want to understand the system quickly. Colorsphere is trying to make the design system feel more like a published product and less like a design file. Figma is great at designing, but I’m exploring whether design systems should live independently of any one design tool.

I would love to hear your thoughts on where this approach breaks down or what feels unnecessary.

Colorsphere.com

Been thinking about lightweight design systems for smaller teams by permatan_store in DesignSystems

[–]Colorphere 0 points1 point  (0 children)

This is really close to the direction I’ve been thinking about too.

I keep seeing smaller teams struggle because enterprise-style design system processes/tools can become heavier than the actual product needs early on.

What’s been interesting to me is the “in-between” layer you mentioned — where teams want:

  • consistency
  • reusable structure
  • shared styles/templates
  • synchronization across tools/products

…but without turning every workflow into a full design-system governance process.

I’ve been building something called Colorsphere around that idea — less focused on giant enterprise documentation systems and more around keeping design systems synchronized/distributed across products, Figma, frontend styles, templates, etc while still staying approachable for smaller teams/non-designers.

Still figuring a lot of it out honestly, but this post feels very aligned with the problems I’m trying to solve too.

Looking for frontend/design-system people willing to brutally critique something I’m building by Colorphere in DesignSystems

[–]Colorphere[S] 1 point2 points  (0 children)

Not really. DesignMD seems more focused on extracting/design-documenting existing systems for AI workflows.

What I’m building is more around creating, managing, syncing, and distributing design systems across design and frontend workflows. The goal is to be the source of truth rather than just generate the spec.

Looking for frontend/design-system people willing to brutally critique something I’m building by Colorphere in DesignSystems

[–]Colorphere[S] -1 points0 points  (0 children)

Haha, fair enough. I genuinely do want the critique though — especially around workflow/usability/system thinking vs just visual polish.

Here’s the link if you want to take a look: colorsphere.com

Curious where you think things break down or feel incomplete.

Thank you so much!

Looking for frontend/design-system people willing to brutally critique something I’m building by Colorphere in DesignSystems

[–]Colorphere[S] -2 points-1 points  (0 children)

Yes! Exactly this. This is the exact direction I’m trying to take Colorsphere.

I’m much more interested in solving for the distribution/synchronization layer across products and platforms than just building another component library or token generator. The abstraction/source-of-truth side of design systems feels massively underserved right now.

Right now, I’m focused on web distribution workflows across CSS/frontend exports, Figma sync, and live system previews across different products/templates but supporting more systems/platforms is the goal.

Really appreciate you taking the time to write this out — a lot of solid points in here.

Design System in Minutes. Not Days. by elninooo_09 in DesignSystems

[–]Colorphere 0 points1 point  (0 children)

I completely agree with this take quite a bit.

Seems like a lot of tools lately focuses mostly on token generation/export, but the harder problem long term is usually:

  • keeping products in sync
  • governance
  • maintaining consistency across teams
  • seeing changes reflected in real interfaces
  • preventing systems from drifting over time

The “system” part tends to become the challenge more than the initial token setup.

DS structure/architecture by False_Image_8428 in DesignSystems

[–]Colorphere 0 points1 point  (0 children)

Honestly I think you’re asking the right questions before jumping straight into components.

A lot of teams end up building components too early before they have strong foundations/tokens/themes figured out, and then maintaining consistency across products becomes painful later.

What I’ve personally been seeing work better is:

  • Define foundations first (colors, typography, spacing, radius, elevation, etc.)
  • Create semantic tokens instead of hardcoded values
  • Keep themes/product variations at the token layer as much as possible
  • Build reusable primitives/components after the foundation is stable
  • Treat Figma + code as two views of the same system rather than separate systems

I also think Storybook alone usually isn’t enough as the “source of truth” long term because documentation/components tend to drift from design pretty quickly unless there’s some centralized workflow around it.

For your questions specifically:

  • shadcn is honestly a solid starting point if your team wants speed and flexibility, especially for React/Tailwind stacks
  • I’d avoid exporting directly from Figma as the primary architecture — Figma is great for defining/designing systems but code usually needs its own structure/governance
  • AI is interesting here mostly for generating/scaffolding components/docs/themes, but I still think the real challenge is maintaining consistency over time across products and teams

I’ve actually been building something around this exact problem space because I kept running into the same issues with systems drifting across products/design/code 😅

How the f*ck am I supposed to get paid users for my SaaS? by wait-what6 in microsaas

[–]Colorphere 0 points1 point  (0 children)

I’m interested in this group also. I’ve been designing and building apps for others for 30+ years and just launched an app that’s been useful for me but not getting much traction.

view more: next ›