A StyleX design system that makes the interface easier to change correctly.
StyleX is most useful when it carries a system into the implementation: named tokens, scoped styles, and explicit variation, with one strategy underneath every component.
Why implementation matters
A system that only lives in Figma depends on translation. Over time, that translation is where the visual language drifts. StyleX gives the system a practical place to live in the product, where decisions are composable and traceable.
When this is the right move
StyleX is worth adopting once styling has become a coordination problem rather than a styling problem. Many teams, one surface. Styles composed by people who did not write them. A codebase where the cost of a stray override is paid by somebody else, later.
The signal is usually a review comment rather than a bug. Somebody asks why this one card sets its own padding, and the honest answer is that there was nowhere else to put it.
It is not the right move on its own. StyleX is a way of writing styles, not a set of decisions, and a codebase can be fully migrated and no more coherent than it was. The value arrives when the tokens, primitives, and variants underneath it carry a system that was decided first.
It is also the wrong move in the middle of a migration on a deadline. Changing how styles are authored while the foundations are still moving leaves two unfinished things at once, and neither of them can be judged.
The work
Nordlean helps set up the layers that make StyleX valuable in a real application.
- Tokens with stable semantic roles
- Primitives with clear responsibilities
- Variants that reflect real product state
- Patterns for composition, responsiveness, and accessibility
How the work runs
The layers go in from the bottom, and each one is proved on live product work before the next is started.
- Foundations first: primitive values, then the semantic roles that reference them
- Primitives next: the small set of elements everything else is built from, each with one responsibility
- Variants after that, derived from product states rather than from a list of visual options
- Composition rules last: how styles merge, what a consumer may override, and what is closed
- One active feature migrated end to end, then the naming and the scale adjusted before wider rollout
Working in that order keeps the system honest. A layer that only works in isolation fails on contact with a real screen, and finding that out in the first feature is far cheaper than finding it out in the fortieth.
What we need from you
A codebase we can read, and one feature team willing to go first.
- The front-end code and its current styling approach, including whatever it is being migrated away from
- The design foundations, in whatever form they exist
- A real, active area of the product to use as the first migration
- An engineer who will keep using the system after we hand it over
The last one matters most. A system without an owner is a snapshot of somebody’s preferences, and the first feature cycle after handover shows which of the two it turned out to be.
The objective
The objective is to reduce the number of decisions a feature team rediscovers, while keeping enough flexibility for the product to stay alive.
Questions
Why implement the system in StyleX rather than only in Figma?
A system that only lives in Figma depends on translation, and over time that translation is where the visual language drifts. StyleX gives the system a practical place to live in the product, where decisions are composable and traceable.
What layers does the work cover?
Tokens with stable semantic roles, primitives with clear responsibilities, variants that reflect real product state, and patterns for composition, responsiveness, and accessibility.
Is adopting StyleX enough on its own?
No. StyleX is a way of writing styles, not a set of decisions. A codebase can be fully migrated and no more coherent than it was. The value arrives when the tokens, primitives, and variants underneath it carry a system that was decided first.
How do we know the system is working?
A feature team rediscovers fewer decisions while the product keeps enough flexibility to stay alive. Each layer is proved on live product work before the next one is started.
Related guides
Make the next part of the product easier to build.
Bring the thing your team is repeatedly working around. We will work out whether a system intervention is the right move.
Let's chat ↗