Product Management
Đăng nhập
ESC

Nhập từ khóa để tìm kiếm

↑↓ Di chuyển
Enter Mở
ESC Đóng

Bài 57 — Common UX Writing Mistakes — Audit

Mở đầu — vì sao bài này quan trọng

Sau 56 bài, bạn đã học rất nhiều nguyên tắc: cách viết button label, error message, empty state, cách chọn voice và tone, cách xưng hô cho đúng ngữ cảnh Việt Nam. Nhưng có một sự thật phũ phàng mà mọi UX Writer đều phải đối mặt: biết nguyên tắc và phát hiện được lỗi trong sản phẩm thật là hai kỹ năng khác nhau.

Trong công việc thực tế, bạn hiếm khi được viết mọi thứ từ đầu trên một tờ giấy trắng. Phần lớn thời gian, bạn sẽ thừa kế một sản phẩm đã có sẵn hàng nghìn dòng chữ — do developer viết vội, do một PM copy từ đối thủ, do bản dịch máy từ tiếng Anh, hoặc do một UX Writer trước đó đã nghỉ việc. Nhiệm vụ của bạn là bước vào mớ hỗn độn đó, tìm ra chỗ sai, và sửa. Đó gọi là content audit (kiểm toán nội dung).

Bài 57 này không dạy thêm nguyên tắc mới. Thay vào đó, nó biến toàn bộ kiến thức bạn đã học thành một checklist thực chiến — một danh sách các lỗi phổ biến nhất mà bạn sẽ gặp đi gặp lại trong 90% dự án. Khi bạn thuộc lòng checklist này, bạn có thể mở bất kỳ màn hình nào lên và trong vòng vài phút chỉ ra: "chỗ này sai, chỗ kia sai, và đây là lý do." Đó chính là năng lực khiến một UX Writer được coi là chuyên gia chứ không phải người "chỉ biết chỉnh chữ cho đẹp."

Khái niệm cốt lõi

Content audit là quá trình rà soát có hệ thống toàn bộ (hoặc một phần) nội dung của sản phẩm để tìm ra các vấn đề về rõ ràng, nhất quán, giọng điệu và trải nghiệm. Khác với việc viết mới, audit đòi hỏi tư duy của một thanh tra: bạn không hỏi "mình muốn viết gì", mà hỏi "chữ này có phục vụ người dùng không, và nếu không thì sai ở đâu."

Dưới đây là Top 10 lỗi UX Writing phổ biến nhất — bộ checklist bạn nên in ra và dán lên bàn.

1. Jargon — dùng thuật ngữ kỹ thuật thay vì ngôn ngữ người dùng

Đây là lỗi số một, và thường là lỗi khó thấy nhất vì người viết ra nó (developer, PM kỹ thuật) coi những từ đó là bình thường.

  • "Submit query" → "Tìm kiếm"
  • "Authenticate" → "Đăng nhập"
  • "Invalid credentials" → "Sai email hoặc mật khẩu"
  • "Transaction failed" → "Chuyển tiền không thành công"
  • "Sync in progress" → "Đang cập nhật dữ liệu"
Nguyên tắc kiểm tra: hỏi mẹ hoặc bà bạn có hiểu câu này không. Nếu không, đó là jargon.

2. Button mơ hồ — label không nói rõ hành động

Button là nơi người dùng đưa ra quyết định, nên nó phải cho biết chính xác điều gì sẽ xảy ra khi bấm.

  • "OK" trong một hộp thoại xóa tài khoản → "Xóa tài khoản"
  • "Có / Không" → "Lưu thay đổi / Hủy"
  • "Submit" → "Đặt hàng", "Gửi đơn", "Thanh toán" tùy ngữ cảnh
  • "Continue" trên bước cuối cùng → "Hoàn tất đăng ký"
Nguyên tắc verb-leading (dẫn dắt bằng động từ) từ Bài 9 áp dụng ở đây: đọc riêng label mà vẫn biết bấm vào sẽ làm gì.

3. Error message đổ lỗi cho người dùng và không có lối thoát

Lỗi kinh điển: thông báo lỗi chỉ nói "có gì đó sai" mà không nói sai gì, tại sao, và phải làm sao.

  • "Error 404" → "Không tìm thấy trang này. Có thể liên kết đã cũ — thử về Trang chủ nhé."
  • "You entered an invalid value" → "Số điện thoại cần có 10 chữ số, bắt đầu bằng 0."
  • "Something went wrong" (đứng một mình) → thêm hành động: "...Vui lòng thử lại sau vài giây."
