Mở đầu — vì sao bài này quan trọng
Có một câu hỏi mà tôi gặp đi gặp lại trong hầu hết các buổi phỏng vấn designer, cả khi tôi ngồi ghế ứng viên lẫn khi tôi ngồi ghế nhà tuyển dụng: "Bạn đã xây design system chưa?". Và tôi để ý một điều thú vị — rất nhiều bạn trẻ tự tin trả lời "Rồi ạ", nhưng khi hỏi sâu thì hóa ra thứ họ làm chỉ là một UI Kit. Hai khái niệm này bị nhầm lẫn nhiều đến mức trong nhiều công ty, người ta gọi bừa file Figma của mình là "design system" cho oai, dù bản chất nó chỉ là một bộ sưu tập component tĩnh.
Sự nhầm lẫn này không đơn thuần là chuyện dùng từ. Nó dẫn đến những quyết định sai lầm rất tốn kém: một startup bỏ ba tháng "xây design system" nhưng sản phẩm vẫn không nhất quán; một team bị sếp mắng vì "đã có design system rồi mà mỗi màn hình mỗi kiểu"; một designer thăng chức Senior nhưng loay hoay không biết vì sao hệ thống của mình không "sống" được.
Bài này giúp bạn phân biệt rạch ròi UI Kit và Design System — không phải để chẻ chữ, mà để bạn biết mình đang cần gì ở thời điểm nào, đầu tư đúng chỗ, và nói chuyện chính xác với sếp lẫn với engineer. Đây là kiến thức nền để bạn không "xây nhầm thứ" trong suốt phần còn lại của khóa học.
Khái niệm cốt lõi
UI Kit là gì?
UI Kit, hiểu đơn giản, là một file (hoặc một bộ file) chứa các component và style đã dựng sẵn để bạn tái sử dụng khi thiết kế. Nó thường gồm: bảng màu, kiểu chữ (text styles), các nút bấm, input, card, icon, và một số layout mẫu. Bạn mở file ra, kéo component vào là dùng được ngay.
Đặc điểm quan trọng nhất của UI Kit: nó là design asset tĩnh. Nghĩa là nó chỉ tồn tại trong không gian thiết kế (Figma, Sketch, XD), phục vụ chủ yếu cho designer. Nó không có "hợp đồng" nào ràng buộc với code, không có tài liệu hướng dẫn cách dùng, không có quy trình cập nhật, không có ai chịu trách nhiệm bảo trì nó lâu dài.
Ưu điểm của UI Kit là nhanh và rẻ. Bạn có thể mua một UI Kit thương mại (Untitled UI, Material 3 Kit, hoặc mua trên UI8) hoặc tự dựng trong vài ngày, rồi lập tức tăng tốc thiết kế. Nhược điểm cũng đến từ chính bản chất tĩnh của nó: rất dễ lỗi thời (outdated). Vì không có cơ chế đồng bộ với sản phẩm thật, chỉ sau vài tháng, file UI Kit và app thực tế sẽ "trôi" xa nhau — designer sửa trong Figma nhưng code không đổi, hoặc dev sửa trong code nhưng Figma không đổi. Cuối cùng UI Kit trở thành một "bảo tàng" đẹp đẽ mà không ai còn tin dùng.
Design System là gì?
Design System là một khái niệm rộng hơn nhiều. Nếu UI Kit là "bộ đồ nghề", thì Design System là "cả xưởng sản xuất kèm sổ tay vận hành". Một design system đúng nghĩa bao gồm nhiều lớp:
- Design tokens & foundations: màu, typography, spacing, elevation, border radius... được định nghĩa có hệ thống (bạn đã và sẽ học kỹ ở các bài trước và sau).
- Component library trong design tool: đây chính là phần trùng với UI Kit — component + styles trong Figma.
- Coded component library: các component tương đương được viết bằng code (React, Vue, SwiftUI...), là thứ dev thực sự dùng để dựng sản phẩm.
- Documentation: tài liệu mô tả khi nào dùng component nào, các state, do/don't, quy tắc accessibility.
- Design principles & guidelines: triết lý, nguyên tắc chung định hướng mọi quyết định.
- Governance & process: ai sở hữu, ai được đóng góp, quy trình đề xuất thay đổi, cách versioning, cách phát hành (release).
- Con người: có một team hoặc ít nhất một người chịu trách nhiệm duy trì hệ thống sống.
Điểm khác biệt then chốt: "living product" vs "static file"
Hãy ghi nhớ một câu tôi luôn dùng để phân biệt: UI Kit là danh từ, Design System là động từ.
UI Kit là một thứ bạn có. Design System là một hoạt động liên tục bạn duy trì. Sự khác nhau nằm ở bốn trục:
| Trục | UI Kit | Design System |
|---|---|---|
| Phạm vi | Chỉ design assets | Design + code + docs + process |
| Đối tượng phục vụ | Chủ yếu designer | Designer, dev, PM, QA, cả tổ chức |
| Tính đồng bộ | Không có cơ chế sync | Có sync giữa design và code |
| Vòng đời | Tĩnh, dễ lỗi thời | Sống, có versioning & governance |
| Chủ sở hữu | Thường không rõ | Có team/người chịu trách nhiệm |
Tình huống thực tế
Ví dụ 1 — Startup fintech ở TP.HCM tưởng mình có design system
Một startup ví điện tử ở Sài Gòn (gọi là "PayNhanh" cho tiện) có team 4 designer. Năm 2023 họ dựng một file Figma khá đẹp: đủ màu, đủ text style, khoảng 40 component nút, input, card. Họ tự hào gọi đó là "PayNhanh Design System" và ghim lên đầu kênh Slack.
Sáu tháng sau, sản phẩm thực tế trên điện thoại nhìn "loạn": nút bấm ba màu xanh khác nhau, khoảng cách padding mỗi màn mỗi kiểu. Sếp bực bội hỏi: "Có design system rồi sao vẫn thế này?". Điều tra ra thì: dev chưa từng đọc file Figma đó, họ tự code component theo cảm tính; designer thì mỗi người detach component ra sửa riêng cho nhanh; không ai cập nhật file gốc; không có tài liệu nào nói "primary button dùng màu #0066FF".
Diễn giải: PayNhanh có một UI Kit (thậm chí là một UI Kit khá tốt), nhưng gọi nhầm là design system. Thứ họ thiếu không phải là component đẹp hơn, mà là lớp code đồng bộ, tài liệu, và quy trình governance. Không có ba thứ đó, mọi file Figma đều sẽ trôi khỏi thực tế.
Bài học: Đừng dán nhãn "design system" cho một file tĩnh. Việc đặt sai tên tạo ra kỳ vọng sai — sếp tưởng vấn đề nhất quán đã được giải quyết, nên không đầu tư thêm nguồn lực, và mọi thứ tệ dần.
Ví dụ 2 — Team nhỏ chọn đúng UI Kit và đúng thời điểm
Ngược lại, một agency 6 người ở Đà Nẵng nhận làm landing page và MVP cho khách hàng. Mỗi dự án chỉ kéo dài 4–8 tuần rồi bàn giao. Họ cố tình không xây design system mà mua một UI Kit thương mại (Untitled UI, khoảng 149 USD) và tùy biến nhẹ cho từng khách.
Kết quả: tốc độ dựng wireframe đến high-fidelity nhanh gấp đôi. Vì dự án ngắn, không cần bảo trì lâu dài, không có coded library dùng chung giữa nhiều sản phẩm, nên toàn bộ chi phí của một design system (docs, governance, sync code) sẽ là lãng phí với họ.
Diễn giải: Ở đây, UI Kit là lựa chọn đúng, không phải lựa chọn "kém sang". Design system chỉ đáng đầu tư khi bạn có nhiều sản phẩm/nhiều team dùng chung, vòng đời dài, và cần nhất quán ở quy mô lớn.
Bài học: "Xịn hơn" không có nghĩa là "phù hợp hơn". Chọn công cụ theo bối cảnh: quy mô, số team, vòng đời sản phẩm. Với đội nhỏ làm dự án ngắn, một UI Kit tốt thắng một design system dang dở.
Ví dụ 3 — Shopee-style: từ UI Kit tiến hóa thành Design System
Hãy tưởng tượng một sàn thương mại điện tử lớn ở Đông Nam Á (kiểu Shopee, Tiki), có tới 5 nền tảng: web, iOS, Android, seller app, admin dashboard, với hàng chục squad. Giai đoạn đầu, mỗi squad có UI Kit riêng. Hậu quả: nút "Mua ngay" có 7 biến thể khác nhau tùy squad, gây trải nghiệm rối và tốn hàng nghìn giờ dev làm lại.
Họ buộc phải nâng cấp: lập một Design System team riêng (3 designer + 2 engineer), xây design tokens dùng chung, một coded component library trên React và một trên native, cổng tài liệu (documentation site), quy trình versioning theo kiểu semantic (v2.3.0), và cơ chế "contribution" để squad đề xuất thêm component. Sau một năm, thời gian một squad dựng màn hình mới giảm khoảng 30–40%, vì họ ráp component có sẵn đã được kiểm định thay vì tự chế.
Diễn giải: Đây là hình mẫu "UI Kit lớn lên thành Design System" khi quy mô đủ lớn để chi phí duy trì được đền bù bằng hiệu quả tái sử dụng. Chú ý: cái làm nên khác biệt không phải component đẹp hơn, mà là tokens dùng chung, code đồng bộ, tài liệu và governance.
Bài học: Design system là khoản đầu tư có điểm hòa vốn. Khi số team và số nền tảng vượt một ngưỡng nào đó, chi phí không có design system (làm lại, thiếu nhất quán) sẽ lớn hơn chi phí xây và nuôi nó.
Hướng dẫn từng bước
Đây là quy trình giúp bạn quyết định nên xây gì và xây theo thứ tự nào.
Bước 1 — Xác định bối cảnh trước khi quyết định. Trả lời ba câu: (a) Có bao nhiêu team/sản phẩm sẽ dùng? (b) Vòng đời sản phẩm bao lâu? (c) Ai sẽ bảo trì sau khi bạn rời đi? Nếu chỉ một sản phẩm, vòng đời ngắn, không ai bảo trì — dừng ở UI Kit. Nếu nhiều team, vòng đời dài, có người sở hữu — bạn cần design system.
Bước 2 — Nếu chọn UI Kit, làm cho nó gọn và đúng chuẩn. Dựng foundations (màu, type, spacing) bằng styles/variables của Figma, tạo component với Auto Layout và Variants, đặt tên nhất quán. Đừng cố nhồi tài liệu hay quy trình vào — giữ nó nhẹ để dễ ship, chấp nhận rằng nó sẽ cần làm mới định kỳ.
Bước 3 — Nếu chọn Design System, đừng bắt đầu bằng component. Bắt đầu bằng design tokens (foundation layer) vì đó là gốc để cả design lẫn code cùng tham chiếu. Token sai thì mọi component xây trên nó đều sai.
Bước 4 — Xây song song design library và coded library. Component trong Figma phải có một "người anh em" trong code. Đây chính là lớp sync biến UI Kit thành design system. Thống nhất tên component, tên token, và các state giống hệt nhau ở cả hai phía.
Bước 5 — Viết documentation tối thiểu cho mỗi component. Không cần hoàn hảo: mỗi component chỉ cần "dùng khi nào / không dùng khi nào / các state / lưu ý accessibility". Tài liệu là thứ phân biệt design system với UI Kit rõ nhất — nó cho phép người không tạo ra component vẫn dùng đúng.
Bước 6 — Thiết lập governance. Chỉ định chủ sở hữu, quy trình đề xuất thay đổi, cách đánh version, và lịch phát hành. Không có bước này, design system sẽ thoái hóa dần thành... một UI Kit lỗi thời.
Lỗi thường gặp & mẹo
Lỗi 1 — Gọi UI Kit là design system. Đây là lỗi phổ biến nhất và gây hại nhất vì nó tạo kỳ vọng sai với sếp và team. Mẹo: khi báo cáo, hãy nói chính xác — "Chúng ta đang có UI Kit, để thành design system cần thêm coded library, docs và governance". Sự trung thực này giúp bạn xin đúng nguồn lực.
Lỗi 2 — Nhảy thẳng vào xây design system khi chưa cần. Team 2 người, một sản phẩm, mà bỏ hai tháng xây documentation site và versioning — đó là over-engineering. Mẹo: dùng "phép thử quy mô" ở Bước 1. Bắt đầu bằng UI Kit, nâng cấp dần khi số team tăng.
Lỗi 3 — Xây design system nhưng bỏ quên lớp code. Nếu Figma và code không đồng bộ, bạn chỉ có một UI Kit đội lốt design system. Mẹo: coi coded component library là bắt buộc, không phải tùy chọn. Có thể dùng công cụ như Storybook để kết nối (bạn sẽ học ở Bài 45).
Lỗi 4 — Bỏ qua governance vì nghĩ "cứ xây xong là dùng mãi". Không có chủ sở hữu, design system chết trong 6–12 tháng. Mẹo: gán trách nhiệm cho một người có tên cụ thể, dù chỉ dành 20% thời gian.
Lỗi 5 — Không có tài liệu. Component đẹp mà không ai biết dùng khi nào thì mỗi người dùng một kiểu. Mẹo: viết do/don't ngắn gọn ngay khi tạo component, đừng để "làm sau".
Mẹo tổng quát: Hãy hình dung một trục tiến hóa — Styles → UI Kit → UI Kit + Docs → Design System. Bạn không nhất thiết phải nhảy một phát tới cuối. Leo từng nấc theo nhu cầu thực tế là chiến lược khôn ngoan nhất.
Bài tập thực hành
Bài 1 — Chẩn đoán. Lấy một file Figma bạn (hoặc công ty bạn) đang gọi là "design system". Chấm điểm nó theo 6 tiêu chí của design system: tokens, design library, coded library, docs, principles, governance. Đếm xem có bao nhiêu tiêu chí đạt. Nếu dưới 4, thành thật gọi nó là UI Kit và ghi ra 3 việc cần làm để nâng cấp.
Bài 2 — Ra quyết định theo bối cảnh. Cho ba tình huống sau, chọn UI Kit hay Design System và giải thích trong 2–3 câu: (a) một freelancer làm landing page cho khách; (b) một scale-up có 4 squad dùng chung một web app; (c) một tập đoàn có web + iOS + Android + admin. Đối chiếu với "phép thử quy mô" ở Bước 1.
Bài 3 — Viết một trang tài liệu. Chọn một component bất kỳ (ví dụ Button) trong file của bạn và viết tài liệu tối thiểu: mô tả, khi nào dùng / không dùng, liệt kê các state, một lưu ý accessibility. Trải nghiệm này cho bạn cảm nhận rõ vì sao docs là ranh giới thực sự giữa UI Kit và design system.
Tóm tắt
Điều cần nhớ nhất của bài này rất ngắn: UI Kit là một tập con của Design System.
UI Kit là một file design tĩnh chứa component và style — nhanh, rẻ, dễ ship nhưng cũng dễ lỗi thời vì không có cơ chế đồng bộ với sản phẩm thật. Design System rộng hơn nhiều: nó gồm tokens, design library, coded library, tài liệu, nguyên tắc và quy trình governance, cùng con người duy trì. UI Kit là danh từ (một thứ bạn có); Design System là động từ (một hoạt động sống bạn duy trì).
Không có cái nào "xịn hơn" một cách tuyệt đối. Chọn theo bối cảnh: đội nhỏ, dự án ngắn thì một UI Kit tốt là đủ và đúng; nhiều team, nhiều nền tảng, vòng đời dài thì mới đáng đầu tư vào design system. Sai lầm tốn kém nhất không phải chọn nhầm công cụ, mà là gọi nhầm tên — dán nhãn design system cho một UI Kit tĩnh, rồi kỳ vọng nó tự giải quyết vấn đề nhất quán mà không đầu tư thêm lớp code, tài liệu và quy trình.
Ở các bài tiếp theo, bạn sẽ đi sâu vào từng lớp làm nên một design system thật sự — naming conventions, sync tokens, documentation, versioning — chính là những thứ biến một UI Kit đẹp thành một hệ thống sống.