Người dùng đang đồng ý hay chỉ đang tìm cách đi tiếp?

Khi sử dụng một dịch vụ trực tuyến, người dùng thường chỉ mất vài giây để đi qua bước xác nhận điều khoản. Họ nhập thông tin, đánh dấu vài tùy chọn, bấm “Tiếp tục”. Hệ thống ghi nhận thao tác, một bước trong phễu chuyển đổi (funnel) được đánh dấu là hoàn tất và người dùng được chuyển sang màn hình kế tiếp. Trên bảng số liệu (dashboard), đó là một lượt chuyển đổi thành công.

Nhìn từ bên ngoài, sự đồng thuận dường như đã được hình thành tại thời điểm nút bấm được nhấn xuống. Nhưng với người làm sản phẩm, cú nhấp chuột ấy là điểm cuối của một chuỗi lựa chọn do chính chúng ta thiết kế: thông tin nào được hiển thị, thông tin nào nằm sau một liên kết, nội dung nào được làm nổi bật, nút nào lớn hơn, người dùng có thể từ chối hay không, và điều gì xảy ra nếu họ không đồng ý.

Vì vậy, câu hỏi không dừng ở việc hệ thống có ghi nhận thao tác đồng ý hay không. Câu hỏi thật sự là: khi nhấn nút, người dùng biết mình đang đưa ra một lựa chọn, hay chỉ đang tìm cách làm xong việc trước mắt?

Bài viết này xoay quanh một câu hỏi: làm sao thiết kế màn hình “Đồng ý” để người dùng vẫn đi tiếp nhanh, nhưng biết rõ mình vừa chọn giải quyết tranh chấp bằng trọng tài?

Luận điểm của tôi: cú nhấp “Đồng ý” chỉ có ý nghĩa khi giao diện giúp người dùng biết mình đang chọn điều gì. Vì vậy, đồng thuận là bài toán thiết kế, không chỉ là bài toán câu chữ.

Một lưu ý về phạm vi: tôi là PM, không phải luật sư. Tôi không bàn về hiệu lực pháp lý của thỏa thuận trọng tài; đó là việc của chuyên gia pháp lý. Tôi bàn về phần thuộc về sản phẩm: cách chúng ta tạo nên khoảnh khắc người dùng bấm “Đồng ý”.

Người dùng đến với sản phẩm để hoàn thành một công việc, không phải để đọc điều khoản

Phần lớn người dùng không mở một ứng dụng vì muốn đọc điều khoản sử dụng. Họ muốn mua một sản phẩm, đặt một dịch vụ, tạo tài khoản, gửi tin nhắn, thanh toán hoặc tiếp tục công việc đang dang dở.

Tâm trí của họ hướng về kết quả cần đạt được. Mỗi màn hình trên đường đi đều được nhìn qua một câu hỏi rất đơn giản: “Tôi cần làm gì để đi tiếp?” Nếu cả giao diện dồn sự chú ý vào nút “Đăng ký”, “Thanh toán” hoặc “Tiếp tục”, phần điều khoản rất dễ trở thành một bước thủ tục. Đây là hành vi “nhấp để tiếp tục” (click-through): một phản xạ quen tay hơn là một quyết định.

Phần lớn trường hợp, điều này không xuất phát từ ý định che giấu thông tin, mà là hệ quả của cách sản phẩm được xây dựng. Đội Kinh doanh muốn giảm tỷ lệ người dùng rời bỏ quy trình (drop-off). Đội Thiết kế muốn giao diện gọn. Đội Kỹ thuật muốn giới hạn số bước và các tình huống ngoại lệ (edge case). Pháp chế cần đưa những nội dung bắt buộc vào luồng thao tác. PM phải kết nối tất cả những yêu cầu ấy thành một trải nghiệm chạy được.

Ví dụ giả định: một ứng dụng giao đồ ăn. Nút “Tạo tài khoản” màu cam, rộng hết chiều ngang; ngay dưới là dòng chữ xám cỡ 11px: “Bằng việc tiếp tục, bạn đồng ý với Điều khoản sử dụng”. Liên kết này mở ra tài liệu 30 trang, và điều khoản trọng tài nằm ở mục 17. Trên bảng số liệu, tỷ lệ hoàn tất đăng ký rất đẹp. Nhưng nếu hỏi mười người vừa đăng ký “nếu có tranh chấp, bạn nghĩ sẽ giải quyết ở đâu?”, có bao nhiêu người biết đến trọng tài?

Khi “giảm ma sát” trở thành mục tiêu mặc định

