Design System
Bộ quy tắc và thư viện thành phần giao diện dùng chung cho cả sản phẩm: màu, chữ, nút, biểu mẫu, thông báo, kèm hướng dẫn khi nào dùng cái nào.
Định nghĩa
Kho phụ tùng dùng chung của giao diện. Thay vì mỗi màn hình lại vẽ một kiểu nút, một cỡ chữ, một sắc xanh hơi khác nhau, cả sản phẩm dùng chung một bộ: nút chính trông thế này, thông báo lỗi trông thế kia, khoảng cách giữa các khối theo bội số 8. Kèm theo là hướng dẫn khi nào dùng thành phần nào, thứ mà nhiều nơi quên mất và chỉ dựng thư viện suông.
Design system giải quyết bài toán nhất quán khi có nhiều người cùng làm giao diện trong nhiều năm.
Gồm những gì
- Nền tảng: bảng màu có ngữ nghĩa (màu chính, màu cảnh báo, màu lỗi), thang chữ, thang khoảng cách, bo góc, đổ bóng.
- Thành phần: nút, ô nhập, dropdown, bảng, thẻ, dialog, toast — mỗi cái đủ các trạng thái mặc định, di chuột, đang focus, vô hiệu hóa, đang tải, lỗi.
- Mẫu bố cục: form hai cột, trang danh sách kèm bộ lọc, màn chi tiết có tab.
- Quy ước chữ nghĩa: gọi khách là "quý khách" hay "bạn", nút ghi "Lưu" hay "Cập nhật", thông báo lỗi viết theo cấu trúc nào.
Phần thứ năm là thứ phân biệt design system thật với một file Figma đông đúc. Dialog dùng khi nào, toast dùng khi nào, bảng bao nhiêu dòng thì chuyển sang phân trang. Viết được phần đó thì bốn phần trên mới có chỗ bám.
So sánh với style guide và component library
| Style guide | Component library | Design system | |
|---|---|---|---|
| Nội dung | Quy định màu, font, logo | Mã nguồn các thành phần dùng lại được | Cả hai, cộng nguyên tắc và hướng dẫn |
| Dạng | Tài liệu PDF hoặc trang web | Thư viện code, ví dụ package React | Tài liệu sống, đồng bộ giữa Figma và code |
| Ai dùng | Designer, marketing | Dev | Cả designer, dev, BA, QC |
| Thiếu nó thì | Mỗi màn một tông màu | Dev code lại nút bấm ở 12 chỗ | Sản phẩm chắp vá, sửa một chỗ hỏng chỗ khác |
Nhiều công ty tưởng mình có design system nhưng thực ra chỉ có một file Figma đầy component và không ai viết hướng dẫn. Thư viện component thì dựng trong một sprint. Bộ hướng dẫn khi nào dùng dialog, khi nào dùng toast thì viết cả quý vẫn chưa xong, và đó mới là phần quyết định.
Ví dụ thực tế
Một ngân hàng có ba sản phẩm số: app khách hàng cá nhân, cổng doanh nghiệp và màn hình giao dịch viên tại quầy. Ba team, ba nhà thầu khác nhau, cùng một thương hiệu.
Trước khi có design system, riêng thông báo lỗi khi sai OTP đã có ba cách hiển thị: một bên hiện dialog đỏ, một bên hiện dòng chữ dưới ô nhập, một bên đẩy toast rồi tự tắt sau 3 giây và người dùng lớn tuổi không kịp đọc. Bộ phận chăm sóc khách hàng nhận cả trăm cuộc gọi mỗi tháng chỉ vì cùng một tình huống nhưng ba hệ thống nói ba kiểu.
Sau khi dựng design system dùng chung, quy tắc rất đơn giản: lỗi liên quan tới một ô nhập thì hiện ngay dưới ô đó và giữ nguyên cho tới khi người dùng sửa. Số cuộc gọi loại này giảm hẳn. Không một tính năng nghiệp vụ nào thay đổi.
BA được lợi gì
Nhiều BA nghĩ đây là chuyện của designer. Thực tế nó tiết kiệm cho BA rất nhiều giấy mực:
- Viết đặc tả ngắn lại. Thay vì mô tả trạng thái lỗi của từng ô nhập ở từng màn, chỉ cần ghi "áp dụng mẫu lỗi cấp trường theo design system". Ba dòng thay cho ba trang.
- Ít câu hỏi lặt vặt từ dev. Nút phụ đặt trái hay phải, bảng bao nhiêu dòng một trang — những thứ đó có sẵn quy ước.
- Ước lượng chính xác hơn. Màn hình ghép từ thành phần có sẵn thì nhanh hơn hẳn màn hình cần thiết kế mới, và bạn nhận ra điều đó ngay từ lúc refinement.
- Có chỗ tra khi tranh cãi. "Tại sao nút xóa lại màu đỏ" — mở tài liệu ra, hết tranh cãi.
Chỗ cần cẩn thận là design system không tự đúng nghiệp vụ. Nó cho bạn cái bảng đẹp, nhưng bảng đó hiển thị cột nào, sắp xếp mặc định theo gì, ai được xem cột doanh thu — vẫn là việc của BA. Đừng để sự tiện lợi của thư viện kéo cả team vào thói quen ghép màn hình cho nhanh mà quên hỏi người dùng cần thấy gì trước.
