Buổi 2 — Trạng thái, luồng và những gì mockup không cho thấy
Đây là buổi có giá trị thực dụng cao nhất trong khoá. Phần lớn lỗi trải nghiệm không nằm ở màn hình chính — nó nằm ở những trạng thái không ai vẽ.
Bốn trạng thái của mọi màn hình
Rỗng — chưa có dữ liệu. Với người dùng mới, đây là màn hình đầu tiên họ thấy, và nó thường bị bỏ trắng. Trạng thái rỗng tốt giải thích sẽ có gì ở đây và gợi ý hành động đầu tiên.
Đang tải — dữ liệu đang về. Cần cho biết đang xảy ra gì, và nếu lâu thì cho biết còn bao lâu. Màn hình trắng trong 3 giây được cảm nhận là hỏng.
Lỗi — có sự cố. Thông báo lỗi tốt nói rõ chuyện gì xảy ra và người dùng làm gì tiếp theo. Mã lỗi kỹ thuật không giúp được ai.
Có dữ liệu — trạng thái duy nhất mockup thường vẽ.
Thêm hai biến thể hay bị quên: một phần tử (bố cục trông kỳ khi chỉ có một dòng) và rất nhiều phần tử (danh sách 10.000 dòng có phân trang không?).
Luồng quan trọng hơn màn hình
Người dùng không trải nghiệm từng màn hình riêng lẻ — họ đi qua một chuỗi. Chuỗi đó mới là thứ cần thiết kế.
Vẽ luồng cho ba trường hợp: đường thuận lợi (mọi thứ đúng), đường lỗi (thất bại ở giữa chừng — hệ thống ở trạng thái nào?), và đường quay lại (người dùng bấm back, hoặc rời đi rồi quay lại sau — dữ liệu dở dang còn không?).
Đường thứ hai và thứ ba là nơi phần lớn độ phức tạp thật nằm ở đó.
Câu hỏi PM nên hỏi trong mọi buổi review thiết kế
- Trạng thái rỗng trông thế nào?
- Nếu bước này thất bại giữa chừng thì sao?
- Người dùng quay lại sau hai ngày, họ thấy gì?
- Trên màn hình điện thoại nhỏ nhất thì thế nào?
- Người dùng chưa đăng nhập bấm vào đây thì sao?
Mobile không phải là desktop thu nhỏ
Trên điện thoại: mạng chập chờn là bình thường chứ không phải ngoại lệ, ngón tay kém chính xác hơn con trỏ, và bàn phím che mất nửa màn hình khi nhập liệu.
Thiết kế cho desktop rồi "co lại" bỏ qua cả ba điều này.
Bài tập
Chọn một màn hình quan trọng trong sản phẩm của bạn. Liệt kê sáu trạng thái ở trên. Đếm xem bao nhiêu cái đã được thiết kế thật sự, bao nhiêu cái do engineer tự quyết lúc code.
<!--les-append-->
Danh sách kiểm bốn trạng thái — dùng cho mọi màn hình
Copy danh sách này vào Definition of Done của đội:
- [ ] Rỗng — có giải thích sẽ có gì ở đây, và một hành động gợi ý
- [ ] Đang tải — có dấu hiệu đang xử lý; nếu quá 3 giây, có biết còn bao lâu
- [ ] Lỗi — nói rõ chuyện gì xảy ra và làm gì tiếp; không hiện mã lỗi kỹ thuật
- [ ] Bình thường — đã thử với dữ liệu THẬT, không phải dữ liệu mẫu
Ba trạng thái nữa hay bị quên
Quá nhiều dữ liệu. Thiết kế đẹp với 5 dòng, vỡ với 500. Hỏi: nhiều nhất là bao nhiêu, và lúc đó màn hình trông thế nào?
Không có quyền. Người dùng thấy gì khi họ không được xem mục này? Ẩn đi hay hiện kèm giải thích? Hai lựa chọn cho hai trải nghiệm rất khác nhau.
Đang xử lý lâu. Khác với "đang tải". Nếu một thao tác mất 30 giây, người dùng có rời trang được không, có nhận thông báo khi xong không?
Vì sao trạng thái rỗng quan trọng nhất
Nó là màn hình đầu tiên mọi người dùng mới nhìn thấy — và nó thường được thiết kế cuối cùng, hoặc không được thiết kế.
Một trạng thái rỗng tốt làm ba việc: nói rõ đây là chỗ nào, giải thích sẽ có gì khi có dữ liệu, và cho một hành động đầu tiên. "Không có dữ liệu" không làm được việc nào trong ba việc đó.
Cách kiểm nhanh không cần công cụ
Yêu cầu designer hoặc lập trình viên cho bạn xem màn hình với: tài khoản vừa tạo (rỗng), mạng chậm (đang tải), ngắt mạng giữa chừng (lỗi), và tài khoản có nhiều dữ liệu nhất trong hệ thống.
Bốn lần xem này mất mười phút và bắt được nhiều lỗi hơn cả một vòng kiểm thử.
Đưa vào yêu cầu, không đưa vào lời nhắc
Nếu bốn trạng thái chỉ được nhắc miệng trong buổi duyệt, chúng sẽ bị quên khi lịch gấp. Cách bền vững là đưa vào chỗ không bỏ qua được: một dòng bắt buộc trong mẫu user story, hoặc một mục trong Definition of Done.
Chi phí là vài phút mỗi story. Lợi ích là không phải sửa những lỗi mà ai cũng biết trước là sẽ xảy ra.
Làm ngay
Mở sản phẩm của bạn bằng một tài khoản mới hoàn toàn. Chụp lại mọi màn hình rỗng bạn gặp. Đó là danh sách việc cần làm, xếp theo thứ tự người dùng mới sẽ gặp chúng. <!--/les-append-->