Áp dụng 4 thành phần bắt buộc từ Bài 10: chuyện gì xảy ra, tại sao, cách khắc phục, giọng không đổ lỗi.

4. Placeholder giả làm label

Rất nhiều form dùng placeholder (chữ mờ trong ô) thay cho label. Khi người dùng bắt đầu gõ, placeholder biến mất và họ quên mất ô này hỏi gì. Đây vừa là lỗi UX vừa là lỗi accessibility (Bài 21).

  • Ô trống chỉ ghi mờ "Nhập ngày sinh" → cần label cố định "Ngày sinh" phía trên, placeholder ghi định dạng "DD/MM/YYYY".

5. Không nhất quán về xưng hô và thuật ngữ

Cùng một sản phẩm nhưng chỗ gọi "bạn", chỗ gọi "quý khách"; chỗ ghi "Giỏ hàng", chỗ ghi "Túi đồ"; chỗ "Đăng xuất", chỗ "Thoát tài khoản". Sự không nhất quán này làm người dùng thấy sản phẩm thiếu chuyên nghiệp và rời rạc.

6. Empty state để trống hoặc vô nghĩa

Màn hình trống chỉ ghi "Không có dữ liệu" là cơ hội bị bỏ phí (Bài 11). Nó nên giải thích tại sao trống và gợi ý hành động tiếp theo.

  • "Danh sách trống" → "Bạn chưa lưu khóa học nào. Khám phá khóa học ngay →"

7. Chữ quá dài, vòng vo

  • "Vui lòng nhấp vào nút bên dưới để tiến hành xác nhận đơn hàng của quý khách" → "Xác nhận đơn hàng"
Microcopy tốt là microcopy ngắn. Mỗi từ thừa là một chút gánh nặng nhận thức đặt lên người dùng.

8. Tone lệch ngữ cảnh cảm xúc

Đùa cợt khi người dùng vừa mất tiền, hoặc lạnh lùng khi họ vừa hoàn thành thành tựu (Bài 12, 39). Ví dụ: giao dịch thất bại mà ghi "Ối, tiền bay mất rồi! 😅" là phản cảm.

9. Chữ "phần thưởng" giả tạo và cường điệu

"Chúc mừng! Bạn là người may mắn nhất hôm nay!" khi thực chất chỉ là hoàn tất một thao tác bình thường. Người dùng Việt Nam ngày càng nhạy với marketing rỗng — nó làm giảm niềm tin (Bài 54).

10. Dịch máy / dịch word-by-word từ tiếng Anh

  • "Please try again later" dịch cứng thành "Xin hãy thử lại sau này" (không tự nhiên) → "Vui lòng thử lại sau."
  • "Your session has expired" → không dịch "phiên của bạn đã hết hạn" một cách máy móc mà viết "Bạn cần đăng nhập lại để tiếp tục."

Tình huống thực tế

Ví dụ 1 — App gọi xe: nút "OK" gây mất khách

Một startup gọi xe khu vực Đông Nam Á (giả định tên GoRide) có màn hình xác nhận hủy chuyến với nội dung: "Bạn có chắc chắn?" kèm hai nút "OK""Hủy".

Vấn đề chí mạng ở đây là sự lẫn lộn ngữ nghĩa: người dùng đang muốn hủy chuyến xe, nhưng nút "Hủy" lại có nghĩa là hủy thao tác hủy — tức là giữ chuyến. Còn "OK" thì không nói rõ OK cái gì. Đội hỗ trợ khách hàng ghi nhận trung bình 40 khiếu nại mỗi tuần kiểu "tôi bấm OK mà xe vẫn tới" hoặc "tôi bấm Hủy mà chuyến vẫn bị hủy."

Sau audit, đội UX Writing sửa thành: tiêu đề "Hủy chuyến xe này?", mô tả "Bạn sẽ phải đặt lại từ đầu nếu đổi ý.", hai nút "Hủy chuyến" (màu đỏ) và "Giữ chuyến". Khiếu nại loại này giảm khoảng 85% trong tháng tiếp theo.

Bài học: button phải mô tả hành động cụ thể, không bao giờ dùng "OK/Hủy" hay "Có/Không" trong ngữ cảnh có hai hành động đối nghịch. Đây là lỗi #2 trong checklist.

Ví dụ 2 — Sàn thương mại điện tử: error message toàn jargon

Một sàn TMĐT Việt Nam khi thanh toán bằng thẻ thất bại hiển thị: "Transaction declined. Error code: DO_NOT_HONOR." Đây là mã lỗi kỹ thuật do ngân hàng trả về, và developer đã hiển thị thẳng nó ra cho người dùng.

