Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn vào làm tại một startup fintech ở TP.HCM. Sản phẩm có web app, mobile app iOS, mobile app Android, và một trang landing marketing. Bốn nền tảng, ba designer, năm developer. Sau sáu tháng, bạn nhận ra một sự thật đau lòng: nút "Xác nhận" có bảy màu xanh khác nhau trên toàn hệ thống. Bảy. Mỗi designer chọn một mã hex theo cảm tính, mỗi developer copy một giá trị khác nhau từ Figma. Khách hàng không nói ra, nhưng họ cảm nhận được sự thiếu nhất quán đó — và nó làm thương hiệu trông thiếu chuyên nghiệp.
Đây chính xác là vấn đề mà Design System sinh ra để giải quyết. Trong các bài trước, bạn đã học component design (Bài 13) và sẽ học sâu hơn về atomic design (Bài 14). Bài 15 này là điểm hội tụ: chúng ta sẽ ghép tất cả lại thành một hệ thống thiết kế hoàn chỉnh — không chỉ là một bộ component đẹp, mà là một "nguồn sự thật duy nhất" (single source of truth) cho cả đội thiết kế lẫn đội kỹ thuật.
Một design system tốt không phải thứ trang trí cho oai. Nó là công cụ vận hành. Nó giúp một designer mới vào team hôm nay có thể tạo ra màn hình đúng chuẩn ngay tuần đầu. Nó giúp developer không phải hỏi "padding ở đây bao nhiêu px?" mười lần một ngày. Nó là khác biệt giữa một sản phẩm trông như được làm bởi một đội ngũ chuyên nghiệp và một sản phẩm trông như được chắp vá. Ở bài này, tôi sẽ giúp bạn hiểu ba trụ cột tạo nên mọi design system — và quan trọng hơn, cách bắt đầu xây một cái từ con số không.
Khái niệm cốt lõi
Design System là gì? Định nghĩa ngắn gọn nhất tôi thích dùng: một bộ tiêu chuẩn được tài liệu hóa, cùng với các thành phần tái sử dụng được, dùng để xây dựng sản phẩm số một cách nhất quán và có khả năng mở rộng.
Lưu ý từ khóa: được tài liệu hóa, tái sử dụng, nhất quán, mở rộng. Thiếu bất kỳ yếu tố nào, bạn chỉ có một bộ sưu tập file Figma đẹp chứ không phải một hệ thống.
Mọi design system, dù lớn như Material Design của Google hay nhỏ như của một startup mười người, đều đứng trên ba trụ cột. Hãy đi qua từng cái.
Trụ cột 1 — Components (Thành phần)
Components là các khối xây dựng giao diện (UI building blocks). Đó là nút bấm (button), ô nhập liệu (input field), thẻ thông tin (card), modal, dropdown, badge, tab... Mỗi component là một đơn vị độc lập, đóng gói cả phần nhìn (visual) lẫn hành vi (behavior), và quan trọng nhất: tái sử dụng được.
Điểm mấu chốt của một component trong design system không phải là nó tồn tại, mà là nó được định nghĩa với đầy đủ các trạng thái và biến thể. Một button không chỉ có trạng thái mặc định. Nó có: default, hover, pressed, focused, disabled, loading. Nó có các biến thể: primary, secondary, ghost, danger. Nó có các kích cỡ: small, medium, large. Một component được làm cho ra hồn là component đã trả lời sẵn mọi câu hỏi mà designer hay developer có thể đặt ra khi dùng nó.
Khi bạn dùng component instance (bản sao) thay vì vẽ lại từ đầu mỗi lần, bạn nhận được sức mạnh thật sự: sửa ở component gốc một lần, toàn bộ sản phẩm cập nhật theo. Đây là lý do design system tiết kiệm thời gian theo cấp số nhân khi sản phẩm lớn dần.
Trụ cột 2 — Tokens (Mã thiết kế)
Nếu components là các viên gạch, thì design tokens là nguyên liệu thô tạo nên những viên gạch đó: màu sắc, khoảng cách, kích thước chữ, độ bo góc, độ đổ bóng.
Token là một biến có tên đại diện cho một giá trị thiết kế. Thay vì viết màu là #0066FF, bạn đặt tên cho nó: color-primary. Thay vì padding là 16px, bạn gọi nó là spacing-md. Giá trị thực vẫn nằm đó, nhưng giờ nó có một cái tên mang ý nghĩa và có thể tham chiếu khắp nơi.
Tại sao điều này quan trọng? Vì khi sếp yêu cầu đổi màu thương hiệu từ xanh dương sang tím, bạn không phải đi tìm và thay 400 chỗ ghi #0066FF. Bạn đổi một giá trị của token color-primary, và toàn bộ hệ thống thay đổi theo. Token chính là tầng trừu tượng (abstraction layer) tách giá trị khỏi cách dùng.
Ở Bài 16, bạn sẽ học kiến trúc token nhiều tầng (primitive, semantic, component) một cách chuyên sâu. Ở bài này, chỉ cần nắm: token là cách design system lưu trữ các quyết định thiết kế nền tảng một cách có hệ thống và có thể thay đổi tập trung.
Trụ cột 3 — Documentation (Tài liệu)
Đây là trụ cột bị xem nhẹ nhất, và cũng là trụ cột làm nên hay phá hỏng một design system. Bạn có thể có 200 component hoàn hảo và 500 token được đặt tên gọn gàng — nhưng nếu không ai biết khi nào dùng cái gì và dùng như thế nào, design system đó vô dụng.
Documentation trả lời những câu hỏi như: Khi nào dùng button primary, khi nào dùng secondary? Card này nên chứa tối đa bao nhiêu dòng text? Modal được dùng cho hành động gì, còn drawer cho hành động gì? Token color-error dùng cho lỗi hệ thống hay cả lỗi nhập liệu của người dùng?
Tài liệu tốt gồm: nguyên tắc sử dụng (usage guidelines), ví dụ đúng/sai (do's and don'ts), anatomy (giải phẫu cấu tạo component), và các quy tắc về accessibility. Bài 18 sẽ đào sâu vào nghệ thuật viết tài liệu này. Ở đây, hãy ghi nhớ một câu: một component không có tài liệu là một component sẽ bị dùng sai.
Ba trụ cột này không tách rời. Components được xây từ tokens, và cả hai được giải thích bởi documentation. Đó là một hệ sinh thái, không phải ba ngăn kéo riêng biệt.
Tình huống thực tế
Tình huống 1 — Tiki và bài toán bảy sắc cầu vồng
Hãy quay lại câu chuyện "bảy màu xanh" ở đầu bài, nhưng đặt vào bối cảnh một sàn thương mại điện tử lớn như Tiki (tình huống minh họa). Khi một sản phẩm phát triển nhanh, mỗi đội tính năng (feature team) tự làm UI của mình. Đội thanh toán dùng xanh #1A94FF, đội giỏ hàng dùng #0E8AEE, đội tài khoản dùng #2196F3. Mắt thường khó phân biệt từng cặp, nhưng khi đặt cạnh nhau trên một luồng mua hàng, người dùng cảm nhận một sự "chệch nhịp" mơ hồ.
Diễn giải: Vấn đề ở đây không phải kỹ năng designer kém. Vấn đề là không có nguồn sự thật duy nhất. Khi mỗi đội tự quyết định màu, sự phân mảnh là điều tất yếu. Giải pháp: định nghĩa một token color-brand-primary duy nhất, công bố cho toàn công ty, và mọi nút hành động chính phải tham chiếu token đó thay vì hardcode mã màu.
Bài học: Design system trước hết là một thỏa thuận về quản trị (governance), sau mới là vấn đề công cụ. Bạn cần một "luật" và một nơi để luật đó sống — đó chính là token.
Tình huống 2 — Startup SaaS Singapore rebrand trong một ngày
Một startup SaaS B2B ở Singapore (khoảng 30 nhân sự) quyết định rebrand: đổi tông thương hiệu từ xanh lá sang xanh navy, đổi font chữ, tăng độ bo góc của toàn bộ component cho "mềm" hơn. Với một sản phẩm gồm hơn 80 màn hình, đây nghe như một dự án hai tháng.
Thực tế, đội design của họ hoàn thành phần Figma trong một ngày làm việc. Lý do: họ đã xây design system trên nền token từ đầu. Đổi color-primary, đổi font-family-base, đổi radius-md — ba thay đổi token lan tỏa qua toàn bộ 80 màn hình tự động vì mọi component đều bind (gắn) vào token chứ không hardcode giá trị.
Diễn giải: Đây là minh chứng rõ nhất cho sức mạnh của tầng token. Khoản đầu tư công sức ban đầu để thiết lập token đúng chuẩn đã trả lại lợi tức khổng lồ khi cần thay đổi quy mô lớn.
Bài học: Token không phải thứ "để sau cũng được". Nó là khoản đầu tư hạ tầng. Sản phẩm càng có ý định mở rộng hay rebrand, token càng phải được dựng sớm.
Tình huống 3 — Đội ba người và cái bẫy "design system quá sớm"
Một bài học ngược chiều. Một nhóm ba người làm app gọi món ở Hà Nội từng dành nguyên một tháng xây "design system hoàn chỉnh" theo chuẩn Material Design — với hàng trăm component, năm tầng token, tài liệu chi tiết — trước khi sản phẩm có người dùng thật. Kết quả: một tháng đó gần như lãng phí, vì sau khi launch, họ phát hiện nhiều giả định về luồng người dùng sai, và phải đập đi xây lại nửa bộ component.
Diễn giải: Design system phải tương xứng với quy mô đội và độ chín của sản phẩm. Một đội ba người chưa có product-market fit không cần 200 component. Họ cần một bộ tối thiểu: bảng màu, thang khoảng cách, vài button, input, card — và mở rộng dần khi nhu cầu thật xuất hiện.
Bài học: Đừng over-engineer. Design system tốt nhất là cái vừa đủ cho hiện tại và dễ mở rộng cho tương lai. Bắt đầu nhỏ, lớn lên theo sản phẩm.
Hướng dẫn từng bước
Đây là lộ trình thực tế để xây một design system cơ bản từ con số không, áp dụng được cho một startup hay một dự án freelance.
Bước 1 — Audit hiện trạng (1–2 ngày). Trước khi tạo cái mới, hãy nhìn cái đang có. Chụp lại tất cả màn hình hiện tại. Liệt kê mọi màu, mọi cỡ chữ, mọi kiểu button bạn đang dùng. Bạn sẽ kinh ngạc khi đếm được "23 sắc xám khác nhau" trong một sản phẩm tưởng như đơn giản. Bản audit này phơi bày mức độ phân mảnh và là điểm xuất phát của mọi việc tiếp theo.
Bước 2 — Định nghĩa tầng token nền tảng. Bắt đầu với những thứ ít nhất và quan trọng nhất:
- Màu: chọn 1 màu primary, 1 màu phụ, một thang xám (5–7 bậc), và các màu trạng thái (success, warning, error, info).
- Khoảng cách: dựng một thang spacing nhất quán, thường theo bội số của 4 hoặc 8 (4, 8, 12, 16, 24, 32, 48...).
- Kiểu chữ: định nghĩa thang typography (cỡ chữ, độ đậm, line-height) cho heading, body, caption.
- Khác: độ bo góc (radius), độ đổ bóng (shadow), độ dày viền.
Bước 3 — Xây các component nền tảng. Dùng token vừa tạo để dựng bộ component cốt lõi: button, input, checkbox, radio, card, badge, modal. Với mỗi component, định nghĩa đầy đủ trạng thái và biến thể như đã nói ở trên. Tuyệt đối không hardcode giá trị — mọi màu, mọi padding phải bind vào token.
Bước 4 — Viết tài liệu tối thiểu. Với mỗi component, viết ngắn gọn: nó là gì, khi nào dùng, khi nào KHÔNG dùng, một ví dụ đúng và một ví dụ sai. Đừng cầu toàn ở bước này — một dòng hướng dẫn còn hơn không có gì.
Bước 5 — Công bố và quản trị. Đặt design system ở một nơi cả đội truy cập được. Thống nhất quy tắc: ai được thêm component mới? Quy trình đề xuất thay đổi ra sao? Đây là phần "design ops" mà Bài 19 sẽ đào sâu, nhưng ngay từ đầu bạn cần ít nhất một người "giữ cổng" để hệ thống không lại phân mảnh.
Bước 6 — Lặp và mở rộng. Design system là sản phẩm sống, không phải dự án có ngày kết thúc. Mỗi khi gặp nhu cầu mới (một loại thông báo mới, một pattern mới), hãy hỏi: cái này nên thành component dùng chung hay chỉ là trường hợp đặc biệt? Mở rộng có chủ đích.
Lỗi thường gặp & mẹo
Lỗi 1 — Hardcode giá trị thay vì dùng token. Đây là lỗi phổ biến nhất và nguy hiểm nhất. Designer vẽ một card và gõ trực tiếp #333333 thay vì gán token color-text-primary. Một lần thì vô hại, nhưng tích lũy lại thì cả hệ thống mất khả năng thay đổi tập trung. Mẹo: tự đặt luật cho bản thân — không bao giờ gõ giá trị thô vào thuộc tính component; luôn dùng biến.
Lỗi 2 — Tài liệu hóa quá muộn hoặc không bao giờ. Đội thường xây component rồi để đó, định "viết doc sau". "Sau" không bao giờ đến. Kết quả: người mới dùng sai, và design system mất uy tín. Mẹo: coi tài liệu là một phần của định nghĩa component — component chưa có doc thì coi như chưa xong.
Lỗi 3 — Nhầm design system với thư viện UI. Một bộ component trong Figma chưa phải design system. Nếu thiếu token làm nền và doc làm hướng dẫn, nó chỉ là một thư viện rời rạc. Mẹo: luôn kiểm tra đủ ba trụ cột trước khi gọi thứ bạn có là "design system".
Lỗi 4 — Đặt tên token theo giá trị thay vì ý nghĩa. Đặt tên color-blue là một cái bẫy: hôm nào màu thương hiệu đổi sang tím thì cái tên color-blue chỉ về màu tím sẽ gây nhầm lẫn chết người. Mẹo: đặt tên theo vai trò (color-primary, color-danger) chứ không theo bề ngoài (color-blue, color-red).
Lỗi 5 — Over-engineer ngay từ đầu. Như tình huống 3, một đội nhỏ không cần năm tầng token và 200 component. Mẹo: quy mô của design system phải khớp quy mô đội. Bắt đầu với cái tối thiểu chạy được.
Mẹo vàng: Hãy đo lường mức độ áp dụng (adoption). Một design system thành công không đo bằng số component, mà bằng tỷ lệ màn hình thực tế đang dùng nó. Nếu designer vẫn "vẽ tay" thay vì dùng component có sẵn, hệ thống của bạn đang thất bại ở đâu đó — thường là ở khâu tài liệu hoặc khâu khiến nó dễ dùng hơn việc tự vẽ.
Bài tập thực hành
Bài tập 1 — Audit phân mảnh. Chọn một app bạn dùng hàng ngày (Grab, Shopee, MoMo, hay một sản phẩm bạn đang làm). Chụp 8–10 màn hình. Đếm số màu khác nhau, số kiểu button, số cỡ chữ bạn nhận ra. Ghi lại con số. Mục tiêu: cảm nhận được mức độ phân mảnh tồn tại ngay cả ở sản phẩm lớn.
Bài tập 2 — Dựng tầng token tối thiểu. Mở Figma. Tạo một bộ token nền tảng cho một sản phẩm giả định: 1 màu primary, thang xám 5 bậc, 4 màu trạng thái, thang spacing theo bội số 8 (6 bậc), và thang typography 4 cấp. Đặt tên token theo vai trò, không theo màu sắc. Đây là móng nhà của mọi việc sau này.
Bài tập 3 — Một component, đủ trạng thái. Dùng token vừa tạo, xây một button hoàn chỉnh: 2 biến thể (primary, secondary), 3 cỡ (S, M, L), và đủ 5 trạng thái (default, hover, pressed, disabled, loading). Mọi thuộc tính phải bind vào token, không hardcode.
Bài tập 4 — Viết doc cho một component. Viết tài liệu cho button vừa tạo: nó là gì, khi nào dùng primary vs secondary, hai ví dụ "nên" và hai ví dụ "không nên". Giới hạn trong nửa trang. Bài tập này luyện kỹ năng truyền đạt — thứ phân biệt designer và người vận hành hệ thống.
Tóm tắt
Design system không phải một bộ sưu tập file đẹp — nó là nguồn sự thật duy nhất giúp một đội ngũ tạo ra sản phẩm nhất quán, nhanh, và có khả năng mở rộng. Nó đứng trên ba trụ cột không thể tách rời:
- Components — các khối UI tái sử dụng được, định nghĩa đầy đủ trạng thái và biến thể.
- Tokens — các biến đại diện cho giá trị thiết kế (màu, khoảng cách, chữ), cho phép thay đổi tập trung.
- Documentation — hướng dẫn khi nào và cách dùng, biến một bộ component thành một hệ thống thật sự.
Ở các bài tiếp theo, chúng ta sẽ đào sâu từng trụ cột: kiến trúc token nhiều tầng (Bài 16), theming đa thương hiệu (Bài 17), và nghệ thuật viết tài liệu (Bài 18). Nhưng nền tảng tư duy về "ba trụ cột" mà bạn vừa nắm ở đây sẽ theo bạn suốt sự nghiệp product designer.