Khi thiết kế ứng dụng, hãy chọn mặc định là điều mà phần lớn người dùng sẽ chọn nếu họ hiểu rõ các phương án, gây ít hại nhất khi chọn sai cho một người cụ thể, dễ đổi lại, và không làm người dùng mất tiền hay dữ liệu khi chưa đồng ý. Bốn tiêu chí này giải quyết được phần lớn các trường hợp, từ trạng thái bật tắt của một tính năng tới phương án hiện ra đầu tiên trong danh sách.
Vì phần lớn người dùng không đổi mặc định, người làm sản phẩm thực chất đang quyết định thay cho họ. Bài này dành cho người làm ứng dụng, trang web, phần mềm nội bộ: các dạng mặc định có trong một sản phẩm, năm câu hỏi để chọn, các loại mặc định và khi nào dùng, những điểm riêng cần đặt đúng cho người dùng Việt, và cách đo, cách thay đổi mặc định sau khi ra mắt mà không làm người dùng phật ý.
Mặc định nằm ở nhiều chỗ hơn bạn nghĩ
Khi nói tới mặc định, người ta thường nghĩ ngay tới trang cài đặt. Thực tế, mỗi màn hình đều chứa một vài quyết định mặc định, và nhiều cái trong số đó được đặt vội bởi người lập trình chứ không qua thảo luận. Liệt kê ra giúp đội của bạn nhìn thấy những quyết định đang ẩn.
- Giá trị điền sẵn trong biểu mẫu: số lượng, ngày giao, quốc gia, phương thức thanh toán.
- Trạng thái bật tắt của tính năng và thông báo khi người dùng mới cài.
- Thứ tự sắp xếp của danh sách: mới nhất, phổ biến nhất, rẻ nhất hay được đề xuất.
- Phương án đứng đầu trong một nhóm lựa chọn, như gói dịch vụ ở giữa được viền đậm.
- Hành vi khi không thao tác: hết thời gian dùng thử thì làm gì, phiên đăng nhập kéo dài bao lâu, bản nháp có tự lưu không.
- Phạm vi chia sẻ mặc định của nội dung người dùng tạo ra, như bài đăng công khai hay chỉ bạn bè. Phần này liên quan quyền riêng tư nên cần được cân nhắc đặc biệt kỹ.
Một bài tập hữu ích là đi qua toàn bộ luồng chính của sản phẩm với vai người dùng mới, ghi lại mọi chỗ có giá trị được chọn sẵn, rồi hỏi đội: ai đã chọn cái này và vì sao? Những chỗ không ai trả lời được là chỗ cần xem lại đầu tiên.
Năm câu hỏi để chọn một mặc định
Nếu hiểu rõ, phần lớn người dùng sẽ chọn gì? Đây là câu hỏi gốc. Trả lời bằng dữ liệu nếu có, như tỉ lệ người dùng tự đổi sang phương án khác, hoặc bằng phỏng vấn ngắn. Mặc định trùng với lựa chọn của đa số giúp phần đông không phải làm gì.
Nếu chọn sai cho một người cụ thể, hậu quả là gì? Một mặc định sai về cỡ chữ chỉ gây bất tiện. Một mặc định sai về việc tự gia hạn có thể làm người dùng mất tiền. Hậu quả càng nặng, mặc định càng phải nghiêng về phía an toàn, hoặc chuyển sang hỏi trực tiếp.
Đổi lại có dễ không? Mặc định nào cũng sẽ sai với một số người. Điều quan trọng là họ đổi được ngay tại chỗ họ gặp nó, chứ không phải đi qua ba lớp cài đặt.
Ai được lợi khi người dùng giữ mặc định? Nếu câu trả lời là chủ yếu doanh nghiệp, như thêm doanh thu, thêm dữ liệu, thêm thời gian dùng, hãy dừng lại cân nhắc. Không phải là không được, nhưng mặc định đó cần minh bạch và dễ từ chối.
Có giải thích công khai được không? Nếu bạn ngại viết lý do của mặc định ra trong phần hỏi đáp của sản phẩm, đó là tín hiệu mặc định đang đặt người dùng vào thế bất lợi.
Các loại mặc định và khi nào dùng
Các nhà nghiên cứu và người làm thiết kế thường chia mặc định thành vài loại theo cách chọn. Bảng dưới là cách chia thực dụng, đủ để đội sản phẩm có ngôn ngữ chung khi thảo luận.
| Loại | Cách chọn | Ví dụ | Dùng khi |
|---|---|---|---|
| Mặc định chung | một giá trị cho mọi người, theo đa số | khổ giấy A4 trong ứng dụng in | nhu cầu giống nhau, sai cũng ít hại |
| Mặc định bảo vệ | nghiêng về phía an toàn cho người dùng | không tự lưu thẻ, không tự gia hạn | hậu quả khi sai nặng về tiền, dữ liệu |
| Mặc định thông minh | suy ra từ thông tin sẵn có | ngôn ngữ theo máy, tỉnh theo địa chỉ giao trước | có tín hiệu đáng tin về người dùng |
| Mặc định cá nhân hoá | nhớ lựa chọn lần trước của chính người đó | phương thức giao hàng đã dùng lần trước | người dùng quay lại thường xuyên |
| Không mặc định | buộc người dùng tự chọn | chọn có hay không nhận bản tin | lựa chọn quan trọng, ý muốn mỗi người khác nhau |
Mặc định thông minh cần cẩn thận: suy luận sai gây khó chịu hơn một mặc định chung. Ví dụ đặt ngôn ngữ theo vị trí địa lý sẽ sai với người nước ngoài đang ở Việt Nam hoặc người Việt ở nước ngoài; đặt theo ngôn ngữ của thiết bị thường đúng hơn.
Mặc định riêng cho người dùng Việt
Rất nhiều thư viện và mẫu giao diện được làm cho thị trường nói tiếng Anh, nên mặc định của chúng lệch với thói quen ở Việt Nam. Sửa những chỗ dưới đây ngay từ đầu giúp sản phẩm trông tự nhiên và tránh nhầm lẫn tốn kém.
- Ngày tháng theo dạng ngày trước tháng sau, như 05/11/2026, không theo kiểu tháng trước ngày sau. Nhầm chỗ này có thể làm khách đặt lịch sai cả tháng.
- Số dùng dấu chấm ngăn hàng nghìn và dấu phẩy thập phân, tiền đồng không có phần lẻ. Hiện "1.250.000 đ" thay vì "1,250,000.00".
- Múi giờ mặc định GMT+7, và lưu ý máy chủ đặt ở nước ngoài có thể ghi giờ theo múi khác.
- Ô địa chỉ theo đơn vị hành chính mới từ 01/7/2025: 34 tỉnh, thành phố và cấp xã, phường, không còn cấp huyện. Danh sách tỉnh cũ trong biểu mẫu cần được cập nhật.
- Họ tên một ô hoặc hai ô theo thứ tự họ trước tên sau, và không bắt buộc tên đệm. Sắp xếp danh sách theo tên thì cần xử lý đúng thứ tự tiếng Việt có dấu.
- Bàn phím số tự bật cho ô số điện thoại và số tiền trên di động, để người dùng không phải chuyển bàn phím.
Những mặc định này nghe nhỏ nhưng ảnh hưởng hằng ngày tới mọi người dùng. Một lỗi định dạng ngày trong đơn đặt hàng có thể tạo ra hàng loạt cuộc gọi hỏi lại cho bộ phận chăm sóc khách hàng.
Đo và thay đổi mặc định sau khi ra mắt
Một mặc định không phải quyết định một lần. Sau khi ra mắt, bạn có dữ liệu để biết nó đang đúng hay sai với người dùng thật. Quy trình dưới đây giúp thay đổi có căn cứ và không làm người dùng phật ý.
- Đo tỉ lệ người dùng tự đổi khỏi mặc định. Nếu một phần lớn đổi đi, mặc định có lẽ đang sai với đa số.
- Đo tỉ lệ đổi lại sau khi đã giữ một thời gian, cùng số lượng khiếu nại, yêu cầu hoàn tiền liên quan. Đây là tín hiệu mặc định đã khiến người dùng làm điều họ không muốn.
- Khi thử nghiệm A/B một mặc định mới, đừng chỉ đo tỉ lệ chuyển đổi trong ngày. Theo dõi thêm tỉ lệ huỷ, đánh giá xấu và mức quay lại sau vài tuần.
- Khi đổi mặc định cho người dùng hiện có, giữ nguyên lựa chọn của những ai đã tự chọn, chỉ áp dụng cho người đang ở mặc định cũ, và báo rõ đã đổi gì, đổi lại ở đâu.
- Ghi lại quyết định và lý do trong tài liệu của đội, để người đến sau biết mặc định này được chọn có chủ đích.
Có thể nhờ trợ lý AI rà một luồng màn hình bằng câu lệnh mẫu: "Dưới đây là mô tả từng bước của luồng đăng ký trong ứng dụng, kèm các giá trị đang được chọn sẵn. Với mỗi giá trị, đánh giá theo bốn tiêu chí: đa số người dùng có chọn như vậy không, hậu quả khi sai, dễ đổi không, ai được lợi; đề xuất thay đổi nếu cần." Chỉ mô tả giao diện, không dán dữ liệu khách hàng, số liệu kinh doanh hay mã nguồn chưa công bố. Đọc kết quả như ý kiến của một đồng nghiệp, rồi kiểm lại bằng dữ liệu thật của sản phẩm.
Khi mục tiêu kinh doanh và lợi ích người dùng lệch nhau
Có những lúc mặc định có lợi cho người dùng lại làm giảm một chỉ số mà đội đang được giao, như tắt sẵn thông báo khuyến mãi làm giảm lượt quay lại ngắn hạn. Đây là chỗ khó nhất của việc chọn mặc định, và không có công thức chung.
Một cách nhìn hữu ích là phân biệt chỉ số ngắn hạn và giá trị dài hạn. Người dùng bị cuốn vào một gói trả phí qua mặc định có thể làm tăng doanh thu tháng này, nhưng cũng là người dễ huỷ, dễ khiếu nại và dễ kể với người khác. Người dùng tự chọn trả phí vì thấy giá trị thường ở lại lâu hơn.
Khi tranh luận, hãy mang dữ liệu dài hạn vào phòng họp: tỉ lệ huỷ của nhóm người dùng đến qua mặc định so với nhóm tự chọn, số yêu cầu hoàn tiền, điểm đánh giá trên kho ứng dụng. Những con số này thường làm cán cân nghiêng về phía mặc định tử tế hơn so với chỉ nhìn tỉ lệ chuyển đổi của tuần đầu.
Ở cấp đội nhóm, nên đặt ra từ đầu vài ranh giới không đổi: không tự gia hạn khi chưa báo rõ, không tích sẵn khoản trả thêm, không mặc định chia sẻ dữ liệu cho bên thứ ba. Khi có ranh giới chung, các cuộc tranh luận về từng mặc định sẽ ngắn hơn, và người mới vào đội cũng biết đâu là giới hạn.
Câu hỏi thường gặp
Có nên để trống mọi ô để người dùng tự chọn không?
Không nên áp dụng cho mọi ô. Để trống tất cả làm biểu mẫu dài và mệt, người dùng có thể bỏ ngang. Chỉ nên buộc tự chọn ở những lựa chọn quan trọng mà ý muốn mỗi người khác nhau; phần còn lại dùng mặc định hợp lý.
Mặc định thông minh dựa vào dữ liệu người dùng có ổn không?
Ổn khi dữ liệu là thứ người dùng đã cung cấp cho đúng mục đích đó, như địa chỉ giao hàng lần trước. Cần cẩn thận khi suy luận từ dữ liệu nhạy cảm hoặc dữ liệu người dùng không biết mình đã cung cấp; phần quyền riêng tư nên hỏi người phụ trách pháp lý.
Làm sao biết một mặc định đang sai?
Dấu hiệu phổ biến là nhiều người tự đổi khỏi mặc định, nhiều khiếu nại hoặc yêu cầu hoàn tiền liên quan, hoặc người dùng mới hay hỏi bộ phận hỗ trợ về đúng chỗ đó.
Đổi mặc định cho người dùng cũ có cần báo không?
Nên báo, nhất là khi thay đổi ảnh hưởng tới tiền, thông báo hay cách sản phẩm hoạt động. Giữ nguyên lựa chọn của những ai đã tự chọn, và cho biết đổi lại ở đâu. Người dùng thấy bị đổi mà không được báo thường phản ứng mạnh.
Kiểm thử A/B mặc định có vấn đề đạo đức không?
Kiểm thử là cách làm bình thường để tìm phương án tốt hơn. Vấn đề nảy sinh khi chỉ tối ưu một chỉ số như tỉ lệ đăng ký mà bỏ qua việc người dùng có bị thiệt không. Hãy đưa chỉ số huỷ, khiếu nại và hài lòng vào kết quả đánh giá.
Ứng dụng nhỏ, đội ít người có cần quy trình này không?
Không cần làm đầy đủ. Một bảng liệt kê các mặc định chính kèm lý do, xem lại mỗi lần ra bản lớn, đã đủ giúp đội nhỏ tránh phần lớn lỗi. Quan trọng là có người chịu trách nhiệm nhìn vào chúng.