Trong phát triển sản phẩm, “ma sát” (friction) thường được dùng để chỉ những yếu tố khiến người dùng mất thêm thời gian, phải suy nghĩ nhiều hơn hoặc có nguy cơ rời khỏi quy trình.

Giảm ma sát là mục tiêu hợp lý. Tuy nhiên, không phải mọi khoảng dừng đều vô ích.

Có những thời điểm người dùng cần được chậm lại vừa đủ để thấy quyết định sắp đưa ra là quan trọng: xác nhận một khoản thanh toán, xóa dữ liệu, cấp quyền truy cập thông tin cá nhân, hay chọn cách giải quyết tranh chấp. Ở những điểm này, tôi coi ma sát là một khoản ngân sách cần chi có chủ đích, không phải chi phí cần cắt về không. Tỷ lệ hoàn tất cao không chứng minh rằng người dùng đã hiểu. Đôi khi, nó chỉ cho thấy giao diện đã khiến việc đi tiếp dễ đến mức không ai còn dừng lại để cân nhắc.

Điều khoản trọng tài rất dễ bị chìm trong một bộ điều khoản dài

Cách liên hệ hỗ trợ, quy tắc sử dụng dịch vụ, chính sách bảo mật, giới hạn trách nhiệm và cơ chế giải quyết tranh chấp thường nằm chung trong một tài liệu dài, trong đó điều khoản trọng tài hay nằm ở nửa sau, sau hàng chục mục khác. Nếu cả tài liệu chỉ hiện ra dưới dạng một đường dẫn duy nhất, người dùng khó biết mục nào ảnh hưởng trực tiếp đến quyền của mình.

Trong cả bộ điều khoản, đây là mục tôi không để bị chìm, vì nó quyết định tranh chấp được giải quyết ở đâu và bằng cách nào nếu quan hệ giữa các bên không diễn ra như mong đợi.

Việc của đội sản phẩm là biến yêu cầu pháp lý thành một trải nghiệm mà người dùng thực sự thấy và hiểu. Vì vậy, vấn đề không nằm ở việc điều khoản có xuất hiện trên giao diện hay không, mà là cách xuất hiện ấy có cho người dùng biết mình đang đồng ý giải quyết tranh chấp bằng trọng tài hay không.

Tiếp cận được thông tin chưa có nghĩa là hiểu thông tin

Một liên kết màu xám nhạt ở cuối màn hình vẫn là một liên kết. Một đoạn chữ nhỏ bên dưới nút xác nhận vẫn là nội dung được hiển thị. Một bộ điều khoản dài hàng chục trang vẫn có thể được mở nếu người dùng chủ động tìm kiếm. Xét theo đặc tả (spec), cả ba đều “đạt”, nhưng tiếp cận được chưa phải là hiểu được.

Khi review một màn hình xác nhận, tôi không dừng ở câu hỏi “thông tin có mặt chưa”; tôi soi thêm các điểm sau:

• • Người dùng có nhận ra liên kết hay không (cỡ chữ, độ tương phản, nhất là trên điện thoại)?
  • Tên của liên kết có cho biết bên trong chứa nội dung gì không? Nhãn “Điều khoản sử dụng” thì không; nhãn có nhắc đến trọng tài thì có.
  • Điều khoản trọng tài có bị hòa lẫn vào nhiều nội dung khác không?
  • Người dùng có thể đọc trước khi thực hiện thao tác xác nhận không? Liên kết nằm trước hay sau nút, có phải cuộn mới thấy không?
  • Nút xác nhận có “nuốt” hết sự chú ý không? Nếu chỉ nút này có màu, còn “Xem chi tiết” là chữ xám, thứ tự chú ý đã được quyết định thay người dùng.

Kích thước chữ, màu sắc, khoảng cách, cách đặt tiêu đề, vị trí của đường dẫn và tương quan giữa nút chấp thuận với lựa chọn khác đều gửi đi một thông điệp. Giao diện có thể nói rằng “đây là thông tin bạn nên cân nhắc”, nhưng cũng có thể ngầm nói rằng “đây chỉ là phần chữ bắt buộc, hãy nhấn nút để tiếp tục”. Đó là kiến trúc lựa chọn (choice architecture), và nó tạo nên sự đồng thuận không kém gì câu chữ.

Làm nổi bật không có nghĩa là làm phức tạp

Khi tôi đề xuất làm rõ một điều khoản quan trọng, phản ứng thường gặp trong đội là lo quy trình sẽ dài hơn, khó dùng hơn và làm giảm tỷ lệ hoàn tất.

