Building a Design System Small Enough to Finish

A lot of design systems fail before they become useful. The designer starts with a giant colour library, dozens of text styles, every possible button state, complex naming conventions, and a component inventory that looks impressive in a presentation. Three weeks later, nobody wants to maintain it.

The problem is not that design systems are too difficult. It is that small products are often given systems designed for much larger products.

If you work on websites, SaaS products, mobile apps, dashboards, or client projects, you usually need something much smaller. Start with the visual decisions that repeat. Add components when the second screen proves you need them. Turn repeated decisions into tokens. Document only the rules people actually need.

This approach produces a design system that can be built quickly, used immediately, and expanded when the product gives you a reason to expand it.

Start With the Decisions That Repeat

A design system becomes useful when it removes repeated decisions from everyday design work. It does not need to contain every possible UI pattern on day one.

If your first screen uses six colours, four font sizes, three spacing values, and one button, there is no reason to create 40 components. Start by capturing the decisions you know will repeat.

Build the foundation before the component library

The first layer should usually contain colour, typography, spacing, radius, and perhaps a few basic effects.

Figma describes design tokens as named values that store design decisions, while variables can be used to implement those values in a Figma design system. Figma also distinguishes primitive tokens from semantic and component-specific layers.

For a small product, you might begin with something like:

Foundation	Small starting set
Brand colours	3 to 5
Neutral colours	5 to 8
Font families	1 to 2
Font weights	3 to 4
Text sizes	5 to 7
Spacing	6 to 8 values
Radius	3 to 4 values
Shadows	2 to 3

These are not rules. They are a starting point.

The important part is resisting the urge to invent values simply to fill the system.

If your product never uses a 72px spacing value, do not create space-72 because another design system has one.

A token earns its place when it represents a decision you expect to reuse.

Use semantic names when the value has a role

There is a big difference between naming a colour blue-600 and naming it text-primary.

blue-600 describes what the value is.

text-primary describes what the value does.

That distinction becomes useful when the interface changes.

Imagine your current brand uses blue as the primary action colour. Six months later, the brand colour changes to green.

If buttons, links, icons and text all point directly to blue-600, you have to figure out where that colour was used.

If the interface uses semantic variables such as:

• text-primary
• surface-primary
• action-primary
• border-default
• text-muted

the role stays stable while the underlying value can change.

Figma’s current design token guidance also describes semantic tokens as the layer that gives raw values contextual meaning.

For a small system, you do not need a complicated three-level token architecture. A small primitive layer plus a useful semantic layer is often enough.

Keep spacing boring on purpose

Spacing is one of the easiest places to create unnecessary complexity.

A designer may use 13px here, 18px there, 22px somewhere else, then create a token for each number.

That is not a system. It is a record of previous decisions.

Start with a small spacing scale, such as:

4 / 8 / 12 / 16 / 24 / 32 / 48 / 64

Then try to design within it.

If a screen genuinely needs 20px, ask why.

Sometimes 20px is correct. Sometimes the design is compensating for a component that has not been structured properly.

The purpose of a spacing scale is not to prevent designers from ever using another number. It is to reduce arbitrary choices.

Add Components Only When Repetition Proves They Are Needed

The second screen is one of the best tests for whether something should become a component.

The first time you design a button, you are solving a design problem.

The second time, you are starting to see a pattern.

The fifth time, you probably have a reusable component.

Use the second-screen rule

Here is a simple rule:

Do not build a reusable component because you think you might need it. Build it when repetition creates a real cost.

Suppose Screen 1 contains:

• Primary button
• Secondary button
• Search field
• Card
• Status badge

Do not immediately build an entire component library.

Design Screen 2.

Now ask:

• Did the button appear again?
• Did the input need the same states?
• Did the card repeat?
• Did the badge use the same visual treatment?
• Did spacing decisions repeat?

Anything that appears again becomes a candidate for systemisation.

This creates a system based on evidence rather than prediction.

