Đừng xây thư viện trên trí nhớ
Khi quyết định làm design system, phản xạ đầu tiên của nhiều đội là mở công cụ thiết kế và bắt đầu vẽ "bộ component chuẩn". Vấn đề là bộ chuẩn đó được vẽ từ trí nhớ và sở thích của người vẽ, không phải từ thứ sản phẩm đang thật sự dùng. Kết quả thường là một thư viện đẹp mà không màn hình nào chuyển sang dùng được, vì nó thiếu đúng những biến thể mà sản phẩm cần.
Kiểm kê giao diện (interface inventory) là việc đi qua toàn bộ sản phẩm, chụp lại và phân loại mọi phần giao diện đang có. Đây cũng là một kỹ thuật mà Brad Frost đề xuất đi kèm atomic design. Nó trả lời hai câu hỏi: chúng ta có bao nhiêu thứ cho cùng một việc, và việc nào thật sự cần nhiều hơn một biến thể. Hướng dẫn từng bước có tại Kiểm kê giao diện, và mẫu bảng để điền có tại Mẫu kiểm kê giao diện.
Cách Giỏ Xanh làm trong năm ngày
Giỏ Xanh dành một tuần, với hai designer, một kỹ sư front-end, một BA, và PM của squad Thanh toán dẫn việc.
| Ngày | Việc | Kết quả |
|---|---|---|
| 1 | Thống nhất danh mục cần đếm và cách chụp | 12 nhóm: nút, ô nhập, màu, chữ, khoảng cách, thẻ, danh sách, thông báo, hộp thoại, điều hướng, biểu tượng, ảnh |
| 2 và 3 | Đi qua 46 màn hình trên cả web và app, chụp từng phần vào đúng nhóm | Bảng kiểm kê với ảnh chụp và vị trí |
| 4 | Gom các thứ gần giống nhau, ghi lý do khác nhau nếu có | Danh sách "khác vì cần" và "khác vì tình cờ" |
| 5 | Trình bày cho cả ba squad và ban lãnh đạo | Quyết định thứ tự gom lại |
Con số kiểm kê
| Nhóm | Đang có | Sau khi gom | Ghi chú |
|---|---|---|---|
| Nút | 31 kiểu | 4 biến thể × 3 cỡ = 12 tổ hợp | Chính, phụ, viền, nguy hiểm; nhỏ, vừa, lớn |
| Màu xanh thương hiệu | 17 mã | 5 bậc | Xem bài 3 |
| Cỡ chữ | 11 | 6 | Xem bài 3 |
| Ô nhập | 7 kiểu | 1 component, 5 trạng thái | Thường, đang nhập, lỗi, vô hiệu, chỉ đọc |
| Thẻ sản phẩm | 5 kiểu | 1 sinh vật, 2 biến thể | Có giảm giá hay không; trạng thái "đã trong giỏ" là thuộc tính |
Trình bày cho người ra quyết định
Kiểm kê chỉ có giá trị nếu nó dẫn tới quyết định. Ở buổi ngày 5, PM của Giỏ Xanh không trình bày bảng số trước. Chị dán lên tường 31 ảnh chụp nút cạnh nhau. Không ai cần giải thích thêm. Sau đó mới đến bảng số và đề xuất.
Một bài trình bày kiểm kê tốt có bốn phần:
- Bức tường: tất cả các biến thể của một nhóm, đặt cạnh nhau. Một hình ảnh thay cho mười trang lập luận.
- Con số: đang có bao nhiêu, cần bao nhiêu, gom được bao nhiêu phần trăm.
- Chi phí đang trả: 42 lỗi lệch thiết kế mỗi quý, đổi màu mất 3 sprint.
- Đề xuất bắt đầu: gom nhóm nào trước, ai làm, trong bao lâu. Bài 9 nói kỹ phần này.
Những sai lầm khi kiểm kê
| Sai lầm | Vì sao hại | Làm thay thế |
|---|---|---|
| Chỉ kiểm kê bản web, bỏ app | Bỏ sót phần lớn biến thể, vì app thường lệch nhất | Đi cả ba nền tảng, ghi nền tảng cho mỗi ảnh |
| Một người làm một mình | Thiếu góc nhìn code: hai thứ trông giống có thể là hai component khác | Ít nhất một designer và một kỹ sư |
| Đếm xong rồi để đó | Bảng kiểm kê thành tài liệu chết | Kết thúc bằng một quyết định có người chịu trách nhiệm |
| Đánh giá ai làm sai | Người làm ra kiểu thứ 31 sẽ phòng thủ | Nói về hệ thống, không nói về người |
| Kiểm kê quá chi tiết | Mất ba tuần đo từng điểm ảnh | Đủ để thấy mẫu hình là dừng |
Kiểm kê là việc định kỳ
Sau lần đầu, Giỏ Xanh lặp lại một bản kiểm kê nhẹ mỗi quý, chỉ cho các màn hình mới. Câu hỏi lúc này đổi thành: có bao nhiêu phần trong màn hình mới không đến từ thư viện, và vì sao? Đó cũng là một chỉ số bài 9 sẽ dùng.
Làm ngay
Dùng mẫu kiểm kê giao diện cho một nhóm duy nhất trong sản phẩm của bạn: nút hoặc ô nhập. Đi qua toàn bộ các màn hình chính trên mọi nền tảng, chụp mọi biến thể, dán cạnh nhau. Với mỗi cặp, ghi "khác vì cần" hay "khác vì tình cờ". Tính số biến thể đang có và số bạn thật sự cần, rồi viết một câu đề xuất cho người ra quyết định.