Lo ngại này có cơ sở: nếu mọi điều khoản đều có màn hình và ô xác nhận riêng, quy trình sẽ nặng nề mà chưa chắc giúp người dùng hiểu hơn. Một giao diện đầy cảnh báo cũng khiến người dùng bỏ qua mọi cảnh báo (hiện tượng “nhờn cảnh báo”, hay alert fatigue).

Quan điểm của tôi: điều khoản giải quyết tranh chấp nên được làm nổi bật; còn có tách thành một bước riêng hay không thì tùy mức rủi ro (khung ba mức ở phần sau). Làm nổi bật không có nghĩa là thêm chữ hay thêm bước, mà là tổ chức thông tin theo mức độ cần thiết. Cách tôi hay dùng là thiết kế theo lớp (progressive disclosure, hay layered notice): người dùng thấy thông tin cốt lõi trước, cần thì đi sâu hơn. Phần tóm tắt không thay thế văn bản đầy đủ, nhưng giúp văn bản đầy đủ không còn là một liên kết trơ trọi, thiếu ngữ cảnh.

Ngôn ngữ pháp lý: đơn giản hóa đến đâu?

Đây là chỗ PM và pháp chế dễ có mâu thuẫn nhất: PM muốn viết như nói chuyện, pháp chế muốn giữ từng chữ. Tôi đề xuất ba nguyên tắc:

• • Đơn giản hóa lớp giải thích, không chạm vào phần ràng buộc. Văn bản đầy đủ vẫn là văn bản có giá trị; phần tóm tắt chỉ trả lời “điều này nghĩa là gì với tôi?”.
  • Tóm tắt phải đúng trước khi dễ đọc. Nếu rút gọn làm mất một nội dung cốt lõi (nơi giải quyết, cách thức giải quyết, ảnh hưởng đến quyền khởi kiện), thà dài thêm một câu. Pháp chế sở hữu từng chữ, PM sở hữu cấu trúc và vị trí hiển thị; mọi thay đổi câu chữ trên giao diện (microcopy) đều cần cả hai bên cùng duyệt.
  • Test bằng người thật. Hỏi 5–8 người dùng đúng đối tượng: “Nếu có tranh chấp, bạn nghĩ sẽ giải quyết ở đâu?”. Họ trả lời sai thì lỗi nằm ở đoạn văn, không phải ở người đọc.

Ví dụ minh họa (giả định, cần pháp chế thẩm định trước khi dùng):

Thời điểm hiển thị quan trọng không kém nội dung

Nếu thông tin chỉ xuất hiện sau khi người dùng đã nhập toàn bộ dữ liệu, lựa chọn sản phẩm và chuẩn bị thanh toán, họ có thể cảm thấy mình không còn một lựa chọn thực tế nào ngoài việc nhấn “Đồng ý”.

Ngược lại, nếu nội dung được đặt quá sớm, trước khi người dùng hiểu dịch vụ là gì, họ cũng khó đánh giá ý nghĩa của lựa chọn.

Nguyên tắc tôi dùng: thông tin cần xuất hiện đủ sớm để người dùng có cơ hội cân nhắc, nhưng cũng phải đủ gần với hành động chấp thuận để họ hiểu mối liên hệ giữa thông tin và quyết định của mình.

Một ô đánh dấu riêng không phải lúc nào cũng là câu trả lời

Ô đánh dấu riêng thường được xem là giải pháp rõ ràng nhất vì người dùng phải chủ động tick trước khi đi tiếp. Nhưng bản thân nó không bảo đảm rằng người dùng nhận biết được nội dung. Nếu nhãn của ô xác nhận quá dài, khó hiểu hoặc gộp nhiều vấn đề khác nhau, người dùng vẫn có thể đánh dấu theo thói quen.

Vì vậy, đừng đánh giá chất lượng đồng thuận chỉ bằng số nút bấm hay ô xác nhận. Hãy nhìn cả hành trình: người dùng được báo điều gì, ở đâu, vào lúc nào; có đường lui không; hệ thống lưu lại gì.

Vậy nên tách đến mức nào? Tôi thường cân nhắc ba mức, tăng dần theo rủi ro (khung tham khảo cá nhân, không phải chuẩn pháp lý):

Chọn mức nào còn tùy bối cảnh: người dùng là cá nhân hay doanh nghiệp, giá trị giao dịch, thỏa thuận xác lập một lần hay áp dụng lặp lại, sản phẩm chạy ở một hay nhiều thị trường. Không có giao diện hoàn hảo cho mọi tình huống. Cái cần cân bằng không phải là “pháp lý hay trải nghiệm”, mà là dồn ma sát vào đúng chỗ có trọng lượng và giữ mọi chỗ khác thật trơn tru.

