Giao diện không rối vì ai làm ẩu
Hầu như không đội nào cố ý làm giao diện lộn xộn. Mỗi màn hình, khi được làm, đều có lý do hợp lý: tính năng gấp nên designer vẽ nhanh một nút mới thay vì đi tìm nút cũ; kỹ sư không thấy component nào vừa nên viết một cái riêng; một chiến dịch khuyến mãi cần "nổi bật hơn" nên có thêm một sắc xanh. Từng quyết định đều nhỏ và đúng lúc đó. Cộng lại sau hai năm, sản phẩm có ba mươi kiểu nút và không ai trả lời được câu "nút chính của chúng ta trông thế nào?".
Cái giá của sự rối này không hiện ra trên bảng sprint. Nó nằm trong thời gian thiết kế lại thứ đã có, thời gian review tranh cãi về khoảng cách 12 hay 16 điểm ảnh, lỗi QA dạng "màn này lệch so với màn kia", và đặc biệt là trong những thay đổi tưởng đơn giản nhưng phải sửa ở hàng chục chỗ. Khoá học này dành cho PM, PO, BA và designer làm việc cùng kỹ sư front-end: những người không viết thư viện component nhưng quyết định mỗi ngày rằng giao diện sẽ được ghép lại hay vẽ lại.
Ví dụ xuyên suốt khoá học: Giỏ Xanh (giả định)
Giỏ Xanh là một ứng dụng đi chợ online giả định, bán rau, thịt, cá và đồ khô ở TP.HCM và Hà Nội, có bản web, Android và iOS. Mọi con số về Giỏ Xanh trong khoá học là bịa ra để minh hoạ, nhưng được giữ khớp nhau từ bài này sang bài khác.
| Thông tin | Giỏ Xanh |
|---|---|
| Sản phẩm | Web, app Android, app iOS |
| Số màn hình đang chạy | 46 |
| Đội | 3 squad (Tìm kiếm và danh mục, Giỏ hàng và thanh toán, Khuyến mãi và thành viên) |
| Con người | 3 PM, 2 BA, 4 designer, 18 kỹ sư web và mobile, 3 QA |
| Lỗi giao diện quý 2 | 140 lỗi, trong đó 42 lỗi là lệch thiết kế (30%) |
Chi phí của màn hình làm một lần
Một màn hình "làm một lần" là màn hình mà các phần của nó chỉ tồn tại cho riêng nó. Chi phí của nó đến muộn và đến nhiều lần:
| Chi phí | Nó xuất hiện ở đâu | Ví dụ ở Giỏ Xanh |
|---|---|---|
| Thiết kế lại | Designer vẽ lại thứ đã có ở màn khác | 5 kiểu thẻ sản phẩm cho cùng một việc: hiện một món hàng |
| Code lại | Kỹ sư viết component trùng | 7 kiểu ô nhập, mỗi kiểu kiểm lỗi một cách |
| Kiểm thử lại | QA phải kiểm từng biến thể riêng | Lỗi bàn phím che ô nhập chỉ sửa ở 2 trên 7 kiểu |
| Thay đổi đắt | Một quyết định phải sửa ở N chỗ | Đổi màu nút mất 3 sprint, sót 4 chỗ |
| Người dùng bối rối | Cùng một hành động trông khác nhau | Nút "Thanh toán" xanh ở web, cam ở app |
| Tranh luận lặp lại | Mỗi review bàn lại chuyện đã quyết | Khoảng cách giữa thẻ là 12 hay 16 điểm ảnh |
Vì sao nó tệ dần theo thời gian
Sự rối của giao diện tăng nhanh hơn số màn hình. Khi có 10 màn hình và 3 kiểu nút, người mới vào còn nhìn được hết và chọn đúng. Khi có 46 màn hình và 31 kiểu nút, chẳng ai biết kiểu nào là "chuẩn", nên cách an toàn nhất là làm thêm kiểu thứ 32. Mỗi màn hình làm một lần làm cho màn hình tiếp theo dễ bị làm một lần hơn.
Có ba dấu hiệu cho thấy đội của bạn đã qua điểm này:
- Câu "cái này có component chưa?" thường được trả lời bằng "chắc có, nhưng không biết ở đâu".
- Ước lượng cho một màn hình mới gần như không giảm dù đội đã làm nhiều màn tương tự.
- Một thay đổi thương hiệu, một quy định mới về khả năng tiếp cận, hay một đợt làm lại font trở thành dự án nhiều tháng.
Thứ khoá học đề xuất: ghép thay vì vẽ lại
Lối ra không phải là "mọi người cẩn thận hơn". Lối ra là đổi cách làm: thay vì thiết kế từng trang, đội thiết kế một hệ thống gồm những phần nhỏ có tên, có quy tắc, rồi ghép trang từ đó. Đây là tinh thần của atomic design, phương pháp do Brad Frost đặt tên và phổ biến, mượn hình ảnh hoá học: những phần nhỏ nhất kết hợp thành phần lớn hơn, rồi thành trang hoàn chỉnh. Bài 2 đi vào năm tầng của nó. Tóm tắt kỹ năng có tại Atomic design.
Một design system là phần thực thi của tư duy đó: thư viện thiết kế và thư viện code dùng chung, design token, tài liệu cách dùng, và một quy trình để nó sống được. Khoá học đi qua cả chín bước:
- Vì sao giao diện rối dần (bài này).
- Năm tầng của atomic design.
- Design token, ngôn ngữ chung về màu, khoảng cách, chữ.
- Kiểm kê giao diện trước khi xây.
- Từ thiết kế sang code với một nguồn sự thật.
- PM và BA viết spec dựa trên component.
- Quản trị design system.
- Khả năng tiếp cận làm một lần ở tầng nguyên tử.
- Bắt đầu nhỏ và đo mức sử dụng.
Vai trò của PM, PO và BA ở đây
Design system thường bị coi là "việc của designer và front-end". Thực tế, ba quyết định quan trọng nhất lại nằm ở phía sản phẩm: có dành thời gian để gom lại hay không, spec có viết theo component hay theo hình vẽ, và một yêu cầu "chỉ màn này thôi" có được phép tạo ra kiểu mới hay không. Một PM luôn chọn "làm riêng cho nhanh" sẽ thắng mọi sprint và thua cả năm.
Làm ngay
Mở sản phẩm của bạn và chọn ba màn hình mà người dùng hay đi qua liền nhau, ví dụ danh sách, chi tiết và thanh toán. Chụp lại và đếm: có bao nhiêu kiểu nút, bao nhiêu sắc màu chính, bao nhiêu cỡ chữ. Rồi hỏi kỹ sư một câu: lần gần nhất đổi một thứ dùng chung (màu, font, một nút), phải sửa ở bao nhiêu chỗ và mất bao lâu? Ghi hai con số đó lại. Chúng là điểm xuất phát bạn sẽ dùng ở bài 4 và bài 9.