App Của Bạn Nên Nói Gì Khi Gặp Lỗi: Viết Thông Báo Lỗi Mà Người Dùng Thực Sự Hiểu Được

App nào rồi cũng có lúc gặp trục trặc. Mạng rớt, server khựng lại, có người gõ số điện thoại lẫn cả chữ cái. Phần đó bạn không thể ngăn chặn hoàn toàn. Nhưng thứ bạn có thể kiểm soát là thông báo lỗi — dòng chữ app hiển thị khi có gì đó trục trặc — và chính thông báo đó thường là ranh giới giữa một người dùng nhún vai rồi thử lại, với một người dùng âm thầm kết luận app của bạn bị hỏng và không bao giờ quay lại nữa.

Hầu hết các app do AI xây dựng đều làm sai khoảnh khắc này. Không phải vì công cụ xây dựng cẩu thả, mà vì thông báo lỗi là thứ chẳng ai nghĩ tới cho đến khi có sự cố xảy ra ngay trước mặt một người dùng thật. Mặc định, app thường hiển thị một trong hai điều tệ nhất: im lặng hoàn toàn, hoặc một khối văn bản kỹ thuật đáng sợ. Hãy cùng khắc phục cả hai.

Vì sao app lại thất bại trong im lặng hoặc hiện thông báo lỗi đáng sợ?

App gặp trục trặc theo hai kiểu tồi tệ: hoặc không nói gì khi có gì đó thất bại, hoặc hiện ra một lỗi kỹ thuật mà người bình thường không thể đọc hiểu. Cả hai đều để người dùng tự đoán, và chính việc phải đoán mò đó khiến người ta bỏ cuộc.

Thất bại trong im lặng. Một freelancer, tạm gọi là Maya, đã xây một biểu mẫu đặt lịch cho việc kinh doanh nhiếp ảnh của cô. Một khách hàng bấm “Xác nhận đặt lịch,” nút nhấp nháy, rồi… không có gì cả. Không xác nhận, không lỗi, không cả vòng xoay tải. Nó có hoạt động không? Vị khách không chắc, nên cô ấy đặt lại lần nữa. Giờ Maya có hai lượt đặt cho cùng một khung giờ và một khách hàng bối rối. App không hề bị crash — chỉ là việc lưu thất bại, và app không nói gì cả, nên người đang thao tác trước màn hình chẳng biết thực tế đang diễn ra như thế nào.

Lỗi kỹ thuật đáng sợ. Kiểu thất bại còn lại thì ồn ào hơn và bằng cách nào đó còn tệ hơn. Một tình nguyện viên đang vận hành một chiến dịch gây quỹ cộng đồng thử tải lên một bảng tính và nhận được một ô đỏ ghi Error 500: Internal Server Error. Cô đọc nó như thể “Tôi đã làm hỏng cái gì đó.” Cô không thử lại, không gửi email nhờ giúp đỡ, chỉ đóng tab lại — vì thông báo đó khiến sự cố nghe như lỗi của cô, và như thể động vào lần nữa có thể không an toàn.

Cả hai người dùng đều gặp phải một vấn đề bình thường, hoàn toàn có thể khắc phục được. Cả hai đều bỏ đi, vì thông báo lỗi của app hoặc không nói gì, hoặc nói ra điều gì đó đáng sợ.

Điều gì làm nên một thông báo lỗi tốt?

Một thông báo lỗi tốt làm bốn việc nhỏ, bằng ngôn ngữ đơn giản: nói rõ chuyện gì đã xảy ra, nói rõ lỗi thuộc về ai, nói rõ tiếp theo nên làm gì, và không làm mất công sức người dùng đã bỏ ra.

Nói rõ chuyện gì đã xảy ra — “Chúng tôi không thể lưu lượt đặt lịch của bạn,” chứ không phải im lặng và cũng không phải 500.
Nói rõ lỗi thuộc về ai — thường thì câu trả lời trung thực là “của chúng tôi,” và việc nói ra điều đó giúp người dùng bình tĩnh lại.
Nói rõ tiếp theo nên làm gì — “Thử lại sau một lát” hoặc “Kiểm tra kết nối mạng rồi thử lại.”
Không làm mất công sức của họ — bất cứ thứ gì họ đã gõ vào vẫn còn nguyên trong biểu mẫu khi thông báo hiện ra.

Chỉ vậy thôi. Không cần cả bài xin lỗi dài dòng, không lấy mã lỗi làm tiêu đề, không đổ lỗi. Đây là ba trường hợp thất bại ở trên, được viết lại:

❌ (không có gì xảy ra) → ✅ “Chúng tôi vừa không lưu được thông tin đó. Thông tin bạn nhập vẫn còn đây — hãy bấm Xác nhận để thử lại.”
❌ Error 500: Internal Server Error → ✅ “Có gì đó trục trặc từ phía chúng tôi khi tải file đó lên. Không phải lỗi của bạn đâu. Hãy thử lại sau một phút nữa.”
❌ Invalid input → ✅ “Số điện thoại đó có vẻ chưa đúng — nó cần đủ 10 chữ số, ví dụ như 555-123-4567.”

Chú ý ở ví dụ cuối, thông báo chỉ thẳng vào ô nhập liệu cụ thể và cho thấy mẫu đúng trông như thế nào. “Invalid input” khiến người ta phải mò mẫm; còn “số điện thoại đó cần đủ 10 chữ số” thì nói rõ chính xác cần sửa gì.

