Hướng dẫn UX Writing tiếng Việt cho nút bấm, biểu mẫu và thông báo lỗi

Ngày rà soát: 4 tháng 10 năm 2026

Trả lời nhanh

UX Writing tiếng Việt cần giúp khách biết làm gì, cần thông tin nào và kết quả thao tác ra sao. Nút mô tả hành động; nhãn xác định trường; thông báo lỗi nêu vấn đề và bước xử lý thực tế. Giữ giọng điệu nhất quán, đúng trạng thái sản phẩm. Câu thân thiện không thể bù cho việc báo thành công sai hoặc nút xóa mơ hồ.

Điểm cần nhớ

• Viết theo tác vụ trước mắt của khách.
• Giữ nhãn khi khách đang nhập và sửa dữ liệu.
• Phân biệt hướng dẫn, cảnh báo, lỗi và xác nhận.
• Hướng dẫn khắc phục, tránh quy lỗi cho khách.
• Rút ngắn câu nhưng giữ điều kiện quan trọng.
• Rà soát cả nội dung nhìn thấy, nhãn truy cập và thông báo.

Giao diện tiếng Việt nên có giọng điệu nào?

Chọn giọng bình tĩnh, trực tiếp, phù hợp đối tượng và tác vụ. Bảng điều khiển doanh nghiệp thường cần hướng dẫn trung tính. Lời chào khi bắt đầu có thể ấm áp hơn, nhưng khôi phục tài khoản và lỗi thanh toán vẫn cần chính xác. Thống nhất cách dùng “bạn”, tránh đổi thất thường giữa trò chuyện, thông báo trang trọng và câu lệnh.

Ưu tiên từ quen thuộc nếu giữ đúng nghĩa. “Lưu thay đổi” phù hợp khi lưu chỉnh sửa; “Hoàn tất” có thể phù hợp cuối quy trình thiết lập. Hai nhãn không thay thế nhau nếu kết quả khác. Không viết hoa mọi từ tiếng Việt chỉ vì nguồn tiếng Anh dùng kiểu viết hoa tiêu đề.

Ghi mục đích nguồn cạnh chuỗi dịch: màn hình, hành động, kết quả và giới hạn. Người rà soát cần trả lời “Khách mong đợi gì sau khi bấm?” trước khi trau chuốt câu văn. Thông tin ngữ cảnh giúp tránh sửa câu cho hay nhưng vẫn mô tả sai chức năng.

Viết nút bấm thế nào để rõ bước tiếp theo?

Dùng động từ ngắn và đối tượng khi cần. “Gửi yêu cầu” cho biết yêu cầu sẽ được gửi; “Tiếp tục” chỉ cho biết còn một bước. Dùng nhãn chung khi màn hình đã làm rõ bước đó. Với chuyển sang cổng thanh toán, “Tiếp tục đến PayPal” mô tả điều hướng, không khẳng định đã trả tiền.

Bảng sau là ví dụ biên tập theo ngữ cảnh giả định, không phải kết quả thử nghiệm khách hàng.

Không ép mọi nút thành một từ. Nếu nhãn không vừa, xem khoảng cách, xuống dòng và nội dung cạnh nút trước khi bỏ chi tiết có nghĩa. Nhãn ngắn có thể dựa vào tiêu đề gần đó, nhưng mối liên hệ phải rõ trên điện thoại và khi thứ tự đọc thay đổi.

Phân chia nhãn, gợi ý và tooltip thế nào?

Nhãn gọi tên trường; gợi ý giải thích điều kiện hoặc định dạng; tooltip bổ sung thông tin. Tránh lặp lại cả phần giới thiệu biểu mẫu. W3C hướng dẫn nhãn xác định mục đích và được liên kết với trường [1]. Phần nhãn trong mã cũng cần được dịch cùng đợt.

Trong biểu mẫu liên hệ, “Email” có thể là nhãn, “Địa chỉ để nhận phản hồi” là gợi ý. Với mã tham chiếu tùy chọn, ghi “Mã đơn hàng (không bắt buộc)”. Chỉ hỏi thông tin quy trình thực sự cần. Không buộc nhập công ty, mã bưu chính hoặc điện thoại chỉ vì mẫu nguồn có sẵn trường đó.

