Flux Design System

A design system is not a UI kit. It is a shared language for making product decisions.

Flux is a design system created for Rentesy to bring visual consistency, reusable patterns, and a more systematic way of designing product experiences. The work spans foundational tokens, layout rules, typography, color, elevation, icons, components, variants, states, documentation, and usage guidance.

The case study is intentionally structured around systems thinking rather than a gallery of screens: what problem the system solves, how the parts relate, what trade-offs were made, and how the system can remain useful as the product grows.

Honest framing

Quantitative project metrics — adoption rate, engineering hours saved, defect reduction — were not provided in the source material. They are deliberately not invented here; a measurement plan is included instead.

As a product grows, inconsistency rarely comes from a lack of design skill. It usually comes from many reasonable decisions being made independently.

A button can slowly acquire different heights, radii, colors, icon rules, and states. Inputs can diverge between flows. Spacing becomes a collection of one-off values. Designers recreate components instead of reusing them. Developers translate visual decisions differently across surfaces.

The underlying problem is therefore bigger than visual inconsistency:

• Design decisions become duplicated.
• Patterns become difficult to discover.
• Small differences accumulate into a fragmented experience.
• Handoff requires more interpretation.
• New screens take longer to build consistently.
• The system becomes harder to evolve because its rules are implicit.

Flux addresses this by turning recurring decisions into explicit, reusable system rules.

The opportunity was to move Rentesy’s product design from:

Individual screens → reusable patterns → shared rules → scalable product language

Instead of treating every interface as a new composition, Flux establishes a hierarchy:

This structure makes the system useful at two levels:

1. Abstract — designers can reason about tokens, patterns, and constraints.
2. Concrete — teams can assemble real product experiences from validated components.

Consistency does not mean everything looks identical. A good design system creates controlled variation.

Flux uses atomic design as a mental model for organizing complexity:

Tokens: separating decision from implementation

Tokens represent the smallest reusable design decisions — colors, typography, spacing, radius, shadows. They are valuable because they separate the decision from the implementation:

A button should not need to know that its primary color is a particular blue value. It should consume a meaningful system value.

Atoms are the smallest meaningful UI elements (icons, buttons, inputs, checkboxes). Molecules combine atoms into functional groups — input + button becomes a search control; icon + label becomes a navigation item. The key principle is composition instead of duplication. Organisms combine molecules into interface structures like product cards, order forms, and navigation. Templates answer “where do the pieces go?”, and pages answer “what does this structure look like with real content, data, and imagery?”

Why the hierarchy matters

It prevents a common failure mode: jumping directly from a screenshot to a component without understanding the system underneath it.

Typography as a scale

Typography is one of the most visible system decisions — it affects hierarchy, density, readability, and perceived brand quality. The system includes weights from thin through black, multiple text sizes, and a reusable hierarchy:

Without a type scale, every screen can slowly invent its own hierarchy. With one, designers choose from a known vocabulary.

Trade-off

A constrained type scale can feel less expressive than designing every headline independently. That is intentional — the system gives up some local freedom in exchange for global coherence.

Spacing: rhythm over arbitrary values

Flux uses an incremental spacing system based primarily on 4px increments. Instead of 17px, 23px, 31px, the system encourages designers to think in reusable increments. Spacing is one of the easiest areas for inconsistency to hide — cards with different internal padding, unrelated section gaps, misaligned controls — and a tokenized scale makes those decisions deliberate.

Radius: a small vocabulary

Radius should communicate component family and hierarchy, not become decoration.

A shared radius vocabulary helps buttons feel related to inputs, cards to other containers, and prevents designers from accumulating one-off corner values. More tokens create flexibility — but too many options increase decision fatigue.

Primitive vs. semantic thinking

The color system organizes ten palettes — primary, gray, red, orange, yellow, green, teal, indigo, purple, pink — into numbered levels, creating a predictable scale from lighter to darker. A mature system distinguishes primitive tokens (raw palette values like blue-500, gray-700) from semantic tokens (meaningful roles like text-primary, surface-default, action-primary, status-error).

This separation allows the same semantic role to change without requiring every component to understand the underlying palette — and it is what makes light and dark themes possible:

Trade-off

A tokenized color architecture adds abstraction. For a tiny product that can feel like overhead — for a growing product, the abstraction pays for itself because a color decision can propagate consistently across many components.

Responsive grids: a layout contract

The important part is not the number of columns — it is that the system explains how content should behave as viewport width changes. A fixed grid vocabulary improves alignment, responsive composition, implementation consistency, design review, and handoff.

Elevation: shadow as a system