Figma’s own design-system guidance describes components as reusable building blocks and libraries as a way to share reusable components, styles, and variables.

Do not turn every visual object into a component

This is where many Figma files become painful.

A designer creates components for:

• Decorative shapes
• Individual headings
• Every icon
• One-off cards
• Unique illustrations
• Single-use layouts
• Sections that will never repeat

The file looks organised but becomes harder to work with.

A component should solve a recurring problem.

A useful test is:

Will changing this component in one place improve at least two or three places elsewhere?

If the answer is no, keep it as ordinary design content unless there is another clear reason to make it reusable.

Component complexity should match actual variation

Another common mistake is creating a component with every imaginable variant.

A button might become:

Type × Size × State × Icon × Width × Theme × Emphasis

Suddenly a simple button has dozens of combinations.

The designer has created a mini application instead of a useful component.

Start with actual needs.

For example:

Button

• Primary
• Secondary
• Disabled
• Small
• Medium

Add destructive, loading, icon-only, large, compact or other variants when the product actually requires them.

This is especially important for small teams. Every variant creates a maintenance responsibility.

Keep Tokens and Components Connected

A small design system becomes much more useful when its components consume the same underlying values as the rest of the product.

This is where variables become practical rather than theoretical.

Connect components to semantic tokens

Consider a primary button.

Instead of manually choosing:

• Background: #4F46E5
• Text: #FFFFFF
• Radius: 8
• Horizontal padding: 16
• Vertical padding: 10

the component can reference the system’s decisions.

For example:

• Background: action-primary
• Text: text-on-primary
• Radius: radius-md
• Horizontal padding: space-16
• Vertical padding: space-8

Now the component is not simply reusable. It is connected to the logic of the design system.

Figma’s variables can store reusable values and support modes, which can be useful for themes such as light and dark interfaces.

Avoid building component-specific tokens too early

There is a temptation to create a token for everything:

button-primary-background-default

button-primary-background-hover

button-primary-background-pressed

button-primary-background-disabled

That level of specificity can be useful in large systems, but it may be unnecessary in a small product.

Figma’s documentation specifically notes that component-specific token structures are more commonly associated with larger, enterprise-level systems and may not be necessary for everyone.

For a smaller system, you might start with:

action-primary

surface-disabled

text-primary

text-disabled

Then introduce component-specific tokens when the product actually develops exceptions.

Let the product create the complexity

Imagine your product starts with one brand theme.

Six months later, the client asks for:

• Dark mode
• Partner branding
• A second product
• A mobile app
• A white-label version

Now a more sophisticated token structure may make sense.

Do not build all of that on day one.

The purpose of a small design system is not to predict every future requirement. It is to make today’s repeated decisions easier while leaving enough structure to grow.

Create a Design System That Designers Will Actually Use

A design system can be technically correct and still fail.

The real test is whether someone designing a new screen chooses the system instead of working around it.

That means usability matters inside the design system itself.

Name things so another designer understands them

Bad naming creates friction.

Imagine a library containing:

• Button 1
• Button 2
• Button New
• Button Final
• Button Final 2
• CTA Blue
• CTA Green

You may understand the history. A new designer does not.

Use names based on role and purpose.

For example:

• Button / Primary
• Button / Secondary
• Button / Destructive
• Input / Default
• Input / Error
• Badge / Success
• Badge / Warning

The exact naming convention matters less than consistency.

Figma’s current guidance recommends clear naming conventions and full words rather than unclear abbreviations when naming variables and styles.

Document usage, not obvious appearance

A button component does not need a 700-word explanation of what a button is.

Document the decisions that are not obvious.

For example:

Primary button

Use for the main action on a screen.

Secondary button

Use for supporting actions when a primary action already exists.

Destructive button

Use for actions that delete, remove, cancel, or cause an irreversible change.

Do not use

Do not place three primary buttons beside each other.

That documentation is valuable because it explains behaviour and hierarchy, not just appearance.

