Does Sinh Vũ take on small projects?

Sinh Vũ serves individuals, SMBs, and enterprises. Each tier has a suitable scope and approach. Small project clients often start with a 30-minute Coffee chat (free) or a Workshop/Audit to get the right direction before investing.

Self-brief, or do you need Sinh Vũ to assist with the brief?

Both are fine. Door 01 Detailed form for you if the scope is clear. Door 02 Chat with Sinh Vũ (5 minutes, AI asks the right questions) for you if the scope is unclear and needs consultation first.

How long from brief to the first deliverable?

Sinh Vũ responds within 24 hours. Detailed proposals within 48–72 hours. The first deliverable depends on the scope, typically 2–6 weeks from contract signing and deposit receipt.

What industries does Sinh Vũ work in?

300+ projects across 16 major sectors: F&B, Cosmetics, Fashion, Real Estate, Technology and SaaS, Manufacturing, Education, Healthcare, Finance, Travel, Agriculture, B2B professional services, and other sectors.

Is there a contract and confidentiality?

Yes. Every project signs a standard service contract from Sinh Vũ Studio, including clear confidentiality (NDA) and intellectual property terms. Briefs are stored separately, accessible only to the responsible team.

When do you need to build a design system, and when do you not?

You need to establish early when the product has many repeated screens (tables, forms, details) and includes long-term features. If you are working on an MVP with a few survey screens, a full design system is not necessary, but you should still maintain basic guidelines to avoid patchwork. An overly cumbersome design system before the product is mature will be labor-intensive and minimally utilized.

Designing SaaS and multi-screen tools: getting it right from the start

Quick summary

When a product has multiple 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 overlook this step early on, you will have to redo everything when scaling up.

Quick comparison

You should choose this direction when

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.

Not needed when.

design each screen separately without a common language
building a design system that is too cumbersome before the product is mature enough

Quick glance

Commonly used industries

SaaSB2B softwareinternal tools

SaaS (software as a service via browser) 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 still expanding, lacking a common language means each new feature will be a piece that doesn't fit. Users start relearning instead of working, and the programming team begins handling 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: style guide (rules for colors, typography, spacing), component library (buttons, input fields, tables, information cards), and pattern library (standardized layouts). Every new screen is assembled from existing blocks in the system, not redesigned from scratch.

According to 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. For SaaS used daily, this advantage accumulates significantly 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 new users 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 time to increase task completion rates and reduce 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.

Two common approaches:
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

No design for edge states: Empty screens (no data), loading, connection errors, overly long data; these states are often overlooked in the design file 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, so we understand how each new screen can inherit the same set of rules instead of being designed from scratch.

For your SaaS project, Sinh Vũ takes on user flow, interface design, design system, and deliverables documentation. The backend development, technical permissions, and system integration are handled by the programming team. Sinh Vũ closely collaborates with that team to ensure the interface and logic align, rather than designing separately and just passing files.

If you are at the MVP stage and unsure about the scale, Sinh Vũ can help determine the right time to invest in the design system; it’s not just about building, but about doing it at the right time and scale.

The tool brings back.

Decision checklist

Topic: Designing SaaS and multi-screen tools. Sinh Vũ guide, sinhvu.com

0 more than 6 items

Select each item you find appropriate, then print or save as PDF to take with you.

Sign indicating that you should take action

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.

Questions to answer before deciding

How many screens does your product currently have, and how far do you plan to expand in the next 12 months?
When is a design system needed, when is it not?
What can Sinh Vũ do in the SaaS project, and what cannot be done?

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ũ takes care of user flow, interface design, building the design system, and deliverables for your development team. The backend setup, technical permissions, and system integration are handled by your programming team. Sinh Vũ collaborates closely with that team to ensure the interface and logic align, rather than designing separately and just passing files.