Does the design system align with your team's technology?
The answer depends on whether you understand the boundary between the token layer and the component layer.
Yes, if done correctly. The token layer (design values like color, spacing, typography) is neutral data, not tied to any specific technology framework, so it is compatible with most modern stacks. The component part, however, must closely adhere to the technology the team is using: React, Vue, or Web Components. Therefore, finalize the stack before building components, and don’t let the studio choose for you.
- the whole team has agreed on a stack (React, Vue, etc.)
- multiple products with different frameworks, keeping the token as a common layer
- needs to be shared across multiple frames, consider Web Components
- building components according to preferred studio stack instead of client team stack
- choosing a unique stack makes it difficult to hire and maintain later
This is a question that Sinh Vũ hears often: "Will the design system you build work on my team's React?" The answer depends on correctly distinguishing between the two layers in a design system: the token layer and the component layer. These two layers have completely different relationships with the technology stack.
The token layer: neutral with the technology framework.
A token is the smallest design unit: colors, spacing, font sizes, border radius. They are stored as data following the DTCG (Design Tokens Community Group) standard, an international community that established a common format for design tokens. This format is pure data, not written in JavaScript, and is not dependent on React or Vue.
Tools like Style Dictionary (a library that converts tokens into CSS, SCSS, or code variables for each platform) can export tokens as CSS variables usable across all web platforms. This means that regardless of whether your team uses React, Vue, Angular, or even a less common framework, tokens can still be accessed through CSS variables.
The component layer: adheres closely to the team's stack.
Component (interface elements like buttons, input fields, information cards) is real source code. Writing a React component cannot be used in Vue, and vice versa. This is the only layer that must match the team's actual stack.
The most common mistake Sinh Vũ sees in projects: studios choose technology frameworks they are familiar with, and once they deliver the components, the client's team cannot read, modify, or maintain them. The system fails right in the first month after delivery.
The principle Sinh Vũ firmly holds: components must be built according to the technology the team is using, not forcing the team to learn a strange stack just to use this set.
When to consider Web Components
Web Components (the native web standard for creating interface components that run on any framework) is a viable option in a specific situation: a team with multiple products running on different frameworks that need to share a common set of components.
Building components according to a framework
Suitable when the whole team agrees on a stack. Better programming experience, fully utilizing the features of that framework. Easier maintenance in the long run.
Building with Web Components
Suitable when multiple products use different frameworks but need to share a common set. It can run across frameworks, but there is a trade-off: some high features of each framework may not be usable, and the experience for developers can sometimes be less smooth than components written purely according to that framework.
The common error when selecting direction
- For the studio to choose a stack instead of the team, once delivered, no one understands how to fix it.
- Choose a frame with few users because it sounds modern; later, it will be difficult to recruit people and find documentation when issues arise.
- Expecting tokens to automatically transform into usable components, overlooking the real effort needed to write components according to the framework.
- Using a shared set of components for React and Vue without using Web Components results in two separate living components that gradually differ.
The viewpoint of Sinh Vũ
Sinh Vũ maintains a clear boundary in service: the DTCG standard token is a neutral layer used for most web platforms. Components are built according to the technology the client is actually using, whether React, Vue, or Web Components.
Do not build components for a unique stack without prior discussion. Delivering a system that no one can maintain is worse than not delivering at all.
Operational perspective, Sinh Vũ.
Before starting to build components, Sinh Vũ will ask clearly: which stack the team is using, if there are any products running on a different framework, and who will maintain the system after handover. These three questions determine the structure of the entire project.
Decision checklist
Topic: Is the design system compatible with your team's technology. Sinh Vũ guide, sinhvu.com
Select each item you find appropriate, 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
Design Tokens Community Group (DTCG); Style Dictionary; Figma Code Connect and Web Components documentation; Sinh Vũ's practical operational perspective.
Frequently asked questions
What is the difference between tokens and components, and which one should we focus on regarding the stack?
Tokens are pure data: color, size, font, spacing, stored as neutral variables according to the DTCG (Design Tokens Community Group) standard. This data is not written in React or Vue, so it can be used anywhere. Components are the actual source code and must be written according to the team's framework. If the team uses React but the studio delivers Vue components, almost no one will be able to maintain them.
What if the team has many products using different frameworks?
This is a situation that requires more detailed design. Tokens still serve as a common layer for everything because they are neutral with the framework. Components can go in two directions: built separately for each framework, or using Web Components as a shared layer across frameworks. Web Components can run on React, Vue, and Angular, but there are trade-offs in functionality and programming experience compared to components written specifically for that framework. Sinh Vũ will discuss clearly before choosing a direction.