Kết quả: người mua hoảng loạn — họ tưởng thẻ bị khóa hoặc bị lừa đảo, nhiều người bỏ luôn giỏ hàng. Đội phân tích phát hiện tỷ lệ bỏ giỏ ở bước thanh toán khi gặp lỗi này lên tới 78%.

Bản audit đề xuất diễn giải mã lỗi thành ngôn ngữ người dùng, đúng 4 thành phần của Bài 10: "Ngân hàng chưa duyệt giao dịch này. Thường do hạn mức thẻ hoặc cài đặt thanh toán online. Bạn thử lại, đổi thẻ khác, hoặc liên hệ ngân hàng nhé." Kèm nút "Thử lại""Chọn phương thức khác". Tỷ lệ hoàn tất thanh toán sau lỗi tăng đáng kể vì người dùng hiểu vấn đề nằm ở phía ngân hàng chứ không phải họ làm sai.

Bài học: không bao giờ để mã lỗi hệ thống lọt ra giao diện. Đây là kết hợp lỗi #1 (jargon) và #3 (error không có lối thoát).

Ví dụ 3 — App fintech: audit tìm ra 6 cách gọi cùng một thứ

Một ví điện tử (giả định tên VíXanh) thuê một UX Writer mới. Việc đầu tiên chị làm là lập bảng audit từ vựng. Chị đi qua toàn bộ app và ghi lại: chức năng nạp tiền được gọi là "Nạp tiền", "Top-up", "Nạp ví", "Add funds", "Thêm tiền""Chuyển vào ví" ở sáu màn hình khác nhau — do sáu team khác nhau xây trong ba năm.

Người dùng mới không thể chắc chắn các nút đó có làm cùng một việc hay không, dẫn đến do dự và câu hỏi lặp lại ở tổng đài. Chị thống nhất tất cả về một từ duy nhất — "Nạp tiền" — và đưa vào content style guide (chủ đề Bài 22) để không lặp lại. Chỉ riêng thay đổi nhỏ này giúp giảm 12% câu hỏi "làm sao nạp tiền" ở kênh chat hỗ trợ.

