Cập nhật lần cuối:
Thiết kế số ký tự cho điều khoản sử dụng và chính sách bảo mật - Cân bằng yêu cầu pháp lý và khả năng đọc
Điều khoản sử dụng và chính sách bảo mật là các văn bản hợp đồng pháp lý giữa nhà cung cấp dịch vụ và người dùng. Tuy nhiên, số ký tự của chúng tiếp tục phình to qua từng năm, và không ít điều khoản của các dịch vụ lớn đã dài đến mức chỉ riêng việc đọc hết toàn văn cũng mất hàng chục phút. Thiết kế văn bản đảm bảo tính toàn diện pháp lý trong khi giữ số ký tự ở mức người dùng thực sự có thể đọc là thách thức đòi hỏi sự phối hợp giữa bộ phận pháp lý và UX. Bài viết này trình bày các phương pháp thực tiễn cho thiết kế số ký tự dựa trên yêu cầu pháp lý trong và ngoài nước.
Điều khoản sử dụng của các dịch vụ lớn - Độ dài phụ thuộc vào cách gộp tài liệu
Đặt cạnh nhau điều khoản sử dụng của các nền tảng lớn, độ dài trải rộng từ vài nghìn đến vài chục nghìn ký tự. Tuy nhiên, thứ tạo ra khoảng cách đó không phải quy mô công ty hay ngành nghề, mà là một quyết định biên tập: các điều kiện được chia thành bao nhiêu tài liệu riêng biệt. Điều khoản còn được phát hành lại sau mỗi lần sửa đổi, nên việc so sánh số ký tự của công ty khác như một con số sẽ khiến bạn làm việc trên tiền đề sụp đổ chỉ sau vài tháng. Điều đáng tham khảo cho thiết kế của chính mình không phải con số, mà là lựa chọn giữa hai cấu trúc sau.
- Kiểu tách rời: Giữ ngắn phần điều khoản gốc áp dụng cho mọi dịch vụ, rồi tách các điều kiện riêng của từng dịch vụ thành tài liệu "điều khoản bổ sung". Điều khoản dịch vụ của Google theo kiểu này, nên chỉ đọc phần chung đã nắm được khung tổng thể, và người dùng chỉ cần theo phần bổ sung của những dịch vụ họ thực sự dùng
- Kiểu gộp chung: Tập hợp điều kiện của nhiều dịch vụ vào một tài liệu duy nhất. Điều khoản dịch vụ media của Apple theo kiểu này, bao trùm App Store, Apple Music và các dịch vụ khác trong cùng một văn bản, khiến tài liệu đó trở nên dài. Không cần tra cứu ở nơi khác, nhưng người đọc được mặc định sẽ bỏ qua những phần không liên quan đến mình
Kiểu tách rời kìm được số ký tự của từng tài liệu, nhưng lại làm phức tạp các tham chiếu chéo giữa các tài liệu và sinh ra một vấn đề khả năng đọc khác: không ai biết một quy định cụ thể được viết ở đâu. Nếu chỉ xét số ký tự thì kiểu tách rời luôn trông đẹp hơn, song tổng khối lượng mà người dùng cuối cùng phải đọc vẫn không đổi. Điều này dễ bị lẫn với phương pháp phân lớp trình bày ở phần sau: phân lớp chia cùng một nội dung theo mức độ chi tiết, còn tách điều khoản bổ sung là chia chính nội dung theo dịch vụ mà nó điều chỉnh.
Để biết điều khoản của chính bạn có nằm trong độ dài đọc được hay không, hãy đo số ký tự của toàn văn đã công bố và quy đổi thành thời gian đọc theo tốc độ đọc của đối tượng dự kiến. Bắt đầu từ số đo của chính mình sẽ nhanh hành động hơn là đi tìm con số công ty khác công bố.
Tại sao điều khoản sử dụng ngày càng dài - Nguyên nhân cấu trúc
- Tránh rủi ro pháp lý: Luật sư hoạt động theo nguyên tắc "điều không được viết ra thì không được đồng ý", cố gắng bao quát mọi kịch bản rủi ro
- Quy định phức tạp hóa: Số lượng quy định cần tuân thủ ngày càng tăng - GDPR, Luật bảo vệ thông tin cá nhân, Luật viễn thông, v.v.
- Đa chức năng hóa dịch vụ: Một nền tảng cung cấp thanh toán, nhắn tin, phân phối nội dung, quảng cáo, mỗi chức năng cần điều kiện sử dụng riêng
- Ứng phó kiện tụng: "Sửa đổi kiểu vá lỗi" lặp đi lặp lại, thêm các điều khoản giải quyết tranh chấp trước đó
- Mở rộng quốc tế: Hỗ trợ nhiều khu vực pháp lý (Nhật Bản, EU, Mỹ, v.v.) đòi hỏi thêm điều khoản riêng cho từng khu vực
Phương pháp phân lớp - Giải pháp thực tiễn cho vấn đề số ký tự
Phương pháp phân lớp (Layered Approach) chia văn bản pháp lý thành nhiều tầng, cung cấp thông tin theo từng bước dựa trên mức độ quan tâm của người dùng. Không có điều khoản nào của GDPR quy định số lớp hay độ dài từng lớp. Tuy nhiên, theo nguyên tắc minh bạch, Recital 58 yêu cầu thông tin gửi tới công chúng hoặc chủ thể dữ liệu phải "ngắn gọn, dễ tiếp cận và dễ hiểu", dùng "ngôn ngữ rõ ràng và đơn giản, và khi thích hợp thì bổ sung hình ảnh trực quan". Chia tài liệu thành nhiều lớp đã trở thành kỹ thuật thực tiễn tiêu chuẩn để đồng thời thỏa mãn yêu cầu đó và tính toàn diện về pháp lý.
| Lớp | Tên | Số ký tự khuyến nghị | Nội dung | Cách hiển thị |
|---|---|---|---|---|
| Lớp 1 | Tóm tắt | 500-1.000 ký tự | Tóm tắt dễ hiểu các điều khoản quan trọng nhất | Hiển thị trực tiếp trên màn hình đồng ý |
| Lớp 2 | Tổng quan | 2.000-5.000 ký tự | Điểm chính của từng mục dạng danh sách | UI accordion mở rộng |
| Lớp 3 | Toàn văn | 10.000-30.000 ký tự | Điều khoản đầy đủ về mặt pháp lý | Liên kết đến trang riêng |
Tóm tắt Lớp 1 không phải tài liệu có hiệu lực pháp lý mà là tài liệu hỗ trợ giúp người dùng hiểu. Thêm ghi chú "Bản tóm tắt này chỉ mang tính tham khảo; chỉ toàn văn mới có hiệu lực pháp lý" giúp giảm rủi ro pháp lý đồng thời cải thiện khả năng đọc.
Phương pháp này về bản chất giống cấu trúc trong thiết kế số ký tự email doanh nghiệp - "truyền tải điểm chính trong tiêu đề, bổ sung chi tiết trong nội dung".
Yêu cầu liên quan đến số ký tự của GDPR
| Điều khoản GDPR | Yêu cầu | Ảnh hưởng đến số ký tự |
|---|---|---|
| Điều 12(1) | Cung cấp thông tin ngắn gọn, minh bạch, dễ hiểu và dễ tiếp cận | Cần tránh ngôn ngữ pháp lý dài dòng, viết bằng từ ngữ đơn giản |
| Điều 12(1) | Sử dụng ngôn ngữ rõ ràng và đơn giản, đặc biệt cho thông tin dành cho trẻ em | Cần giảm thiểu thuật ngữ chuyên môn và thêm giải thích |
| Điều 13 | Công bố danh tính bên kiểm soát, mục đích xử lý, cơ sở pháp lý, thời gian lưu trữ, quyền chủ thể dữ liệu | Nhiều mục cần công bố, đòi hỏi số ký tự nhất định |
| Điều 14 | Cung cấp thông tin về dữ liệu cá nhân không thu thập trực tiếp từ chủ thể | Cần giải thích thêm khi có thu thập dữ liệu từ bên thứ ba |
Yêu cầu "ngắn gọn dễ hiểu" và "công bố tất cả thông tin cần thiết" của GDPR vốn mâu thuẫn. Cố thỏa mãn cả hai trong một tài liệu duy nhất thì chọn sự ngắn gọn sẽ để lại lỗ hổng trong công bố, còn chọn tính toàn diện sẽ tạo ra độ dài không ai đọc. Thiết kế phân lớp bám rễ được trong thực tiễn vì nó giải quyết mâu thuẫn này ở phía cấu trúc tài liệu. Đặt bản tóm tắt ngắn gọn ở Lớp 1 và toàn văn đầy đủ về pháp lý ở Lớp 3 thì không phải bỏ yêu cầu nào.
Mẫu cấu trúc chính sách bảo mật
| Mục | Số ký tự khuyến nghị | Nội dung | Ưu tiên |
|---|---|---|---|
| Giới thiệu | 200-400 ký tự | Mục đích chính sách, phạm vi, ngày cập nhật cuối | Bắt buộc |
| Thông tin thu thập | 500-1.000 ký tự | Loại dữ liệu thu thập, phương pháp thu thập | Bắt buộc |
| Mục đích sử dụng | 300-800 ký tự | Mục đích cụ thể cho từng loại dữ liệu | Bắt buộc |
| Chia sẻ bên thứ ba | 300-600 ký tự | Đối tượng nhận, dữ liệu chia sẻ, cơ sở pháp lý | Bắt buộc |
| Lưu trữ và xóa dữ liệu | 200-400 ký tự | Thời gian lưu trữ, tiêu chí và phương pháp xóa | Bắt buộc |
| Quyền người dùng | 300-600 ký tự | Cách yêu cầu công bố, sửa đổi, xóa, ngừng sử dụng | Bắt buộc |
| Cookie và theo dõi | 300-600 ký tự | Công nghệ sử dụng, phương pháp từ chối | Bắt buộc cho dịch vụ web |
| Biện pháp bảo mật | 200-400 ký tự | Biện pháp bảo vệ dữ liệu kỹ thuật và tổ chức | Bắt buộc |
| Thay đổi chính sách | 100-200 ký tự | Phương thức thông báo thay đổi, ngày có hiệu lực | Bắt buộc |
| Liên hệ | 100-200 ký tự | Thông tin liên hệ người phụ trách bảo vệ dữ liệu | Bắt buộc |
Theo mẫu này, tổng số ký tự chính sách bảo mật khoảng 2.600-5.500 ký tự. So với độ dài tối ưu bài blog, đây là khoảng bằng một bài blog thông thường. Ở phạm vi này, việc người dùng đọc toàn bộ là khả thi.
Thiết kế UI điều khoản sử dụng và số ký tự
- Hộp văn bản cuộn: Hộp văn bản nhỏ nhúng trong màn hình đồng ý, buộc phải cuộn. Khung nhìn hẹp nên mỗi màn hình chứa được rất ít, việc theo hết toàn văn cần hàng chục lần cuộn. Đây là dạng tốn công đọc nhất, và khi nút đồng ý có thể bấm ngay từ đầu thì gần như không được đọc
- UI Accordion: Các mục có thể thu gọn/mở rộng theo ý người dùng. Vì danh sách tiêu đề hiện ra trước, người dùng mở được đúng mục mình quan tâm. Mặt trái là một mục đang thu gọn được đọc như "thứ không cần đọc", nên các điều khoản quan trọng để đóng sẵn sẽ được đồng ý mà không ai mở ra
- Dạng từng bước: Chia điều khoản thành nhiều bước, mỗi bước hiển thị 1-2 mục. Giữ mỗi màn hình trong 500-1.000 ký tự sẽ tạo ra đơn vị mà người đọc có thể đọc xong, nhưng số người bỏ giữa đường tăng lên khi số bước nhiều, nên số lần chia và khối lượng mỗi màn hình đánh đổi với nhau
- Đánh dấu + liên kết toàn văn: Đánh dấu các điều khoản quan trọng (mục đích sử dụng dữ liệu, chia sẻ bên thứ ba, điều kiện hủy), toàn văn truy cập qua liên kết. Cách này thu hẹp phạm vi muốn người đọc đọc, nhưng việc chọn đánh dấu gì lại thuộc quyền của chính nhà cung cấp, và bỏ sót các điều khoản bất lợi sẽ làm hỏng tính minh bạch
Dù dùng cách nào, nếu nút đồng ý có thể bấm ngay từ đầu thì mọi thiết kế văn bản đều không hiện ra trong kết quả. An toàn hơn là coi các cải tiến UI chỉ đi xa đến mức giảm gánh nặng cho những người dùng vốn đã có lý do để đọc.
Đo lường tỷ lệ đọc hết
| Chỉ số | Phương pháp đo | Tiêu chuẩn |
|---|---|---|
| Thời gian trên trang | Công cụ phân tích | Đọc như tỷ lệ so với thời gian ước tính cần để đọc hết toàn văn, không phải số giây thô |
| Độ sâu cuộn | Theo dõi sự kiện cuộn | Tỷ lệ người dùng tới được vùng gần cuối (đặt ngưỡng theo cách văn bản được cấu trúc) |
| Tỷ lệ mở accordion | Theo dõi sự kiện nhấp | So sánh tỷ lệ mở để xác định mục quan tâm cao |
| Thời gian đến đồng ý | Thời gian nhấp nút đồng ý - thời gian tải trang | Dưới 3 giây gợi ý "đồng ý mà không đọc" |
Nếu đại đa số người dùng đồng ý trong dưới 3 giây, điều đó có nghĩa điều khoản thực tế không được đọc. Giải pháp cốt lõi không chỉ là giảm số ký tự mà là chuyển đổi cấu trúc thành dạng người dùng "muốn đọc".