Khách gửi một form dài và chỉ nhận câu “Dữ liệu không hợp lệ”. Họ không biết ô nào cần sửa, phần đã nhập có được giữ không hoặc lần gửi vừa rồi đã tạo yêu cầu chưa. Một thông báo ngắn ở góc màn hình có thể báo có vấn đề nhưng chưa tạo được đường đi để người dùng hoàn thành công việc.
Thiết kế lỗi form website cần nối ba thứ: lỗi hệ thống trả về, trường người dùng đang nhìn và hướng dẫn sửa có thể thực hiện. Bài này dùng một form tư vấn giả định để phân tích đường quay lại đó. Không tự đặt thêm giới hạn email, số điện thoại hay chính sách dữ liệu cho mọi doanh nghiệp; quy tắc hợp lệ phải đến từ phạm vi đã được xác nhận.
Một lỗi cần chỉ được tới nơi sửa
Giả sử form có tên liên hệ, thời điểm mong muốn và mô tả nhu cầu. Người dùng nhập một ngày theo cách họ quen, nhưng định dạng không phù hợp hợp đồng của form. Server trả lỗi liên quan trường ngày. Nếu giao diện chỉ hiện “gửi thất bại”, người dùng có thể sửa nhầm tên hoặc bấm lại mà không đổi dữ liệu.
Hướng dẫn User Notification của W3C WAI đề cập danh sách lỗi có liên kết tới điều khiển tương ứng và thông tin giúp sửa. Đây là một quan hệ chức năng giữa lỗi và trường, không chỉ là chọn câu chữ thân thiện hơn.
Trong ví dụ, cần biết tên trường trong phản hồi được ánh xạ tới điều khiển nào. Định danh kỹ thuật phía server có thể khác nhãn người dùng đọc. Đội triển khai phải duy trì bản đồ này; không nên đưa nguyên tên nội bộ khó hiểu ra ngoài hoặc đoán trường dựa trên vị trí của nó trong form.
Nếu lỗi thuộc một nhóm trường, ví dụ hai giá trị không thống nhất, thiết kế cần chỉ rõ mối quan hệ cần sửa. Không gắn tùy tiện lỗi vào ô đầu tiên để mọi phản hồi đều có nơi đặt. Khi chưa xác định được nguồn, nên báo đúng phạm vi lỗi chung và cung cấp bước tiếp theo được phép làm.
Nội dung hướng dẫn cũng phải giữ đúng chính sách. Nếu quy tắc chỉ yêu cầu một ngày ở định dạng đã mô tả, đừng thêm yêu cầu chọn giờ làm việc hoặc thời hạn ngoài phạm vi vì thấy hợp lý. Người dùng cần một điều kiện nhất quán giữa hướng dẫn ban đầu, kiểm phía client và kiểm phía server.
Danh sách tổng hợp và thông báo tại trường phục vụ hai thời điểm
Với form dài, người dùng cần nhận ra có lỗi sau gửi mà không phải cuộn tìm. Danh sách tổng hợp ở vị trí dễ nhận biết có thể cho biết những phần cần sửa. Sau đó, thông báo tại trường giúp họ hiểu điều kiện trong lúc đang chỉnh đúng dữ liệu.
Hai lớp này không nên mâu thuẫn hoặc nhân đôi mọi câu một cách gây nhiễu. Danh sách tổng hợp có thể dùng nhãn trường và mô tả ngắn; chi tiết định dạng nằm gần điều khiển. Khi lỗi được sửa, trạng thái cần cập nhật nhất quán để người dùng không tiếp tục đọc một cảnh báo đã cũ.
| Loại phản hồi | Đường xử lý giao diện | Không nên làm |
|---|---|---|
| Trường ngày chưa đúng định dạng | Nối tới ô ngày và nhắc định dạng đã công bố | Chỉ hiện mã lỗi nội bộ |
| Một quan hệ giữa hai trường chưa hợp lệ | Giải thích nhóm cần đối chiếu | Đánh lỗi một ô ngẫu nhiên |
| Dịch vụ nhận yêu cầu chưa phản hồi rõ | Thông báo trạng thái chưa xác định và hướng tiếp tục phù hợp | Bảo khách đổi dữ liệu vốn đang đúng |
W3C WAI cũng nêu cách liên kết điều khiển với thông báo qua thuộc tính mô tả. Việc nối này giúp giữ quan hệ trong cấu trúc, nhưng vẫn phải được kiểm với giao diện thật. Một ID được viết trong mã không chứng minh phần tử đích tồn tại đúng, tên trường dễ hiểu hoặc thông báo được nhận biết đúng lúc.
Không dùng màu đỏ làm tín hiệu duy nhất. Người dùng cần thông tin bằng chữ và quan hệ rõ với trường. Nếu có biểu tượng, biểu tượng phải hỗ trợ thông điệp thay vì thay thế nó. Một dấu chấm than chung ở đầu form không thể nói người dùng cần đổi giá trị nào.
Việc chọn câu từ vẫn quan trọng. Prompt microcopy hỗ trợ hoàn tất biểu mẫu có thể giúp chuẩn bị nhãn và lời nhắc theo đầu vào. Bài này tập trung vào phần triển khai để câu nhắc xuất hiện đúng trường và đúng trạng thái, không coi văn bản hay là đủ để form hoạt động tốt.
Giữ dữ liệu đúng mà không tự thêm nơi lưu rộng quyền
Gửi lại form sau lỗi không nên bắt người dùng nhập lại tất cả phần đã đúng nếu thiết kế có thể giữ chúng trong phạm vi phù hợp. Tuy nhiên, giữ dữ liệu là một quyết định riêng cần được xác nhận theo loại thông tin, thời gian tồn tại và người có thể dùng thiết bị.
Không mặc định đưa mọi nội dung vào localStorage hoặc log để tiện khôi phục. Một form tư vấn có thể chứa dữ liệu riêng mà người dùng không muốn lưu trên máy dùng chung. Đội triển khai cần giải thích trường nào được giữ trong phản hồi hiện tại, trường nào cần nhập lại và lý do của giới hạn đó.
Với lỗi chỉ ở ô ngày, người dùng nên thấy lại các trường không bị ảnh hưởng nếu chính sách cho phép. Nhưng dữ liệu nhạy cảm có thể cần xử lý khác. Không đưa giá trị nhạy cảm vào thông báo lỗi chỉ để giúp kỹ thuật tìm nguyên nhân; báo cáo cần mô tả loại điều kiện mà không sao chép nội dung thật.
Khi lỗi xuất hiện vì dữ liệu phía server vừa thay đổi, thông báo cần phản ánh thay đổi đó. Một thời điểm không còn khả dụng khác với một chuỗi ngày sai định dạng. Cùng hiện chữ “ngày không hợp lệ” sẽ làm khách không biết nên sửa cách gõ hay chọn một lựa chọn khác.
Đội triển khai nên dùng quy tắc validator dựa trên policy như một phạm vi liên quan. Validator quyết định dữ liệu đáp ứng điều kiện nào; giao diện phải diễn đạt quyết định đó mà không thêm chính sách mới. Không để frontend và backend có hai định nghĩa hợp lệ không được giải thích.
Focus và phản hồi động phải giúp người dùng tiếp tục
Nếu form tải lại trang sau gửi, người dùng cần nhận biết đang quay về một form có lỗi chứ không phải một trang mới vô nghĩa. Nếu phản hồi được đưa vào động, cần một cách thông báo thay đổi phù hợp với người dùng công nghệ hỗ trợ. WAI có hướng dẫn cho cả hai tình huống; không nên lấy một cơ chế cho mọi trường hợp.
Chuyển focus tới lỗi đầu tiên có thể hữu ích sau submit, nhưng cần xét cấu trúc form và danh sách tổng hợp. Đừng liên tục cướp focus khi người dùng đang gõ. Lỗi có thể được cập nhật theo thời điểm phù hợp, thay vì phát thông báo cho từng ký tự chưa hoàn chỉnh.
Với một form trong hộp thoại, đường quay lại lỗi cần nằm trong luồng bàn phím của hộp thoại đó. Nếu focus bị đưa ra nội dung phía sau, khách có thể không biết form còn mở. Đây là tình huống cần kiểm cùng thành phần modal, không chữa bằng cách giấu lỗi hoặc vô hiệu hóa bàn phím.
Cũng cần phân biệt lỗi dữ liệu với kết quả gửi chưa rõ. Nếu request đã rời trình duyệt nhưng không nhận được xác nhận, không nên tự kết luận khách nhập sai rồi mở nút gửi liên tục. Phần đối chiếu tác động cần theo thiết kế của luồng form; thông báo giao diện không thay thế bằng chứng server.
Nghiệm thu một vòng sửa hoàn chỉnh
Chọn dữ liệu giả và môi trường đã cô lập tác động ngoài. Chốt trước quy tắc của từng ca, không tạo thêm một địa chỉ email hoặc điều kiện không có trong chính sách chỉ để thử cho dễ. Mỗi ca cần có phản hồi mong muốn, trường liên quan và kết quả sau khi người dùng sửa.
Thử một lỗi đơn, rồi một tổ hợp lỗi ở hai vị trí khác nhau. Quan sát danh sách tổng hợp, liên kết tới trường, phần dữ liệu được giữ và thông báo tại chỗ. Sửa một lỗi để xem trạng thái còn lại có được giữ đúng không; đừng chỉ kiểm màn hình đầu tiên sau submit.
Đi bằng bàn phím qua đường sửa và thử lại ở mobile, desktop. Xem thông báo có bị cắt, đè lên nhãn hoặc đẩy người dùng mất vị trí không. Một ảnh chụp form rỗng không đại diện cho trạng thái lỗi có nhiều dòng hướng dẫn.
Báo cáo nên nêu những nhánh đã kiểm và những phần chưa được xác minh, bao gồm phản hồi lỗi hệ thống nếu có. Không dùng dữ liệu khách thật để chụp bằng chứng. Nếu cần Onter rà form từ hợp đồng validator đến đường sửa lỗi, chuẩn bị bản đồ trường và vài ca giả định. Nhận tư vấn & báo giá. Giá: Liên hệ.