Bài học: không nhất quán về thuật ngữ (lỗi #5) là loại lỗi âm thầm nhưng cực kỳ phổ biến ở sản phẩm nhiều đội. Một cuộc audit từ vựng đơn giản thường là "quả ngọt" đầu tiên mà UX Writer mới mang lại.

Hướng dẫn từng bước

Đây là quy trình audit bạn có thể áp dụng cho bất kỳ sản phẩm nào:

Bước 1 — Xác định phạm vi. Đừng cố audit cả app trong một lần. Chọn một luồng cụ thể: onboarding, checkout, hoặc luồng lỗi thanh toán. Một luồng rõ ràng dễ hoàn thành và dễ chứng minh giá trị.

Bước 2 — Chụp lại toàn bộ. Đi qua luồng đó và chụp màn hình mọi trạng thái: trạng thái thường, trạng thái lỗi, empty state, loading, success. Lỗi thường ẩn ở các trạng thái ít ai kiểm tra (empty và error).

Bước 3 — Lập bảng inventory. Tạo một bảng (Google Sheets là đủ) với các cột: Màn hình | Chữ hiện tại | Lỗi thuộc loại nào (theo checklist #1–#10) | Mức độ nghiêm trọng | Đề xuất sửa.

Bước 4 — Chấm theo checklist Top 10. Với mỗi dòng chữ, chạy qua 10 lỗi ở trên như một danh sách kiểm tra. Ghi số lỗi tương ứng để dễ thống kê sau này.

Bước 5 — Xếp ưu tiên. Không phải lỗi nào cũng ngang nhau. Ưu tiên theo: (a) lỗi trong luồng liên quan tiền/dữ liệu quan trọng, (b) lỗi xuất hiện tần suất cao, (c) lỗi dễ sửa và tác động lớn. Sửa nhóm "tác động cao, công sức thấp" trước.

Bước 6 — Đề xuất bản sửa kèm lý do. Đừng chỉ ghi "sửa lại cho hay hơn". Ghi rõ: "Đổi 'OK' thành 'Xóa tài khoản' vì button phải mô tả hành động (nguyên tắc verb-leading)." Lý do gắn với nguyên tắc giúp bạn thuyết phục PM và developer.

Bước 7 — Chuẩn hóa vào style guide. Mọi quyết định về thuật ngữ và xưng hô phải được ghi lại để lần sau không audit lại từ đầu. Audit mà không có style guide đi kèm sẽ phải làm lại sau sáu tháng.

Lỗi thường gặp & mẹo

  • Sa vào tranh luận sở thích. Audit không phải chỗ để cãi "tôi thấy câu này hay hơn." Luôn neo mọi nhận xét vào một nguyên tắc cụ thể hoặc dữ liệu (khiếu nại, tỷ lệ bỏ giỏ). Ý kiến cá nhân dễ bị bác; nguyên tắc thì khó cãi.
  • Bỏ quên các trạng thái ẩn. 80% lỗi nằm ở error, empty và loading state — những màn hình developer viết vội và ít ai review. Đừng chỉ audit "happy path".
  • Sửa một chỗ, quên cả hệ thống. Nếu bạn đổi "Top-up" thành "Nạp tiền" ở một màn, phải tìm và đổi tất cả những chỗ khác. Dùng chức năng tìm kiếm trong codebase hoặc file dịch (thường là các file .json chứa chuỗi văn bản) để không bỏ sót.
  • Audit quá to nên không bao giờ xong. Một luồng nhỏ được audit trọn vẹn có giá trị hơn cả app được audit nửa vời. Bắt đầu nhỏ, giao kết quả, rồi mở rộng.
  • Mẹo "đọc to". Đọc thành tiếng từng dòng microcopy. Nếu nghe như robot hoặc như bản dịch, đó là lỗi #10. Tai của bạn bắt lỗi tự nhiên tốt hơn mắt.
  • Mẹo "test bà ngoại". Với mỗi thuật ngữ, tự hỏi người thân không rành công nghệ có hiểu không. Đây là bộ lọc jargon nhanh và đáng tin nhất.

Bài tập thực hành

Bài 1 — Sửa nhanh checklist. Sửa lại 5 dòng dưới đây và ghi rõ nó vi phạm lỗi số mấy trong Top 10:

  • Nút "Submit" ở cuối form đăng ký tài khoản.
  • Thông báo "Error: null value not allowed".
  • Màn hình lịch sử giao dịch trống, chỉ ghi "No data".
  • Hộp thoại xóa ảnh với hai nút "Có" / "Không".
  • "Phiên đăng nhập của bạn đã bị hết hiệu lực."
Bài 2 — Mini audit thật. Mở một app bạn hay dùng (ví điện tử, app ngân hàng, sàn TMĐT). Chọn đúng một luồng — ví dụ luồng chuyển tiền. Đi qua nó, cố tình tạo ra một lỗi (nhập sai số tài khoản, để trống ô bắt buộc). Lập bảng inventory 4 cột như Bước 3 và tìm ít nhất 3 lỗi thuộc checklist. Với mỗi lỗi, viết bản sửa kèm lý do neo vào nguyên tắc.

Bài 3 — Audit từ vựng. Trong app đó, tìm một chức năng và liệt kê tất cả các cách gọi khác nhau của cùng một thứ (như ví dụ VíXanh). Đề xuất một từ chuẩn duy nhất và giải thích vì sao chọn từ đó.

Tóm tắt

  • Content audit là kỹ năng biến kiến thức nguyên tắc thành khả năng phát hiện và sửa lỗi trong sản phẩm thật — năng lực cốt lõi phân biệt UX Writer chuyên nghiệp.
  • Thuộc lòng Top 10 lỗi phổ biến: jargon, button mơ hồ, error đổ lỗi/không lối thoát, placeholder giả label, không nhất quán, empty state vô nghĩa, chữ vòng vo, tone lệch cảm xúc, cường điệu giả tạo, dịch máy cứng nhắc.
  • Ba tình huống thực tế cho thấy mỗi lỗi đều có cái giá đo được: khiếu nại tăng, bỏ giỏ hàng, câu hỏi lặp ở tổng đài.
  • Quy trình 7 bước: khoanh phạm vi → chụp lại → lập inventory → chấm theo checklist → xếp ưu tiên → đề xuất kèm lý do → chuẩn hóa vào style guide.
  • Luôn neo nhận xét vào nguyên tắc hoặc dữ liệu, đừng tranh luận sở thích. Đừng quên các trạng thái ẩn (error, empty, loading) — nơi trú ngụ của phần lớn lỗi. Và bắt đầu nhỏ: một luồng audit trọn vẹn giá trị hơn cả app làm dở dang.
Học xong bài này rồi? Tạo tài khoản miễn phí để lưu lại — lần sau vào là biết ngay đang dở ở đâu, và học hết khóa thì có chứng chỉ. Lưu tiến độ của tôi