Design system, hay hệ thống thiết kế, là tập hợp các quy tắc, giá trị dùng chung và thành phần giao diện dựng sẵn giúp mọi màn hình của một sản phẩm trông và hoạt động nhất quán. Nó gồm ba lớp: những giá trị nền như màu, cỡ chữ, khoảng cách (thường gọi là token); các thành phần như nút, ô nhập, thẻ, thanh điều hướng cùng mọi trạng thái của chúng; và tài liệu hướng dẫn khi nào dùng thành phần nào.
Nghe tới design system, nhiều người nghĩ tới bộ tài liệu đồ sộ của các tập đoàn công nghệ. Thực tế, một trang web bán hàng mười màn hình cũng hưởng lợi từ một hệ thống tối thiểu: mười lăm thành phần, một thang khoảng cách, một trang ghi chú. Bài này phân biệt design system với style guide và thư viện thành phần, chỉ ra mức tối thiểu cho dự án nhỏ, và cách dùng AI ở hai khâu tốn công nhất là kiểm kê giao diện cũ và viết tài liệu.
Design system, thư viện thành phần và style guide
Ba khái niệm lồng vào nhau, và người ta hay gọi lẫn. Phân biệt giúp bạn báo đúng phạm vi với khách khi được nhờ "làm cái design system".
| Khái niệm | Gồm những gì | Thường ai làm | Dự án nhỏ có cần |
|---|---|---|---|
| Style guide | Quy định thị giác: logo, màu, chữ, giọng văn, cách dùng ảnh | Người làm nhận diện thương hiệu | Có, thường đã có từ bộ nhận diện |
| Token | Giá trị được đặt tên: màu chính, khoảng cách nhỏ, bo góc vừa, cỡ chữ tiêu đề | Người thiết kế giao diện, thống nhất với lập trình viên | Có, dù chỉ vài chục giá trị |
| Thư viện thành phần | Nút, ô nhập, thẻ, hộp thoại… cùng biến thể và trạng thái | Người thiết kế dựng trong phần mềm, lập trình viên dựng bằng mã | Có, ở mức những thành phần thật sự dùng |
| Design system | Tất cả những thứ trên cộng với nguyên tắc, tài liệu hướng dẫn, quy trình cập nhật | Một nhóm, có người phụ trách | Phiên bản rút gọn là đủ |
Khi khách nói "làm design system", hỏi lại họ cần dùng cho ai: chỉ cho bạn và một lập trình viên, hay cho nhiều nhóm làm nhiều sản phẩm. Câu trả lời quyết định khối lượng việc chênh nhau hàng chục lần.
Mức tối thiểu cho một trang web hay ứng dụng nhỏ
Một hệ thống tối thiểu cần trả lời được câu hỏi: nếu hôm nay thêm một màn hình mới, người làm có đủ thứ để dựng nó mà không phải tự nghĩ ra nút mới, màu mới, khoảng cách mới không. Nếu câu trả lời là có, hệ thống đã làm được việc chính.
Thực tế, phần lớn sản phẩm nhỏ dùng khoảng mười đến hai mươi thành phần: nút (chính, phụ, chữ), ô nhập chữ, ô chọn, hộp kiểm, nút gạt, thẻ sản phẩm hoặc thẻ nội dung, thanh điều hướng trên và dưới, thanh tìm kiếm, thông báo ngắn, hộp thoại xác nhận, nhãn trạng thái, khung ảnh, phân trang. Bắt đầu từ những gì sản phẩm đang dùng, không dựng trước những thành phần "có thể sẽ cần".
Phần token tối thiểu gồm bảng màu theo vai trò (nền, chữ chính, chữ phụ, màu nhấn, màu báo lỗi, màu báo thành công), thang cỡ chữ năm sáu mức, thang khoảng cách năm sáu mức, hai ba mức bo góc và một hai mức đổ bóng nếu có. Ít mức hơn nghĩa là ít quyết định hơn, giao diện tự nhiên nhất quán hơn.
Tài liệu tối thiểu có thể chỉ là một trang trong chính tệp thiết kế: liệt kê thành phần, chụp các trạng thái, ghi hai ba dòng khi nào dùng và khi nào không. Không cần trang web tài liệu riêng cho tới khi có nhiều người cùng dùng.
Đặt tên token theo vai trò, không theo giá trị
Tên theo vai trò sống lâu hơn. Một token tên "xanh dương 500" sẽ thành vô nghĩa khi thương hiệu đổi sang màu khác. Token tên "màu nhấn" hay "màu nút chính" vẫn đúng sau khi đổi giá trị, và mọi nơi dùng nó tự cập nhật.
Hai tầng tên giúp đổi giao diện dễ. Nhiều hệ thống dùng hai tầng: tầng gốc là bảng màu thô có tên theo giá trị, tầng ngữ nghĩa là tên theo vai trò trỏ vào tầng gốc. Muốn làm giao diện tối, bạn chỉ đổi phần trỏ của tầng ngữ nghĩa.
Thang khoảng cách nên theo một bội số. Ví dụ các mức 4, 8, 12, 16, 24, 32 điểm. Lập trình viên và người thiết kế cùng gọi tên mức, như "khoảng cách vừa", thay vì đo từng con số, nên ít lệch hơn.
Cỡ chữ đặt tên theo chức năng. Tiêu đề trang, tiêu đề mục, chữ thân, chữ chú thích, chữ trên nút. Tránh tên kiểu "chữ 18", vì khi đổi cỡ thân bài cho dễ đọc hơn trên điện thoại, tên đó lại sai.
Thống nhất tên với lập trình viên từ đầu. Token chỉ có giá trị khi cả hai bên dùng cùng tên. Ngồi với lập trình viên mười lăm phút để chốt cách đặt tên tiết kiệm hàng giờ dịch qua dịch lại về sau.
Thành phần và biến thể: một chiếc nút có bao nhiêu trạng thái
Thành phần trong design system khác hình vẽ trong tệp ấn phẩm ở chỗ nó phải có đủ trạng thái. Lấy ví dụ nút bấm chính, danh sách trạng thái thường gặp:
- Bình thường: trạng thái mặc định khi màn hình mở ra.
- Di chuột qua: trên máy tính, báo cho người dùng biết đây là thứ bấm được. Điện thoại không có trạng thái này nên không được dùng nó để truyền thông tin quan trọng.
- Đang được chọn bằng bàn phím: viền hoặc vòng sáng rõ ràng cho người dùng bàn phím, không được xoá chỉ vì thấy xấu.
- Đang nhấn: phản hồi tức thì khi ngón tay chạm vào.
- Đang xử lý: sau khi bấm, nút báo đang chờ và tạm khoá để tránh bấm hai lần.
- Không dùng được: khi điều kiện chưa đủ; nên kèm lý do ở gần đó thay vì để người dùng đoán.
- Biến thể kích thước và kiểu: lớn, vừa, nhỏ; có biểu tượng hay không; chiếm hết bề ngang hay vừa nội dung.
Nhân số trạng thái với số biến thể, một chiếc nút có thể ra vài chục tổ hợp. Đây là chỗ AI giúp bạn không sót: đưa tên thành phần và mô tả ngắn, nhờ liệt kê mọi trạng thái và biến thể thường gặp, rồi bạn chọn những cái sản phẩm thật sự cần. Đừng dựng đủ mọi tổ hợp nếu không dùng; mỗi biến thể thêm vào là một thứ phải bảo trì.
Dùng AI kiểm kê giao diện cũ trước khi dựng hệ thống
Với sản phẩm đã chạy một thời gian, bước đầu tiên là kiểm kê: chụp lại mọi nút, ô nhập, thẻ đang có để thấy đang có bao nhiêu kiểu khác nhau cho cùng một việc. Việc này tốn công và nhàm, nên chia với AI như sau:
- Chụp màn hình các trang chính, thay dữ liệu thật của khách bằng dữ liệu mẫu hoặc làm mờ trước khi chụp.
- Cắt riêng từng loại thành phần ra một bảng: tất cả các nút vào một chỗ, tất cả các ô nhập vào một chỗ.
- Đưa từng nhóm ảnh cho chatbot có khả năng đọc ảnh và hỏi: "Trong nhóm nút này, có bao nhiêu kiểu khác nhau về màu nền, bo góc, cỡ chữ, chiều cao? Nhóm những nút gần giống nhau lại và chỉ ra khác biệt."
- Tự kiểm lại kết quả bằng cách đo trong phần mềm thiết kế. AI đọc ảnh có thể nhầm vài điểm ảnh, nhưng giúp bạn thấy nhanh bức tranh tổng thể.
- Với mỗi nhóm, chọn một kiểu làm chuẩn, ghi lại các kiểu sẽ bị gộp vào.
- Lập danh sách thành phần chuẩn và token rút ra từ đó, rồi mới bắt đầu dựng thư viện.
Kết quả kiểm kê là thứ thuyết phục khách tốt nhất. Một bảng cho thấy trang web đang có mười một kiểu nút chính khác nhau nói nhiều hơn mọi lời giải thích về sự cần thiết của hệ thống.
Viết tài liệu thành phần với sự giúp đỡ của AI
Tài liệu là phần hay bị bỏ nhất, vì người dựng thư viện nghĩ mọi thứ đã rõ. Ba tháng sau, khi người mới vào dự án hoặc chính bạn quên, những câu hỏi như "thẻ sản phẩm có được bỏ ảnh không" hay "khi nào dùng hộp thoại, khi nào dùng thông báo ngắn" sẽ quay lại.
AI giúp viết nháp tài liệu nhanh nếu bạn đưa đủ bối cảnh. Ví dụ câu lệnh: "Viết tài liệu ngắn cho thành phần thông báo ngắn trong một ứng dụng đặt lịch. Thành phần có bốn loại: thành công, cảnh báo, lỗi, thông tin; tự ẩn sau vài giây trừ loại lỗi. Gồm: khi nào dùng, khi nào không dùng, nội dung viết thế nào, lỗi hay gặp. Mỗi mục tối đa bốn dòng." Sau đó bạn sửa theo quyết định thật của dự án.
Cái AI không làm thay được là quyết định quy tắc. "Khi nào dùng hộp thoại" là lựa chọn thiết kế, phụ thuộc sản phẩm và người dùng; AI chỉ đưa ra những quy tắc phổ biến để bạn cân nhắc. Ghi rõ quyết định của dự án, kể cả khi nó khác thông lệ, kèm lý do ngắn.
Duy trì hệ thống: ai được sửa và sửa thế nào
Hệ thống thiết kế hỏng không phải vì dựng sai mà vì không ai giữ. Mỗi lần có màn hình mới, người làm vội tạo thêm một biến thể "chỉ dùng ở đây", và một năm sau thư viện lại rối như lúc đầu. Dự án nhỏ cũng nên có một người được giao giữ thư viện, dù đó chính là bạn.
Quy trình đơn giản: muốn thêm thành phần hay biến thể mới, trước hết kiểm xem thành phần sẵn có có làm được việc không. Nếu thật sự cần, thêm vào thư viện chung kèm ghi chú, không tạo bản rời trong màn hình. Mỗi lần thay đổi đáng kể, ghi một dòng nhật ký: ngày, thay đổi gì, vì sao, ảnh hưởng màn hình nào, và báo cho lập trình viên.
Định kỳ vài tháng một lần, rà lại những thành phần ít dùng hoặc không còn dùng và gỡ bớt. Hệ thống gọn là hệ thống người ta chịu dùng. Nếu bàn giao dự án cho người khác, bản nhật ký và trang tài liệu ngắn quý hơn mọi tệp thiết kế đẹp.
Câu hỏi thường gặp
Freelancer làm một trang web cho khách có cần design system không?
Không cần một hệ thống đầy đủ, nhưng nên có thư viện thành phần và token cơ bản trong tệp thiết kế. Nó giúp bạn làm nhanh hơn khi thêm trang, giúp lập trình viên dựng đúng, và là thứ bàn giao có giá trị để khách hoặc người làm sau tiếp tục.
Nên dùng bộ thành phần có sẵn hay tự dựng từ đầu?
Bộ thành phần có sẵn của các hệ thống phổ biến giúp tiết kiệm thời gian và đã tính tới nhiều trạng thái, khả năng tiếp cận. Tự dựng cho phép khớp thương hiệu hơn. Cách hay gặp ở dự án nhỏ là lấy một bộ có sẵn làm nền rồi chỉnh token cho đúng thương hiệu. Đọc kỹ giấy phép của bộ bạn dùng.
Design token có cần lập trình viên tham gia không?
Nên có. Token chỉ phát huy tác dụng khi cùng một tên được dùng ở tệp thiết kế và trong mã. Bạn đề xuất danh sách, lập trình viên cho biết cách họ tổ chức trong mã, hai bên chốt một cách đặt tên chung.
Thư viện thành phần trong phần mềm thiết kế có tự đồng bộ với mã không?
Thường không tự động hoàn toàn. Một số phần mềm và công cụ trung gian cho phép xuất token hoặc đồng bộ một phần, nhưng thành phần trong mã vẫn do lập trình viên dựng. Tính năng này thay đổi theo phiên bản, nên kiểm công cụ cụ thể mà nhóm bạn dùng.
Có thể nhờ AI tạo cả bộ thành phần không?
AI có thể gợi ý danh sách thành phần, trạng thái, cách đặt tên và viết nháp tài liệu. Dựng thành phần trong phần mềm với cấu trúc lớp đúng, biến thể đúng, khoảng cách theo token vẫn là việc của người thiết kế. Ảnh AI vẽ bộ nút đẹp không dùng làm thư viện được.
Khi nào hệ thống nhỏ cần nâng lên thành trang tài liệu riêng?
Khi có từ ba bốn người trở lên cùng thiết kế hoặc dựng giao diện, khi có nhiều sản phẩm dùng chung thành phần, hoặc khi câu hỏi "dùng cái nào" lặp lại thường xuyên. Trước đó, một trang ghi chú trong tệp thiết kế cộng nhật ký thay đổi thường là đủ.