Hai thư viện, một sự thật
Một design system có hai nửa. Nửa thứ nhất nằm trong công cụ thiết kế: thư viện component mà designer kéo thả để làm màn hình. Nửa thứ hai nằm trong code: thư viện component mà kỹ sư gọi để dựng màn hình. Nếu hai nửa được làm riêng và cập nhật riêng, chúng sẽ lệch nhau, và đội quay lại đúng chỗ bài 1: màn hình trong thiết kế một kiểu, trên sản phẩm một kiểu.
Một nguồn sự thật nghĩa là với mỗi quyết định, có đúng một chỗ được coi là chuẩn, và mọi chỗ khác lấy từ đó. Không nhất thiết phải là code hay phải là file thiết kế. Điều quan trọng là cả đội biết chỗ đó là đâu khi hai bên khác nhau.
Giỏ Xanh chọn gì làm chuẩn
| Thứ | Nguồn sự thật | Lý do |
|---|---|---|
| Design token | Một file token trong kho code, xuất ra cho cả công cụ thiết kế và code | Thay đổi qua review như code, có lịch sử |
| Component đã phát hành | Thư viện code | Đó là thứ người dùng thật thấy |
| Component đang đề xuất | File thiết kế | Còn đang thay đổi, chưa đáng để viết code |
| Cách dùng và khi nào không dùng | Trang tài liệu của design system | Một chỗ cho cả designer, kỹ sư, PM, QA |
Một component đầy đủ gồm những gì
Một component không chỉ là một hình vẽ hay một đoạn code. Để dùng lại được, nó cần đủ năm phần:
| Phần | Nội dung | Ví dụ với nút |
|---|---|---|
| Tên | Một tên, giống nhau ở thiết kế, code, tài liệu | Button / Nút |
| Thuộc tính | Những gì người dùng component được chọn | biến thể: chính, phụ, viền, nguy hiểm; cỡ: nhỏ, vừa, lớn |
| Trạng thái | Mọi trạng thái có thể xảy ra | thường, rê chuột, đang nhấn, đang tải, vô hiệu, đang được chọn bằng bàn phím |
| Quy tắc dùng | Khi nào dùng, khi nào không | Mỗi màn hình tối đa một nút chính |
| Khả năng tiếp cận | Những gì đã được đảm bảo sẵn | Độ tương phản, vùng chạm, tên đọc được cho trình đọc màn hình |
Đường đi của một thay đổi
flowchart TD
A[Đổi token hoặc component trong kho chung] --> B[Review bởi đội nền tảng giao diện]
B --> C[Phát hành phiên bản mới của thư viện]
C --> D[Thư viện thiết kế cập nhật theo]
C --> E[Các squad nâng phiên bản trong code]
D --> F[Màn hình mới dùng bản mới]
E --> FĐiều cần thấy ở sơ đồ: không có mũi tên nào đi từ một màn hình cụ thể ngược lên thư viện. Nếu một squad cần nút khác đi, squad đó đề xuất thay đổi thư viện, không sửa riêng trong màn hình của mình. Bài 7 nói cách đề xuất được duyệt.
Trang tài liệu là sản phẩm cho người trong nhà
Thư viện code có thể chạy tốt mà không ai dùng, vì không ai tìm được thứ mình cần. Giỏ Xanh dựng một trang tài liệu nội bộ, mỗi component một trang, có:
- ảnh và bản chạy thử của mọi biến thể và trạng thái;
- đoạn code mẫu để dán vào;
- mục "dùng khi" và "đừng dùng khi", có ví dụ đúng và sai;
- tên tương ứng trong công cụ thiết kế;
- người phụ trách và phiên bản hiện tại.
Lệch nhau thì làm gì
Dù có quy trình, thiết kế và code vẫn sẽ lệch. Cách Giỏ Xanh xử lý:
- Phát hiện: QA và designer đánh dấu lệch bằng một nhãn riêng trong hệ thống ticket, để đếm được.
- Phân loại: lệch do màn hình không dùng component (lỗi của màn hình), hay do component trong code khác thiết kế (lỗi của thư viện).
- Sửa ở đúng tầng: lỗi của thư viện sửa trong thư viện một lần; lỗi của màn hình sửa bằng cách chuyển màn hình sang component.
PM và BA cần biết gì ở đây
Bạn không cần viết component. Nhưng bạn cần biết thư viện có gì để không yêu cầu một thứ đã có, và cần hiểu rằng "sửa riêng cho màn này" là một quyết định tạo ra nợ. Cách làm việc giữa sản phẩm, thiết kế, kỹ sư và QA quanh thư viện chung được nói thêm ở kỹ năng phối hợp Dev, QA và Design.
Làm ngay
Chọn một component phổ biến trong sản phẩm của bạn, như nút hoặc ô nhập. Tìm nó ở ba chỗ: file thiết kế, code, và tài liệu (nếu có). So sánh năm phần trong bảng: tên, thuộc tính, trạng thái, quy tắc dùng, khả năng tiếp cận. Ghi lại chỗ nào khác nhau và chỗ nào bị thiếu. Rồi hỏi đội: khi hai bên khác nhau, ai và cái gì đang được coi là đúng?