Shadow is treated as a system rather than an ad-hoc visual effect. Documented levels — shadow-sm through shadow-2xl — each correspond to a different combination of x/y position, blur, spread, and opacity. A component floating above a surface should not require a designer to invent a new shadow every time; a small vocabulary creates a consistent visual depth model.

Trade-off

The system sacrifices some ability to create unique atmospheric effects. That is appropriate — elevation should communicate meaning, not simply add visual polish.

Icons: a typography-like vocabulary

Flux includes solid and line icon families, along with social and flag groups. Icons are treated as part of the interface’s typography-like vocabulary — they need consistent stroke/weight, bounding box, visual density, alignment, and optical sizing.

Trade-off

Supporting both solid and line styles increases flexibility but also the risk of mixing styles inconsistently. The presence of an icon does not automatically mean every icon style is interchangeable.

Buttons are a good example of how Flux moves from a visual element to a configurable system. Instead of creating separate components — PrimaryButton, SecondaryButton, SmallPrimaryButton, IconButton, PrimaryButtonWithLeftIcon — the system models the button as a single component with controlled properties:

The button system documents four sizes (large, base, small, extra-small), three styles (filled, outlined, alternative), interaction states (default, hover, focus), content options (text, icon-only, left icon, right icon), and multiple semantic color families with their corresponding states.

Usage guidance: behavior, not only dimensions

• Use one primary action when appropriate
• Use secondary/alternative actions for lower-priority choices
• Avoid presenting multiple competing primary actions

A design system should document behavior and intent, not only dimensions.

Trade-off

Too few variants → designers create hacks and overrides. Too many variants → the component becomes difficult to understand. Flux sits in the middle by exposing properties that correspond to meaningful design decisions.

Text fields demonstrate the same system thinking. The component supports label, input control, helper text, left/right icons, placeholder, multiple sizes, light/dark behavior — and the full documented state set:

Trade-off

More states mean more design and implementation effort. But omitting states simply pushes that work downstream, where it is more expensive and more likely to become inconsistent.

Form principle

Help users understand what an input requires instead of relying only on placeholder text.

The system distinguishes supporting/helper information from the placeholder itself — supporting better accessibility, clearer validation, easier scanning, and more robust form behavior. A design system moving beyond aesthetics into interaction quality.

The component library is where the system becomes operational. The source material presents 60+ components and variants — a breadth that matters because a design system becomes valuable when it solves recurring product problems, not only when it defines visual foundations.

This gives Flux a practical role in the product lifecycle: designers can compose interfaces from established patterns instead of repeatedly solving the same interaction problems.

One of the most important decisions in Flux is that documentation is part of the system itself. A component is not complete simply because it exists in Figma. A useful component needs:

1. An API
2. Visual examples
3. States
4. Variants
5. Usage guidance
6. Constraints
7. Implementation intent

Documentation changes from a reference archive into a decision-making tool.

The system’s decision hierarchy

A useful way to understand Flux is as a chain of responsibility:

The diagnostic question

When something feels wrong, the team can ask: at which layer does the problem belong? Wrong blue → token problem. Inconsistent padding → spacing problem. Wrong button state → component problem. Confusing action hierarchy → pattern problem.

A compelling design-system case study should not pretend every decision was universally correct. The value is in understanding what was optimized for and what was deliberately sacrificed.

Three levels the system operates at

Accessibility as a system property

The visual material does not provide a complete accessibility audit, so accessibility outcomes should not be claimed as completed. But Flux creates a strong foundation for an accessibility layer. Future validation should explicitly cover:

A mature design system should treat accessibility as a system property, not a screen-by-screen checklist.

Engineering readiness

The strongest next step is mapping design tokens directly to implementation tokens, so the design file and product code describe the same system:

Without governance, a design system tends to decay. A lightweight Flux governance model could include contribution, review, and release:

1. Is this problem recurring?
2. Can an existing component solve it?
3. Does it require a new token?
4. Is the behavior documented?
5. Are all states defined?
6. Does it work responsively?
7. Is accessibility considered?
8. Does it increase or decrease system complexity?

Measuring success

Because the provided material contains no verified quantitative metrics, the strongest approach is to define what should be measured rather than invent results:

The most meaningful metric is not how many components exist. It is: how much product work can happen without inventing the same solution again?

If two people solve the same interface problem independently, their solutions should converge.

Not because they produce identical screens — but because they naturally reach for the same tokens, the same components, the same states, the same spacing rhythm, the same interaction patterns, and the same responsive rules. That is the real value of a design system.

The most important lesson from Flux is that a design system should be judged by the decisions it prevents teams from having to make repeatedly. The visible output is a library of colors, typography, spacing, radii, shadows, icons, components, and variants — but the real product is the invisible layer underneath.

In one sentence

Flux is best understood not as a collection of UI assets, but as an operating system for product design decisions.