Does the design system align with your team's technology?
The answer depends on whether you correctly understand the boundaries between the token layer and the component layer.
Yes, if done correctly. The token layer (design values like colors, spacing, typography) is neutral data. It is not tied to any technology framework, making it compatible with most modern technologies. The component layer must adhere closely to the technology the team is using: React, Vue, or Web Components. Therefore, finalize the technology before building the component; do not let the vendor 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 the vendor's familiar stack instead of the team's stack.
- choosing a unique stack makes it difficult to hire and maintain later
This is a common question: "Will this design system work with my team's React?" The answer lies in correctly distinguishing the two layers in a design system: the token layer and the component layer. These two layers have completely different relationships with the technology being used.
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 even if your team uses React, Vue, Angular, or a less common technology framework, tokens can still be integrated 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 in projects is when the vendor chooses a technology framework they are familiar with. After delivering the component, the client team cannot read, modify, or maintain it. The system fails within the first few months after handover.
The principle to maintain: components must be built according to the technology the team is using, and do not force the team to learn an unfamiliar stack just to use this set.
When to consider Web Components
Web Components (the native web standard that allows the creation of interface components that can run on any framework) are a viable option in a specific situation. This is when the team has multiple products running on different frameworks and needs to use 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
- Letting the vendor choose the stack for the team means that after delivery, 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.
When considering, you should answer three questions before starting to build components: what technology is your team using, are there any products running on different frameworks, 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
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
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: colors, sizes, fonts, 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 and the component is delivered in Vue, almost no one can maintain it.
What if the team has many products using different frameworks?
This is a situation that requires more detailed design. Tokens serve as a common layer for all because they are neutral to the framework. Components have two directions: building separately for each framework or using Web Components as a common layer across frameworks. Web Components can run on React, Vue, and Angular, but there are trade-offs in features and programming experience compared to components written specifically for that framework. Therefore, it is important to discuss these trade-offs before choosing a direction.
This article is for reference. The scope, pricing, and specific commitments of Sinh Vũ are detailed in the proposal and signed contract.