Design System là hệ thống dùng chung để thiết kế, xây dựng và vận hành giao diện nhất quán ở quy mô lớn. Nó không chỉ là UI Kit hoặc file Figma, mà gồm foundations, design tokens, components, patterns, content rules, accessibility requirements, code, documentation và governance.
Design System chỉ tạo giá trị khi được dùng trong sản phẩm thật, có owner, version, quy trình contribution, kế hoạch deprecation và số liệu adoption. Một thư viện component đẹp nhưng không nối với code, state, nội dung và quy trình release vẫn có thể làm tăng design debt.
Cấu trúc tối thiểu
- Foundations: nguyên tắc, brand, typography, color, spacing và accessibility.
- Tokens: giá trị thiết kế có tên và có thể trao đổi giữa công cụ.
- Components: anatomy, variants, states, content, code và tests.
- Patterns: tổ hợp component giải quyết một task hoặc flow.
- Documentation: khi dùng, khi không dùng, ví dụ và migration.
- Governance: owner, contribution, review, versioning và deprecation.
Design System khác UI Kit và Style Guide thế nào?
| Lớp | Trả lời câu hỏi | Thành phần |
|---|---|---|
| Style Guide | Thương hiệu trông và nói như thế nào? | Logo, màu, typography, imagery, tone |
| UI Kit | Designer có thể lắp giao diện từ gì? | Button, form, card, icon, layout |
| Component Library | Developer triển khai thành phần nào? | Code, props, states, tests, examples |
| Design System | Team ra quyết định và vận hành giao diện thế nào? | Foundations, tokens, components, patterns, docs, governance |
Design System có thể bao gồm Style Guide, UI Kit và Component Library, nhưng giá trị khác biệt nằm ở logic sử dụng và cơ chế duy trì. Nếu không có governance, mỗi team có thể tiếp tục tạo component mới dù thư viện đã tồn tại.
Bảy lớp của một Design System
1. Principles và foundations
Foundations mô tả nguyên tắc sản phẩm và các quyết định nền như color, typography, spacing, grid, iconography, motion, elevation, breakpoint và content voice. Chúng phải giải thích mục đích, không chỉ liệt kê giá trị.
- Color role và contrast.
- Type scale, line length, zoom và localization.
- Spacing scale và layout behavior.
- Motion duration, reduced motion và pause controls.
- Content principles, terminology và error voice.
2. Design tokens
Design tokens là tên đại diện cho quyết định thiết kế, ví dụ màu hành động chính, khoảng cách section hoặc radius card. Nhóm Design Tokens Community Group của W3C phát triển định dạng trao đổi nhằm giúp token di chuyển giữa công cụ và hệ thống.
| Loại token | Ví dụ semantic | Không nên chỉ dùng |
|---|---|---|
| Color | color.action.primary | blue.500 cho mọi ngữ cảnh |
| Spacing | space.section.medium | 24px rải rác |
| Typography | type.heading.page | font-size-48 |
| Radius | radius.control | 8px không có vai trò |
| Motion | motion.feedback.fast | 200ms dùng cho mọi chuyển động |
Semantic token giúp đổi theme, dark mode, brand hoặc platform mà không buộc mọi component biết giá trị raw. Tuy nhiên token không thay thế design rationale và accessibility testing.
3. Components
Component cần được định nghĩa như một phần tử có anatomy, behavior và state, không chỉ là screenshot. Mỗi component nên có acceptance matrix.
| Hạng mục | Cần tài liệu |
|---|---|
| Anatomy | Phần bắt buộc, optional và thứ tự |
| Variants | Size, hierarchy, intent và platform |
| States | Default, hover, focus, active, loading, disabled, error, success |
| Content | Label, length, truncation, localization và empty copy |
| Accessibility | Semantics, keyboard, focus, name, role, state, contrast |
| Responsive | Resize, wrap, stack, scroll và touch target |
| Code | API, props, dependency, version và examples |
| Tests | Unit, interaction, visual, accessibility và browser |
| Owner | Maintainer, review date và support channel |
Với button, xem thêm thiết kế CTA Button. Với behavior và recovery, xem State-Based Design và Interaction Design.
4. Patterns
Pattern kết hợp nhiều component để giải quyết một task như search, sign-in, checkout, form submission, notification hoặc content navigation. Pattern phải ghi context, entry point, sequence, error, recovery, exit và evidence.
Không copy pattern từ sản phẩm nổi tiếng chỉ vì giao diện đẹp. Dùng nguồn UI Design Patterns để tham khảo, sau đó kiểm tra lại bằng task, usability và accessibility.
5. Content design
Component không hoàn chỉnh nếu thiếu quy tắc nội dung. Design System nên chuẩn hóa terminology, CTA label, field label, helper text, error, confirmation, empty state và notification.
| Loại nội dung | Guardrail |
|---|---|
| CTA | Nêu hành động hoặc kết quả, tránh nhãn mơ hồ |
| Form label | Luôn có label rõ; placeholder không thay label |
| Error | Nêu vấn đề, vị trí và cách phục hồi |
| Success | Xác nhận kết quả và bước tiếp theo |
| Empty state | Giải thích trạng thái và action phù hợp |
| Destructive action | Nêu hậu quả, scope và khả năng hoàn tác |
6. Documentation và component workshop
Documentation nên đặt gần component đang chạy, có ví dụ, controls, source và tests. Storybook mô tả chính nó là frontend workshop để xây UI component và page trong trạng thái cô lập, tạo stories, documentation và hỗ trợ testing.
- Overview và use cases.
- Do/Don’t và counterexample.
- Interactive examples và edge cases.
- Design link, code link và changelog.
- Accessibility notes và test status.
- Migration guide khi API thay đổi.
Công cụ không quyết định chất lượng hệ thống. Xem cách chọn công cụ UX/UI theo workflow.
7. Governance
Governance xác định ai quyết định, ai đóng góp và cách thay đổi được phát hành. Không có governance, hệ thống dễ bị phân nhánh, duplicate hoặc bỏ qua.
| Quy trình | Câu hỏi cần trả lời |
|---|---|
| Contribution | Ai đề xuất? Evidence và use case tối thiểu là gì? |
| Review | Design, code, accessibility, content và product ai duyệt? |
| Versioning | Breaking change được đánh dấu và phát hành thế nào? |
| Deprecation | Thời hạn, replacement và migration guide là gì? |
| Support | Team hỏi ở đâu, response và owner là ai? |
| Audit | Adoption, duplicate, defect và outdated docs được rà khi nào? |
Khi nào doanh nghiệp cần Design System?
Website nhỏ không cần hệ thống quy mô enterprise. Tuy nhiên mọi website nên có bộ chuẩn tối thiểu cho color, typography, spacing, button, form, content và responsive behavior.
| Tín hiệu | Hành động phù hợp |
|---|---|
| Một website, ít template, một team | Foundations + component starter |
| Nhiều landing page và campaign | Reusable patterns + content rules |
| Nhiều product team | Versioned components + contribution model |
| Design và code lệch nhau | Mapping token/component + Storybook |
| Nhiều brand hoặc theme | Semantic tokens + mode governance |
| Accessibility regression lặp lại | Acceptance criteria + automated/manual tests |
Quy trình triển khai theo từng giai đoạn
- Audit: inventory component, pattern, token, defect và owner.
- Prioritize: chọn phần dùng nhiều, rủi ro cao hoặc gây duplicate.
- Standardize: foundations, semantic tokens và naming.
- Build pilot: triển khai một flow đại diện trong design và code.
- Validate: usability, accessibility, responsive, tests và performance.
- Document: use case, API, examples, do/don’t và migration.
- Adopt: migrate sản phẩm theo roadmap, không ép big-bang.
- Govern: contribution, release, support, audit và deprecation.
Design System nên được đưa vào quy trình thiết kế website và checklist bàn giao, thay vì là file riêng không ai duy trì.
Accessibility trong Design System
WCAG cung cấp tiêu chí đánh giá nội dung web, nhưng component cần thêm guidance về implementation và testing. Validation tự động không đủ; keyboard, focus, screen reader, zoom, motion và error recovery thường cần kiểm tra thủ công.
- Semantic element và ARIA chỉ dùng khi cần.
- Accessible name, description, role và state rõ.
- Keyboard sequence và visible focus.
- Contrast, forced colors, zoom và text resize.
- Error identification, status message và recovery.
- Touch target, orientation và reduced motion.
Đo hiệu quả và mức độ áp dụng
Design System không tự bảo đảm conversion hoặc tốc độ phát triển. Tác động cần đo theo baseline và phạm vi.
| Nhóm metric | Ví dụ | Giới hạn |
|---|---|---|
| Adoption | % screen hoặc component dùng bản chuẩn | Adoption cao không chứng minh UX tốt |
| Duplication | Số component trùng chức năng | Cần phân biệt variant hợp lệ |
| Delivery | Time-to-ship cho page/feature tương tự | Phụ thuộc scope và team |
| Quality | UI defect, accessibility regression, support issue | Tracking phải nhất quán |
| Maintenance | Outdated version, deprecated usage, migration time | Không chỉ đếm release |
| Contribution | Proposal, review time, accepted contribution | Số lượng không bằng chất lượng |
Nên kết hợp số liệu với interview của designer, developer, content và product team để tìm nguyên nhân không adoption: thiếu component, API khó dùng, docs yếu, review chậm hoặc hệ thống không giải quyết đúng task.
Lỗi thường gặp
| Lỗi | Hệ quả | Cách sửa |
|---|---|---|
| Xây quá nhiều trước khi pilot | Component không có nhu cầu thật | Bắt đầu từ flow đại diện |
| Figma và code không đồng bộ | Handoff và implementation lệch | Mapping, version và shared review |
| Thiếu state và content | Happy path đẹp nhưng production lỗi | Acceptance matrix đầy đủ |
| Không có owner | Docs và component lỗi thời | RACI, support và review cadence |
| Breaking change không có migration | Team tránh nâng version | Deprecation window và codemod/guide |
| Ép adoption bằng quy định | Shadow components xuất hiện | Đo friction và sửa hệ thống |
| Đo thành công bằng số component | Thư viện phình to | Đo adoption, quality và outcome |
Checklist nghiệm thu Design System
- Principles và scope của hệ thống đã rõ.
- Token có naming, type, alias và source of truth.
- Component có anatomy, variants, states và content rules.
- Design và code có mapping/version tương ứng.
- Accessibility acceptance criteria và tests đầy đủ.
- Responsive, localization và edge cases được kiểm tra.
- Documentation có examples, do/don’t và migration.
- Contribution, release và deprecation có owner.
- Adoption và quality metrics có baseline.
- Tài sản, repository, account và license được bàn giao.
FAQ
Website nhỏ có cần Design System không?
Cần bộ chuẩn tối thiểu, không cần hệ thống enterprise. Foundations, tokens chính, button, form, card, content rules và responsive guidance thường đã đủ để tránh rối khi mở rộng.
Nên xây trong Figma hay code?
Nên có source of truth và mapping phù hợp giữa design với code. Figma hỗ trợ thiết kế; component workshop/code library hỗ trợ implementation và tests. Chỉ có một phía dễ tạo lệch.
Design token có phải CSS variable không?
Không hoàn toàn. Token là quyết định thiết kế có tên và metadata; CSS variable là một cách triển khai trên web. Token có thể được chuyển sang nhiều nền tảng và định dạng.
Design System có làm tăng conversion không?
Không có bảo đảm. Nó có thể cải thiện consistency và delivery; tác động tới conversion chỉ được xác nhận qua trải nghiệm thực tế, nội dung, offer và đo lường phù hợp.
Kết luận
Design System là sản phẩm nội bộ phục vụ nhiều team và cần được quản lý như sản phẩm: có người dùng, roadmap, support, quality gates và số liệu. Hệ thống tốt không phải hệ thống có nhiều component nhất, mà là hệ thống giúp team giải quyết đúng task với ít duplicate và ít regression hơn.
Khi xây mới hoặc chuẩn hóa website, có thể tham khảo dịch vụ thiết kế website chuyên nghiệp để nối UX/UI, component, SEO và bàn giao thành một quy trình thống nhất.
Nguồn tiêu chuẩn và hệ thống tham khảo
- Design Tokens Community Group
- W3C Design Tokens Community Group
- Storybook Documentation
- GOV.UK Design System
- W3C WAI: WCAG
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.
