Thiết kế thông báo lỗi: Số ký tự và nguyên tắc UX
Thông báo lỗi là một phần quan trọng của trải nghiệm người dùng. Một thông báo lỗi được thiết kế tốt giúp người dùng khắc phục nhanh chóng, trong khi một thông báo viết kém gây ra sự thất vọng và bỏ cuộc. Theo nghiên cứu của Nielsen Norman Group, người dùng chỉ dành trung bình 1,5 giây để đọc thông báo lỗi trước khi quyết định hành động, nghĩa là 5–7 từ đầu tiên mang gần như toàn bộ trọng lượng truyền đạt. Bài viết này đề cập đến hướng dẫn về số ký tự và nguyên tắc thiết kế cho thông báo lỗi hiệu quả, dựa trên những hiểu biết từ tâm lý học nhận thức và nghiên cứu khả năng sử dụng. Để tìm hiểu sâu hơn về nguyên tắc viết UX, bạn có thể tham khảo sách về viết UX trên Amazon.
Số ký tự đề xuất theo loại lỗi
Số ký tự đề xuất dưới đây được rút ra từ hai yếu tố: bối cảnh hiển thị (nội tuyến, toast, toàn trang) và trạng thái tâm lý của người dùng (khẩn cấp, bối rối, lo lắng) tại thời điểm lỗi xuất hiện.
| Loại lỗi | Độ dài đề xuất | Ví dụ |
|---|---|---|
| Xác thực nội tuyến | 30–60 ký tự | "Vui lòng nhập địa chỉ email hợp lệ" |
| Lỗi gửi biểu mẫu | 50–100 ký tự | "Không thể gửi. Vui lòng kiểm tra các trường được đánh dấu." |
| Toast / Snackbar | 40–80 ký tự | "Đã lưu thay đổi thành công" / "Mất kết nối" |
| Trang 404 | 100–200 ký tự | Giải thích ngắn gọn + tùy chọn điều hướng |
| Lỗi máy chủ (500) | 80–150 ký tự | "Đã xảy ra lỗi. Vui lòng thử lại sau." |
| Phản hồi lỗi API | 50–200 ký tự | Mã máy đọc được + thông báo cho người dùng |
Cấu trúc cơ bản của mọi thông báo lỗi là "điều gì đã xảy ra + phải làm gì tiếp theo." Một thông báo chỉ nêu nguyên nhân mà không đưa ra giải pháp sẽ khiến người dùng bế tắc. Nghiên cứu tâm lý học nhận thức cho thấy lượng thông tin con người có thể xử lý khi căng thẳng giảm xuống còn khoảng 60% so với bình thường. Vì người dùng gặp lỗi đang ở chính trạng thái này, thông báo cần ngắn gọn hơn và có cấu trúc rõ ràng hơn so với văn bản thông thường.
Nguyên tắc thiết kế
- Cụ thể: "Mật khẩu phải có ít nhất 8 ký tự" tốt hơn "Mật khẩu không hợp lệ"
- Đưa ra giải pháp: Cho người dùng biết phải làm gì, không chỉ nêu lỗi gì đã xảy ra
- Sử dụng ngôn ngữ đơn giản: Tránh thuật ngữ kỹ thuật như "Error 422: Unprocessable Entity"
- Lịch sự nhưng trực tiếp: "Vui lòng nhập email của bạn" thay vì "Bạn quên nhập email"
- Không đổ lỗi cho người dùng: "Địa chỉ email này chưa được đăng ký" thay vì "Bạn đã nhập sai email"
Ba nguyên tắc của thông báo lỗi tốt
Mọi thông báo lỗi hiệu quả đều tuân theo ba nguyên tắc cốt lõi, bất kể nền tảng hay bối cảnh nào. Những nguyên tắc này tương ứng trực tiếp với nguyên tắc khả năng sử dụng của Nielsen "Giúp người dùng nhận biết, chẩn đoán và khắc phục lỗi."
- Nói điều gì đã xảy ra: Mô tả rõ ràng vấn đề bằng ngôn ngữ người dùng hiểu được. "Không thể tải tệp lên vì vượt quá giới hạn 10 MB" hữu ích hơn nhiều so với "Tải lên thất bại." Từ góc độ lý thuyết tải nhận thức, thuật ngữ kỹ thuật làm tăng tải nhận thức ngoại lai, tiêu tốn nguồn lực tinh thần lẽ ra nên dành cho việc giải quyết vấn đề.
- Giải thích tại sao xảy ra: Cung cấp đủ ngữ cảnh để người dùng hiểu nguyên nhân. "Phiên của bạn đã hết hạn sau 30 phút không hoạt động" giúp người dùng hiểu hành vi của hệ thống và ngăn họ nghĩ rằng ứng dụng bị hỏng. Việc cung cấp nguyên nhân giúp điều chỉnh mô hình tư duy của người dùng về cách hệ thống hoạt động, giảm khả năng lỗi tương tự tái diễn.
- Cho biết cách khắc phục: Mọi thông báo lỗi nên bao gồm bước tiếp theo rõ ràng. "Vui lòng chọn tệp dưới 10 MB" hoặc "Đăng nhập lại để tiếp tục" biến một ngõ cụt gây thất vọng thành tình huống có thể khắc phục. Nghiên cứu khả năng sử dụng cho thấy thông báo lỗi có chứa giải pháp có thể cải thiện tỷ lệ hoàn thành tác vụ lên đến 50%. Khi có thể, hãy bao gồm hành động trực tiếp - nút thử lại, liên kết đến trang đăng nhập, hoặc sửa lỗi nội tuyến.
Thông báo tuân theo cả ba nguyên tắc thường có độ dài 60–120 ký tự. Thông báo ngắn hơn thường hy sinh sự rõ ràng; dài hơn có nguy cơ bị bỏ qua.
Mẫu thông báo lỗi từ các dịch vụ lớn
Google, Apple và Microsoft đều có cách tiếp cận riêng biệt trong thiết kế thông báo lỗi. Phân tích các mẫu của họ cho thấy những hướng đi hữu ích cho sản phẩm của bạn.
| Dịch vụ | Triết lý thiết kế | Đặc điểm chính |
|---|---|---|
| Cụ thể và hướng hành động | Liệt kê yêu cầu rõ ràng, ví dụ: "Mật khẩu phải có ít nhất 8 ký tự và bao gồm một số." Người dùng biết ngay phải làm gì. | |
| Apple | Ngắn gọn và quan tâm cảm xúc | Sử dụng cụm từ ngắn, không đổ lỗi như "Kết nối thất bại." Chi tiết được tiết lộ dần qua liên kết "Tìm hiểu thêm". |
| Microsoft | Tiết lộ dần dần | Từ Windows 11, BSOD hiển thị mã QR liên kết đến trang hỗ trợ - cấu trúc hai lớp phục vụ cả người dùng thông thường và nhân viên kỹ thuật. |
Mặc dù phong cách khác nhau, cả ba đều chia sẻ hai nguyên tắc chung: không bao giờ đổ lỗi cho người dùng, và luôn cung cấp hành động tiếp theo. Cách tiếp cận khắc phục lỗi có thể khác nhau, nhưng cam kết thực hiện điều đó là phổ quát.
Giọng điệu và phong cách thông báo lỗi
Giọng điệu của thông báo lỗi ảnh hưởng đáng kể đến cách người dùng nhìn nhận sản phẩm của bạn. Nghiên cứu của Nielsen Norman Group cho thấy thông báo lỗi thân thiện, nghe tự nhiên giảm sự thất vọng của người dùng lên đến 30% so với cách diễn đạt kỹ thuật hoặc máy móc. Lý thuyết quy kết trong tâm lý học giải thích lý do: con người có xu hướng quy thất bại cho nguyên nhân bên ngoài, và ngôn ngữ đổ lỗi kích hoạt phản ứng phòng thủ cản trở việc giải quyết vấn đề.
| Giọng điệu | Ví dụ | Phù hợp nhất cho |
|---|---|---|
| Trung lập / Chuyên nghiệp | "Không thể xử lý yêu cầu của bạn. Vui lòng thử lại." | Phần mềm doanh nghiệp, ngân hàng, y tế |
| Thân thiện / Đối thoại | "Ôi! Có gì đó không hoạt động. Hãy thử lại nhé." | Ứng dụng tiêu dùng, mạng xã hội, thương mại điện tử |
| Tối giản / Kỹ thuật | "Error 404: Resource not found" | Công cụ phát triển, API, nhật ký hệ thống |
| Đồng cảm | "Chúng tôi xin lỗi - trang này hiện không khả dụng." | Gián đoạn dịch vụ, lỗi thanh toán |
Dù bạn chọn giọng điệu nào, hãy duy trì sự nhất quán trong toàn bộ sản phẩm. Việc trộn lẫn thông báo lỗi thân mật và trang trọng trong cùng một ứng dụng tạo ra trải nghiệm rời rạc.
Hướng dẫn thông báo lỗi theo mã trạng thái HTTP
Trong ứng dụng web, thông báo lỗi nên được tối ưu hóa dựa trên mã trạng thái HTTP. Mã trạng thái là thông tin dành cho nhà phát triển - người dùng nên thấy tình huống và giải pháp, không phải mã.
| Mã trạng thái | Thông báo cho người dùng | Độ dài đề xuất | Ghi chú thiết kế |
|---|---|---|---|
| 400 Bad Request | "Có vấn đề với dữ liệu nhập của bạn" | 30–60 ký tự | Chỉ rõ dữ liệu nhập nào có vấn đề |
| 401 Unauthorized | "Vui lòng đăng nhập để tiếp tục" | 30–50 ký tự | Cung cấp liên kết trực tiếp đến trang đăng nhập |
| 403 Forbidden | "Bạn không có quyền truy cập nội dung này" | 40–60 ký tự | Hướng dẫn người dùng cách lấy quyền truy cập |
| 404 Not Found | "Trang này không tồn tại" | 100–200 ký tự | Cung cấp tìm kiếm và điều hướng về trang chủ |
| 408 Request Timeout | "Kết nối đã hết thời gian chờ" | 40–80 ký tự | Đề xuất kiểm tra mạng và thử lại |
| 429 Too Many Requests | "Quá nhiều yêu cầu - vui lòng đợi" | 40–60 ký tự | Cho biết thời gian chờ ước tính |
| 500 Internal Server Error | "Đã xảy ra lỗi từ phía chúng tôi" | 80–150 ký tự | Cung cấp ước tính khắc phục và phương án thay thế |
| 503 Service Unavailable | "Chúng tôi đang bảo trì" | 80–150 ký tự | Nêu thời gian khắc phục dự kiến khi có thể |
Một lưu ý bảo mật quan trọng: việc phân biệt giữa 401 và 403 trong thông báo hiển thị cho người dùng có thể rò rỉ thông tin về việc tài nguyên có tồn tại hay tài khoản người dùng đã được đăng ký hay chưa. Trên trang đăng nhập, hãy sử dụng "Email hoặc mật khẩu không đúng" thay vì chỉ rõ cái nào sai - điều này ngăn chặn các cuộc tấn công liệt kê người dùng.
Phương pháp tốt nhất cho xác thực biểu mẫu
Lỗi xác thực biểu mẫu là loại thông báo lỗi phổ biến nhất mà người dùng gặp phải. Xử lý đúng cách có tác động trực tiếp đến tỷ lệ chuyển đổi.
- Xác thực nội tuyến, không phải khi gửi: Hiển thị lỗi ngay khi người dùng rời khỏi trường (on blur), không phải sau khi họ nhấn "Gửi." Điều này giảm tải nhận thức khi phải sửa nhiều lỗi cùng lúc. Tuy nhiên, tránh hiển thị lỗi ngay khi trường nhận focus - người dùng thậm chí chưa bắt đầu nhập. Đối với phản hồi thời gian thực như độ mạnh mật khẩu, xác thực trong trường là phù hợp.
- Đặt văn bản lỗi ngay bên dưới trường: Người dùng không bao giờ phải cuộn hoặc tìm kiếm lỗi. Tóm tắt ở đầu biểu mẫu hữu ích như bổ sung, nhưng không thay thế cho thông báo nội tuyến.
- Sử dụng màu đỏ một cách tiết chế: Văn bản và viền đỏ hiệu quả để thu hút sự chú ý, nhưng lạm dụng tạo ra nhiễu thị giác. Kết hợp màu sắc với biểu tượng (như tam giác cảnh báo) để đảm bảo khả năng tiếp cận - chỉ màu sắc thôi không đủ cho người dùng mù màu.
- Hiển thị định dạng đúng: Thay vì "Ngày không hợp lệ," hãy viết "Vui lòng nhập ngày theo định dạng DD/MM/YYYY." Thay vì "Số điện thoại không hợp lệ," hãy viết "Số điện thoại phải có 10 chữ số."
- Giữ nguyên dữ liệu nhập của người dùng: Không bao giờ xóa trường khi hiển thị lỗi. Người dùng cần thấy những gì họ đã nhập và sửa lại, không phải nhập lại mọi thứ từ đầu.
Thông báo Toast so với hiển thị nội tuyến
Phương thức hiển thị thông báo lỗi nên phù hợp với bản chất của lỗi. Dưới đây là hướng dẫn về các mẫu hiển thị chính và khi nào nên sử dụng từng loại.
| Phương thức hiển thị | Phù hợp nhất cho | Lưu ý |
|---|---|---|
| Hiển thị nội tuyến | Xác thực biểu mẫu, lỗi theo trường cụ thể | Đặt ngay bên dưới trường liên quan. Tự động cuộn đến lỗi nếu nằm ngoài màn hình. |
| Toast / Snackbar | Thông báo tạm thời (lưu thành công, mất kết nối), cảnh báo không chặn | Tự động biến mất sau 3–5 giây, nên giữ dưới 80 ký tự. Không dùng cho lỗi nghiêm trọng. |
| Hộp thoại modal | Cảnh báo mất dữ liệu, xác nhận hành động không thể hoàn tác | Chặn hoàn toàn tương tác người dùng - chỉ dùng cho tình huống thực sự quan trọng. |
| Banner / Thanh cảnh báo | Gián đoạn toàn hệ thống, thông báo bảo trì | Cố định ở đầu trang với nút đóng. |
Khả năng tiếp cận là yếu tố thiết yếu ở đây. Thông báo lỗi hiển thị động nên sử dụng role="alert" hoặc aria-live="assertive" để người dùng trình đọc màn hình được thông báo ngay lập tức. Thông báo toast tự động biến mất có thể biến mất trước khi trình đọc màn hình đọc xong, vì vậy hãy ưu tiên hiển thị nội tuyến cho các lỗi quan trọng.
Lỗi hệ thống và thiết kế trang 404
Lỗi cấp hệ thống (lỗi 500, hết thời gian chờ, trang 404) đòi hỏi cách tiếp cận khác so với xác thực biểu mẫu. Người dùng gặp những lỗi này thường cảm thấy lạc lõng, vì vậy ưu tiên là trấn an và điều hướng.
- Trang 404 nên bao gồm: giải thích ngắn gọn (50–80 ký tự), thanh tìm kiếm, liên kết đến các trang phổ biến, và liên kết quay về trang chủ. Những trang 404 tốt nhất tạo cảm giác như một đường vòng hữu ích thay vì ngõ cụt.
- Lỗi 500 / Lỗi máy chủ nên thừa nhận vấn đề một cách trung thực ("Đã xảy ra lỗi từ phía chúng tôi"), tránh chi tiết kỹ thuật, và cung cấp tùy chọn thử lại hoặc thời gian khắc phục ước tính khi có thể. Dựa trên nguyên tắc tâm lý học về tránh sự không chắc chắn, "Chúng tôi dự kiến hoạt động trở lại trong khoảng 30 phút" giảm căng thẳng cho người dùng nhiều hơn so với "Vui lòng thử lại sau."
- Lỗi hết thời gian chờ nên phân biệt giữa hết thời gian phía máy khách và phía máy chủ. "Kết nối của bạn có vẻ chậm - vui lòng kiểm tra mạng và thử lại" có tính hành động hơn so với thông báo hết thời gian chung chung.
- Trang bảo trì nên bao gồm thời gian dự kiến, phương thức liên hệ thay thế, và tùy chọn liên kết trang trạng thái. Giữ tổng văn bản dưới 150 ký tự để đảm bảo được đọc hết.
Trên thiết bị di động, hạn chế kích thước màn hình đòi hỏi sự chú ý bổ sung. Trên điện thoại thông minh rộng 320px, thông báo xác thực nội tuyến xuống dòng hơn hai dòng có thể phá vỡ toàn bộ bố cục biểu mẫu. Đối với di động, hãy nhắm đến 15–30 ký tự và sử dụng tiết lộ dần dần (liên kết "Tìm hiểu thêm") cho chi tiết bổ sung.
Những điều thú vị về thông báo lỗi
"Màn hình xanh chết chóc" (BSOD) của Windows được coi là thông báo lỗi được nhìn thấy nhiều nhất trong lịch sử. Microsoft đã thiết kế lại nó trong Windows 8, thay thế mã lỗi kỹ thuật bằng biểu tượng mặt buồn ":(". Trong Windows 11, họ thêm mã QR liên kết người dùng đến trang hỗ trợ - phát triển từ "đồng cảm qua cảm xúc" sang "hướng dẫn đến hành động tiếp theo."
Trang 404 của GitHub ("This is not the web page you are looking for," nhại theo Star Wars) được công nhận rộng rãi là ví dụ thành công về sự hài hước trong trang lỗi. Trang 404 của Amazon hiển thị ảnh chó, củng cố sự ấm áp thương hiệu. Tuy nhiên, sự hài hước chỉ phù hợp cho lỗi không nghiêm trọng như trang 404 - không phù hợp cho lỗi thanh toán hoặc mất dữ liệu.
Nguồn gốc của mã trạng thái HTTP 404 có nhiều giả thuyết. Câu chuyện phổ biến về Phòng 404 tại CERN chứa các máy chủ web đầu tiên vẫn còn tranh cãi. Điều chắc chắn là mã trạng thái HTTP được định nghĩa có hệ thống vào năm 1992, với dải 400 được chỉ định cho lỗi phía máy khách.
Tại sao số ký tự khác nhau theo loại lỗi
Độ dài tối ưu của thông báo lỗi được xác định bởi ba yếu tố: trạng thái cảm xúc của người dùng, độ phức tạp của vấn đề, và không gian màn hình khả dụng.
- Xác thực nội tuyến (30–60 ký tự): Người dùng đang tích cực điền biểu mẫu và ở trạng thái "dòng chảy." Thông báo dài làm gián đoạn sự tập trung này. Những lỗi này cũng bị giới hạn bởi chiều rộng của trường biểu mẫu.
- Thông báo toast (40–80 ký tự): Chúng xuất hiện ngắn gọn và tự động biến mất. Người dùng chỉ có 3–5 giây để đọc, vì vậy mỗi từ đều phải có ý nghĩa.
- Hộp thoại modal (80–150 ký tự): Người dùng đã dừng quy trình làm việc để đọc thông báo này. Bạn có toàn bộ sự chú ý của họ, vì vậy có thể chi tiết hơn - nhưng đừng lạm dụng.
- Lỗi toàn trang như 404 (100–200 ký tự): Người dùng đã hoàn toàn lạc đường. Bạn cần đủ văn bản để giải thích tình huống và cung cấp tùy chọn điều hướng, nhưng không quá nhiều đến mức gây choáng ngợp.
Về mặt tâm lý học nhận thức, Định luật Miller (con số kỳ diệu 7±2) gợi ý rằng một thông báo lỗi đơn lẻ không nên chứa quá 3–4 khối thông tin để vẫn có thể xử lý được khi căng thẳng.
Thiết kế thông báo lỗi đa ngôn ngữ
Đối với dịch vụ toàn cầu, hỗ trợ thông báo lỗi đa ngôn ngữ là không thể tránh khỏi. Tuy nhiên, dịch thuật đơn giản thường không duy trì được chất lượng. Các nhóm làm việc về quốc tế hóa có thể tham khảo hướng dẫn quốc tế hóa phần mềm trên Amazon để thiết lập các phương pháp nhất quán.
- Mở rộng văn bản: Thông báo lỗi tiếng Anh dịch sang tiếng Đức hoặc Pháp thường mở rộng 30–40%. Bản dịch tiếng Nhật có xu hướng co lại còn khoảng 60–70% độ dài tiếng Anh. Bố cục giao diện phải phù hợp với phiên bản ngôn ngữ dài nhất.
- Cân nhắc văn hóa: Tiếng Nhật tự nhiên bao gồm tiền tố lịch sự như "恐れ入りますが" (tạm dịch "Chúng tôi xin lỗi vì sự bất tiện, nhưng..."), nghe dài dòng trong tiếng Anh. Điều chỉnh giọng điệu phù hợp với kỳ vọng văn hóa của từng ngôn ngữ.
- Cạm bẫy mẫu: Mẫu như "{field} is required" hoạt động tự nhiên trong tiếng Anh, nhưng thứ tự từ và biến đổi ngữ pháp trong các ngôn ngữ khác có thể tạo ra kết quả vụng về. Cân nhắc ngữ pháp ngôn ngữ đích khi thiết kế mẫu.
- Ngôn ngữ phải-sang-trái (RTL): Tiếng Ả Rập và tiếng Hebrew đảo ngược hướng văn bản. Vị trí biểu tượng lỗi và căn chỉnh văn bản cũng phải được phản chiếu.
Bảo mật và thông báo lỗi
Thông báo lỗi có thể là nguồn thông tin quý giá cho kẻ tấn công. Từ góc độ bảo mật, các biện pháp phòng ngừa sau đây là thiết yếu.
- Ngăn chặn rò rỉ thông tin: Không bao giờ bao gồm stack trace, tên bảng cơ sở dữ liệu, endpoint API nội bộ, hoặc thông tin phiên bản máy chủ trong thông báo lỗi. Trong môi trường sản xuất, chỉ ghi nhật ký thông tin lỗi chi tiết phía máy chủ và trả về thông báo chung cho người dùng.
- Ngăn chặn liệt kê người dùng: Hiển thị "Địa chỉ email này chưa được đăng ký" trên biểu mẫu đăng nhập cho phép kẻ tấn công xác định địa chỉ email nào có tài khoản. Sử dụng "Email hoặc mật khẩu không đúng" thay thế - không tiết lộ cái nào sai.
- Thông báo giới hạn tần suất: Hiển thị "Còn 3 lần thử trước khi tài khoản bị khóa" cho kẻ tấn công biết chính xác còn bao nhiêu lần thử brute-force. "Vui lòng đợi một lát trước khi thử lại" an toàn hơn.
Thiết kế phản hồi lỗi API
Phản hồi lỗi API phải phục vụ cả nhà phát triển frontend và người dùng cuối. Cấu trúc kết hợp mã lỗi máy đọc được với thông báo thân thiện cho người dùng được khuyến nghị.
Một phản hồi lỗi được thiết kế tốt thường có ba lớp: mã lỗi (định danh duy nhất máy đọc được), thông báo (mô tả người đọc được), và chi tiết (lỗi theo trường cụ thể cho lỗi xác thực). Mã lỗi riêng của ứng dụng, tách biệt với mã trạng thái HTTP, giúp logic điều kiện frontend dễ triển khai hơn nhiều.
Đối với quốc tế hóa thông báo lỗi API, quản lý bản dịch theo khóa mã lỗi là cách tiếp cận hiệu quả nhất. Máy chủ trả về thông báo tiếng Anh, và frontend hiển thị bản dịch phù hợp dựa trên ngôn ngữ của người dùng - thiết kế xuất sắc về cả khả năng bảo trì và mở rộng.
Kỹ thuật thiết kế thông báo lỗi chuyên nghiệp
- Hướng dẫn phong cách thông báo lỗi: Tạo tài liệu tập trung định nghĩa giọng điệu, định dạng và giới hạn ký tự cho mọi loại lỗi trong sản phẩm. Điều này ngăn sự không nhất quán khi nhiều nhà phát triển viết thông báo lỗi độc lập.
- Ưu tiên phòng ngừa lỗi: Thông báo lỗi tốt nhất là thông báo không bao giờ xuất hiện. Hiển thị ràng buộc đầu vào theo thời gian thực (như bộ đếm ký tự), làm mờ tùy chọn không hợp lệ, và sử dụng tự động hoàn thành để ngăn lỗi chính tả. Nguyên tắc "Phòng ngừa lỗi" của Nielsen chính thức hóa cách tiếp cận này.
- Tách nhật ký lỗi khỏi thông báo người dùng: Ghi nhật ký thông tin lỗi chi tiết (stack trace, ID yêu cầu) cho nhà phát triển, và chỉ hiển thị thông báo ngôn ngữ đơn giản cho người dùng. Tuy nhiên, hiển thị "ID lỗi" nhỏ trên màn hình người dùng để tham chiếu hỗ trợ.
- Mẫu hóa thông báo lỗi: Trong ứng dụng lớn, quản lý thông báo lỗi dưới dạng mẫu. Mẫu có cấu trúc như "{hành động} thất bại. {lý do}. {giải pháp}" với tham số cho từng lỗi giúp quản lý tính nhất quán và dịch thuật dễ dàng hơn nhiều.
- A/B test thông báo lỗi: Xử lý thông báo lỗi như bản sao tiếp thị. Thử nghiệm các cách diễn đạt khác nhau và đo lường tác động đến tỷ lệ hoàn thành tác vụ và tỷ lệ bỏ biểu mẫu. Ngay cả thay đổi từ ngữ nhỏ cũng có thể ảnh hưởng đáng kể đến tỷ lệ chuyển đổi.
- Kiểm tra thông báo lỗi hàng năm: Xem xét mọi thông báo lỗi trong sản phẩm ít nhất mỗi năm một lần. Bạn thường sẽ tìm thấy thông báo lỗi thời, định dạng không nhất quán, và tham chiếu đến tính năng không còn tồn tại.
- Dự phòng bản địa hóa: Khi thiết kế thông báo lỗi cho sản phẩm quốc tế, giữ phiên bản tiếng Anh ở 70% giới hạn ký tự tối đa. Bản dịch tiếng Đức và Pháp thường mở rộng 30–40%, và không tính đến điều này gây ra lỗi bố cục.
Kết luận
Thông báo lỗi hiệu quả ngắn gọn (30–200 ký tự), cụ thể và có tính hành động. Như nghiên cứu tâm lý học nhận thức cho thấy, người dùng khi căng thẳng chỉ có thể xử lý lượng thông tin hạn chế. Chúng cho người dùng biết điều gì đã xảy ra và cách khắc phục. Sử dụng Bộ đếm ký tự để đảm bảo thông báo lỗi của bạn nằm trong độ dài tối ưu. Đừng quên cân nhắc các vấn đề bảo mật (rò rỉ thông tin), mở rộng văn bản đa ngôn ngữ, và yêu cầu khả năng tiếp cận. Xây dựng trải nghiệm thông báo lỗi nhất quán trong toàn bộ sản phẩm là điều phân biệt UX tốt với UX tuyệt vời.