SaaS software: when to upgrade to a design system

Standards and design systems are not two names for the same thing. Confusion in either direction can be costly: creating a comprehensive design system too early may result in it becoming outdated by the time it's completed, while sticking to a PDF standard when the team has grown can lead to each person creating their own version, resulting in a lack of consistency. Sinh Vũ has written this page to help you accurately determine the level appropriate for your current stage.

Two different concepts need to be distinguished first

Brand guidelines answer the question: what does your product look like? Primary colors, typography, logo, image principles, writing tone. This is the identity layer, applicable to all touchpoints from the website to sales documents.

A design system answers a different question: how do multiple teams create a consistent interface at scale, across all pages and screen sizes, without starting over each time? The design system includes tokens (design values as variables, such as colors, spacing, font sizes), a reusable component library, programming guidelines, and inter-team synchronization processes.

All software products need standards. Not every team needs a complete design system from the start.

Factors to consider before upgrading

• Number of people working on the interface: One to two designers with a basic Figma library is sufficient for control. When this number increases and includes developers creating components, individual libraries can no longer maintain consistency.
• Interface stability level: If the product has not found product-market fit, the design system will always be misaligned because the interface changes continuously. Build when the interface has started to solidify, not before.
• Rebuilding costs: When each team creates buttons, forms, and error messages in their own way, rebuilding costs accumulate with each sprint (development cycle). A shared component library cuts these costs.
• Is there a maintenance team afterwards: the design system needs operators: updating tokens when the brand changes, adding new components, synchronizing between Figma files and code. Without someone to maintain it, the design system will become a static document that gets overlooked.
• Are there partners or third-party developers: when needing to open an API (application programming interface) or module for partner integration, a public portal with the right standards helps external parties build correctly from the start instead of having to fix it later.

When to choose which direction

Establishing a design system when the interface is just starting to stabilize, not before. If the product hasn't found product-market fit, the design system will always be misaligned.

UserQ, Design systems vs brand guidelines

Common mistakes

• Startups build extensive design systems too early. Interfaces change every month, making the design system outdated before the team can use it. The result: wasted time building and additional time discarding.
• A large team still only uses PDF. Each designer translates standards according to their own understanding. After a few months, the interface drifts away from the standard, and no one notices because each part seems correct when viewed in isolation.
• Viewing the token library as sufficient. Tokens address numerical values (color, spacing), but cannot replace the process: who decides to add new components, who approves changes, how the technical team synchronizes code. Without a process, the library will branch out according to each team.

The viewpoint of Sinh Vũ

Sinh Vũ has worked with B2B software companies, providing a Figma library of over eighty components for multiple designers to apply consistently. The lesson learned is that the right level depends on how the client team operates in practice, not on long-term ambitions.

Sinh Vũ finalizes the level based on this principle: a large team and stable products allow for a full library with tokens and reusable components. A small team or one still pivoting should create a concise version first, avoiding the establishment of a system that the team is not yet ready to operate.

The delivery boundary is also clear: Sinh Vũ establishes brand guidelines, a component library, and delivers the Figma source files. Operating the token pipeline (the process of converting design value into code) and integrating it into the codebase is part of your technical team's responsibility. These two parts need to coordinate from the beginning, not wait until delivery to discuss.