Trải nghiệm người dùng
Để thông báo lỗi hướng dẫn hành động tiếp theo
Thông báo lỗi cần cho biết điều gì xảy ra, phần công việc nào còn an toàn và nên làm gì tiếp theo. Hãy phân biệt dữ liệu có thể sửa, dịch vụ không sẵn sàng và kết quả chưa xác định trước khi viết thông báo.
Một thất bại không được giải thích có thể biến gián đoạn nhỏ thành yêu cầu hỗ trợ hoặc thao tác nghiệp vụ bị lặp. Thông báo là một phần của quy trình khắc phục, không phải phần trang trí sau khi phát sinh ngoại lệ. Chủ sản phẩm nên hỏi: người dùng dự kiến có thể làm bước hữu ích tiếp theo mà không đoán hệ thống đã làm gì hay không?
Gọi đúng loại thất bại
Phân biệt giá trị người dùng có thể sửa với hạn chế quyền truy cập hoặc sự cố dịch vụ tạm thời. Thay nhãn lỗi chung bằng tên tác vụ bị ảnh hưởng và hành động tiếp theo có thể thực hiện. Tránh đổ lỗi cho người dùng khi hệ thống không xác định được nguyên nhân. Đừng dùng dấu vết lỗi lập trình làm hướng dẫn nghiệp vụ.
WAI khuyến nghị kiểm tra dữ liệu ở máy chủ bên cạnh kiểm tra trong trình duyệt.[1] Hãy dự kiến tình huống máy chủ từ chối dù trang ban đầu chấp nhận giá trị. Thông báo khi đó nên giải thích quy tắc nghiệp vụ, không chỉ đưa mã triển khai mà chỉ lập trình viên hiểu.
Nêu rõ công việc đã ở trạng thái nào
Cho biết nội dung sửa còn trên màn hình, đã có bản nháp hay kết quả cuối vẫn chưa rõ. Nếu mất kết nối sau khi gửi, thử lại có thể chưa phù hợp trước khi ứng dụng kiểm tra yêu cầu hiện có. Nên cung cấp cách xem trạng thái hoặc đường khắc phục đúng với hành vi thực tế của hệ thống phía sau.
Khi lỗi động thuộc loại thông báo trạng thái, WAI hướng dẫn cung cấp thông tin đó cho công nghệ hỗ trợ mà không chuyển tiêu điểm.[3] Cần phối hợp nội dung nhìn thấy với phần được đọc thông báo. Người dùng trình đọc màn hình cần đủ ngữ cảnh để nhận biết thao tác liên quan, không chỉ nghe một số lỗi rời rạc.
Ví dụ giả định: tệp đính kèm khoản chi
Một nhân viên giả định gửi khoản chi kèm tệp hóa đơn. Dịch vụ tệp từ chối vì định dạng không được hỗ trợ, còn khoản chi vẫn là bản nháp. Thông báo nêu tệp nào thất bại, liệt kê định dạng được nhận và cho thay tệp mà không xóa số tiền đã nhập.
Một gián đoạn khác xuất hiện sau khi nhân viên gửi khoản chi để phê duyệt. Ứng dụng chưa xác nhận được kết quả. Thay vì yêu cầu gửi lại ngay, ứng dụng cho kiểm tra trạng thái khoản chi. Hai thất bại cần cách viết khác nhau vì bằng chứng hiện có và hành động tiếp theo an toàn không giống nhau.
Rà soát toàn bộ đường khắc phục
Hỏi nhóm hỗ trợ thông tin nào giúp xử lý trường hợp còn tồn đọng. Một mã tham chiếu an toàn có thể nối báo cáo của người dùng với chẩn đoán nội bộ mà không lộ chi tiết kỹ thuật. Đi kèm mã phải có hướng dẫn dễ hiểu và kênh hỗ trợ dùng được. Đừng để mã trở thành toàn bộ thông báo.
Thông báo cụ thể cần được duy trì khi quy tắc hoặc dịch vụ thay đổi. Gắn nội dung với nhóm phụ trách hành vi sản phẩm và rà soát các bản dịch cùng lúc. Câu chữ rõ ràng không sửa được việc thiếu cơ chế khắc phục.
- Nêu thao tác bị ảnh hưởng bằng ngôn ngữ nghiệp vụ thông thường.
- Giải thích dữ liệu nhập hoặc bản nháp còn dùng được hay không.
- Chỉ đề xuất hành động ứng dụng thực sự hỗ trợ.
- Phân biệt từ chối đã xác nhận với kết quả gửi chưa rõ.
- Thử đường khắc phục với người dùng bàn phím và công nghệ hỗ trợ.