SaaS software: when to upgrade to a design system
Standards and design systems are not the same, and mixing up these two concepts can incur costs in two different ways.
Upgrade to a design system when multiple designers and developers are interacting with the interface and it has started to stabilize. If the product is still pivoting frequently, create light guidelines along with a basic Figma library first, and build a complete design system after the interface is finalized. It is a waste for a small team or one still searching for product direction to create an extensive design system, as the entire system will become outdated before it can be used.
- many teams with a stable product need a complete design system
- has external partners and developers needing a public gateway
- A small team or an undecided interface needs a standard template along with basic Figma.
- startups with an interface that changes every month should not establish a design system
- Deliver a PDF to a large team of designers, each reconstructing it, then it gets lost.
Standards and design systems are not two names for the same thing. Confusion in either direction can be costly: creating a massive design system too early means it will be outdated by the time it's finished, while sticking to PDF standards when the team grows leads to inconsistent products as each person creates their own style. Sinh Vũ created this page to help you determine the right level 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, applied 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
Upgrade to a full design system: multiple teams working on a stable product, releasing features on a regular cycle, need a shared component library and tokens for everyone to pull and use instead of building their own. Add a public portal if there are partners or third-party developers who need to access the standards.
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 boundaries of handover are clear: Sinh Vũ establishes brand rules, a component library, and delivers Figma source files. Operating the token pipeline (the process of converting design values into code) and integration into your codebase is part of your technical team. These two parts need to collaborate from the beginning, not just wait until the handover to discuss.
Decision checklist
Topic: SaaS software: when to upgrade to a design system. Sinh Vũ Handbook, sinhvu.com
Tick each item that applies or that you can already answer, then print or save as PDF to take with you.
If you have marked most of the signs above, this is the time to discuss in more detail. Sinh Vũ can help you review and propose a direction.
References
UserQ, Design systems vs brand guidelines. Salesforce Ben, Welcome to Salesforce Lightning Design System. Sinh Vũ, B2B software case with a Figma library of over eighty components.
Frequently asked questions
What is the difference between brand guidelines and the design system?
Brand guidelines specify how the product looks: color, typography, logo, tone of voice. The design system explains how to implement it at scale: tokens, reusable components, programming guidelines, and synchronization processes among teams. A software product needs both, but the order and level of investment depend on the stage and size of the team.
Does a small software startup need a design system?
Not necessary if the team still has one or two designers and the product hasn't found a stable direction. At this stage, creating a light standard and a Figma library with commonly used components is sufficient. Build a complete design system when the team grows larger, the interface is finalized, and the costs of rebuilding from scratch become evident.
Up to what point does Sinh Vũ deliver, and who takes care of the rest?
Sinh Vũ establishes brand rules, a component library, and delivers Figma source files. The operation of the token pipeline (the process of converting design values into code) and integration into your codebase is the responsibility of your technical team. Sinh Vũ can collaborate with your technical team to ensure proper handover, but will not operate the code system in the long term.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.