Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn đang đặt một chuyến xe qua ứng dụng gọi xe lúc 11 giờ đêm sau một ngày dài. Bạn nhấn nút thanh toán, và màn hình hiện lên: "Đã xảy ra lỗi. Mã lỗi: -1001". Bạn nhìn dòng chữ đó, chẳng hiểu gì cả. Tiền đã bị trừ chưa? Có phải lỗi từ ngân hàng của bạn, hay từ app? Bạn cần làm gì tiếp theo? Không có câu trả lời. Cảm giác bất lực đó — sự tức giận trộn lẫn với hoang mang — chính là thứ mà một dòng error message tồi tệ tạo ra.
Trong Bài 1, chúng ta đã học nền tảng của UX Writing: viết cho hành vi, không phải cho vẻ đẹp câu chữ. Bài 2 này đưa nền tảng đó vào hai loại màn hình mà rất nhiều người viết bỏ quên nhưng lại quyết định phần lớn cảm xúc người dùng: error messages (thông báo lỗi) và empty states (trạng thái rỗng).
Đây là hai khoảnh khắc "mong manh" nhất trong hành trình của người dùng. Error messages xuất hiện đúng lúc họ đang thất vọng — điều gì đó vừa hỏng. Empty states xuất hiện đúng lúc họ đang bối rối — họ mở một màn hình nhưng chẳng thấy gì. Nếu bạn viết tốt hai loại này, bạn biến giây phút khó chịu thành giây phút được dẫn dắt. Nếu viết dở, bạn đẩy người dùng ra khỏi sản phẩm. Một nghiên cứu nội bộ của nhiều đội sản phẩm cho thấy tỉ lệ rời bỏ (drop-off) tại màn hình lỗi thường cao gấp 2–3 lần so với luồng bình thường. Đây không phải chi tiết nhỏ — đây là nơi giữ chân hoặc mất người dùng.
Khái niệm cốt lõi
Error message tốt gồm những gì? — Ba thành phần bắt buộc
Một thông báo lỗi tốt không chỉ báo rằng "có lỗi". Nó trả lời ba câu hỏi mà người dùng đang thầm hỏi trong đầu, theo đúng thứ tự:
1. Chuyện gì đã xảy ra (What happened) — bằng ngôn ngữ đời thường. Người dùng cần biết điều gì vừa hỏng, diễn đạt theo cách họ hiểu, không phải theo cách hệ thống ghi log. "Không gửi được tin nhắn" tốt hơn nhiều so với "Error 500: Internal Server Error".
2. Vì sao (Why) — nếu điều đó hữu ích. Không phải lỗi nào cũng cần giải thích lý do, nhưng khi lý do giúp người dùng hiểu và tránh lặp lại, hãy nói. "Mật khẩu cần ít nhất 8 ký tự" cho biết vì sao mật khẩu bị từ chối. Lưu ý chữ "nếu hữu ích": đừng nhồi lý do kỹ thuật mà người dùng không quan tâm.
3. Cách khắc phục (How to fix) — bước hành động cụ thể. Đây là phần quý giá nhất và cũng hay bị bỏ sót nhất. Người dùng không muốn biết mình sai — họ muốn biết làm sao để đi tiếp. "Kiểm tra kết nối mạng rồi thử lại" cho họ một hành động rõ ràng. Lý tưởng nhất, phần này đi kèm một nút bấm để họ thực hiện luôn.
Hãy so sánh:
> Xấu: "Đã xảy ra lỗi." > > Tốt: "Không tải được danh sách đơn hàng. Có vẻ kết nối mạng của bạn bị gián đoạn. Vui lòng kiểm tra Wi-Fi hoặc 4G rồi nhấn Thử lại."
Dòng thứ hai trả lời cả ba câu hỏi: chuyện gì (không tải được đơn hàng), vì sao (mất mạng), làm gì (kiểm tra mạng, nhấn thử lại).
Nguyên tắc giọng điệu cho error message
Khi có lỗi, người dùng đang căng thẳng. Giọng văn của bạn phải làm dịu, không đổ thêm dầu vào lửa. Ba quy tắc:
- Đừng đổ lỗi cho người dùng. Tránh "Bạn đã nhập sai" — thay bằng "Email này chưa đúng định dạng". Đại từ "bạn" đi kèm lỗi tạo cảm giác bị chỉ trích.
- Đừng dùng ngôn ngữ kỹ thuật hoặc mã lỗi trần trụi. "Null pointer exception" hay "Error -1001" không nói gì với người dùng. Nếu buộc phải có mã lỗi cho mục đích hỗ trợ, hãy đặt nó nhỏ, phụ, sau phần giải thích đời thường.
- Đừng cố tỏ ra hài hước lố lăng ở lỗi nghiêm trọng. Một câu đùa khi mất tiền hoặc mất dữ liệu sẽ phản tác dụng. Hài hước chỉ hợp với lỗi nhẹ, không hậu quả.
Empty state là gì và vì sao nó quan trọng
Empty state là trạng thái của màn hình khi chưa có nội dung để hiển thị: giỏ hàng trống, hộp thư chưa có tin, danh sách yêu thích chưa có gì, kết quả tìm kiếm không tìm thấy. Nhiều đội để mặc những màn hình này trắng trơn hoặc chỉ ghi "Không có dữ liệu". Đó là lãng phí.
Empty state không phải chỗ trống vô nghĩa — nó là cơ hội đầu tiên để hướng dẫn và tạo động lực. Có ba loại empty state chính, mỗi loại cần cách viết khác nhau:
- First-use (lần đầu): người dùng mới, chưa từng tạo nội dung. Đây là lúc onboarding tự nhiên nhất — hãy giải thích màn hình này để làm gì và mời họ hành động đầu tiên.
- User-cleared (đã dọn sạch): người dùng đã hoàn thành hết việc, ví dụ đọc hết thông báo. Đây là khoảnh khắc tích cực — hãy chúc mừng nhẹ nhàng, đừng để họ tưởng có lỗi.
- No-results (không tìm thấy): tìm kiếm hoặc bộ lọc không ra kết quả. Đây gần với error hơn — hãy giúp họ điều chỉnh truy vấn hoặc gợi ý bước tiếp.
Tình huống thực tế
Tình huống 1 — Lỗi thanh toán ở một ví điện tử Việt Nam
Một ví điện tử phổ biến ở Việt Nam (giả định tên là "PayVi") từng hiển thị dòng lỗi khi giao dịch thất bại: "Giao dịch không thành công. Vui lòng thử lại sau." Nghe có vẻ ổn, nhưng đội hỗ trợ khách hàng nhận trung bình khoảng 400 cuộc gọi mỗi ngày chỉ để hỏi cùng một câu: "Tiền của tôi có bị trừ không?"
Vấn đề nằm ở chỗ dòng lỗi trả lời được "chuyện gì" (giao dịch thất bại) nhưng bỏ trống "vì sao" và "làm gì". Người dùng lo nhất là tiền — mà dòng chữ không đả động gì tới tiền. Đội UX Writing đã viết lại theo tình huống cụ thể:
> "Giao dịch chưa hoàn tất. Số dư của bạn không bị trừ. Nguyên nhân có thể do ngân hàng đang bảo trì. Bạn có thể thử lại sau vài phút, hoặc chọn nguồn tiền khác."
Kết quả sau một tháng: số cuộc gọi hỏi về "tiền bị trừ" giảm khoảng 35%, và tỉ lệ người dùng thử lại giao dịch ngay trong app tăng lên. Bài học: ở lĩnh vực tài chính, hãy nói thẳng vào nỗi lo lớn nhất của người dùng (ở đây là tiền), và luôn cung cấp một lối đi thay thế thay vì chỉ "thử lại sau".
Tình huống 2 — Empty state của giỏ hàng trên một sàn TMĐT
Trên một sàn thương mại điện tử Đông Nam Á, màn hình giỏ hàng trống ban đầu chỉ hiển thị một biểu tượng giỏ và dòng chữ "Giỏ hàng của bạn trống". Hết. Người dùng nhìn xong không biết đi đâu, nhiều người thoát app.
Đội thiết kế nội dung nhận ra đây là empty state loại first-use hoặc user-cleared — và là cơ hội để kéo người dùng quay lại mua sắm. Họ viết lại:
> Tiêu đề: "Giỏ hàng đang chờ bạn" > Dòng phụ: "Thêm sản phẩm bạn thích để không bỏ lỡ ưu đãi hôm nay." > Nút: "Khám phá sản phẩm hot"
Cùng lúc, họ thêm bên dưới một dải gợi ý "Dựa trên lượt xem gần đây của bạn". Sau thử nghiệm A/B, phiên bản mới giúp tỉ lệ người dùng rời khỏi màn hình giỏ trống mà tiếp tục duyệt sản phẩm tăng rõ rệt. Bài học: empty state không phải ngõ cụt — nó là bệ phóng. Một tiêu đề mời gọi, một dòng tạo động lực và một CTA rõ ràng biến màn hình "không có gì" thành điểm chuyển hướng.
Tình huống 3 — Kết quả tìm kiếm rỗng trên app giao đồ ăn
Một ứng dụng giao đồ ăn hiển thị khi người dùng tìm món không có: "Không tìm thấy kết quả." Vấn đề là người dùng ở khu vực ngoại thành thường gõ tên món kèm lỗi chính tả, hoặc tìm món mà quán gần đó không bán, rồi bỏ cuộc.
Đội viết lại empty state loại no-results theo hướng cứu vãn truy vấn:
> Tiêu đề: "Chưa tìm thấy 'phơ bo' gần bạn" > Dòng phụ: "Có thể do lỗi chính tả, hoặc quán gần bạn chưa có món này. Thử lại nhé:" > Gợi ý: các nút nhanh "Phở bò", "Bún bò", "Mở rộng phạm vi giao hàng"
Bằng cách lặp lại đúng từ khóa người dùng đã gõ (kể cả khi sai chính tả) và đưa ra các lựa chọn thay thế bấm được, tỉ lệ tìm kiếm lần hai thành công tăng lên đáng kể thay vì để người dùng thoát. Bài học: với no-results, đừng chỉ báo "không có" — hãy đoán ý định người dùng và mở cho họ một cánh cửa khác ngay tại chỗ.
Hướng dẫn từng bước
Đây là quy trình bạn có thể áp dụng cho bất kỳ error message hoặc empty state nào:
Bước 1 — Xác định ngữ cảnh và cảm xúc. Hỏi: người dùng đang ở đâu trong luồng? Họ đang cảm thấy gì lúc màn hình này xuất hiện? Lo lắng (mất tiền), bối rối (không thấy nội dung), hay thất vọng (thao tác hỏng)? Cảm xúc quyết định giọng điệu.
Bước 2 — Với error, trả lời đủ ba câu hỏi. Viết ra: (a) Chuyện gì đã xảy ra? (b) Vì sao, nếu hữu ích? (c) Làm gì tiếp theo? Nếu một trong ba thiếu, người dùng sẽ mắc kẹt. Nếu bạn không biết lý do chính xác, hãy trung thực và tập trung vào bước khắc phục.
Bước 3 — Với empty state, phân loại trước khi viết. Đây là first-use, user-cleared, hay no-results? Mỗi loại có mục tiêu khác nhau: hướng dẫn, chúc mừng, hay cứu vãn. Viết tiêu đề, dòng phụ và CTA phù hợp với loại đó.
Bước 4 — Dùng ngôn ngữ đời thường, loại bỏ thuật ngữ. Đọc lại và gạch bỏ mọi từ kỹ thuật: server, timeout, null, exception, mã lỗi trần. Thay bằng cách người dùng thật sự nói.
Bước 5 — Luôn để lại một hành động. Không màn hình lỗi hay rỗng nào được là ngõ cụt. Phải có ít nhất một nút hoặc liên kết dẫn người dùng đi tiếp: thử lại, quay về, khám phá, liên hệ hỗ trợ.
Bước 6 — Đọc to và kiểm tra cảm xúc. Đọc thành tiếng như đang nói với một người bạn đang bực bội. Nghe có trách móc không? Có lạnh lùng không? Có bỏ rơi họ không? Chỉnh cho tới khi nghe như một người đồng hành đang giúp đỡ.
Lỗi thường gặp & mẹo
Lỗi 1 — Dùng thông báo lỗi chung chung cho mọi tình huống. "Đã có lỗi xảy ra, vui lòng thử lại" áp cho mọi trường hợp là dấu hiệu người viết lười. Mỗi loại lỗi (mất mạng, sai mật khẩu, hết phiên đăng nhập, server quá tải) cần một thông báo riêng vì cách khắc phục khác nhau. Mẹo: lập một bảng liệt kê các loại lỗi phổ biến của sản phẩm và viết riêng cho từng loại.
Lỗi 2 — Đổ lỗi hoặc dùng giọng buộc tội. "Bạn nhập sai định dạng" khiến người dùng khó chịu. Mẹo: chuyển trọng tâm từ người sang việc — "Email cần có dạng ten@example.com".
Lỗi 3 — Hiển thị mã lỗi kỹ thuật ở tuyến đầu. Mẹo: nếu cần mã lỗi để hỗ trợ tra cứu, hãy đặt nó dưới cùng bằng chữ nhỏ, ví dụ "(Mã: PAY-402)", sau khi đã giải thích bằng ngôn ngữ đời thường.
Lỗi 4 — Bỏ trống hoặc coi thường empty state. Màn hình trắng với dòng "Không có dữ liệu" là cơ hội bị lãng phí. Mẹo: coi mỗi empty state như một mini-landing-page có tiêu đề, động lực và CTA.
Lỗi 5 — Empty state chúc mừng nhầm chỗ hoặc báo động nhầm chỗ. Khi người dùng đọc hết thông báo (user-cleared), đừng viết như thể có lỗi. Ngược lại, khi tìm kiếm thất bại, đừng viết vui vẻ như thể mọi thứ ổn. Mẹo: khớp giọng điệu với đúng loại empty state.
Lỗi 6 — Quên nút hành động. Một thông báo lỗi hoàn hảo về câu chữ nhưng không có nút "Thử lại" vẫn khiến người dùng phải tự mò. Mẹo: mỗi error/empty state phải trả lời được câu hỏi "giờ tôi bấm vào đâu?".
Bài tập thực hành
Bài 1 — Chữa lỗi generic. Cho dòng lỗi sau: "Lỗi. Vui lòng thử lại." Bối cảnh: người dùng vừa nhấn đăng nhập nhưng mật khẩu sai. Hãy viết lại theo đúng ba thành phần (chuyện gì / vì sao / làm gì) mà không đổ lỗi cho người dùng.
Bài 2 — Viết ba phiên bản empty state. Cho màn hình "Danh sách yêu thích" của một app đọc sách. Viết ba phiên bản cho ba loại: (a) first-use — người dùng chưa lưu cuốn nào; (b) no-results — họ lọc theo thể loại "Kinh dị" nhưng chưa lưu cuốn kinh dị nào; (c) đề xuất CTA phù hợp cho mỗi phiên bản. Mỗi phiên bản gồm tiêu đề, dòng phụ và nút.
Bài 3 — Audit sản phẩm thật. Mở một ứng dụng bạn hay dùng (ví điện tử, app giao hàng, ngân hàng số). Cố tình tạo ra một lỗi (nhập sai mật khẩu, tắt mạng khi tải trang) và tìm ít nhất hai empty state (giỏ hàng trống, tìm kiếm không ra). Chấm điểm từng màn hình theo tiêu chí: có đủ ba câu hỏi không? có nút hành động không? giọng điệu có phù hợp không? Viết lại bản tốt hơn cho hai màn hình tệ nhất.
Bài 4 — Bảng lỗi. Liệt kê 5 loại lỗi phổ biến nhất của một app giao đồ ăn (mất mạng, hết món, ngoài vùng giao, thanh toán lỗi, phiên hết hạn) và viết thông báo riêng cho từng loại.
Tóm tắt
Error messages và empty states là hai khoảnh khắc mong manh nhất trong trải nghiệm người dùng — nơi họ đang thất vọng hoặc bối rối, và cũng là nơi cách bạn viết quyết định họ ở lại hay rời đi.
Với error message, hãy luôn trả lời ba câu hỏi: chuyện gì đã xảy ra (bằng ngôn ngữ đời thường), vì sao (nếu hữu ích), và cách khắc phục (một bước hành động cụ thể). Đừng đổ lỗi, đừng phô mã lỗi kỹ thuật, và luôn để lại một lối đi.
Với empty state, hãy nhớ nó không phải chỗ trống vô nghĩa mà là cơ hội hướng dẫn và tạo động lực. Phân loại đúng — first-use, user-cleared, hay no-results — rồi viết tiêu đề, dòng phụ và CTA phù hợp với mục tiêu của từng loại.
Nguyên tắc xuyên suốt: không màn hình nào được là ngõ cụt. Mỗi lần điều gì đó hỏng hoặc trống rỗng, đó là một lời mời để bạn dắt tay người dùng đi tiếp. Viết tốt hai loại màn hình này, bạn không chỉ giảm cuộc gọi hỗ trợ và tỉ lệ rời bỏ — bạn xây dựng niềm tin, thứ khó có mà dễ mất trong mọi sản phẩm số.