Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vừa được nhận vào làm designer cho một startup fintech ở TP.HCM. Tuần đầu tiên, sếp giao cho bạn thiết kế màn hình "Lịch sử giao dịch". Bạn mở Figma, lấy mã màu xanh từ một file cũ, chọn một button trông giống button mà đồng nghiệp đã làm, gõ font size 16px vì cảm thấy hợp lý. Sản phẩm ra mắt. Hai tháng sau, bạn nhìn lại toàn bộ app: màn hình A dùng màu xanh #0066FF, màn hình B dùng #0A5FE0, màn hình C lại là #1565D8. Cùng một "màu thương hiệu" nhưng có tới sáu phiên bản khác nhau. Button thì cái bo góc 4px, cái 6px, cái 8px. Khoảng cách giữa các phần tử thì tùy hứng.
Đây không phải lỗi của riêng bạn. Đây là điều xảy ra với MỌI sản phẩm không có design system. Khi đội ngũ lớn lên, khi sản phẩm phình ra, sự thiếu nhất quán này biến thành một khoản nợ kỹ thuật và nợ thiết kế khổng lồ.
Design System chính là câu trả lời. Đây là bài học bản lề của cả khóa: từ Bài 3 đến Bài 37, bạn đã học về visual hierarchy, color, typography, layout, component. Bài 38 này là nơi tất cả những mảnh ghép đó được tổ chức lại thành một hệ thống có thể mở rộng. Hiểu được nền tảng design system, bạn sẽ nâng cấp từ một người "vẽ giao diện" thành một người "xây dựng ngôn ngữ thiết kế" — kỹ năng phân biệt junior với senior trong nghề.
Khái niệm cốt lõi
Component vs Design System — phân biệt cho rõ
Đây là điểm nhiều bạn nhầm lẫn nhất, nên ta làm rõ ngay từ đầu.
Component là MỘT mảnh UI có thể tái sử dụng. Một cái button. Một cái card. Một ô input. Nó là viên gạch.
Design System là TOÀN BỘ ngôi nhà cộng với bộ quy tắc xây nhà. Nó bao gồm:
- Design tokens — các giá trị nền tảng như màu sắc, khoảng cách (spacing), kích thước chữ, bo góc, đổ bóng. Đây là "nguyên tử" nhỏ nhất.
- Components — các viên gạch UI được dựng từ tokens.
- Patterns — cách kết hợp nhiều component để giải quyết một bài toán lặp lại (ví dụ: pattern "form đăng nhập", pattern "danh sách có phân trang").
- Guidelines / Documentation — tài liệu hướng dẫn: khi nào dùng cái gì, dùng như thế nào, không nên dùng ra sao.
- Principles — các nguyên tắc thiết kế nền tảng định hướng mọi quyết định.
Vì sao cần một hệ thống chứ không chỉ một thư viện component
Nhiều bạn nghĩ "tôi gom hết button, card vào một file Figma là xong design system". Sai. Đó mới chỉ là một UI library (thư viện giao diện). Một design system thực thụ phải có lớp tokens bên dưới và tài liệu bên trên.
Hãy hình dung ba tầng:
Tầng 3: Guidelines & Patterns (cách dùng, khi nào dùng)
Tầng 2: Components (button, card, input...)
Tầng 1: Design Tokens (màu, spacing, type, radius...)
Tầng 1 là nền móng. Nếu bạn định nghĩa color-primary = #0066FF ở một chỗ duy nhất, rồi mọi button, mọi link, mọi icon đều tham chiếu tới token đó, thì khi thương hiệu đổi màu, bạn chỉ sửa MỘT giá trị. Toàn bộ hệ thống tự cập nhật. Đó là sức mạnh thật sự.
Single Source of Truth — nguồn chân lý duy nhất
Khái niệm quan trọng nhất của design system là Single Source of Truth (SSOT) — nguồn sự thật duy nhất. Mọi giá trị thiết kế chỉ được định nghĩa ở MỘT nơi. Designer lấy từ đó, developer lấy từ đó. Không ai "tự chế" một mã màu mới giữa chừng.
Khi có SSOT, bạn loại bỏ được câu hỏi muôn thuở: "Cái này dùng màu nào nhỉ? Spacing bao nhiêu?". Câu trả lời luôn nằm trong hệ thống.
Atomic Design — một cách tư duy về cấu trúc
Brad Frost đề xuất mô hình Atomic Design (thiết kế nguyên tử) — một ẩn dụ rất dễ nhớ cho cách design system được tổ chức:
- Atoms (nguyên tử): phần tử nhỏ nhất — một label, một input, một icon.
- Molecules (phân tử): vài atom ghép lại — một ô tìm kiếm = input + button + icon.
- Organisms (sinh vật): nhiều molecule ghép thành khối lớn — một header hoàn chỉnh.
- Templates: bố cục trang chưa có dữ liệu thật.
- Pages: template với nội dung thật.
Đặc điểm của một design system tốt
Một hệ thống nền tảng tốt cần ba phẩm chất:
- Consistent (nhất quán): cùng một vấn đề luôn có cùng một giải pháp.
- Scalable (mở rộng được): thêm component mới không phá vỡ cái cũ.
- Maintainable (dễ bảo trì): sửa một chỗ, cập nhật toàn bộ; có tài liệu để người mới hiểu nhanh.
Tình huống thực tế
Tình huống 1: Tiki và bài toán nhất quán ở quy mô lớn
Hãy lấy một sàn thương mại điện tử lớn của Việt Nam như Tiki làm ví dụ. Một sản phẩm như thế có hàng trăm màn hình: trang chủ, trang sản phẩm, giỏ hàng, thanh toán, TikiNOW, ví, đánh giá... Giả sử đội ngũ có 8 designer và 30 developer cùng làm.
Nếu không có design system, mỗi designer sẽ tự vẽ button theo cảm nhận riêng. Kết quả: button "Mua ngay" trên trang sản phẩm cao 44px, nhưng button "Thanh toán" ở giỏ hàng cao 48px, màu đỏ thì lệch nhau vài độ. Người dùng có thể không gọi tên được vấn đề, nhưng họ "cảm thấy" app thiếu chỉn chu.
Khi áp dụng design system với token color-brand = #1A94FF, button-height = 44px, radius-md = 6px, mọi button trong toàn bộ app đều rút từ cùng một nguồn. Designer mới vào việc chỉ cần kéo component "Button/Primary" từ thư viện là tự động đúng chuẩn.
Bài học rút ra: Ở quy mô càng lớn, design system càng không phải "thứ làm cho đẹp" mà là hạ tầng bắt buộc để giữ nhất quán và đi nhanh. Một designer mới có thể đóng góp ngay ngày đầu mà không cần đoán mò.
Tình huống 2: Startup 3 người và sai lầm "để sau hẵng làm system"
Một startup edtech ở Đà Nẵng, đội ngũ chỉ 3 người: một founder, một dev fullstack, một designer kiêm marketer. Họ lao vào làm MVP để kịp demo cho nhà đầu tư. Quan điểm của họ: "Design system là chuyện của công ty lớn, mình nhỏ thế này làm gì cho mất thời gian."
Sáu tháng sau, sản phẩm có 40 màn hình. Họ gọi vốn thành công, tuyển thêm 2 designer. Hai người mới mở file Figma ra và choáng: 11 sắc thái xanh khác nhau, không có tên component nào thống nhất, mỗi màn hình là một "ốc đảo". Việc đầu tiên họ phải làm không phải thiết kế tính năng mới, mà là dành trọn 3 tuần để "dọn dẹp" và xây lại tokens cơ bản — một khoản nợ thiết kế phải trả bằng lãi.
Bài học rút ra: Bạn KHÔNG cần một design system đồ sộ ngay từ đầu. Nhưng ngay cả startup nhỏ nhất cũng nên định nghĩa sớm bộ tokens tối thiểu — bảng màu, thang spacing, type scale. Chỉ mất một buổi chiều nhưng tiết kiệm hàng tuần về sau. "Start small, but start" — bắt đầu nhỏ, nhưng phải bắt đầu.
Tình huống 3: Shopee và cái lợi của "ngôn ngữ chung" giữa design và code
Ở các công ty công nghệ lớn khu vực Đông Nam Á như Shopee hay Grab, design system còn giải quyết một bài toán nữa: khoảng cách giữa designer và developer. Khi token trong Figma (spacing-4 = 16px) khớp chính xác với biến trong code (--spacing-4: 16px), thì lúc bàn giao thiết kế, developer không phải "đo lại bằng mắt". Designer nói "dùng spacing-4", dev hiểu ngay, và sản phẩm code ra giống hệt thiết kế.
Một đội ở Grab từng chia sẻ rằng sau khi chuẩn hóa tokens chung giữa Figma và codebase, thời gian một tính năng đi từ thiết kế đến chạy thật giảm rõ rệt, vì gần như không còn vòng lặp "dev làm sai pixel — designer phản hồi — dev sửa lại".
Bài học rút ra: Design system không chỉ phục vụ designer. Nó là giao thức giao tiếp giữa thiết kế và kỹ thuật. Tokens được đặt tên tốt chính là từ vựng mà cả hai phía cùng nói.
Hướng dẫn từng bước
Đây là lộ trình xây nền tảng một design system từ con số 0, phù hợp với một sản phẩm nhỏ tới vừa:
Bước 1 — Kiểm kê hiện trạng (audit). Trước khi xây mới, chụp lại toàn bộ giao diện đang có. Gom hết button, màu, font đang dùng vào một trang. Bạn sẽ giật mình khi thấy mình đang có 9 màu xám và 5 cỡ chữ tiêu đề. Đây là bước "soi gương".
Bước 2 — Định nghĩa tokens nền tảng. Bắt đầu từ tầng dưới cùng:
- Color: chọn 1 màu primary, 1 màu secondary, một thang xám (gray-50 đến gray-900), và các màu trạng thái (success, warning, error, info).
- Spacing: dùng một thang đều, ví dụ bội số của 4: 4, 8, 12, 16, 24, 32, 48, 64.
- Typography: xác định font family, và một type scale (ví dụ 12, 14, 16, 20, 24, 32).
- Radius & Shadow: vài mức bo góc (sm, md, lg) và vài mức đổ bóng.
color-primary thay vì color-blue, vì mai mốt primary có thể đổi sang tím mà tên vẫn đúng. Đây là khái niệm "semantic token" — token ngữ nghĩa.Bước 4 — Dựng những component cốt lõi từ tokens. Bắt đầu với 5–7 component dùng nhiều nhất: Button, Input, Card, Typography, Icon. Mỗi component phải tham chiếu tokens, không hard-code giá trị.
Bước 5 — Tạo các trạng thái và biến thể. Mỗi component cần đủ states: default, hover, active, disabled. Button cần variants: primary, secondary, ghost.
Bước 6 — Viết tài liệu tối thiểu. Mỗi component nên có: ảnh minh họa, khi nào dùng, khi nào KHÔNG dùng, ví dụ đúng/sai. Không cần cầu kỳ — một trang Figma hay Notion là đủ cho đội nhỏ.
Bước 7 — Đồng bộ với code. Đảm bảo tokens trong Figma khớp với biến trong CSS/Tailwind. Đây là cây cầu để design system "sống" trong sản phẩm thật chứ không chỉ nằm trong file thiết kế.
Bước 8 — Quản trị và phát triển (governance). Quy định ai được thêm/sửa component, quy trình ra sao. Dù chỉ là "mọi thay đổi tokens phải được team review", một quy tắc nhỏ cũng ngăn hệ thống bị loạn trở lại.
Lỗi thường gặp & mẹo
Lỗi 1: Nhầm UI library với design system. Gom component vào một file rồi gọi là design system. Thiếu tầng tokens và tầng tài liệu thì hệ thống không bền. Mẹo: luôn bắt đầu từ tokens, đừng bắt đầu từ component.
Lỗi 2: Quá kỹ ngay từ đầu (over-engineering). Bỏ ra ba tháng xây hệ thống hoàn hảo cho một app mới có 5 màn hình. Mẹo: xây vừa đủ với hiện tại, để hệ thống lớn lên cùng sản phẩm. Một design system tốt là cái được dùng, không phải cái hoàn hảo trên giấy.
Lỗi 3: Hard-code giá trị trong component. Vẽ button với màu #1A94FF gõ thẳng vào, không qua token. Khi đổi màu thương hiệu, bạn phải sửa từng cái một. Mẹo: mọi giá trị trong component phải trỏ về token.
Lỗi 4: Đặt tên token theo giá trị. Đặt color-blue-bright — đến khi đổi sang xanh lá thì cái tên thành nói dối. Mẹo: đặt tên theo vai trò ngữ nghĩa: color-primary, color-danger, text-muted.
Lỗi 5: Làm xong rồi bỏ mặc. Design system không phải dự án một lần. Không ai bảo trì thì sau 6 tháng nó lỗi thời, mọi người quay lại "tự chế". Mẹo: phân công người chủ trì (dù là bán thời gian) và đặt lịch review định kỳ.
Lỗi 6: Bỏ qua developer. Designer xây hệ thống một mình, không bàn với dev. Token đẹp trong Figma nhưng không khớp code. Mẹo: mời developer tham gia từ khâu đặt tên token.
Bài tập thực hành
Bài tập 1 — Audit một app bạn dùng hằng ngày. Chọn một app Việt Nam bạn hay dùng (MoMo, ZaloPay, Tiki...). Chụp 5 màn hình bất kỳ. Liệt kê: có bao nhiêu màu chủ đạo, bao nhiêu cỡ chữ tiêu đề, button có nhất quán về chiều cao và bo góc không. Viết một đoạn ngắn nhận xét mức độ nhất quán của họ.
Bài tập 2 — Xây bộ tokens nền tảng. Mở Figma (hoặc giấy). Định nghĩa cho một sản phẩm giả định: 1 màu primary, thang xám 5 mức, 4 màu trạng thái, thang spacing bội số 4 (ít nhất 6 mức), type scale 5 mức. Đặt tên tất cả theo quy ước ngữ nghĩa.
Bài tập 3 — Dựng component Button từ tokens. Dùng đúng bộ tokens vừa tạo, thiết kế component Button với: 2 variants (primary, secondary) và 4 states (default, hover, disabled, và một state bạn tự chọn). Yêu cầu: KHÔNG được gõ thẳng giá trị màu/spacing nào — tất cả phải tham chiếu token.
Bài tập 4 — Viết "guideline" một trang. Viết tài liệu một trang cho component Button: khi nào dùng primary, khi nào dùng secondary, kèm một ví dụ ĐÚNG và một ví dụ SAI.
Tóm tắt
Trong bài này, bạn đã phân biệt được hai khái niệm cốt lõi: component là một mảnh UI tái sử dụng, còn design system là cả hệ thống gồm tokens + components + patterns + guidelines + principles. Design system được tổ chức theo ba tầng: tokens ở dưới làm nền móng, components ở giữa, guidelines ở trên.
Ba ý quan trọng nhất cần khắc cốt ghi tâm:
- Bắt đầu từ tokens, không phải từ component. Tokens là nguồn chân lý duy nhất (Single Source of Truth) — định nghĩa một lần, dùng mọi nơi.
- Start small, but start. Ngay cả startup nhỏ cũng nên có bộ tokens tối thiểu từ sớm để tránh nợ thiết kế.
- Design system là ngôn ngữ chung của cả designer và developer — đặt tên token ngữ nghĩa và đồng bộ với code là chìa khóa.