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.

Should we set a deadline for the team to start using the design system?

You shouldn't proceed if friction hasn't been resolved. If you rush while components are still missing states and documents are hard to reference, the team will transition nominally but continue to struggle underneath, meaning you waste effort on the transition while accruing new technical debt. Prioritize making the right path easy first, then set expectations for deadlines.

How complex should the request for contributions (RFC) process be?

No need for complexity; rather, clarity is needed regarding the steps involved. At a minimum: the team should know where to send proposals, who reviews them, and how long it takes to get feedback. Missing any of these three points will lead the team to not submit and instead handle things themselves.

Why teams abandon design systems for manual work, and how to prevent it

Quick summary

The root cause is almost always friction: when following the system is more labor-intensive than creating a custom component, the team will choose to create it themselves, not out of stubbornness but because it makes sense. The way to prevent this is not to mandate compliance but to make the correct path easier than the shortcut, along with a clear contribution channel for quickly supplementing what is missing instead of being silently suppressed.

Quick comparison

You should choose this direction when

Prioritize reducing friction when teams avoid systems due to difficulty or slowness.
open contributions when the team is self-limiting components
Add hours for supervision and mentoring when a new system or team is launched.

Not needed when.

issuing a mandate to comply within a deadline without consulting the team first

Each time Sinh Vũ audits a design system that has been running for a few months, the common observation is not that the system is broken, but that it has become convoluted: Figma has one set of components, the code has another, and some teams are using both along with a self-created third set. No one is rebelling; everyone just chooses the path of least resistance.

The root cause is friction, not awareness.

When following the system (using standard components, according to design tokens) takes more steps than simply dragging a new frame and adjusting it manually, people will choose to adjust manually. This is a rational behavior, not disobedience. The team does not abandon the system out of laziness or disrespect for the effort invested in building it, but because they have a deadline and the system is blocking their path.

According to the practices compiled by the Design Systems Collective, low usage rates almost always stem from friction rather than a lack of awareness. Mandating compliance without reducing friction only shifts resistance from public to covert.

Four common sources of friction

Component lacks real states. The system only has a default state, with no error state, loading state, or empty state. When the team encounters real situations, they cannot use it, have to create additional ones, and then do not bother to look it up next time.
Hard-to-research documents. The team is unsure if the component already exists, so it's better to create it for certainty. A good search page saves more effort than ten training sessions.
No feedback channel. If the team lacks something and there’s no place to report it, they will override it on the spot. After a few months, the codebase and Figma accumulate dozens of unrecorded overrides, and the system gradually dilutes without anyone knowing when it started.
Top-down launch approach. The system is announced through a limited transition order without a support phase. The team transitions on paper but keeps a manual version as a backup, then the backup version becomes the real one.

When to prioritize which direction

Reduce friction upfront: when the team avoids the system due to slow usage or components not covering enough scenarios. What needs to be done is to add the missing states, improve search documentation, and shorten the number of steps to use a component from the start. Until this is done, expectations about usage rates should not be set.

Open parallel contributions: when the team is self-imposing restrictions without sending requests. The RFC (Request for Comments) process does not require many steps, just clarity on: where to send, who reviews, and how long for feedback. Missing one of the three means the team does not send.

Common errors when handling this situation

Set a deadline to switch when the system is not ready. The result is the team switches formats, continues to push through, and now has additional technical debt from a half-hearted transition.
No tracking of the post-launch version. If you cannot measure where the team is self-performing, you won't know which components need urgent addition.
Component too rigid, with no controlled customization points. The team needs flexibility; if the system does not allow it, they will separate it in Figma and recreate it manually from scratch. Brad Frost emphasizes in Atomic Design that maintaining a system requires being rigid enough for consistency and flexible enough to meet real needs.

The viewpoint of Sinh Vũ

When Sinh Vũ builds components, the minimum requirement is to have all real states: default, hover, focus, error, loading, empty. This is not for aesthetics, but to ensure the team has no excuse to redo it. A beautiful shell lacking states is just a template, not a system.

The RFC process is a gateway for the proposing team to make controlled changes, rather than silently imposing them. Sinh Vũ applies it not for procedural reasons, but because without that gateway, everything lacking will be patched outside the system, and the system gradually loses its authority.

One thing Sinh Vũ tells clients directly: if the technical team is too small or the product does not have real users, the system will be neglected due to insufficient maintenance personnel and not enough demand for reuse to demonstrate value. At that point, it is not a friction issue but a timing issue.

A clear governance process is essential for the system to exist long-term. Without it, each team adjusts in their own way, overlapping versions, and the system gradually breaks down without accountability.
Brad Frost, A Design System Governance Process

The tool brings back.

Decision checklist

Topic: Why the team quietly returns to manual work and how to stop it. Sinh Vũ guide, sinhvu.com

0 more than 7 items

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

Sign indicating that you should take action

Prioritize reducing friction when teams avoid systems due to difficulty or slowness.
open contributions when the team is self-limiting components
Add hours for supervision and mentoring when a new system or team is launched.

Questions to answer before deciding

Where is your team most often duplicating components, and is it due to a lack of states or hard-to-find documentation?
How to know if the team is quietly working manually instead of using the system?
Should we set a deadline for the team to switch to using the design system?
How complex does the contribution process (RFC) need to be?

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

Brad Frost, A Design System Governance Process; Brad Frost, Atomic Design (chapter Maintaining Design Systems); Design Systems Collective, Why Your Design System Fails; practical experience from Sinh Vũ.

Frequently asked questions

How to know if the team is quietly working manually instead of using the system?

The clearest sign is that Figma or the codebase has many components with the same name but different forms, or the team often asks 'is this in the system yet' and the answer is always 'no'. When the number of overrides increases without any contribution requests being sent back, that is a sign that the system is being surpassed rather than used.

Should we set a deadline for the team to switch to using the design system?

You shouldn't proceed if friction hasn't been resolved. Rushing to meet a deadline while components are still lacking clarity and documents are hard to reference means the team will transition nominally but continue to struggle internally, resulting in wasted effort and new technical debt. Prioritize creating a clear path first, then set expectations for the timeline.

How complex does the contribution process (RFC) need to be?

There is no need for complexity; what is needed is clarity and several steps. At a minimum: the team should know where to send proposals, who will review them, and how long it will take to receive feedback. Missing any of these three elements will lead the team to not submit and do it themselves.