Microcopy là câu chữ ngắn trên app/website như nút bấm, hướng dẫn nhập, báo lỗi và xác nhận. “Xác nhận đặt lịch” rõ hơn “OK” vì nói đúng việc khách sắp làm.
Câu chữ hay không sửa được quy trình lỗi hoặc ứng dụng chậm. Hãy thử cả chức năng và lời hướng dẫn.
Tóm tắt: Mỗi câu nên giúp người dùng hiểu đang xảy ra điều gì, cần làm gì tiếp theo và dữ liệu có được giữ không. Đặc biệt, khi nhập sai, hết hạn mã, mất mạng hoặc thanh toán chưa rõ, phải có hướng xử lý cụ thể; không chỉ hiển thị “Có lỗi”.
Microcopy là gì?
Microcopy giúp khách làm một việc; UX Writing thống nhất cách viết trên toàn app; quảng cáo nhằm giới thiệu sản phẩm.
Ví dụ: dùng “Gửi mã xác thực” cho cùng một nút ở mọi màn hình, thay vì nơi gọi “Gửi”, nơi lại gọi “Xác nhận”.
Theo Apple, chữ giao diện cần rõ. W3C yêu cầu báo lỗi nhập bằng chữ và gợi ý cách sửa khi phù hợp.
Câu chữ rõ giúp người dùng thao tác thế nào?
Câu rõ có thể giảm nhập sai và bỏ dở. Đo việc hoàn tất, số lỗi và yêu cầu hỗ trợ; không tự quy tăng doanh thu cho việc đổi chữ.
Nếu đổi cả giá hoặc giao diện, không thể coi kết quả mới hoàn toàn do câu chữ.
Nguyên tắc viết microcopy
- Viết đúng việc người dùng muốn làm, tránh chữ chung chung.
- Nói rõ hậu quả trước thao tác khó hoàn tác như xóa tài khoản.
- Dùng một tên cho cùng một thao tác trên các màn hình.
- Khi lỗi, chỉ ra phần cần sửa và đường tiếp tục.
- Xin quyền hoặc dữ liệu một cách minh bạch, không ép đồng ý.
- Kiểm tra chữ đủ rõ với người đọc bằng công cụ hỗ trợ và các ngôn ngữ cần dùng.
Ví dụ viết cho nút, biểu mẫu và thông báo
Nút bấm và lời kêu gọi hành động
Nút nên nói rõ hành động; với thanh toán, xóa dữ liệu hoặc việc khó hoàn tác, hiển thị hậu quả và xác nhận phù hợp.
| Nút khó hiểu | Nút/giải thích phù hợp |
|---|---|
| Gửi | Gửi mã xác thực — ghi rõ gửi qua SMS hay email khi cần. |
| Xác nhận | Xác nhận đặt lịch — chỉ hiện thành công khi lịch thực sự được ghi nhận. |
| Xóa | Xóa tài khoản — giải thích dữ liệu nào mất và cho xác nhận nếu không khôi phục được. |
| Mua | Thanh toán — hiện đúng số tiền và phí thực tế trước khi xác nhận. |
Biểu mẫu và lời hướng dẫn nhập
Ô nhập cần tên rõ bên ngoài ô, ví dụ “Email nhận hóa đơn”; có gợi ý định dạng và báo đúng ô sai, không bắt nhập lại toàn bộ.
- Chỉ hỏi thông tin cần thiết; đánh dấu ô bắt buộc.
- Ghi định dạng cần nhập ngay tại ô.
- Báo lỗi bằng chữ, không chỉ dùng màu.
- Giữ dữ liệu đã nhập khi an toàn.
Theo W3C, không dùng chữ gợi ý trong ô thay cho tên trường.
Thông báo lỗi và cách khắc phục
Lỗi cần nói rõ điều gì sai và cách khắc phục. Không báo đã lưu khi chưa lưu, hoặc yêu cầu trả tiền lần hai khi chưa xác minh. Xem Nielsen Norman Group và Atlassian.
| Tình huống | Câu đề xuất (chỉ dùng khi hệ thống hỗ trợ) |
|---|---|
| Email chưa nhập | “Nhập email để nhận xác nhận lịch hẹn.” |
| Mất mạng, chưa gửi | “Chưa gửi được yêu cầu. Kiểm tra kết nối rồi thử lại.” |
| Mã OTP hết hạn | “Mã đã hết hạn. Chọn Gửi mã mới.” Hiển thị thời gian chờ nếu có. |
| Thanh toán chưa rõ trạng thái | “Đang kiểm tra kết quả thanh toán. Đừng thanh toán lại; xem lịch sử giao dịch hoặc liên hệ hỗ trợ.” |
Khi chưa có dữ liệu hoặc không có kết quả
Phân biệt chưa có lịch, không tìm thấy món và mất mạng; mỗi trường hợp cần hướng tiếp tục khác nhau.
Ví dụ: “Chưa có lịch — Đặt lịch”; “Không tìm thấy món — Xóa lọc”; “Mất mạng — Thử lại” khi nút này dùng được.
Câu xin quyền camera, vị trí và dữ liệu
Khi khách chọn “Chụp hóa đơn”, giải thích “Cho phép camera để chụp hóa đơn”. Nếu từ chối, hỗ trợ tải ảnh/nhập tay khi có chức năng.
- Nêu việc nào cần quyền và dùng trong lúc nào.
- Cho biết quyền dùng một lần hay trong app khi áp dụng.
- Có cách tiếp tục khi từ chối mà vẫn làm được việc.
- Không dùng lời đe dọa để ép đồng ý.
Thông báo trên điện thoại và trong app
Tin đơn hàng phải đúng trạng thái; tin quảng cáo cần có quyền nhận và cách tắt.
Đối chiếu chiến lược push notification để quản lý audience, timing, measurement và opt-out.
Dùng chung một bộ cách viết trong toàn ứng dụng
Nhóm sản phẩm, thiết kế, kỹ thuật và hỗ trợ nên thống nhất tên nút, thông báo lỗi, xưng hô và người duyệt.
Khi dịch nhiều ngôn ngữ, tránh ghép câu từ các mảnh rời vì trật tự từ có thể khác. Thử các biến, độ dài chữ và định dạng ngay trong giao diện thật.
5 bước rà lại câu chữ trên ứng dụng
- Chọn một việc khách hay nhầm: đăng ký, nhập OTP, đặt lịch hay thanh toán.
- Kiểm tra câu chữ lúc chờ, thành công, lỗi, trống và hủy.
- So tên nút, câu lỗi với thao tác thực tế và người chịu trách nhiệm.
- Cho khách thử trên điện thoại, kể cả người đọc chậm hoặc dùng công cụ hỗ trợ.
- Sau cập nhật, theo dõi tỷ lệ hoàn tất, lỗi và phản hồi để sửa tiếp.
Kiểm tra câu chữ có dễ hiểu không?
Không phải nút nào cũng cần A/B. Cho người dùng đọc và thử thao tác thật trước; dùng so sánh số liệu khi đủ mẫu.
Chọn kiểm tra cách hiểu cho câu mơ hồ, quan sát thao tác khi khách bị kẹt; chỉ thử A/B khi có cách đo và kiểm soát rủi ro.
Với OTP, xem xác thực thành công, nhập sai, gửi mã lại và khóa tài khoản; không chỉ đo tốc độ.
Ví dụ kiểm tra câu chữ khi nhập mã OTP
| Nội dung thử nghiệm giả định | Cách kiểm tra |
|---|---|
| Khách bỏ ở bước nhập mã | Xác định bước lỗi hoặc khách không hiểu hướng dẫn. |
| Viết lại nội dung | Rõ mã hết hạn, gửi lại và chờ nếu có; chỉ hiện chức năng sẵn có. |
| Kết quả cần xem | So tỷ lệ xác thực hoàn tất trong nhóm khách phù hợp. |
| Điều không được xấu đi | Không tăng khóa tài khoản, lỗi gửi mã hoặc yêu cầu hỗ trợ. |
| Sau thử nghiệm | Giữ, sửa hoặc hoàn tác nếu có dữ liệu đủ tin cậy. |
Đây là tình huống giả định, không phải số liệu tăng trưởng đã đo.
Nhất quán từ landing page đến trong app
Thông tin tính năng, giá, điều kiện cần khớp từ quảng cáo và kho ứng dụng đến trong app.
Đối chiếu landing page giới thiệu app, mô tả App Store và Google Play và content cho ứng dụng di động.
Checklist trước khi cập nhật ứng dụng
- Nút cho biết sẽ làm gì; thao tác xóa hoặc trả tiền nêu đúng hậu quả.
- Ô nhập có nhãn, hướng dẫn định dạng và thông báo lỗi bằng chữ.
- Màn hình chờ, lỗi mạng, mã hết hạn, hủy và thành công nói đúng thực tế.
- Xin quyền minh bạch, có lựa chọn từ chối khi phù hợp.
- Thử tiếng Việt trên màn hình nhỏ, công cụ đọc màn hình và các chỉ số quan trọng.
Ứng dụng có nút bấm hoặc thông báo khó hiểu?
WebsiteHCM có thể hỗ trợ kiểm tra câu chữ trên app, viết lại hướng dẫn, thông báo lỗi và đo khả năng hoàn tất thao tác. Để trao đổi, doanh nghiệp nên chuẩn bị các màn hình đang gây khó hiểu, câu chữ hiện tại và lỗi khách thường gặp.
Câu hỏi thường gặp
Microcopy có chỉ là chữ trên nút không?
Không: còn có lời hướng dẫn nhập, báo lỗi, xác nhận, xin quyền và thông báo.
Microcopy có làm tăng conversion không?
Có thể, nhưng không có mức tăng chung. Phải đo cả lỗi, giao diện và tốc độ.
Ai chịu trách nhiệm microcopy?
Nhóm sản phẩm, thiết kế, kỹ thuật và hỗ trợ cùng kiểm tra; nội dung về tiền và dữ liệu cần người duyệt.
Có nên dùng giọng hài hước trong lỗi?
Chỉ khi rủi ro thấp và phù hợp thương hiệu. Với thanh toán, bảo mật, mất dữ liệu hoặc sức khỏe, ưu tiên rõ, bình tĩnh và hỗ trợ phục hồi.
Có cần A/B test mọi câu?
Không. Hãy kiểm tra người dùng có hiểu và làm đúng không trước; chỉ thử hai phiên bản bằng số liệu khi có đủ người tham gia và tiêu chí đo rõ.
Kết luận
Microcopy giúp người dùng hiểu và hoàn thành thao tác, không chỉ làm giao diện hấp dẫn hơn. Hãy thiết kế theo trạng thái thật của hệ thống, kiểm tra lỗi và quyền riêng tư, sau đó đo kết quả có điều kiện.
Đoàn Trình Dục là Giảng viên Khoa Công nghệ Thông tin tại Đại học Công nghệ Sài Gòn (STU), với hơn 10 năm kinh nghiệm thực chiến trong các lĩnh vực Mạng máy tính, Marketing Online, SEO và Bảo mật hệ thống.
Với nền tảng sư phạm và kinh nghiệm tư vấn cho nhiều doanh nghiệp, thầy chuyên sâu vào việc xây dựng các giải pháp kỹ thuật số toàn diện và hiệu quả.