Managing and maintaining StyleSeat’s design systems

For each component in the Figma library, pinning and auto-layout are set up correctly to allow for easy re-sizing, content updates, and swapping between instances.

Variants and properties are set up to handle responsive versions of components, as well as the ability to hide or manipulate content. These are set up to be 1:1 with the variables developers use in React.

Each component has a brief description, rules for usage if applicable, and a link to its corresponding component in Storybook for easy development.

One of the main things StyleSeat lacked when I started is a token system for managing color usage and consistency across the app. There was no formal usage for background colors, type etc.

Building the design token system in Figma is one thing, but getting development resources for something without direct tie to revenue is always a struggle. I pitched the build as a means to save development time, and easily update colors for any future rebrands, and ensuring developers use correct tokens in order to reduce color adjustments during design reviews.

A small tiger team was formed to implement and update the existing codebase, with the goal to remove all raw hex values from the app.

The tokens were defined in three stages, and then presented to the engineers for review.

Contribution is open and encouraged. New patterns start in the feature file where they're needed, then get promoted to the base library once they prove useful beyond that feature — a button with a dropdown, a chart type, or anything with a clear second use. Review happens at promotion, not creation, so experimentation stays lightweight and governance kicks in only when a shared dependency is actually being introduced. Most of the promotion work is normalization: aligning the contribution with the conventions the rest of the library already follows.

Updating shared components is the harder case — a single change can ripple across every screen that uses it, and nothing in the component file alone tells you who's affected. Chromatic makes that blast radius visible by snapshotting every render across the product. I review the visual diffs, flag what needs attention, and fix any regressions before publishing the update.

Figma has no equivalent check, and its update model makes one harder to build: publishing offers a change rather than applying it, so a design library never has one coordinated migration, it has as many as it has consuming files. The leverage is at the entry requirement instead. Pinned, auto layout, scalable, or it does not go in, which is what makes an update behave the same way in every file that eventually takes it.

Deprecated components stay in place, labelled, beside their replacement, so anyone still on one can move on their own schedule rather than finding it gone.