Nên sửa lỗi nào trước tiên trong app của bạn?

Bạn không cần một thông báo riêng cho từng khả năng thất bại — chỉ ba loại đã bao quát gần như mọi thứ có thể trục trặc trong một app điển hình: việc lưu hoặc gửi bị thất bại, dữ liệu nhập vào mà app không dùng được, và sự cố xảy ra ở phía bạn.

Việc lưu hoặc gửi bị thất bại. Đây là kiểu phá vỡ lòng tin nhiều nhất, vì người dùng đã làm mọi thứ đúng mà vẫn không chắc liệu nó có thành công hay không. Luôn xác nhận khi thành công và giải thích khi thất bại. Đừng bao giờ để họ phải đoán mò, và đừng bao giờ xóa mất những gì họ đã gõ.

“Chúng tôi không dùng được thứ bạn vừa nhập” (kiểm tra dữ liệu). Đây thực ra không phải là lỗi — mà là một sự hiểu lầm. Hãy bắt lỗi ngay khi người dùng rời khỏi ô nhập liệu, chỉ thẳng vào đúng ô đó, và đưa ra ví dụ cho định dạng đúng. Đừng đợi đến khi họ bấm Gửi rồi mới hiện ra cả một mảng đỏ.

“Có gì đó ở phía chúng tôi bị hỏng.” Những sự cố thật sự về server hoặc mạng. Hãy nói rõ đây là lỗi từ phía bạn, giữ giọng điệu bình tĩnh, và cho họ một cách để thử lại. Người dùng không thể tự sửa server của bạn, nên đừng khiến họ cảm thấy như họ phải làm điều đó.

Ba thói quen âm thầm tạo ra khác biệt

Có vài điều phân biệt những app xử lý sự cố một cách khéo léo với những app không làm được điều đó:

Đừng bao giờ hiển thị mã lỗi thô làm toàn bộ thông báo. Mã lỗi có thể nằm nhỏ ở phía dưới để phục vụ hỗ trợ, nhưng dòng tiêu đề mà con người đọc phải là một câu văn, chứ không phải ERR_CONN_RESET.
Đừng bao giờ đổ lỗi cho người dùng. “Bạn đã nhập sai gì đó” khiến người ta khó chịu; còn “ngày này có vẻ đã ở trong quá khứ — bạn có muốn chọn tháng sau không?” thì lại giúp ích. Cùng một thông tin, nhưng cảm giác hoàn toàn khác nhau.
Luôn giữ lại dữ liệu họ đã nhập. Nếu app tải lại hoặc việc lưu thất bại và biểu mẫu bị trống trơn, bạn đã biến một trục trặc nhỏ thành mười phút gõ lại từ đầu. Người ta có thể tha thứ cho một lần lưu thất bại. Nhưng họ sẽ không tha thứ cho việc phải làm lại công việc đó hai lần.

Làm sao để công cụ AI xây dựng app của bạn viết thông báo lỗi tốt hơn?

Bạn có thể đạt được hầu hết điều này chỉ với một yêu cầu — dán đại loại như prompt bên dưới và công cụ AI xây dựng app của bạn sẽ áp dụng các quy tắc ngôn ngữ đơn giản ở trên trên toàn bộ app.

“Khi việc lưu hoặc tải lên bị thất bại, đừng thất bại trong im lặng và đừng hiện mã lỗi kỹ thuật. Hãy hiện một thông báo ngắn gọn, thân thiện bằng ngôn ngữ đơn giản, cho biết chuyện gì đã xảy ra, cho biết là có thể thử lại được, và giữ nguyên bất cứ thứ gì người dùng đã nhập. Với các ô trong biểu mẫu, hãy kiểm tra ngay khi người dùng rời khỏi từng ô và hiện một thông báo cụ thể kèm ví dụ cho định dạng đúng.”

Sau đó, hãy yêu cầu nó dẫn bạn qua ba tình huống: mạng bị tắt, một ô bắt buộc bị bỏ trống, và server phản hồi chậm. Nếu câu trả lời cho bất kỳ tình huống nào là “nó không hiện gì cả” hoặc “nó hiện lỗi thô,” đó chính là điều cần sửa tiếp theo.

Làm sao để kiểm tra thông báo lỗi trong app của bạn?

Tắt wifi, mở app của bạn lên, và thử làm việc chính — đó là toàn bộ bài kiểm tra, chỉ mất hai phút.

Đặt lịch, lưu ghi chú, tải file lên. Xem nó nói gì. Nó có cho bạn biết điều gì mà một người bình thường có thể hiểu được không? Nó có làm mất những gì bạn đã gõ không? Giờ bật wifi lại và cố tình gõ những ký tự vô nghĩa vào một ô nhập liệu. Lặp lại những câu hỏi tương tự.

Hầu hết các app đều trượt bài kiểm tra này ngay lần đầu, và điều đó cũng không sao — nó chỉ cho bạn biết chính xác nên bắt đầu từ đâu. Bạn không cần phải làm cho mọi thông báo lỗi đều hoàn hảo. Hãy tìm ra một điều trong app của bạn hay gặp trục trặc nhất, và làm cho thông báo đó trở nên tử tế, rõ ràng, và trung thực trước tiên. Lần tới khi một người dùng thật gặp phải nó, họ sẽ thử lại thay vì rời đi — và việc thử lại chính là toàn bộ cuộc chơi.