Mở đầu — vì sao bài này quan trọng
Có một sự thật hơi phũ phàng mà mọi UX writer cần chấp nhận: hầu như không ai muốn vào màn hình Settings cả. Người dùng tìm đến Cài đặt chỉ khi họ đang bực bội (muốn tắt thông báo đang làm phiền), lo lắng (muốn kiểm tra ai nhìn thấy dữ liệu của mình), hoặc bối rối (không biết đổi mật khẩu ở đâu). Nói cách khác, Settings là nơi người dùng đến với một mục tiêu rất cụ thể và một sự kiên nhẫn rất thấp.
Đây chính là lý do phần copy trong Settings khó hơn nhiều so với cảm nhận ban đầu. Ở màn hình onboarding hay success state, bạn có thể "dẫn dắt" cảm xúc người dùng. Nhưng ở Settings, người dùng không cần bạn truyền cảm hứng — họ cần tìm đúng thứ, hiểu đúng nghĩa, và bấm đúng nút mà không sợ làm hỏng gì. Một dòng label mơ hồ như "Đồng bộ nâng cao" hay một toggle không rõ bật là bật cái gì có thể khiến người dùng hoặc bỏ cuộc, hoặc tệ hơn, vô tình tắt mất thứ quan trọng rồi quay lại đổ lỗi cho sản phẩm.
Bài này tập trung riêng vào một khía cạnh mà các bài khác trong khóa không chạm tới: cách tổ chức và viết copy cho màn hình Settings/Preferences — tức là chuyện gom nhóm thế nào, đặt cái gì lên trên, viết label và mô tả cho từng tùy chọn ra sao, và làm sao để người dùng tìm được thứ họ cần. Đây không phải bài về error message hay form nói chung; đây là bài về kiến trúc nội dung và microcopy của chính khu vực Cài đặt.
Khái niệm cốt lõi
Settings là bài toán tổ chức trước, bài toán câu chữ sau
Điểm khác biệt lớn nhất của Settings so với các màn hình khác: giá trị của nó nằm ở cấu trúc nhiều hơn ở từ ngữ. Một câu label hoàn hảo mà nằm sai nhóm thì vẫn vô dụng, vì người dùng sẽ không bao giờ scroll tới đó. Vì vậy công việc của UX writer ở đây bắt đầu bằng câu hỏi: "Người dùng đang nghĩ về tùy chọn này bằng từ nào, và họ kỳ vọng tìm thấy nó ở đâu?"
Nguyên tắc gom nhóm phổ biến và đáng tin cậy nhất là chia theo danh mục theo mô hình tư duy của người dùng (mental model), không phải theo cấu trúc kỹ thuật của hệ thống. Bốn nhóm kinh điển mà gần như sản phẩm nào cũng cần:
- Tài khoản (Account): thông tin cá nhân, email, số điện thoại, mật khẩu, đăng xuất, xóa tài khoản.
- Thông báo (Notifications): push, email, SMS, in-app — bật/tắt theo loại sự kiện.
- Quyền riêng tư & Bảo mật (Privacy & Security): ai nhìn thấy gì, quyền truy cập, xác thực 2 lớp, phiên đăng nhập.
- Hiển thị (Display / Appearance): giao diện sáng/tối, ngôn ngữ, cỡ chữ, đơn vị đo.
Đặt cái hay dùng lên trên
Nhóm được rồi thì đến thứ tự. Nguyên tắc vàng: most-used at top — thứ được truy cập nhiều nhất phải nằm trên cùng. Bạn không thể đoán cái này bằng cảm tính; hãy nhìn vào dữ liệu (analytics ghi lại người dùng bấm vào mục nào nhiều nhất). Với đa số sản phẩm, "Thông báo" và "Tài khoản" luôn nằm top, còn những mục kỹ thuật như "Nhà phát triển" hay "Thử nghiệm" thì đẩy xuống đáy.
Trong từng nhóm cũng vậy: tùy chọn phổ biến hoặc dễ hiểu để trên, tùy chọn nguy hiểm hoặc hiếm dùng (như "Xóa tài khoản") để dưới cùng và tách biệt rõ ràng.
Label phải cụ thể và trung lập
Ba tiêu chí cho một label Settings tốt:
- Cụ thể: người dùng đọc xong biết ngay nó điều khiển cái gì. "Cho phép ứng dụng gửi thông báo khuyến mãi" tốt hơn "Thông báo tiếp thị".
- Trung lập về trạng thái: label không nên thay đổi theo trạng thái bật/tắt. Dùng danh từ/cụm mô tả cố định ("Xác thực 2 lớp") thay vì động từ ("Bật xác thực 2 lớp") — vì khi đã bật rồi, chữ "Bật" gây bối rối.
- Đi kèm mô tả khi cần: với tùy chọn có hậu quả không hiển nhiên, thêm một dòng helper text ngắn giải thích điều gì xảy ra khi bật/tắt.
Tìm kiếm trong Settings — không phải tính năng phụ
Khi số lượng mục cài đặt vượt quá khoảng 20–30, con người không còn quét được nữa. Đó là lúc search trong Settings trở thành cứu cánh. Ô tìm kiếm cần placeholder gợi ý ("Tìm cài đặt…"), và quan trọng hơn: mỗi mục nên gắn thêm từ khóa ẩn (synonyms) để người dùng gõ "chế độ tối" vẫn ra "Giao diện tối", gõ "đổi pass" vẫn ra "Đổi mật khẩu". UX writer chính là người liệt kê bộ từ đồng nghĩa này.
Tình huống thực tế
Ví dụ 1 — MoMo và cuộc "dọn nhà" màn hình Cài đặt
Giả định một đội sản phẩm tại ví điện tử MoMo phát hiện qua support ticket rằng rất nhiều người dùng không tìm được nơi bật xác thực vân tay, dù tính năng đã có. Lý do: nó bị chôn trong mục tên "Cấu hình bảo mật nâng cao", nằm giữa hàng chục dòng kỹ thuật.
Đội quyết định tái tổ chức. Họ gộp mọi thứ liên quan đăng nhập vào nhóm "Bảo mật", đổi label "Cấu hình xác thực sinh trắc học" thành "Đăng nhập bằng vân tay / khuôn mặt", thêm mô tả "Dùng vân tay hoặc Face ID thay cho mã PIN khi mở ứng dụng." Họ cũng đẩy mục này lên đầu nhóm Bảo mật vì analytics cho thấy đây là thứ người dùng mò tìm nhiều nhất.
Kết quả giả định: tỷ lệ bật sinh trắc học trong 30 ngày tăng đáng kể, và ticket dạng "làm sao bật vân tay" giảm rõ rệt. Bài học: người dùng không tìm bằng từ kỹ thuật của bạn ("sinh trắc học"), họ tìm bằng từ đời thường ("vân tay"). Label phải nói ngôn ngữ của họ.
Ví dụ 2 — Grab và cái toggle "Chia sẻ vị trí" gây hoảng
Bối cảnh giả định tại Grab: màn hình quyền riêng tư có một toggle ghi vỏn vẹn "Chia sẻ vị trí". Nhiều người dùng tắt nó đi vì sợ bị theo dõi, rồi bối rối khi app không đặt xe được. Câu label đúng nhưng thiếu ngữ cảnh về hậu quả.
Đội content sửa lại thành hai lớp thông tin: tiêu đề "Vị trí khi sử dụng ứng dụng", mô tả bên dưới "Grab cần vị trí để tìm tài xế gần bạn và ước tính giá cước. Khi tắt, bạn sẽ phải nhập điểm đón thủ công." Đồng thời họ tách riêng một dòng khác cho "Chia sẻ vị trí khi không dùng app" — đây mới là thứ liên quan quyền riêng tư mà người dùng thực sự lo.
Kết quả: người dùng phân biệt được hai loại chia sẻ vị trí, tắt đúng cái họ muốn tắt, và tỷ lệ than phiền "app tự nhiên không đặt xe được" giảm. Bài học: với các tùy chọn nhạy cảm hoặc có hậu quả, mô tả phải trả lời câu "nếu tôi tắt cái này thì sao?" ngay tại chỗ.
Ví dụ 3 — Notion và search cứu vãn màn hình Settings khổng lồ
Notion là ví dụ về sản phẩm có hàng trăm tùy chọn. Nếu chỉ gom nhóm, người dùng vẫn lạc. Cách họ xử lý: mọi mục cài đặt đều searchable, và ô tìm kiếm khớp cả từ khóa lẫn synonym. Gõ "dark" ra ngay "Appearance", gõ "export" ra các tùy chọn xuất dữ liệu ở nhiều nơi khác nhau.
Với người dùng Việt trong một sản phẩm nội địa tương tự, điều này có nghĩa: bạn phải chuẩn bị bộ từ khóa song ngữ và cả tiếng lóng ("chế độ ban đêm", "nền đen", "dark mode" cùng trỏ về một mục). Bài học: khi Settings quá lớn để tổ chức gọn, search với synonym là lối thoát — và chất lượng search phụ thuộc trực tiếp vào việc UX writer có chịu khó liệt kê từ đồng nghĩa hay không.
Hướng dẫn từng bước
Bước 1 — Kiểm kê toàn bộ tùy chọn. Liệt kê mọi setting hiện có ra một bảng: tên hiện tại, nó điều khiển gì, tần suất người dùng đụng tới (lấy từ analytics nếu có). Đây là nguyên liệu thô.
Bước 2 — Nhóm theo mental model. Dùng kỹ thuật card sorting: đưa danh sách cho 5–8 người dùng thật, nhờ họ tự gom nhóm và đặt tên nhóm. Bạn sẽ ngạc nhiên vì cách họ nhóm thường khác cách kỹ sư nhóm. Ưu tiên bốn nhóm nền tảng: Tài khoản, Thông báo, Quyền riêng tư & Bảo mật, Hiển thị.
Bước 3 — Sắp thứ tự theo tần suất. Trong mỗi nhóm, xếp mục hay dùng lên trên. Đẩy các mục nguy hiểm (xóa tài khoản, reset) xuống đáy và tách khối riêng.
Bước 4 — Viết label cụ thể, trung lập. Mỗi label trả lời được "cái này điều khiển gì" chỉ trong 2–5 từ. Tránh động từ trạng thái. Dùng danh từ mô tả.
Bước 5 — Thêm helper text cho mục có hậu quả. Với bất kỳ toggle nào mà tắt/bật gây thay đổi người dùng khó đoán, thêm một dòng mô tả trả lời "chuyện gì xảy ra khi tôi đổi cái này?".
Bước 6 — Thiết kế search và gắn synonym. Nếu có trên ~20 mục, thêm ô tìm kiếm. Với mỗi mục, viết ra 2–4 từ khóa đồng nghĩa (kể cả tiếng Anh và tiếng lóng người Việt hay dùng).
Bước 7 — Kiểm tra bằng nhiệm vụ. Đưa người dùng thật 5 nhiệm vụ ("tắt email khuyến mãi", "đổi sang giao diện tối"…) và đo họ mất bao lâu, có tìm đúng không. Đây là thước đo cuối cùng.
Lỗi thường gặp & mẹo
Lỗi 1 — Nhóm theo kiến trúc kỹ thuật. Gom setting theo module code ("Cấu hình API", "Đồng bộ dịch vụ") thay vì theo cách người dùng nghĩ. Người dùng không quan tâm hệ thống bạn chia thế nào.
Lỗi 2 — Label đổi theo trạng thái. Dùng "Bật thông báo" làm label một toggle. Khi toggle đã ở trạng thái ON, người dùng đọc "Bật thông báo" và không biết đây là mô tả hay là nút cần bấm. Hãy dùng "Thông báo" cố định, để chính cái toggle thể hiện trạng thái.
Lỗi 3 — Toggle mơ hồ về chiều nghĩa. "Ẩn trạng thái hoạt động" — bật lên là ẩn hay là hiện? Toggle phủ định luôn gây nhầm. Viết theo chiều khẳng định: "Hiển thị khi bạn đang online".
Lỗi 4 — Không giải thích hậu quả của mục nhạy cảm. Đặc biệt trong nhóm Quyền riêng tư và Xóa tài khoản. Luôn nói rõ điều gì sẽ mất, có khôi phục được không.
Lỗi 5 — Bỏ quên search hoặc làm search vô dụng. Có ô tìm kiếm nhưng chỉ khớp đúng chữ trong label. Người dùng gõ "đổi pass" không ra "Đổi mật khẩu" — thất bại.
Mẹo: Với mỗi toggle, tự đọc to câu hỏi "Nếu tôi là người dùng lần đầu, tôi có đoán được bật cái này thì chuyện gì xảy ra không?" Nếu do dự, cần thêm helper text. Và luôn dùng nhãn nhóm bằng danh từ ngắn, quen thuộc — "Thông báo" chứ không "Quản lý tùy chọn thông báo".
Bài tập thực hành
Chọn một app bạn đang dùng hằng ngày (ngân hàng, ví điện tử, mạng xã hội) và làm audit màn hình Settings của nó:
- Kiểm kê: Chụp lại toàn bộ màn hình Cài đặt, liệt kê mọi mục ra một bảng.
- Chấm nhóm: Đánh giá cách họ gom nhóm. Có theo mental model không? Có mục nào bạn phải mò mãi mới thấy? Viết lại cấu trúc nhóm mà bạn cho là tốt hơn, dựa trên bốn nhóm nền tảng.
- Viết lại label: Chọn 5 label mà bạn thấy mơ hồ hoặc đổi theo trạng thái. Viết lại theo nguyên tắc cụ thể + trung lập, và thêm helper text cho những mục có hậu quả.
- Thiết kế synonym: Với 5 mục quan trọng nhất, viết ra bộ 3–4 từ khóa tìm kiếm đồng nghĩa (gồm cả tiếng Anh và tiếng lóng người Việt hay gõ).
- Test nhanh: Nhờ một người thân thực hiện 3 nhiệm vụ ("tắt thông báo khuyến mãi", "đổi mật khẩu", "chuyển giao diện tối") trên bản gốc, quan sát chỗ họ vấp. Ghi lại và đối chiếu với bản bạn viết lại.
Tóm tắt
Settings là nơi người dùng đến với mục tiêu cụ thể và kiên nhẫn thấp, nên copy ở đây phục vụ tìm kiếm và hiểu đúng, không phải truyền cảm hứng. Ba trụ cột cần nhớ: tổ chức trước (gom theo mental model của người dùng — Tài khoản, Thông báo, Quyền riêng tư & Bảo mật, Hiển thị — và đặt cái hay dùng lên trên), label cụ thể và trung lập về trạng thái (kèm helper text giải thích hậu quả cho mục nhạy cảm), và search với synonym khi số lượng tùy chọn lớn. Ba ví dụ MoMo, Grab, Notion cho thấy cùng một bài học lặp lại: hãy nói ngôn ngữ đời thường của người dùng, trả lời sẵn câu "nếu tôi đổi cái này thì sao", và đừng bao giờ để người dùng lạc trong chính màn hình Cài đặt của mình.