Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang chuyển 5 triệu đồng qua ứng dụng ngân hàng lúc 11 giờ đêm. Bạn bấm "Xác nhận", màn hình quay quay vài giây, rồi hiện lên một dòng chữ đỏ: "Đã xảy ra lỗi. Vui lòng thử lại sau." Tim bạn hụt một nhịp. Tiền đã trừ chưa? Người nhận có nhận được không? "Thử lại sau" là bao lâu? Có phải lỗi do mình gõ sai số tài khoản không? Bạn không biết gì cả — và chính cái "không biết" đó biến một trục trặc kỹ thuật nhỏ thành một trải nghiệm đầy lo âu.
Đây chính là lý do error message (thông báo lỗi) là một trong những phần khó nhất và quan trọng nhất của UX writing. Người dùng đọc microcopy khác — như tiêu đề, nút bấm — trong trạng thái bình thường, thư thái. Nhưng họ đọc error message trong trạng thái đã thất bại: bực bội, hoang mang, đôi khi hoảng sợ. Đây là khoảnh khắc dễ khiến họ rời bỏ sản phẩm nhất. Một nghiên cứu kinh điển của Nielsen Norman Group xếp "thông báo lỗi rõ ràng, mang tính xây dựng" vào 10 nguyên tắc heuristic cốt lõi của giao diện — không phải vì nó "cho vui", mà vì nó trực tiếp quyết định người dùng có vượt qua được trở ngại hay bỏ cuộc.
Ở Bài 2, chúng ta đã nói tổng quan về error messages và empty states. Bài 10 này đi sâu vào một khung công thức cụ thể, có thể áp dụng ngay: 4 thành phần bắt buộc của một error message tốt. Sau bài này, bạn sẽ có một checklist để "soi" bất kỳ thông báo lỗi nào — của sản phẩm mình hay của đối thủ — và biết chính xác nó thiếu gì.
Khái niệm cốt lõi
Một error message tốt không chỉ nói "có lỗi". Nó phải trả lời trọn vẹn ba câu hỏi mà người dùng đang thầm hỏi trong đầu, cộng thêm một yếu tố về giọng điệu. Đó là 4 thành phần:
1. What happened — Chuyện gì đã xảy ra
Đây là thành phần bắt buộc tuyệt đối, không bao giờ được thiếu. Người dùng cần biết chính xác cái gì không thành công. Điểm mấu chốt: hãy mô tả bằng ngôn ngữ của người dùng, không phải ngôn ngữ của hệ thống.
- Tệ: "Error 400: Bad Request"
- Tốt: "Số điện thoại này chưa được đăng ký"
2. Why — Tại sao (nếu hữu ích)
Đây là thành phần có điều kiện — chữ "nếu hữu ích" rất quan trọng. Đôi khi giải thích nguyên nhân giúp người dùng hiểu và tránh lặp lại; đôi khi nó chỉ làm rối và thậm chí gây rủi ro bảo mật.
- Hữu ích: "Mật khẩu cần ít nhất 8 ký tự, bao gồm 1 chữ hoa và 1 số" — người dùng hiểu tiêu chí và sửa được.
- Không nên: "Đăng nhập thất bại vì mật khẩu sai" khi tài khoản không tồn tại. Nói quá cụ thể ("email đúng, mật khẩu sai") giúp kẻ tấn công dò ra email nào có tồn tại. Trong trường hợp này, một câu chung chung "Email hoặc mật khẩu không đúng" lại an toàn hơn.
3. How to fix — Cách khắc phục
Đây là thành phần biến một thông báo lỗi từ "than phiền" thành "hướng dẫn". Người dùng cần biết bước tiếp theo cụ thể. Một error message không có lối thoát giống như một tấm biển "Đường cấm" mà không chỉ đường vòng — nó khiến người ta đứng chôn chân.
- Tệ: "Kết nối thất bại."
- Tốt: "Không kết nối được máy chủ. Hãy kiểm tra kết nối mạng của bạn rồi thử lại." (kèm nút "Thử lại")
4. Tone — Giọng điệu phù hợp
Thành phần thứ tư không phải về nội dung mà về cách nói. Trong Bài 5 chúng ta đã phân biệt voice và tone; ở error message, tone phải: không đổ lỗi cho người dùng, không hoảng loạn, không đùa cợt vô duyên.
- Đừng đổ lỗi: tránh "Bạn đã nhập sai định dạng". Hãy dùng "Định dạng email chưa đúng" — cùng thông tin nhưng không chĩa ngón tay vào người dùng.
- Đừng đùa lố: một câu jokey như "Hic, server của tụi mình lăn ra ngủ rồi!" nghe dễ thương khi lỗi vô hại, nhưng cực kỳ vô duyên khi người dùng vừa mất một giao dịch quan trọng.
Ghi nhớ khung này bằng một câu: What → Why → How, với đúng Tone. Không phải error message nào cũng cần cả 4 (Why là tùy chọn), nhưng "What", "How" và "Tone" thì gần như luôn luôn cần.
Tình huống thực tế
Ví dụ 1: Ứng dụng gọi xe — lỗi thanh toán ví điện tử
Bối cảnh: Một ứng dụng gọi xe kiểu Grab/Be tại Việt Nam. Người dùng đặt chuyến xe 85.000đ, chọn thanh toán bằng ví điện tử liên kết. Đến cuối chuyến, hệ thống trừ tiền thất bại vì ví không đủ số dư.
Phiên bản cũ hiển thị: "Giao dịch không thành công. Mã lỗi: PAY_ERR_09."
Phân tích: Thông báo này chỉ có một nửa của "What" (giao dịch nào? tiền chuyến xe à?) và hoàn toàn không có "Why" theo ngôn ngữ người dùng, cũng chẳng có "How to fix". Mã "PAY_ERR_09" là ngôn ngữ của lập trình viên, hoàn toàn vô nghĩa với bác tài và với hành khách. Kết quả thực tế: hành khách bối rối, tài xế phải gọi tổng đài, chuyến xe kẹt lại 10 phút ở lề đường.
Phiên bản viết lại theo khung 4 thành phần:
> What: "Chưa thanh toán được cước phí 85.000đ." > Why: "Số dư ví của bạn hiện không đủ." > How: "Bạn có thể nạp thêm vào ví, hoặc thanh toán bằng tiền mặt cho tài xế." (kèm 2 nút: "Nạp ví" và "Trả tiền mặt") > Tone: điềm tĩnh, không trách móc.
Bài học rút ra: Trong bối cảnh thanh toán, "How to fix" nên cung cấp lối thoát tức thời (trả tiền mặt) chứ không bắt người dùng loay hoay trong lúc tài xế đang đợi. Một error message tốt phải hiểu ngữ cảnh vật lý mà người dùng đang đứng.
Ví dụ 2: Sàn thương mại điện tử — lỗi ở bước checkout
Bối cảnh: Một sàn TMĐT kiểu Shopee/Tiki. Người dùng thêm hàng vào giỏ, tới bước đặt hàng thì mã giảm giá không áp dụng được vì đơn hàng chưa đạt giá trị tối thiểu.
Phiên bản cũ: "Mã không hợp lệ."
Phân tích: Câu này gây hiểu lầm nghiêm trọng. "Không hợp lệ" khiến người dùng tưởng mã đã hết hạn hoặc bị nhập sai, nên họ gõ đi gõ lại, rồi bực bội bỏ mã. Nhưng thực tế mã hoàn toàn đúng — chỉ là đơn chưa đủ điều kiện. Đây là lỗi thiếu "Why" chính xác, dẫn tới người dùng chẩn đoán sai vấn đề.
Phiên bản viết lại:
> What: "Chưa áp dụng được mã FREESHIP50." > Why: "Mã này áp dụng cho đơn từ 300.000đ. Đơn của bạn hiện là 240.000đ." > How: "Thêm 60.000đ nữa để dùng mã này." (kèm gợi ý sản phẩm hoặc nút "Xem thêm sản phẩm") > Tone: hữu ích, gợi mở.
Bài học rút ra: Ở đây "Why" không chỉ giải thích — nó còn chuyển đổi kinh doanh. Bằng cách nói rõ "thêm 60.000đ nữa", thông báo lỗi biến thành cơ hội upsell. Một error message được viết tốt không chỉ cứu trải nghiệm mà đôi khi còn tạo ra doanh thu. Con số cụ thể (300k, 240k, 60k) làm cho "How to fix" trở nên rõ ràng, không mơ hồ.
Ví dụ 3: Ứng dụng học trực tuyến — lỗi tải video bài giảng
Bối cảnh: Một nền tảng edtech. Học viên đang xem bài giảng thì video ngừng, hiện thông báo lỗi. Nguyên nhân là mạng của học viên chập chờn (lỗi phía người dùng), không phải lỗi máy chủ.
Phiên bản cũ: "Không thể phát video. Đã xảy ra lỗi không xác định."
Phân tích: "Lỗi không xác định" là một trong những cụm từ tệ nhất trong UX writing — nó thừa nhận hệ thống cũng không biết chuyện gì, và đẩy toàn bộ gánh nặng chẩn đoán sang người dùng. Không "How to fix", không hướng dẫn, chỉ có bế tắc.
Phiên bản viết lại:
> What: "Video tạm dừng vì mất kết nối." > Why: "Đường truyền mạng của bạn đang không ổn định." > How: "Hãy kiểm tra Wi-Fi hoặc chuyển sang chất lượng thấp hơn để xem mượt hơn." (kèm nút "Thử lại" và tùy chọn "Xem ở chất lượng 480p") > Tone: động viên, đúng tinh thần edtech.
Bài học rút ra: Khi lỗi nằm ở phía người dùng nhưng không phải lỗi của họ, "How to fix" nên đưa ra nhiều hơn một lựa chọn — thử lại (nếu mạng đã ổn) hoặc giảm chất lượng (giải pháp thích ứng). Điều này trao lại quyền kiểm soát cho học viên thay vì bắt họ ngồi chờ.
Hướng dẫn từng bước
Khi bạn phải viết hoặc sửa một error message, hãy làm theo quy trình sau:
Bước 1 — Xác định người dùng vừa cố làm gì. Đừng bắt đầu từ mã lỗi kỹ thuật. Hãy hỏi: người dùng đang ở màn hình nào, vừa bấm nút gì, kỳ vọng điều gì? Error message phải nối tiếp hành động đó, không phải nối tiếp log của server.
Bước 2 — Viết "What happened" bằng ngôn ngữ người dùng. Một câu ngắn, cụ thể, không thuật ngữ kỹ thuật, không mã số. Kiểm tra: nếu đưa câu này cho mẹ hoặc bà của bạn đọc, họ có hiểu chuyện gì vừa xảy ra không?
Bước 3 — Quyết định có cần "Why" không. Tự hỏi hai câu: (a) Biết nguyên nhân có giúp người dùng sửa được không? (b) Nêu nguyên nhân có làm lộ thông tin nhạy cảm không? Nếu (a) có và (b) không, hãy thêm "Why". Ngược lại, bỏ qua.
Bước 4 — Cung cấp "How to fix" với hành động rõ ràng. Ưu tiên hành động người dùng tự làm được. Nếu có thể, biến nó thành một nút bấm ngay trong thông báo (ví dụ: nút "Thử lại", "Nạp ví", "Đặt lại mật khẩu") thay vì chỉ mô tả bằng chữ.
Bước 5 — Chỉnh tone theo mức độ nghiêm trọng. Đọc to câu lên. Nó có nghe như đang đổ lỗi cho người dùng không? Có đùa cợt không đúng lúc không? Có gây hoảng sợ không? Điều chỉnh cho tới khi giọng vừa điềm tĩnh vừa tôn trọng.
Bước 6 — Rút gọn. Sau khi có đủ 4 thành phần, cắt bỏ mọi từ thừa. Error message nên ngắn nhất có thể mà vẫn đủ 4 yếu tố. Người đang bực bội không đọc một đoạn văn.
Lỗi thường gặp & mẹo
Lỗi 1 — Hiển thị mã lỗi kỹ thuật cho người dùng cuối. "Error 500", "NullPointerException", "PAY_ERR_09" không nên xuất hiện trước mặt người dùng thường. Mẹo: nếu bộ phận hỗ trợ cần mã lỗi để tra cứu, hãy ẩn nó ở dạng nhỏ, phụ ("Mã tham chiếu: 09" ở cuối), không để nó là nội dung chính.
Lỗi 2 — Dùng "Vui lòng thử lại sau" cho mọi thứ. Đây là câu "lười" nhất trong UX writing. Nó không nói What, không nói Why, "How" thì mơ hồ ("sau" là khi nào?). Mẹo: luôn cố cung cấp một hành động cụ thể hơn hoặc ít nhất là một lối thoát khác.
Lỗi 3 — Đổ lỗi cho người dùng. "Bạn đã nhập sai", "Bạn chưa điền đủ". Mẹo: chuyển sang thể vô nhân xưng hoặc tập trung vào trường dữ liệu: "Email chưa đúng định dạng", "Còn thiếu số điện thoại".
Lỗi 4 — Đùa cợt trong lỗi nghiêm trọng. Tone dí dỏm chỉ hợp với lỗi vô hại (trang 404 chẳng hạn). Với lỗi mất tiền, mất dữ liệu, giao dịch thất bại — tuyệt đối nghiêm túc.
Lỗi 5 — Đặt error message sai chỗ. Thông báo lỗi của một trường form nên nằm ngay cạnh trường đó, không phải một cục đỏ trên đỉnh trang khiến người dùng phải đoán trường nào sai. (Chi tiết về form errors sẽ được đào sâu ở Bài 29 — ở đây chỉ lưu ý nguyên tắc vị trí.)
Mẹo vàng — Viết error message trước, code sau. Nhiều lỗi tệ ra đời vì lập trình viên viết vội thông báo lúc code. Nếu UX writer chuẩn bị sẵn thư viện các thông báo lỗi theo khung 4 thành phần, chất lượng đồng đều hơn hẳn.
Bài tập thực hành
Bài 1 — Chẩn đoán. Lấy 3 error message bất kỳ mà bạn gặp trong tuần này (chụp màn hình từ app ngân hàng, app đặt đồ ăn, website bạn dùng). Với mỗi cái, đánh dấu nó có bao nhiêu trong 4 thành phần: What / Why / How / Tone đúng. Cái nào thiếu gì?
Bài 2 — Viết lại. Viết lại thông báo sau theo đủ khung 4 thành phần: "Đăng ký thất bại. Thử lại sau." — biết rằng nguyên nhân thật là email đã được dùng cho một tài khoản khác. Viết cả nội dung nút bấm đi kèm.
Bài 3 — Cân nhắc "Why". Cho tình huống đăng nhập thất bại. Viết hai phiên bản: một phiên bản có "Why" cụ thể và một phiên bản ẩn "Why" vì lý do bảo mật. Giải thích trong tình huống nào bạn chọn phiên bản nào.
Bài 4 — Điều chỉnh tone. Viết cùng một lỗi "Không lưu được bản nháp của bạn" ở 2 mức nghiêm trọng: (a) app ghi chú cá nhân nhẹ nhàng, (b) app soạn hợp đồng quan trọng. Chú ý sự khác biệt trong tone và trong "How to fix".
Tóm tắt
Error message là microcopy quan trọng bậc nhất vì người dùng đọc nó ở đúng khoảnh khắc dễ bỏ cuộc nhất. Một thông báo lỗi tốt được xây trên 4 thành phần:
- What happened — nói rõ chuyện gì xảy ra, bằng ngôn ngữ người dùng, không phải mã kỹ thuật. Bắt buộc.
- Why — nêu nguyên nhân khi nó giúp người dùng sửa và không lộ thông tin nhạy cảm. Tùy chọn.
- How to fix — chỉ ra bước tiếp theo cụ thể, lý tưởng là một nút bấm hành động ngay. Gần như luôn cần.
- Tone — điềm tĩnh, không đổ lỗi, không đùa cợt sai lúc; tỷ lệ thuận với mức nghiêm trọng.