Nêu giới hạn tệp trước khi tải lên theo quy tắc máy chủ. Làm rõ áp dụng cho từng tệp hay tổng lần gửi, và cách tính MB của sản phẩm. Không ghi “dưới 25 MB mỗi lần gửi” nếu hệ thống kiểm tra khác. Điều kiện cần để hoàn thành không nên bị giấu trong tooltip.

Tách dữ liệu mẫu khỏi giá trị đã nhập. Placeholder biến mất khi gõ nên không phải cách duy nhất nhận diện trường. Dùng mẫu không nhạy cảm và bảo đảm bộ kiểm tra chấp nhận định dạng đã hướng dẫn.

Thông báo lỗi cần có gì?

Lỗi cần nêu vấn đề và bước xử lý hệ thống hỗ trợ. Hướng dẫn thông báo của W3C nhấn mạnh phản hồi rõ, ngắn và cách sửa lỗi [2]. Cũng cần xác định dữ liệu có được giữ, có thể thử lại an toàn và kết quả cuối đã biết hay chưa.

Không viết “Bạn nhập sai” khi nguyên nhân có thể là dịch vụ. Không đưa nguyên lỗi máy chủ như hướng dẫn cho khách. Mã hỗ trợ có thể hữu ích, nhưng phải đi cùng thông báo dễ hiểu. Chỉ báo thành công khi kết quả đã được xác nhận đúng như câu mô tả.

Thời điểm xuất hiện cũng cần rà soát. Cảnh báo lúc khách chưa gõ xong có thể trông như lỗi quá sớm. Xem thông báo còn đúng không, khách sửa được không và có mất phần nhập khác không. Câu văn, điều kiện kích hoạt và cách khắc phục cần cùng một trường hợp kiểm tra.

Trạng thái trống và onboarding hướng dẫn ra sao?

Trạng thái trống cần nói lý do và bước phù hợp. “Bạn chưa có dự án” dùng cho tài khoản mới; “Không có kết quả phù hợp” dùng cho tìm kiếm. Nút tạo dự án giúp trường hợp đầu, có thể không phù hợp trường hợp sau. Hai danh sách đều trống nhưng không nên dùng chung mọi thông báo.

Khi hướng dẫn bắt đầu, giới thiệu từng tác vụ trước mắt. Giải thích lợi ích của thông tin được hỏi và cho phép bỏ qua nếu chức năng hỗ trợ. Đừng báo hoàn tất thiết lập khi còn thiếu quyền, xác minh hoặc kết nối bắt buộc. Nhãn tiến độ phải tương ứng giai đoạn thật.

Thông báo cần bám sự kiện. “Đã có bản dịch để xem xét” dẫn đến việc rà soát nếu có, không đồng nghĩa đã duyệt hoặc bàn giao. Giữ nhất quán email, thông báo trong ứng dụng và tiêu đề màn hình để khách nhận ra cùng sự kiện.

Cảnh báo và xác nhận mô tả hậu quả thế nào?

Nêu thao tác, đối tượng và hậu quả trước khi yêu cầu xác nhận. Hộp xóa vĩnh viễn cần nhiều hơn “Bạn chắc chứ?”. Nếu có khôi phục, mô tả điều kiện thật. Hủy gói cũng cần làm rõ quyền truy cập kết thúc ngay hay cuối kỳ.

Phân biệt hai lựa chọn như “Xóa dự án” và “Hủy”. Không thêm cảnh báo nặng nề cho thao tác điều hướng đơn giản. Chỉ ngắt luồng khi khách cần hiểu một lựa chọn có hậu quả đáng chú ý.

Rà soát nội dung trước phát hành thế nào?

Thử bằng dữ liệu kiểm tra: gửi bình thường, trường sai, thao tác gián đoạn, tìm kiếm trống và xóa. Đọc tiêu đề, nút, gợi ý cùng thông báo sau thao tác như một cuộc trao đổi liên tục. Ghi mâu thuẫn và giao người sửa.

