SaaS design: maintain consistency across multiple screens
A multi-screen product does not fail due to a lack of features, but rather due to a lack of a common set of rules.
When a product has many screens and is expected to add more features, investing in a shared design system is the most important leverage. The design system allows each new screen to inherit the same set of rules instead of being designed from scratch, enabling users to focus on their work rather than relearning the interface. If you skip this step early on, you will have to redo everything when scaling.
- multi-screen products expected to have long-term additional features
- screens repeating the same format like data tables, forms, details
- Products serving various types of users and different rights.
- design each screen separately without a common language
- building a design system that is too cumbersome before the product is mature enough
SaaS (software as a service) and internal tools are types of products with many screens that repeat: data tables, forms, detail pages, dashboards. When the number of screens is large and continues to grow, lacking a common set of rules means each new feature will be a mismatched piece. Users start to relearn instead of working, and the development team begins to handle exceptions instead of building. That is why Sinh Vũ establishes the design system as a foundation, not just an afterthought.
What a design system is and why SaaS needs it
A design system is a common standard consisting of three layers. The first layer is the style guide, which includes rules for colors, typography, and spacing. The second layer is the component library, which includes buttons, input fields, tables, and information cards. The third layer is the pattern library, which consists of standardized layouts. Every new screen is assembled from existing blocks in the system, not designed from scratch.
According to the Nielsen Norman Group, consistency is one of the ten most important heuristics (usability evaluation principles). When everything operates the same across screens, users focus on completing tasks rather than relearning controls. With SaaS used daily, this advantage becomes even clearer over time.
Four factors to consider before designing
- Number of screens and level of repetition: If the product has many data tables, forms, and detailed pages, this is a clear signal to standardize the layout template from the start.
- Navigation structure: Multi-layered products and tasks need intentionally designed navigation, so users know where they are and where they can go.
- Role and delegation: the same feature may display differently depending on the user; administrators see more than operational staff. Design needs to account for this early on, rather than waiting for the development team to handle it alone.
- Expansion paths: where new features will fit into the current structure, whether the design system can accommodate them or if it will disrupt the overall design.
Gradually reveal: do not expose everything at once.
SaaS often has many features, and both new and experienced users need two different experiences on the same interface. The principle of progressive disclosure, according to the Nielsen Norman Group, is to reveal complexity at the right moment. This approach helps achieve higher task completion rates and reduces the learning burden compared to exposing everything at once.
In practice, this means: newcomers see the basic flow first, with advanced options behind an interactive layer. Experienced users can still access it quickly, but the screen is not overwhelmed with features from the start.
Designing each screen separately: Quick at the beginning of the project, but the more screens added, the more patchwork it becomes. Each time a feature is added, it requires resolving interface conflicts. The programming team handles exceptions more than building.
Establishing a design system early: Spending additional time in the initial phase to define tokens (reusable design units like colors, spacing, typography), components, and layout templates. From the third screen onward, each new screen can be assembled faster and with fewer errors. Suitable for products expected to expand in the long term.
Common mistakes when designing SaaS
- Do not design edge states: Empty screens when there is no data, loading, connection errors, overly long data. These states are often overlooked in design files, but users encounter them daily.
- Showcasing all features at once: New users may feel overwhelmed, leading to a high dropout rate, even if the product is actually strong.
- Overly complex design system too early: Building a complete design system while the product is still exploratory is a waste. It is essential to judge the right time to invest.
- Logically separated design: Aesthetically pleasing interface but does not consider how real data flows, requiring many adjustments during programming.
Consistency does not mean everything looks the same. It means everything operates under the same set of rules, so users don’t have to guess.
Sinh Vũ, distilled from practical experience in multi-screen SaaS design
The viewpoint of Sinh Vũ
This is an area where Sinh Vũ excels: building design systems and maintaining consistency across multiple screens. Sinh Vũ operates its own products on a tokenized design system. This allows Sinh Vũ to understand how each new screen inherits the same set of rules instead of being designed from scratch.
For your SaaS project, Sinh Vũ handles the user flow, interface design, design system, and documentation delivery. The backend development, technical permissions, and system integration are managed by the development team. Sinh Vũ closely collaborates with that team to ensure the interface and logic align, rather than designing separately and just passing files over.
If you are at the MVP stage and are unsure about the scale, Sinh Vũ can help determine the right time to invest in a design system. It's not just about building; it needs to be at the right time and the right scale.
Decision checklist
Topic: Designing SaaS and multi-screen tools. Sinh Vũ guide, 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
Nielsen Norman Group: Design Systems 101; Nielsen Norman Group: 10 Usability Heuristics (Consistency and Standards); Nielsen Norman Group: Progressive Disclosure; practical experience at Sinh Vũ Studio.
Frequently asked questions
When is a design system needed, when is it not?
It is necessary to build early when the product has many repeated screens (tables, forms, details) and also includes long-term features. If you are working on an MVP with a few exploratory screens, a full design system is not yet needed, but you should still maintain basic rules to avoid patchwork. An overly cumbersome design system before the product is mature will waste effort with little use.
What can Sinh Vũ do in the SaaS project, and what cannot be done?
Sinh Vũ handles the user flow, interface design, builds the design system, and delivers documentation to your development team. The backend development, technical permissions, and system integration are handled by your development team. Sinh Vũ closely collaborates with that team to ensure the interface and logic align, rather than designing separately and just passing files over.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.