Thiết kế thúc ép làm suy yếu chính doanh nghiệp

Sản phẩm số có nhiều cách để hướng người dùng đến một lựa chọn. Đây là chức năng tự nhiên của thiết kế: giúp người dùng thấy bước tiếp theo và hoàn thành công việc thuận lợi hơn. Ranh giới nằm ở chỗ giao diện thôi hướng dẫn và bắt đầu thúc ép hoặc gây hiểu nhầm.

Một nút chấp thuận có màu sắc nổi bật trong khi lựa chọn từ chối gần như không nhìn thấy; ô đồng ý được tick sẵn; một thông báo tạo cảm giác khẩn cấp không cần thiết; một quy trình khiến người dùng rất dễ đồng ý nhưng rất khó thay đổi lựa chọn — những cách thiết kế như vậy (thường gọi là thiết kế thao túng, hay dark pattern) có thể cải thiện một chỉ số ngắn hạn nhưng làm giảm niềm tin dài hạn.

Với thỏa thuận trọng tài, thiết kế thúc ép còn tự tạo ra mâu thuẫn. Doanh nghiệp muốn có bằng chứng cho thấy người dùng đã đồng ý, nhưng chính giao diện lại khiến người ta đặt câu hỏi: sự đồng ý đó có được đưa ra một cách có nhận thức, hay chỉ là kết quả của một lựa chọn đã được sắp đặt?

Một cơ chế đồng thuận đáng tin cậy không thể xây trên mục tiêu khiến người dùng nhấn “Đồng ý” bằng mọi giá. Nó phải cho thấy doanh nghiệp đã nỗ lực truyền đạt trung thực nội dung của lựa chọn. Một phép thử tôi hay dùng: nếu phải chiếu màn hình này trước một bên thứ ba và giải thích từng quyết định thiết kế, ta có thấy thoải mái không?

Đồng thuận không phải công việc riêng của pháp chế

Trong nhiều tổ chức, pháp chế soạn điều khoản sử dụng rồi chuyển cho đội sản phẩm để đưa lên hệ thống. Nếu phối hợp chỉ dừng ở đó, khoảng trống gần như chắc chắn sẽ xuất hiện.

PM không quyết định điều khoản nào có hiệu lực. Việc của PM là giúp các bộ phận cùng trả lời một nhóm câu hỏi thực tế:

• • Nội dung nào người dùng cần biết trước khi tiếp tục?
  • Thời điểm nào phù hợp để hiển thị?
  • Có thể diễn đạt ngắn gọn đến đâu mà không làm sai lệch ý nghĩa?
  • Cần một xác nhận chung hay một thao tác riêng?
  • Doanh nghiệp sẽ chứng minh hành trình đó ra sao nếu có tranh chấp?

Nếu những câu hỏi này chỉ được đặt ra sau khi giao diện đã hoàn thiện, gần như chắc chắn điều khoản pháp lý sẽ bị gắn vào sản phẩm như một bản vá (patch). Ngược lại, nếu được đưa vào tài liệu yêu cầu sản phẩm (PRD) ngay từ đầu, sự đồng thuận sẽ trở thành một phần tự nhiên của kiến trúc sản phẩm.

Những gì hệ thống lưu lại phản ánh những gì doanh nghiệp đã nghĩ tới

Một bản ghi chỉ cho biết tài khoản đã nhấn nút vào thời điểm nào là chưa đủ để tái hiện bối cảnh. Doanh nghiệp còn cần biết phiên bản giao diện nào đã được sử dụng, nội dung điều khoản nào được liên kết, người dùng thực hiện thao tác trong trạng thái nào và điều khoản đã thay đổi ra sao theo thời gian. Nói cách khác, nhật ký đồng thuận (consent log) không thể chỉ là một dấu thời gian. Lưu gì và lưu bao lâu cần chốt cùng pháp chế và bộ phận bảo vệ dữ liệu.

Nếu sản phẩm không được thiết kế để quản lý phiên bản điều khoản, nhật ký thao tác và lịch sử thay đổi, doanh nghiệp có thể biết rằng người dùng “đã từng đồng ý” nhưng không xác định được chính xác họ đã đồng ý với nội dung nào. Khi điều khoản thay đổi, cũng cần quyết định trước nhóm người dùng nào phải được thông báo hoặc xác nhận lại.

