Khi một website hay ứng dụng lớn dần, nút bấm bắt đầu mỗi nơi một kiểu, màu xanh có ba sắc độ khác nhau, khoảng cách lúc 12 lúc 16 pixel mà chẳng ai nhớ vì sao. Đó là lúc nhóm làm sản phẩm cần một bộ khung dùng chung để mọi người tra cùng một nguồn. Bộ khung đó chính là design system.
Hiểu đúng về design system
Theo Nielsen Norman Group, design system là một bộ tiêu chuẩn sống và hoàn chỉnh, dùng để quản lý thiết kế ở quy mô lớn thông qua các component và pattern (mẫu lặp — nhóm phần tử giao diện ghép lại thành một tương tác quen thuộc) tái dùng được. Từ khoá quan trọng ở đây là “sống”: design system không phải một file PDF chốt một lần rồi để đó, mà cập nhật liên tục theo sản phẩm.
Một cách dễ hình dung: design system đứng giữa hai phía. Khi bạn nhờ Web22 dựng website, người thiết kế lấy từ đó các khối dựng sẵn để ráp màn hình nhanh và đúng chuẩn. Lập trình viên lấy từ đó đoạn code tương ứng để dựng lại y hệt. Nhờ một nguồn chung, cái vẽ ra và cái chạy thật không lệch nhau.
Một design system gồm những phần nào
Theo cách phân lớp của Nielsen Norman Group, một kho design system thường chứa bốn nhóm nội dung, đi từ nhỏ tới lớn:
1. Design token — đơn vị nhỏ nhất
Design token (biến thiết kế — đơn vị nhỏ nhất lưu một quyết định như màu, cỡ chữ, khoảng cách) là tầng nền. Thay vì gõ mã màu #FF6986 rải rác khắp nơi, bạn đặt tên nó một lần, ví dụ color-brand-primary, rồi tham chiếu ở mọi chỗ. Đổi một lần ở token là đổi đồng loạt, không phải dò sửa tay từng file. Đây là lớp giúp design system tránh “trôi” (drift — các giá trị lệch dần theo thời gian). Phần này được nói riêng trong bài design token là gì.
2. Component library — tập component tái dùng
Trên nền token là các component (thành phần giao diện) như nút bấm, ô nhập, thẻ thông tin. Mỗi component được mô tả đủ trạng thái (mặc định, di chuột qua, đang chọn, vô hiệu) và các thuộc tính tuỳ chỉnh (cỡ, nội dung chữ). Tập hợp chúng gọi là component library — kho phần tử để ráp lại thành màn hình thay vì vẽ lại từ đầu mỗi lần.
3. Pattern và style guide — quy ước dùng chung
Pattern là các cụm component ghép lại để giải một bài toán quen thuộc, ví dụ luồng đăng nhập hay một biểu mẫu nhiều bước. Bên cạnh đó là style guide (cẩm nang phong cách) ghi rõ quy ước về thương hiệu, giọng chữ và quy tắc thị giác. Nhiều người nhầm style guide với cả design system; thực ra style guide chỉ là một phần con. Bài phân biệt style guide và design system nói kỹ chỗ này.
4. Tài liệu và tài nguyên
Cuối cùng là tài liệu hướng dẫn dùng (khi nào dùng component nào, dùng ra sao), kèm file thiết kế gốc (thường là Figma), logo, bộ phông, icon. Theo xu hướng 2026, tài liệu ngày càng “sống” cùng code — mô tả component nằm ngay cạnh chính component đó, để đọc tới đâu thấy đúng phiên bản đang chạy tới đó.
Hai cách tổ chức và dựng phổ biến
Có một phương pháp tư duy nổi tiếng để sắp xếp các phần trên theo tầng: atomic design (thiết kế nguyên tử — chia giao diện thành atom, molecule, organism rồi ghép lên). Đây là cách nghĩ về cấu trúc, không phải một công cụ. Bạn đọc thêm ở bài atomic design là gì.
Về công cụ dựng, hai nơi thường gặp:
| Nơi dựng | Phù hợp khi |
|---|---|
| Figma | Bắt đầu từ phía thiết kế, làm thư viện component và token để cả nhóm dùng chung. Xem cách xây design system trong Figma. |
| Code (web) | Dựng thẳng bằng shadcn/ui hoặc Tailwind để bản thiết kế và bản chạy là một. |
Khi nào một dự án cần design system
Không phải dự án nào cũng cần. Một trang đơn lẻ, làm một lần rồi gần như không sửa, thì dựng design system là phí công. Bộ khung này đáng đầu tư khi xuất hiện các dấu hiệu sau:
- Giao diện trải trên nhiều trang, nhiều thiết bị, hoặc cả web lẫn ứng dụng.
- Nhiều người cùng làm, dễ mỗi người ráp một kiểu.
- Sản phẩm còn sửa và mở rộng dài hạn, không phải làm xong là dừng.
Đây là bài toán chi phí và lợi ích thật sự, nên góc nhìn dành cho chủ doanh nghiệp được tách thành bài riêng: khi nào đầu tư design system mới đáng.
Có rồi vẫn phải nuôi
Một điểm hay bị quên: design system không phải làm một lần là xong. Component cần thêm mới, token cần điều chỉnh khi thương hiệu đổi, tài liệu cần cập nhật để không nói một đằng mà code làm một nẻo. Phần vận hành lâu dài này nằm ở bài duy trì design system. Bỏ bê khâu nuôi, hệ thống sẽ trôi dần và quay lại đúng mớ hỗn loạn ban đầu.
Câu hỏi thường gặp
Design system khác thư viện UI dựng sẵn thế nào?
Thư viện UI dựng sẵn là tập component chung cho mọi người, chưa mang quyết định thương hiệu của riêng bạn. Design system gói cả token, nguyên tắc và tài liệu riêng cho một sản phẩm cụ thể, nên nó “của bạn” theo cách thư viện chung không có.
Dự án nhỏ có cần design system không?
Thường là chưa cần một hệ thống đầy đủ. Nhưng đặt sẵn vài design token cơ bản (màu, cỡ chữ, khoảng cách) ngay từ đầu thì luôn đáng, vì sau này lớn lên đỡ phải làm lại từ con số không.
Bắt đầu từ token hay từ component trước?
Bắt đầu từ token. Token là nền; component dựng trên token. Làm component trước rồi mới rút token ra thường tốn công sửa lại nhiều hơn.
Nếu bạn đang dựng một sản phẩm cần giao diện nhất quán và lớn lên không vỡ, dịch vụ xây design system của Web22 làm trọn từ token, component tới tài liệu bàn giao đúng như bản chạy thật.