Buổi 5 — Thiết kế cho lỗi và cho sự phục hồi
Người dùng sẽ mắc lỗi. Câu hỏi không phải làm sao ngăn hoàn toàn, mà là chuyện gì xảy ra sau đó.
Ba tầng xử lý lỗi, theo thứ tự ưu tiên
Tầng 1 — Ngăn lỗi xảy ra. Vô hiệu hoá nút không dùng được thay vì báo lỗi sau khi bấm. Chọn sẵn giá trị mặc định hợp lý. Giới hạn định dạng nhập ngay tại chỗ nhập.
Tầng 2 — Làm lỗi dễ nhận ra. Kiểm tra ngay khi người dùng rời khỏi ô nhập, không đợi tới lúc bấm gửi. Báo lỗi ngay cạnh ô sai, không gom hết lên đầu trang.
Tầng 3 — Làm lỗi dễ khắc phục. Giữ lại dữ liệu đã nhập, chỉ ra chính xác chỗ sai, và nói rõ cần làm gì.
Tầng 1 luôn tốt hơn tầng 3. Rất nhiều nỗ lực viết thông báo lỗi hay lẽ ra nên dành cho việc làm lỗi đó không thể xảy ra.
Thông báo lỗi tốt
Ba thành phần: chuyện gì xảy ra, vì sao, làm gì tiếp theo.
Kém: "Đã xảy ra lỗi. Mã: ERR_5012" Được: "Không lưu được vì mất kết nối. Nội dung của bạn vẫn còn — thử lại khi có mạng."
Chú ý phần thứ ba trong ví dụ trên: nó trả lời nỗi lo lớn nhất của người dùng (mình có mất công không) trước khi họ kịp hỏi.
Undo mạnh hơn confirm
Hộp thoại "Bạn có chắc không?" bị bấm qua theo phản xạ sau vài lần. Nó tạo ma sát cho mọi người mà bảo vệ được rất ít.
Undo thì ngược lại: không cản trở ai, và cứu được đúng người vừa mắc lỗi. Với thao tác xoá, "Đã xoá — Hoàn tác" gần như luôn tốt hơn một hộp xác nhận.
Ngoại lệ: thao tác thật sự không thể hoàn tác (chuyển tiền, gửi email hàng loạt). Ở đó cần xác nhận có ma sát thật — ví dụ gõ lại tên đối tượng.
Trạng thái chờ và cảm nhận thời gian
Thời gian cảm nhận khác thời gian thật. Một thao tác 3 giây có phản hồi tức thì và thanh tiến trình được cảm nhận nhanh hơn một thao tác 2 giây với màn hình đứng im.
Nguyên tắc: dưới 100ms cảm giác tức thì; tới 1 giây vẫn liền mạch nhưng nên có phản hồi; trên 1 giây bắt buộc có chỉ báo; trên 10 giây nên cho làm việc khác trong lúc chờ.
Mất dữ liệu là lỗi nghiêm trọng nhất
Người dùng tha thứ cho chậm, cho xấu, cho khó tìm. Họ không tha thứ cho việc mất công sức đã bỏ ra.
Tự động lưu nháp, giữ nội dung form khi có lỗi, cảnh báo trước khi rời trang có thay đổi chưa lưu — ba việc này đáng ưu tiên hơn hầu hết tính năng mới.
Bài tập
Liệt kê ba thao tác nguy hiểm nhất trong sản phẩm của bạn. Với mỗi cái, kiểm tra: có ngăn được không, có undo không, và nếu thất bại giữa chừng thì hệ thống ở trạng thái nào.
<!--les-append-->
Viết thông báo lỗi dùng được
Một thông báo lỗi tốt trả lời ba câu, theo đúng thứ tự này:
- Chuyện gì xảy ra — bằng ngôn ngữ người dùng
- Vì sao — nếu biết và nếu có ích
- Làm gì tiếp — luôn luôn phải có
| Thông báo tệ | Thông báo dùng được |
|---|---|
| "Lỗi 500" | "Không lưu được. Kết nối bị gián đoạn — dữ liệu bạn nhập vẫn còn, thử lại sau vài giây." |
| "Dữ liệu không hợp lệ" | "Số điện thoại cần 10 chữ số. Bạn đang nhập 9." |
| "Không có quyền" | "Mục này chỉ dành cho quản trị viên. Liên hệ chị Hà (hr@congty.vn) để được cấp quyền." |
| "Thao tác thất bại" | "Không xoá được vì đơn hàng này đang được xử lý. Huỷ đơn trước rồi thử lại." |
Hoàn tác tốt hơn xác nhận
Hộp thoại "Bạn có chắc không?" là phản xạ mặc định và thường là lựa chọn kém:
- Người dùng học cách bấm "Có" mà không đọc, trong vòng một tuần.
- Nó làm chậm mọi thao tác đúng để ngăn một thao tác sai hiếm gặp.
| Dùng xác nhận khi | Dùng hoàn tác khi |
|---|---|
| Không thể đảo ngược thật (xoá vĩnh viễn, gửi tiền) | Đảo ngược được |
| Ảnh hưởng người khác (gửi email cho 400 người) | Chỉ ảnh hưởng người thao tác |
| Rất hiếm khi xảy ra | Thao tác thường xuyên |
Giữ lại công sức của người dùng
Quy tắc không có ngoại lệ: khi có lỗi, đừng xoá thứ người dùng đã nhập.
Biểu mẫu 12 ô, người dùng điền xong, bấm gửi, gặp lỗi ở ô thứ 3, và toàn bộ trống trơn — đây vẫn là một trong những trải nghiệm tệ nhất còn tồn tại trên web, và nó thuần tuý là lỗi thực hiện.
Làm ngay
Lấy năm thông báo lỗi trong sản phẩm của bạn. Với mỗi cái, kiểm ba câu ở trên. Sửa cái nào thiếu câu số 3 trước — đó là câu người dùng cần nhất. <!--/les-append-->