Đừng chỉ đo xem người dùng có hoàn tất hay không

Tỷ lệ hoàn tất, thời gian thực hiện hay số người rời bỏ ở từng bước đều cần thiết, nhưng nếu chỉ đo tốc độ và tỷ lệ chuyển đổi, đội ngũ sẽ có xu hướng tối ưu sản phẩm theo một hướng duy nhất: giúp người dùng đi qua quy trình càng nhanh càng tốt.

Với những lựa chọn quan trọng, tôi thêm vài chỉ số bảo vệ (guardrail metric):

• • Người dùng có nhận ra rằng điều khoản giải quyết tranh chấp tồn tại không?
  • Họ có thể tìm lại điều khoản sau khi đăng ký không?
  • Nội dung tóm tắt có dễ hiểu không?

Cách đo đơn giản nhất là một câu hỏi khảo sát ngắn ngay sau khi đăng ký, hoặc một buổi kiểm tra mức hiểu với 5–8 người dùng. Khi chạy A/B test cho màn hình này, tôi muốn thấy mức nhận biết và tỷ lệ hoàn tất trong cùng một bảng kết quả, với ngưỡng sụt giảm chấp nhận được do các bên thống nhất từ trước.

Không phải câu hỏi nào cũng đo được chính xác. Nhưng đặt ra chúng giúp đội ngũ không nhầm một cú nhấp chuột thành công với một quyết định có chất lượng.

Đôi khi, thêm vài giây vào hành trình lại giúp doanh nghiệp xây dựng một mối quan hệ minh bạch hơn với người dùng.

Một cú nhấp chuột là kết quả của cả một hệ thống

Khi tranh chấp phát sinh, sự chú ý thường tập trung vào thao tác cuối cùng: người dùng có nhấn nút hay không.

Nhưng dưới góc nhìn phát triển sản phẩm, cú nhấp chuột đó không tồn tại độc lập. Nó là kết quả của một hệ thống gồm nội dung, giao diện, luồng thao tác, dữ liệu, quy tắc vận hành và những quyết định được nhiều bộ phận đưa ra từ trước.

Nếu hệ thống giúp người dùng nhận ra mình đang đứng trước một lựa chọn, tiếp cận được thông tin cần thiết và hiểu hành động nào tạo ra sự chấp thuận, thì cú nhấp chuột khi đó có ý nghĩa hơn một sự kiện kỹ thuật.

Bởi sau cùng, một sản phẩm tốt không chỉ giúp người dùng đi tiếp. Nó còn giúp họ biết mình đang đi tiếp với điều gì.

______

Giới thiệu tác giả

Tuan Nguyen là chuyên gia quản lý sản phẩm với hơn 10 năm kinh nghiệm trong lĩnh vực phát triển phần mềm, từng đảm nhiệm các vị trí quản lý sản phẩm tại Sea Group (Shopee, SeaTalk). Ông bắt đầu sự nghiệp với vai trò kỹ sư phần mềm, sau đó trải qua các vị trí tư vấn kỹ thuật, quản lý dự án và quản lý sản phẩm. Kinh nghiệm của ông tập trung vào các ứng dụng, nền tảng web, sản phẩm giao tiếp số và thương mại điện tử.

Bài viết thể hiện quan điểm chuyên môn cá nhân của tác giả, không nhất thiết phản ánh quan điểm chính thức của các tổ chức mà tác giả đã hoặc đang làm việc, hoặc của VTA.

Điều khoản trọng tài mẫu (Model Arbitration Clause) của VTA: “Mọi tranh chấp phát sinh từ hoặc liên quan đến hợp đồng này sẽ được giải quyết bằng trọng tài tại Trung tâm Trọng tài Thương nhân Việt Nam (VTA) theo Quy tắc tố tụng trọng tài của Trung tâm này”. “Any dispute arising out of or in relation with this contract shall be resolved by arbitration at the Vietnam Traders Arbitration Centre (VTA) in accordance with its Rules of Arbitration”.

Trung tâm Trọng tài Thương nhân Việt Nam (VTA) là cơ quan tổ chức, điều phối hoạt động giải quyết tranh chấp trong kinh doanh bằng trọng tài quy chế, với thẩm quyền giải quyết các tranh chấp: (i) Tranh chấp giữa các bên phát sinh từ hoạt động thương mại; (ii) tranh chấp giữa các bên trong đó có ít nhất một bên có hoạt động thương mại; (iii) tranh chấp giữa các bên mà pháp luật quy định giải quyết bằng Trọng tài.