Quy tắc viết thông báo lỗi. Tại sao các thông báo lỗi thường được viết không chính xác và làm cách nào để khắc phục điều này? Thông báo lỗi về việc nhập dữ liệu không chính xác
Tóm tắt: Sự hiểu biết thông thường nói rằng các báo cáo lỗi tốt phải lịch sự, chính xác và mang tính xây dựng. Với sự ra đời của Web, một số yêu cầu khác đã được bổ sung vào các yêu cầu này: làm cho thông báo lỗi hiển thị rõ ràng; khi xảy ra lỗi thì người dùng không phải mất nhiều thời gian để sửa lỗi; Đào tạo người dùng khi bạn đi.Các quy tắc tạo thông báo lỗi hiệu quả vẫn được giữ nguyên trong 20 năm qua. Tin nhắn tốt thông báo lỗi phải là:
- Rõ ràng chỉ ra rằng có điều gì đó không ổn. Thông báo lỗi tồi tệ nhất là thông báo không được tạo. Nếu người dùng mắc lỗi và không nhận được bất kỳ phản hồi nào từ hệ thống thì đó là điều tồi tệ nhất đối với họ. Ví dụ: một ứng dụng làm việc với bằng email có một số tình huống mà việc chỉ ra lỗi đã xảy ra sẽ rất hữu ích. Giả sử bạn đã gửi tin nhắn bưu chính, đã được hệ thống nuốt một cách an toàn nhưng không bao giờ đến tay người nhận. Một vi dụ khac? Trong thư bạn nói rằng bạn đang đính kèm một tập tin vào nó, nhưng đơn giản là bạn đã quên làm như vậy. Đây là nơi sẽ có việc làm cho chiếc kẹp giấy ngu ngốc này của MS Office: " Có vẻ như bạn muốn đính kèm tệp vào tin nhắn của mình nhưng không thực hiện được. Bạn muốn làm điều này?"
- Được viết trong ngôn ngữ của con người thay vì sử dụng những mật mã và chữ viết tắt bí ẩn như " đã xảy ra lỗi loại 2".
- Là lịch sự và đừng trách người dùng quá ngu ngốc hay làm điều gì sai trái, chẳng hạn như trong tin nhắn " đội bị cấm"
- Chính xác mô tả nguồn gốc của vấn đề chứ không chỉ đưa ra những cụm từ chung chung như " lỗi cú pháp ".
- Cho lời khuyên mang tính xây dựng về cách khắc phục vấn đề. Ví dụ: thay vì báo cáo rằng sản phẩm " Không có sẵn", thông báo lỗi của bạn sẽ cho bạn biết khi nào mặt hàng đó có hàng trở lại hoặc nhắc người dùng thiết lập thông báo để gửi cho họ khi mặt hàng đó có hàng trở lại.
Lỗi phổ biến nhất trên Web là 404 - vi phạm hầu hết các quy tắc này. Tôi khuyên bạn nên viết thông báo lỗi 404 của riêng mình thay vì dựa vào "trang" trung bình của máy chủ. không tìm thấy".
Luật mới
Sự phức tạp khi làm việc với các trang web đã dẫn đến một quy tắc khác ngày xưa không được yêu cầu. Trong giao diện DOS, người dùng gõ lệnh và thông báo lỗi sẽ xuất hiện trong hàng tiếp theo trên màn hình. Ở thời hiện đại vỏ đồ họa Khi người dùng chọn lệnh sai, thông báo lỗi sẽ hiển thị trong hộp thoại lớn ở giữa màn hình và không biến mất cho đến khi người dùng chấp nhận. Tuy nhiên, trong Tin nhắn trên web Thông báo lỗi thường bị ẩn trong nội dung của trang, đó là lý do tại sao chúng tôi suy ra quy tắc sau: thông báo lỗi phải là:
- Dễ thấy và rất đáng chú ý, cả về bản thân thông báo và nơi người dùng phải sửa lỗi.
Tôi thường nhận thấy cách người dùng mắc lỗi trên biểu mẫu web, gửi biểu mẫu và nhận lại biểu mẫu tương tự trên màn hình mà không có bất kỳ dấu hiệu nào cho thấy nó có vấn đề gì. Thường sẽ có một thông báo lỗi nhỏ ở đầu trang, nhưng vì người dùng trước tiên nhìn vào những gì họ đang làm việc trên trang (tức là các trường biểu mẫu) nên họ thường không nhận thấy thông báo này.
Tương tự, sẽ không chính xác nếu chỉ hiển thị thông báo lỗi bằng màu đỏ. Điều này vi phạm một trong những quy tắc lâu đời nhất và đơn giản nhất trong việc tạo ra công nghệ mà người dùng có vấn đề về sức khỏe có thể tiếp cận: không bao giờ chỉ sử dụng màu sắc trong giao diện để biểu thị trạng thái hệ thống; luôn bổ sung cho nó một số tín hiệu khác mà những người có vấn đề về nhận biết màu sắc có thể nhìn thấy.
Dưới đây là một số quy tắc khác sẽ giúp giảm thiểu tình huống khó chịu mà người dùng gặp phải khi mắc lỗi:
- Cứu càng nhiều càng tốt từ công việc được thực hiện bởi người dùng. Cho phép người dùng sửa lỗi trong hành động của họ thay vì yêu cầu họ bắt đầu lại. Ví dụ: khi hiển thị kết quả tìm kiếm cho anh ấy, hãy hiển thị trường tìm kiếm ở đó và hiển thị những kết quả đó trong đó từ khóa, mà người dùng đang tìm kiếm để có thể sửa chúng và cải thiện kết quả. Nếu tìm kiếm không trả lại bất kỳ kết quả nào, hãy cung cấp cho người dùng khả năng mở rộng tìm kiếm chỉ bằng một cú nhấp chuột.
- Cắt giảm công việcđể sửa lỗi. Nếu có thể, hãy cố gắng để hệ thống đoán hành động chính xác và nhắc người dùng chọn hành động đó hành động đúng từ một danh sách nhỏ các tùy chọn. Ví dụ: thay vì chỉ viết " tên của thành phố không tương ứng với nó mã bưu điện ", cho phép người dùng nhấp vào nút và chọn thành phố tương ứng với mã zip của họ từ danh sách.
Đào tạo người dùng
Và cuối cùng, có thể bạn đã biết Luật Tài liệu Máy tính Đầu tiên của Nielsen: mọi người không đọc nó. Luật này thậm chí còn mạnh hơn đối với các trang web, nơi người dùng thực sự tránh đọc bất cứ thứ gì không cần thiết cho nhiệm vụ của họ. Nhấp vào liên kết "Trợ giúp"? Không đời nào.
Người dùng chỉ đọc tài liệu hệ thống khi họ gặp vấn đề (đây là Định luật thứ hai). Họ đọc nó đặc biệt cẩn thận khi họ muốn sửa một hành động sai lầm. Trong trường hợp này, bạn có thể sử dụng các thông báo lỗi làm tài liệu đào tạo và đưa kiến thức này vào chúng theo từng phần nhỏ. Đương nhiên, các thông báo lỗi phải ngắn gọn và đúng trọng tâm, cũng như tất cả nội dung trang web. Tuy nhiên, thông báo lỗi vẫn có thể cung cấp cho mọi người thông tin về cách hệ thống hoạt động và đề xuất cách tốt nhất để làm việc với nó. Và để kết thúc chủ đề này, Web giới thiệu thêm một quy tắc nữa:
- Liên kết siêu văn bản có thể được sử dụng để liên kết một thông báo lỗi ngắn gọn với tài liệu bổ sung hoặc lời giải thích về vấn đề. (Chỉ cần cẩn thận đừng lạm dụng nó).
Ai cũng có lúc mắc sai lầm, đó là điều không thể tránh khỏi: đó chính là mục đích của các thông báo lỗi. Tuy nhiên, nhiều công ty lại ít chú ý đến yếu tố giao diện này, điều này khiến người dùng tức giận và sợ hãi.
Thông báo lỗi có thể khó hiểu và nhìn chung cực kỳ khó chịu. Chắc chắn ít nhất một lần bạn thử đăng ký tài khoản trên Internet và nhận được kết quả như thế này:
“Trợ giúp: Làm thế nào để tạo mật khẩu chính xác?”
Những điều như thế này khiến bạn từ bỏ mọi thứ và ngừng những nỗ lực tiếp theo. Bạn có thể thiết kế thông báo lỗi như thế nào để cải thiện trải nghiệm người dùng, khả năng sử dụng và chuyển đổi?
Tin nhắn hỗn hợp
Điều tồi tệ nhất là những tin nhắn hỗn hợp không trả lời được câu hỏi "Có chuyện gì ở đây vậy?" Đây là giao diện của trang Amazon khi vì lý do nào đó, nó không chấp nhận mã khuyến mãi:
"Mã khuyến mại đã nhập không thể sử dụng được cho giao dịch mua này." Tại sao?!
Bất kỳ vấn đề nào, bao gồm cả thông báo lỗi, đều kích thích sản xuất hormone cortisol, một dấu hiệu sinh học nổi tiếng về căng thẳng. Sự gia tăng cortisol có thể phát triển thành lo lắng và khi người dùng bối rối, họ sẽ bỏ cuộc:
Biểu đồ năng suất so với mức độ căng thẳng, từ trái sang phải: trạng thái bình tĩnh, căng thẳng “có lợi”, đau khổ (có hại cho sức khỏe)
Đôi khi thiệt hại không chỉ là tỷ lệ chuyển đổi thấp—thông báo lỗi có thể khiến mọi người rời bỏ thương hiệu của bạn. Đầu tư vào trải nghiệm người dùng tốt hơn bao gồm cả nỗ lực ngắn hạn (tăng chuyển đổi) và nỗ lực dài hạn (giữ chân người dùng, lòng trung thành với thương hiệu, câu cửa miệng và như thế).
Mặc dù báo cáo lỗi có vẻ như là một chủ đề yếu kém so với tối ưu hóa hoặc trò chơi hóa, nhưng bạn có thể cải thiện đáng kể trải nghiệm người dùng của mình chỉ bằng cách tránh một số vấn đề phổ biến.
Bạn đã từng đặt chuyến bay với Spirit Airlines chưa? Nói một cách nhẹ nhàng, đây không phải là một ví dụ về trải nghiệm tốt hơn tương tác và thông báo lỗi trên trang này cũng không đạt tiêu chuẩn.
Nếu bạn cố tình trộn lẫn mọi thứ (như thể đang điền vào biểu mẫu bởi một người ở xa Internet), bạn sẽ nhận được kết quả sau:
“Trường “yêu cầu” phải được điền vào”
Vì vậy, bạn đã quên cho biết bạn là “Ông” hay “Bà”. Sau khi sửa xong lại xuất hiện một lỗi khác:
Có vấn đề gì với email à? Forgotten.com nhưng rất dễ khắc phục:
Bây giờ có chuyện gì thế? Có vẻ như bạn gặp lỗi tương tự trong cửa sổ xác nhận email. Sẽ thật tuyệt nếu bạn được thông báo về điều này ngay khi nhập địa chỉ đầu tiên:
“Địa chỉ email bạn nhập đã được người dùng FreeSpirit sử dụng. Sử dụng một địa chỉ khác"
Bây giờ hóa ra ai đó đã tạo tài khoản bằng địa chỉ email đó. Sẽ thật tuyệt nếu có thể khôi phục quyền truy cập nếu địa chỉ này vẫn là của bạn. Cũng có thể để lại mật khẩu đã nhập.
Không phải tất cả các hình dạng đều trông rất buồn, nhưng nhiều trong số đó trông có vẻ buồn. những vấn đề chung. Tránh chúng và bạn sẽ dẫn đầu. Hãy nhìn vào mọi thứ theo thứ tự.
Vấn đề #1: Sự mơ hồ
Thông báo lỗi của bạn phải làm rõ chính xác điều gì sai. Bạn đã bao giờ nhận được những tin nhắn như thế này chưa?
"Email của bạn không thể gửi được"
Tại sao? Người dùng nên hiểu điều này như thế nào?
Dịch vụ Bitly đơn giản là nhàm chán với những tin nhắn như thế này mà không giải thích cụ thể điều gì sai. Tên tài khoản? Mật khẩu? Cả hai? Giúp người đó hiểu mình đã sai ở đâu:
"Không thử lại"
Đây là một vấn đề khá phổ biến.
Thật tuyệt khi các lỗi trong biểu mẫu được đánh dấu rõ ràng so với các trường khác được điền chính xác. Ví dụ: Meetup.com luôn hiển thị chính xác vị trí xảy ra sự thiếu chính xác hoặc sự cố và những việc cần làm khi xử lý vấn đề đó:
"Xin lỗi, đã xảy ra lỗi. Chi tiết lỗi được đánh dấu bằng màu bên dưới"
Điều chính là không buộc người dùng phải giải đố về biểu mẫu của bạn. Hãy cho chúng tôi biết lý do xảy ra lỗi, lỗi xuất hiện ở đâu và cách khắc phục. Tăng sự rõ ràng.
Vấn đề #2: Giọng điệu trịch thượng/đổ lỗi cho người dùng
Điều bạn chắc chắn không nên làm là cố gắng dọa người dùng với ý tưởng rằng lỗi còn tệ hơn nhiều so với thực tế. Bạn không muốn ép buộc khách hàng tiềm năng cảm thấy ngu ngốc hoặc tội lỗi.
Chỉ cần nói rằng có vấn đề là đủ. Ngay cả khi đây là lỗi của người dùng, đừng đổ lỗi cho anh ta trong bất kỳ trường hợp nào. Đây là một ví dụ phóng đại (mặc dù phổ biến):
“Chúng tôi đã cảnh báo bạn ba lần rằng tập tin này không tồn tại. Đừng làm vậy nữa"
Ngoài ra, bạn không nên sử dụng những từ có hàm ý tiêu cực - chúng khiến người dùng nghĩ rằng tình hình còn tồi tệ hơn thực tế. Dưới đây là một số từ cần tránh:
"Rất tiếc, đã xảy ra lỗi" (Rất tiếc)
"Biểu mẫu này có lỗi" (Lỗi)
"Gửi biểu mẫu không thành công" (Không thành công)
"Đã xảy ra sự cố khi tạo hồ sơ của bạn" (Sự cố)
“Các trường được điền không chính xác” (Sai)
“3 lỗi khiến không thể cứu được người dùng nhất định"(Không thể nào)
Vấn đề #3: Vị trí thông báo lỗi không chính xác
Đây là những gì UXMovement viết trong bài viết của mình:
“Danh sách sai lầm làm tăng căng thẳng. Khi người dùng nhìn thấy nhiều lỗi cùng một lúc, họ sẽ dễ dàng bỏ qua mọi thứ và quên đi hơn là sửa nó.”
Còn gì đáng sợ hơn việc nhìn thấy thứ gì đó như thế này ngay khi bạn chuẩn bị nhấn gửi?
“Đã tìm thấy lỗi khi điền, vui lòng sửa lại và xác nhận lại biểu mẫu”
Xác nhận từng dòng có thể giải quyết vấn đề này vì người dùng nhận được ngay lập tức nhận xét và học cách tránh mắc lỗi sau này. Tuy nhiên, ngay cả khi bạn không muốn triển khai xác thực dữ liệu theo từng dòng, ít nhất hãy làm rõ cho người dùng biết chính xác lỗi đã xảy ra ở đâu.
Vị trí của thông báo lỗi không phải là điều mà mọi người thường nghĩ đến, nhưng dù sao nó cũng quan trọng. Đây là những gì Usabilla nói về nó:
“Cuối cùng, việc đặt thông báo lỗi của bạn trở nên rất quan trọng vì đặt đúng vị trí là chìa khóa mang lại trải nghiệm tích cực cho người dùng. Việc đặt lỗi một cách hợp lý không chỉ giúp bạn tiết kiệm thời gian giải thích mà còn cho phép người dùng nhanh chóng tìm ra nguồn gốc của vấn đề và khắc phục nó.”
Trong ví dụ sau, các lỗi được đặt tốt hơn so với khi chúng nằm cùng nhau, nhưng vẫn chưa rõ lỗi cụ thể xảy ra ở đâu (ví dụ: lỗi "Trường 'tên' không thể để trống" nằm giữa họ và tên các trường, tạo ra sự mơ hồ):
Người dùng phải hiểu chính xác mình đã mắc lỗi ở đâu. Vì vậy, trong Netflix, văn bản lỗi nằm phía trên biểu mẫu và các trường chỉ được đánh dấu màu đỏ. Rất dễ bỏ lỡ thông báo lỗi như thế này hoặc không tìm thấy trường bạn đang tìm kiếm:
"Mật khẩu của bạn phải từ 4 đến 60 ký tự"
Vấn đề #4: Kỳ vọng không rõ ràng
Cái này rất lỗi phổ biến, vì vậy điều quan trọng là không nên làm điều đó. Ngay cả khi thông điệp của bạn không tiêu cực, đặt đúng chỗ và nói rõ chính xác điều gì sai, bạn vẫn sẽ khiến người dùng tức giận khi không nói cho họ biết họ nên làm gì.
Nhiều thông báo lỗi không rõ ràng bước tiếp theo. Giống như ví dụ về Spirit Airlines, họ có thể cung cấp một số tùy chọn để lấy lại quyền truy cập vào tài khoản của bạn hoặc hỏi: “Bạn đã có tài khoản chưa? Đăng nhập tại đây." Thay vào đó, họ chỉ báo cáo rằng email của bạn đã được sử dụng.
“Email này đã được sử dụng, vui lòng nhập email khác”
Một thông báo lỗi tuyệt vời nhằm giáo dục người dùng và giúp họ khắc phục lỗi đến từ MailChimp:
“Xin lỗi, chúng tôi không tìm thấy tài khoản có tên đó. Tôi có thể giúp bạn khôi phục tên người dùng của mình không?"
Nếu biểu mẫu của bạn không cho phép điền linh hoạt các trường với dữ liệu nhất định (ví dụ: số điện thoại, mã zip, v.v.), thì tốt nhất là bạn nên làm rõ cho người dùng chính xác cách họ nên nhập dữ liệu. Bạn có thể báo cáo điều này bằng cách sử dụng văn bản có phông chữ nhỏ ngay bên dưới trường.
Microtext là “những lời nhắc nhở nhỏ nhằm giáo dục và hướng dẫn người dùng”. Nó giúp bạn tránh được những sai lầm trước khi chúng xảy ra.
Vì vậy, thông tin về cách nhập địa chỉ liên kết với thẻ tín dụng, có thể giảm đáng kể số lượng câu hỏi khi điền vào biểu mẫu, tiết kiệm thời gian cho người dùng và tăng lợi nhuận của bạn từ chuyển đổi được cải thiện:
“Hãy đảm bảo bạn đang nhập địa chỉ được liên kết với thẻ tín dụng của mình.”
Đây là một ví dụ khác trong đó văn bản có hướng dẫn sẽ hữu ích:
"Vui lòng nhập một giá trị số"
Peep Laja đang cố gắng điền vào biểu mẫu trên một trang web để lấy liên kết đến một sự kiện. Tuy nhiên, điều này dẫn đến việc anh ấy phải quay lại trang đầu tiên có chứa một thông báo lớn màu đỏ, “Có vấn đề với việc đăng ký của bạn,” đầy sự không chắc chắn.
Vấn đề là anh ta đã nhập từ “Một số” vào trường “Số lượng khách” (hợp lý, vì khá khó để tính số lượng khách cho một sự kiện), nhưng biểu mẫu lại ngụ ý một con số chính xác. Tất nhiên, không có đề cập nào về điều này trước khi anh nhấn nút gửi: microtext sẽ rất hữu ích trong tình huống này.
(Mặc dù trong ví dụ cụ thể này có nhiều vấn đề hơn là chỉ thiếu lời giải thích).
Thông báo lỗi tốt và xấu có kết quả rất khác nhau về hành vi của người dùng. Đây là một câu chuyện hài hước từ kinh nghiệm của chuyên gia Jennifer Aldrich:
“Một lần trong phòng thí nghiệm của chúng tôi, có hai người dùng đang làm việc cạnh nhau - một người trong chương trình nhà sản xuất bên thứ ba, người thứ hai đã thử nghiệm sản phẩm của chúng tôi. Chuyện xảy ra là cả hai đều phạm sai lầm cùng một lúc. Chương trình của bên thứ ba hiển thị một chữ thập đỏ khổng lồ và từ “Lỗi” được viết bằng chữ hoa, sau đó là một lời giải thích dài dòng khó hiểu. Người dùng thở dài, thu nhỏ trình duyệt và quay người trên ghế như thể màn hình có thể tấn công anh ta.
Một người đang thử nghiệm sản phẩm của chúng tôi đã nhận được thông báo như: “Đã xảy ra sự cố lạ, chúng tôi xin lỗi. Hãy làm mới trang và thử lại." Mã lỗi được liệt kê bằng chữ in nhỏ bên dưới thông báo và cũng có tùy chọn mở rộng mã lỗi để xem thêm chi tiết nếu muốn. Người dùng mỉm cười, làm mới trang và tiếp tục làm việc.”
Thật không thể nghĩ ra được văn bản hoàn hảo, vị trí, màu sắc, khung thời gian, v.v. đối với các thông báo lỗi lẽ ra sẽ xuất hiện trên trang web của bạn.
Tuy nhiên, bạn có thể sử dụng các mẫu thiết kế hiện có và thực tiễn tốt nhất. Thực hiện một số nghiên cứu và phân tích về khả năng sử dụng nếu bạn muốn tìm hiểu thêm về cách tạo thông báo lỗi hoàn hảo và xem liệu nó có thể được áp dụng cho tài nguyên của bạn hay không.
Những ví dụ tốt nhất về thông báo lỗi, đã được thử nghiệm qua nhiều năm
Nhóm Nielsen Norman đã đề xuất các phương pháp hay nhất về báo cáo lỗi sau đây vào năm 2001—và chúng vẫn có tác dụng:
- Một thông báo hiển thị và dễ nhận thấy liên quan đến cả văn bản lỗi và thành phần cần được sửa.
- Tiết kiệm năng lượng của người dùng của bạn. Yêu cầu họ chỉ tự sửa lỗi—đừng buộc họ phải điền lại biểu mẫu. Khi hiển thị kết quả tìm kiếm, hiển thị một cửa sổ có bản gốc truy vấn tìm kiếmđể đơn giản hóa quá trình. Nếu không tìm thấy kết quả phù hợp, người dùng sẽ chỉ cần mở rộng truy vấn tìm kiếm đã chuẩn bị sẵn.
- Giảm công việc sửa lỗi. Nếu có thể, hãy gợi ý cho người dùng càng tốt lựa chọn đúng và yêu cầu chọn cái bạn cần từ danh sách. Ví dụ: thay vì chỉ viết “Thành phố và mã zip không khớp”, hãy cho phép người dùng nhấp vào nút có tên thành phố khớp với mã zip đã nhập.
UXMa có một quy tắc hữu ích liên quan đến việc báo cáo lỗi mà họ gọi là “4H”. Theo quy tắc này, thông báo lỗi sẽ là:
- Nhân loại
- Hữu ích
- Hài hước
- Đơn Giản (Khiêm tốn)
1. Con người
UXMas cho biết quy tắc số một là "đảm bảo thông báo lỗi nghe giống như cuộc trò chuyện giữa hai người". Dưới đây là ví dụ về thông báo lỗi không thỏa mãn quy tắc này:
Có vẻ như nó được viết bởi một robot. Bạn cũng nên tránh biệt ngữ ngôn ngữ kỹ thuật(tất nhiên, nếu khán giả của bạn không phải là dân kỹ thuật). Ví dụ, điều này có nghĩa là gì?
2. Hữu ích
Ba yếu tố làm cho thông báo lỗi trở nên hữu ích:
- Nó có đáng chú ý không?
- Nó có giải thích được điều gì đã xảy ra không?
- Nó có giúp người dùng sửa lỗi không?
Chúng ta đã nói về điều này trước đây: đăng bài viết của bạn một cách trực quan. ở những nơi rõ ràng, làm cho chúng đủ sáng và gây chú ý, giải thích rõ ràng bản chất của vấn đề và đưa ra giải pháp.
3. Hài hước
Theo UXMas, “giọng điệu nhẹ nhàng và đáng tin cậy của thông điệp khiến người dùng cảm thấy như họ đứng về phía bạn - đặc biệt nếu nó phù hợp với chính sách thương hiệu của bạn”.
Tuy nhiên, sự hài hước nên được sử dụng trong bối cảnh của khán giả: nó có thể khiến người dùng bối rối hơn hoặc có tác dụng ngược lại. Các trang có lỗi 404 - nơi hoàn hảo dành cho các ứng dụng hài hước nhẹ nhàng (và chuyển hướng chiến lược sang một trang khác).
“Ồ! Winston ăn mặc rất ngầu. Tuy nhiên, bây giờ anh ấy dường như đang mặc thứ gì đó không phù hợp (giống như trang bạn đang tìm kiếm). Hãy giúp anh ấy chọn thứ khác nhé!"
Yahoo! Đây là một ví dụ tuyệt vời về việc sử dụng sự hài hước khi gửi biểu mẫu:
"Bạn thực sự tới từ tương lai sao??"
4. Đơn giản
Thật dễ dàng: đừng đổ lỗi cho người dùng. Chúng ta đã nói về điều này trước đây - nhận lỗi, xin lỗi và đưa ra giải pháp cho vấn đề.
Làm thế nào về việc kiểm tra từng dòng?
Kiểm tra từng dòng là một cách tuyệt vời để tìm, ngăn chặn và sửa lỗi trong thời gian thực. Thay vì đợi biểu mẫu hoàn tất, bạn ngay lập tức thông báo cho người dùng rằng có nội dung nào đó được điền không chính xác:
“Bạn có thể sử dụng các chữ cái, số và dấu chấm.”
"Vui lòng nhập từ 6 đến 30 ký tự"
Có kết quả của những nghiên cứu khá nghiêm túc về việc xác minh từng dòng một. Luke Wroblewski đã thử nghiệm nó vào năm 2009 bằng một tấm séc sau khi nhấp vào nút gửi. Mặc dù không có nhiều ví dụ về mẫu trong quá trình nghiên cứu nhưng kết quả thử nghiệm từng dòng như sau:
- Thêm 22% biểu mẫu được hoàn thành thành công,
- Ít lỗi hơn 22%,
- Sự hài lòng của người dùng tăng 31%,
- Thời gian làm đầy giảm 42%,
- Số lần nhìn chằm chằm giảm 47%.
Việc có thêm 22% số người điền thành công vào biểu mẫu là điều xứng đáng—cũng như việc tạo ra trải nghiệm người dùng hấp dẫn hơn.
Một ví dụ điển hình về việc kiểm tra từng dòng trên trang web booking.com:
“Chúng tôi sẽ gửi cho bạn xác nhận đặt phòng và hướng dẫn đến Tallinn!”
Cách theo dõi lỗi bằng cách sử dụng Google phân tích
Tim Leighton-Boyce của CXFocus gần đây đã viết blog về một trong những báo cáo GA yêu thích của anh ấy:
“Một trong những báo cáo yêu thích của tôi là báo cáo tiêu chuẩn mà nhiều người không chú ý đến: Chuyển đổi > Mục tiêu > Đường dẫn quay lại mục tiêu. Tôi sử dụng nó để theo dõi lỗi.
Điều này đòi hỏi khả năng tạo mục tiêu lỗi, điều này không phải lúc nào cũng có thể thực hiện được đối với một trang web. Tuy nhiên, nếu bạn có thể tạo ra một mục tiêu như vậy thì “Con đường ngược tới mục tiêu” sẽ trở thành công cụ tuyệt vời. Nó hoạt động tốt trong trường hợp không thể dự đoán được các bước dẫn đến lỗi, không giống như kênh đặt hàng. Trên thực tế, các bước dẫn đến mục tiêu là trong trường hợp này và đó là những gì chúng tôi đang cố gắng tìm kiếm":
Đường trở lại mục tiêu
Bạn cũng có thể sử dụng tập lệnh để theo dõi Lỗi JavaScript trên trang của bạn rồi thêm chúng vào tính năng theo dõi sự kiện trong Google Analytics. Tìm kiếm
Engine Watch giải thích cách thiết lập theo dõi sự kiện để phát hiện lỗi khi hoàn thành biểu mẫu:
“Đặt biểu mẫu của bạn để theo dõi các sự kiện, trong đó mỗi sự kiện đại diện cho một trường biểu mẫu cụ thể. Danh mục phải xác định biểu mẫu nào chứa nhiều lỗi nhất và nhãn phải động, đưa ra định nghĩa về quy tắc gây ra lỗi và giá trị đã nhập vi phạm quy tắc đó, ví dụ: được phân tách bằng ký tự "|".
Ở trên có thể yêu cầu sự hỗ trợ của nhà phát triển. Tuy nhiên, sau khi thiết lập tất cả cài đặt, bạn sẽ có quyền truy cập vào báo cáo sự kiện, trong đó các lỗi khi điền vào biểu mẫu của bạn sẽ được tính và sắp xếp. Bạn có thể hiểu nguyên nhân lỗi bằng cách phân tích các giá trị do người dùng nhập vào. Do đó, bạn sẽ quyết định đơn giản hóa logic để kiểm tra giá trị trong trường hoặc thêm văn bản giải thích để giảm số lượng lỗi ảnh hưởng đến chuyển đổi.
Thay vì một kết luận
Xử lý các thông báo lỗi nhằm mục đích giảm bớt sự khó chịu của người dùng khi điền vào biểu mẫu. Nếu người dùng bị căng thẳng (tức là cơ thể họ sản sinh ra hormone cortisol), bạn có nguy cơ đánh mất họ và buộc họ phải rời bỏ để đến với đối thủ cạnh tranh của bạn.
Sự khôn ngoan thông thường nói rằng các báo cáo lỗi tốt phải lịch sự, chính xác và mang tính xây dựng. Với sự ra đời của Web, một số yêu cầu khác đã được bổ sung vào các yêu cầu này: làm cho thông báo lỗi hiển thị rõ ràng; khi xảy ra lỗi thì người dùng không phải tốn nhiều thời gian để sửa lỗi; Đào tạo người dùng khi bạn đi.
Các quy tắc tạo thông báo lỗi hiệu quả vẫn được giữ nguyên trong 20 năm qua. Một thông báo lỗi tốt nên:
Chỉ ra rõ ràng rằng có điều gì đó không ổn. Thông báo lỗi tồi tệ nhất là thông báo không được tạo. Nếu người dùng mắc lỗi và không nhận được bất kỳ phản hồi nào từ hệ thống thì đó là điều tồi tệ nhất đối với họ. Ví dụ: một ứng dụng email có một số tình huống trong đó việc chỉ ra lỗi đã xảy ra sẽ rất hữu ích. Giả sử bạn đã gửi một email đã được hệ thống nuốt thành công nhưng chưa bao giờ đến tay người nhận. Một vi dụ khac? Trong thư bạn nói rằng bạn đang đính kèm một tập tin vào nó, nhưng đơn giản là bạn đã quên làm như vậy. Đây chính là lúc mà chiếc kẹp giấy MS Office ngu ngốc đó sẽ phát huy tác dụng: "Có vẻ như bạn muốn đính kèm một tập tin vào tin nhắn của mình nhưng lại không làm vậy. Bạn có muốn làm điều đó không?"
Được viết bằng ngôn ngữ của con người, không sử dụng các mã và chữ viết tắt bí ẩn như "đã xảy ra lỗi loại 2".
Hãy lịch sự và đừng trách người dùng ngu ngốc hoặc làm sai điều gì đó, chẳng hạn như trong thông báo "lệnh bị cấm".
Mô tả chính xác nguồn gốc của vấn đề thay vì chỉ đưa ra những cụm từ chung chung như "lỗi cú pháp".
Đưa ra lời khuyên mang tính xây dựng về cách giải quyết vấn đề. Ví dụ: thay vì nói rằng một mặt hàng là "hết hàng", thông báo lỗi của bạn phải cho bạn biết khi nào mặt hàng đó có hàng hoặc nhắc người dùng thiết lập tin nhắn thông báo để gửi cho họ khi mặt hàng đó có lại Cổ phần.
Lỗi phổ biến nhất trên Web, 404, vi phạm hầu hết các quy tắc này. Tôi khuyên bạn nên viết thông báo lỗi 404 của riêng mình thay vì dựa vào cụm từ "không tìm thấy trang" của máy chủ.
Luật mới
Sự phức tạp khi làm việc với các trang web đã dẫn đến một quy tắc khác ngày xưa không được yêu cầu. Trong giao diện DOS, người dùng gõ lệnh và thông báo lỗi sẽ xuất hiện ở dòng tiếp theo trên màn hình. Trong môi trường đồ họa hiện đại, khi người dùng chọn một lệnh sai, thông báo lỗi sẽ hiển thị trong hộp thoại lớn ở giữa màn hình và thông báo lỗi sẽ không biến mất cho đến khi người dùng chấp nhận. Tuy nhiên, trên Web, các thông báo lỗi thường bị ẩn trong nội dung của trang, đó là lý do tại sao chúng tôi đưa ra quy tắc sau: thông báo lỗi phải là:
Hiển thị và rất đáng chú ý, cả về bản thân thông báo và nơi người dùng phải sửa lỗi.
Tôi thường nhận thấy cách người dùng mắc lỗi trên biểu mẫu web, gửi biểu mẫu và nhận lại biểu mẫu tương tự trên màn hình mà không có bất kỳ dấu hiệu nào cho thấy nó có vấn đề gì. Thường sẽ có một thông báo lỗi nhỏ ở đầu trang, nhưng vì người dùng trước tiên nhìn vào những gì họ đang làm việc trên trang (tức là các trường biểu mẫu) nên họ thường không nhận thấy thông báo này.
Tương tự như vậy, sẽ không chính xác nếu chỉ hiển thị thông báo lỗi bằng màu đỏ. Điều này vi phạm một trong những quy tắc lâu đời nhất và đơn giản nhất trong việc tạo ra công nghệ mà người dùng có vấn đề về sức khỏe có thể tiếp cận: không bao giờ chỉ sử dụng màu sắc trong giao diện để biểu thị trạng thái hệ thống; luôn bổ sung cho nó một số tín hiệu khác mà những người có vấn đề về nhận biết màu sắc có thể nhìn thấy.
Dưới đây là một số quy tắc khác sẽ giúp giảm thiểu tình huống khó chịu mà người dùng gặp phải khi mắc lỗi:
Giữ lại càng nhiều công việc của người dùng càng tốt. Cho phép người dùng sửa lỗi trong hành động của họ thay vì yêu cầu họ bắt đầu lại. Ví dụ: khi hiển thị kết quả tìm kiếm cho anh ta, hãy hiển thị trường tìm kiếm ở đó và hiển thị các từ khóa mà người dùng đang tìm kiếm để anh ta có thể sửa chúng và cải thiện kết quả. Nếu tìm kiếm không trả lại bất kỳ kết quả nào, hãy cung cấp cho người dùng khả năng mở rộng tìm kiếm chỉ bằng một cú nhấp chuột.
Giảm bớt công việc cần thiết để sửa lỗi. Nếu có thể, hãy cố gắng để hệ thống đoán hành động chính xác và nhắc người dùng chọn hành động đúng đó từ một danh sách tùy chọn nhỏ. Ví dụ: thay vì chỉ viết "tên thành phố không khớp với mã zip của nó", hãy cho người dùng cơ hội nhấp vào nút và chọn thành phố khớp với mã zip của họ từ danh sách.
Đào tạo người dùng
Cuối cùng, có thể bạn đã biết Định luật đầu tiên về Tài liệu Máy tính của Nielsen: Mọi người không đọc nó. Luật này thậm chí còn mạnh hơn đối với các trang web, nơi người dùng thực sự tránh đọc bất cứ thứ gì không cần thiết cho nhiệm vụ của họ. Nhấp vào liên kết "Trợ giúp"? Không đời nào.
Người dùng chỉ đọc tài liệu hệ thống khi họ gặp vấn đề (đây là Định luật thứ hai). Họ đọc nó đặc biệt cẩn thận khi họ muốn sửa một hành động sai lầm. Trong trường hợp này, bạn có thể sử dụng các thông báo lỗi làm tài liệu đào tạo và đưa kiến thức này vào chúng theo từng phần nhỏ. Đương nhiên, các thông báo lỗi phải ngắn gọn và đúng trọng tâm, cũng như tất cả nội dung trang web. Tuy nhiên, thông báo lỗi vẫn có thể cung cấp cho mọi người thông tin về cách hệ thống hoạt động và đề xuất cách tốt nhất để làm việc với nó. Và để kết thúc chủ đề này, Web giới thiệu thêm một quy tắc nữa:
| Mặt sau |