Figma’s design-system curriculum also treats documentation, feedback, testing, contribution, and updates as part of maintaining a system rather than as separate activities.

Make the library easier to use than starting from scratch

This is the simplest adoption test.

Open a new screen and ask:

Can I find what I need in under a minute?

If the answer is no, the system has an information architecture problem.

A small library might have:

Foundations

• Colours
• Typography
• Spacing
• Radius
• Effects

Components

• Buttons
• Inputs
• Select
• Checkbox
• Badge
• Card
• Modal

Patterns

• Header
• Form layout
• Empty state
• Search results

That is enough for many small projects.

Do not create 25 categories because the system looks more professional that way.

Know When Your Small System Is Finished

This is probably the hardest part.

Designers often keep adding things because there is always another component they could create.

A system needs a stopping point.

Define “done” by coverage, not size

A small design system is ready when it covers the repeated decisions required by the product.

It does not need:

• Every possible form control
• Every possible notification
• Every responsive breakpoint
• Every future feature
• Every component found in Material Design
• Every state imaginable

Instead, ask:

Can I design the next three screens without repeatedly inventing the same visual rules?

If yes, your system may already be large enough.

Use a simple completion checklist

Your first version can be considered usable when:

• Core colours are defined
• Semantic colour roles are defined
• Typography hierarchy is consistent
• Spacing follows a repeatable scale
• Radius values are controlled
• Common components have clear names
• Components cover repeated UI
• Common states are defined
• Components use the system’s tokens
• Usage guidance exists for non-obvious decisions
• The library is easy to find and use

That is a much better definition of “finished” than reaching a specific number of components.

Expect the system to change when the product changes

A design system is not a museum.

If a new feature introduces a new interaction pattern, the correct response is not automatically to force it into an existing component.

Ask:

Is this genuinely a new pattern, or is the existing component missing a necessary variation?

If the same new pattern appears repeatedly, promote it into the system.

If it happens once, leave it local.

This keeps the system connected to actual product development.

FAQs

How small can a design system be?

A design system can be surprisingly small. For an early product or small website, it may begin with colour, typography, spacing, radius, a few reusable components, and basic usage rules. The right size depends on how much repeated UI the product actually has.

Should I create a design system before designing the product?

Usually, you do not need to build a complete system first. Establish a small foundation before or during the first screens, then let repeated design decisions reveal which components deserve to become reusable.

What should be included in a small design system?

Start with colour, typography, spacing, radius, and common UI components. Add states, patterns, icons, accessibility rules, and more advanced token structures when the product actually requires them.

When should a Figma element become a component?

A good practical trigger is repetition. If the same UI element appears on a second or third screen and needs to stay consistent, it becomes a strong candidate for a component. Other reasons, such as complex interaction states or the need for controlled reuse, can also justify componentisation.

Do small design systems need design tokens?

They can benefit from tokens, particularly for repeated colours, typography, spacing, and other foundational values. Figma currently supports variables as a way to implement reusable design values and design tokens.

How do I stop a design system from becoming too complicated?

Only add something when it solves a repeated problem. Avoid speculative components, unnecessary variants, excessive token layers, and documentation that nobody needs. Review the system against current product usage rather than trying to predict every future requirement.

Conclusion

A useful design system is not the one with the largest component library. It is the one that removes enough repeated decisions to make the next screen easier to design.

Start with colour, type, spacing, radius, and other foundations that genuinely repeat. Design the first screen. Build the second. Look for repetition. Turn the repeated pieces into components. Connect those components to your tokens. Add documentation only where another designer needs guidance.

This approach works particularly well for startups, small product teams, agencies, client websites, MVPs, and designers working alone. It is less suitable when you already have many products, platforms, brands, or large teams with complex governance requirements. Those environments may eventually need deeper token structures, contribution processes, accessibility standards, code integration, versioning, and dedicated system ownership.

For a small product, though, restraint is a feature.

A system you can finish, understand, and actually use is more valuable than a huge library nobody wants to maintain.