Xem cả tên truy cập trong mã. Hướng dẫn Label in Name của WCAG đề cập việc tên truy cập chứa chữ của nhãn nhìn thấy [3]. Nút tiếng Việt nhưng tên đọc tiếng Anh không liên quan có thể khiến tương tác thiếu nhất quán. Rà soát ngôn ngữ giúp phát hiện, nhưng không thay toàn bộ kiểm thử khả năng tiếp cận.

Lưu danh sách thông báo gồm mã, trạng thái, câu tiếng Việt, biến, điều kiện xuất hiện, kết quả và người phụ trách. Khi hành vi đổi, cập nhật các câu phụ thuộc cùng nhau. Cách này rõ hơn bảng chuỗi rời không có màn hình hoặc ngữ cảnh.

Đề xuất của LocalizeZone

Gửi luồng khách hàng, tệp chuỗi và màn hình khi hỏi dịch vụ bản địa hóa phần mềm. LocalizeZone đề xuất rà soát nút, biểu mẫu và thông báo cùng nhau. Nêu quy tắc kiểm tra, giới hạn tệp và hành vi hủy để báo giá phản ánh phần dịch, thuật ngữ và rà soát theo ngữ cảnh cần thiết.

Câu hỏi thường gặp

Mọi nút phải bắt đầu bằng động từ?

Nút thao tác thường phù hợp; tab hoặc điểm đến có thể dùng danh từ. Chọn theo vai trò điều khiển.

Câu nào cũng cần “vui lòng”?

Không. Giữ giọng nhất quán; lặp từ lịch sự có thể che tác vụ đơn giản.

Tooltip có thể chứa giới hạn tệp bắt buộc?

Có thể thêm chi tiết, nhưng điều kiện chính cần thấy được trước tải lên và khi sửa lỗi.

Mọi lỗi đều nên có “thử lại”?

Không. Chỉ thử lại khi an toàn. Thanh toán chưa rõ kết quả cần kiểm tra trạng thái trước.

Nội dung dịch có bảo đảm tăng chuyển đổi?

Không. Đây là đề xuất biên tập; cần đo luồng khách của sản phẩm trước khi tuyên bố hiệu quả.

Cần gửi gì cùng chuỗi để rà soát?

Màn hình, trạng thái, định nghĩa biến, kết quả mong đợi và giới hạn ảnh hưởng đến câu hoặc cách khắc phục.

Nguồn và phương pháp

Hướng dẫn kết hợp ví dụ tiếng Việt tự soạn với nguồn W3C rà soát ngày 4 tháng 10 năm 2026. Bảng giả định luồng thao tác, không mô tả sản phẩm khách hàng đã thử nghiệm. Cần xác nhận hành vi, đối tượng và bố cục thực tế. Bài không công bố số liệu chuyển đổi, lời chứng thực hoặc chứng nhận khả năng tiếp cận. Nguồn hỗ trợ nguyên tắc cụ thể, không quy định từ vựng tiếng Việt.

Tài liệu tham khảo

[1] W3C Web Accessibility Initiative. Forms Tutorial: Labeling Controls.

[2] W3C Web Accessibility Initiative. Forms Tutorial: User Notifications.

[3] W3C. Understanding WCAG 2.2 Success Criterion 2.5.3: Label in Name.

Bài viết liên quan

• Cẩm nang bản địa hóa tiếng Việt cho phần mềm và SaaS
• 100 thuật ngữ giao diện Anh–Việt thường gặp trong SaaS và ứng dụng
• 50 lỗi bản địa hóa Anh–Việt thường gặp
• Hướng dẫn định dạng ngày giờ, số và tiền tệ trong tiếng Việt
• Định dạng địa chỉ Việt Nam cho biểu mẫu, thương mại điện tử và cơ sở dữ liệu
• Tên người Việt: Hướng dẫn cho biểu mẫu, cơ sở dữ liệu và giao diện