Trong phần trước, chúng ta đã cùng nhau tìm hiểu những “tips” cơ bản đầu tiên trong việc thiết kế thông báo lỗi. Nếu bạn vô tình bỏ lỡ, đừng lo! bạn có thể xem lại phần 1 của bài viết tại đây:
Ngày hôm nay, hãy cùng Mirr khám phá tiếp những tips còn lại nhé!
Cẩn Thận Với Những Thông Báo Dạng Toast Messages
Mặt tích cực của thông báo kiểu này đó là thông báo cho người dùng về sự thay đổi trạng thái của hệ thống thông qua việc làm nội dung thông điệp nổi lên so với các nội dung còn lại. Loại thông báo kiểu này ít phổ biến trong biểu mẫu, nhưng thường xuất hiện trong các bảng và dashboard của doanh nghiệp.
Ví dụ về Toast Message
Có một số vấn đề thường gặp về usability của thông báo lỗi kiểu Toast Message:
Toast Message thường chỉ hiển thị trong một thời gian ngắn. Người dùng có rất ít thời gian để đọc hoặc hiểu rõ thông báo lỗi trước khi nó biến mất, và không có cách nào để khôi phục hoặc giữ cho thông báo nổi lên.
Toast Message thường xuất hiện ở cạnh bên của màn hình và khá xa trường nhập lỗi. Điều này làm cho thông báo lỗi và trường nhập liệu bị tách rời, dẫn đến không thể đọc thông báo và sửa lỗi cùng lúc.
Toast Message dài thường che một phần lớn nội dung trên web hoặc ứng dụng, thậm chí là che luôn phần nội dung của trường nhập đã gây ra lỗi.
Ví dụ về Toast Messages hiển thị không hợp lý, che mất các nội dung quan trọng khác
Toast Message cần được thông báo cho người dùng, đồng thời cho phép họ chuyển đổi lựa chọn giữa thông báo lỗi và trường nhập bị lỗi.
Trong một Toast Message, thường không có đủ không gian để gắn hướng dẫn chi tiết bằng hình ảnh hoặc video, 100% phải dựa vào văn bản thuần túy và liên kết đến các trang trợ giúp bên ngoài.
Nhìn chung, Toast Message nên được đặt cố định nếu hiển thị thông tin chứa nội dung cần thực hiện hành động, và người dùng nên có quyền đóng thông báo một cách thủ công.
Với quan điểm cá nhân của Mirr cũng như tác giả gốc của bài viết, chúng ta nên tránh sử dụng Toast Message, ngay cả khi chúng được hiển thị cố định. Hãy thiết kế thông báo lỗi theo hướng người dùng có thể tương tác trực tiếp với nguyên nhân gây ra lỗi, đưa nội dung giải thích cách khắc phục lỗi ngay bên cạnh nguyên nhân, người dùng sẽ hiểu nhanh hơn về những gì họ cần phải làm.
Cho Phép Người Dùng Tiếp Tục Thực Hiện Tác Vụ Của Họ Trong Một Số Trường Hợp
Không có bộ kiểm tra lỗi nào chính xác hoàn toàn, luôn có những ngoại lệ khi mà bộ kiểm tra lỗi không thể bao quát hết tất cả các trường hợp. Chúng ta cần chuẩn bị phương án cho những tình huống như vậy để người dùng không có những trải nghiệm tiêu cực với sản phẩm/dịch vụ.
Trong một số trường hợp, khi lỗi xuất hiện và nút bấm bị vô hiệu hóa, người dùng không biết làm thế nào để có thể khắc phục lỗi và tiếp tục.
Ghi đè trình kiểm tra địa chỉ trong trường hợp này có thể là một ý tưởng tốt
Trong tình huống có quá nhiều trường hợp ngoại lệ khiến trình kiểm tra lỗi bị hạn chế, chúng ta có thể cho phép người dùng ghi đè lên phần cảnh báo của trình kiểm tra. Sẽ có những kết quả thu về không như mong muốn, nhưng nếu việc ghi đè này mang lại nhiều giá trị hơn so với việc phải tuân thủ theo cách hoạt động mặc định của giao diện, thì việc thay đổi này là hoàn toàn xứng đáng.
Phương pháp này hoạt động tốt cho trường hợp nhập địa chỉ và số điện thoại, nhưng có thể khó áp dụng với trường nhập dữ liệu yêu cầu format chính xác như số tài khoản hay số thẻ tín dụng. Trong những trường hợp như vậy, thay vì cho phép khách hàng tự quyết định, chúng ta cần xem xét một cách cẩn thận đầu vào và hướng dẫn họ về vấn đề cụ thể và giúp họ khắc phục nó.
Dành Thời Gian Cho Testing Error Messages
Nhìn chung, chúng ta cần đầu tư thời gian và công sức cho việc test và cải tiến một thông báo lỗi. Việc giúp người dùng giải quyết một số lỗi khó hiểu và tối nghĩa bằng những văn bản rõ ràng và hữu ích là cách tác động mạnh mẽ nhất đến khả năng và tỷ lệ chuyển đổi của người dùng.
Gợi ý cách để viết thông báo lỗi tốt hơn bởi Wix.
Trên thực tế, Jenni Nadler (Head of UX Writing, Wix) đã viết một case study tuyệt vời về cách viết thông báo lỗi tốt hơn, hướng dẫn cụ thể làm thế nào để nêu rõ vấn đề trong thông báo lỗi, giải thích tại sao lỗi đó xảy ra, cách đưa ra lời trấn an đến người dùng, và cách để cung cấp gợi ý giúp người dùng khắc phục vấn đề đó.
Kết Luận
Thoạt nhìn, chúng ta nghĩ rằng việc thiết kế một thông báo lỗi có vẻ không quan trọng. Tuy nhiên, khi đi sâu vào chi tiết, có rất nhiều yếu tố cần xem xét để thực hiện việc này. Thông báo lỗi có thể giúp hạn chế tình trạng rời trang hoặc rời ứng dụng, đồng thời giúp người dùng giải quyết vấn đề một cách nhanh chóng.
Trên đây là những hướng dẫn giúp bạn thiết kế thông báo lỗi (Error Message) một cách tốt hơn. Hãy cân nhắc những giá trị mà thông báo lỗi mang lại, và lên phương án thích hợp cho doanh nghiệp của bạn nhé!
Reference: Designing Better Error Messages UX - Vitaly Friedman
Dịch và tổng hợp bởi: Mirr Design
Mirr Design hiện đang tuyển sinh khóa học “User Experience Essentials” - UXE. Kiến tạo tư duy giải quyết vấn đề, và xây dựng trải nghiệm người dùng xuất sắc.
Ai nên học? Khoá học phù hợp với tất cả những ai đang phát triển các sản phẩm số và muốn đưa sản phẩm của mình đến tay người dùng, từ Product Owner/Product Manager, Business Analyst, Visual Designer, Marketer và cả những người muốn bắt đầu sự nghiệp trong lĩnh vực UI/UX.
Comentários