隱私用戶體驗：隱私意識設計框架
已發表: 2022-03-10- 第 1 部分：Web 表單中的隱私問題和隱私
- 第 2 部分：更好的 Cookie 同意體驗
- 第 3 部分：更好的通知 UX 和權限請求
- 第 4 部分：隱私意識設計框架
我們已經探索了更好的 cookie 同意提示、權限請求和通知 UX 的方法，但是當我們在設計工具中做出設計決策時，它們如何適應整體設計策略？
在她的文章“GDPR 對 UX 意味著什麼？”中，英國布里斯托爾 Mubaloo 的 UX 和 UI 設計師 Claire Barrett 分享了一套非常實用、可操作的 UX 指南，該設計機構一直在遵循 GDPR . 雖然這些指南專門針對 GDPR，但它們適用於更廣泛的用戶友好和隱私意識交互，因此可以適用於任何類型的項目：
- 用戶必須主動選擇收集和使用他們的數據。
- 用戶必須同意每種類型的數據處理活動。
- 用戶應有權隨時輕鬆撤回其同意。
- 用戶應該能夠檢查將處理數據的每個組織和所有第三方。
- 同意不等於同意條款和條件，因此不應將它們捆綁在一起； 它們是分開的，應該有不同的形式。
- 雖然在正確的時間徵求同意很好，但最好清楚地解釋為什麼同意會有益於他們的體驗。
Claire 在她的文章中推薦的一件有趣的事情是專注於“即時”數據收集（在本系列的第 3 部分中提到）； 也就是說，解釋為什麼需要數據，以及如何使用和不使用這些數據——但僅限於應用程序或網站真正需要它的時候。 顯然，這可以通過在收集的更多個人信息旁邊包含一個“信息”圖標來完成，並根據要求顯示工具提示以及數據收集背後的好處和理由。
許多移動應用程序需要在安裝過程中訪問位置、照片甚至攝像頭，這不是大多數客戶願意同意的。 獲得許可的一種更有效的方法是通過使用“及時”提示來解釋收集點對數據的需求，這樣用戶只有在理解數據的目的時才能給予同意，就像我們已經做到的那樣在本系列前面的權限中看到。
解釋還應告知客戶如何在適用的情況下撤回同意，並提供隱私政策的鏈接。 這些多年來一直是投訴的問題，因為如果沒有專門的審查會議，幾乎不可能理解用完全晦澀的法律術語編寫的冗長隱私政策。 （事實上，2008 年的一項研究表明，普通人每年大約需要 244 小時才能閱讀他們使用的網站的所有隱私政策，這相當於每天大約 40 分鐘。）
與其將隱私政策呈現為一堵複雜的文本牆，不如將其分塊並分組為清晰標記的部分和可擴展的文本，並針對掃描、定位和理解進行優化。
一旦獲得同意，客戶應該可以完全控制他們的數據； 也就是說，瀏覽、更改和刪除我們的應用程序保存的任何數據的能力。 這意味著我們的移動應用程序中的數據設置需要提供精細的選項來撤銷同意，選擇退出營銷偏好，以及下載和刪除任何數據的選項，而無需在錯綜複雜的幫助部分和模棱兩可的設置面板中徘徊。
隱私意識設計決策的主要問題是很難評估數據收集的影響以及它對設計和開髮帶來的所有界面挑戰。 謙虛和微妙不僅僅是尊重的問題，也是減少技術債務和避免未來法律糾紛的問題。 為此，以下一般準則也可能有所幫助。
盡可能少地保存數據
如果您選擇存儲信用卡數據，則必須提前了解您為保密存儲而採取的安全措施。 您需要和存儲的數據越少，潛在違規的影響就越小。
善待個人資料
並非所有數據都是平等的。 當用戶提供個人信息時，區分不同層次的數據，因為私人信息可能比公共信息更敏感。 善待個人數據，絕不默認發布。 例如，當用戶完成他們的個人資料時，提供一個選項以在發布之前查看所有輸入。 謙虛，總是先徵求許可； 主動保護用戶，不存儲敏感數據。 這可能有助於防止出現不舒服的情況。
這不僅適用於在您的服務器上存儲和發布用戶數據的過程，還適用於密碼恢復或將客戶數據用於任何類型的附屬夥伴關係的過程。 事實上，在沒有明確同意的情況下將客戶的電子郵件交給其他人是違反信任和隱私的行為，並且通常會導致電子郵件被標記為垃圾郵件，因為客戶突然面臨一個他們不信任的陌生品牌。 事實上，後者幾乎就像是一種防禦機制，可以抵禦貪婪的網站，這些網站不斷收集電子郵件以換取免費的禮物、視頻的訪問權和免費增值產品。
儘早解釋第三方將收到什麼樣的用戶數據
在提供社交登錄選項時，請具體說明用戶數據會發生什麼以及第三方將擁有哪些權限。 通常在提示社交登錄時會出現一個微妙的註釋，但最好直接明確說明如何處理數據，特別是用戶數據不會發生什麼。
一旦客戶被迫將他們的全新帳戶與現有帳戶連接起來，或者當他們被鼓勵使用他們的社交資料來使用應用程序取得進展時，通常會看到用戶交互停止。 這絕不是一個簡單的步驟，並且需要一些解釋和保證撤銷訪問權限很容易。
準備要導出的客戶數據
全面了解收集的數據並非易事，尤其是在涉及第三方的情況下。 確保無論何時收集個人數據，其結構都經過優化，便於日後導出和刪除。 如果最終用戶也可以消化它，則可以加分，因此一旦他們對非常具體的事物感興趣，他們就可以找到所需的點點滴滴。 這也意味著跟踪收集了哪些類型的數據以及數據流向何處，因為我們稍後可以使用此結構在我們的 UI 中提供對數據設置和隱私偏好的精細控制。
您可能聽說過一些友好的公司，它們可以非常無縫地導入個人數據，但導出用戶數據卻非常困難，或者幾乎是不可能的。 不出所料，這種做法並沒有得到客戶的好評。 尤其是在他們考慮刪除賬戶的時候，這種普遍的鎖定會導致客戶支持投訴、呼叫中心電話以及社交渠道中的憤怒爆發。 這不是一個能讓他們長期保持忠誠的令人愉快的功能。
雖然有些公司因為規模太大而可以公開指責，但對於許多中小型公司來說，聲譽是他們擁有的最寶貴的資產，所以不要拿它來賭博是明智的。 您甚至可以考慮與類似的服務合作，讓用戶數據無縫地移植和傳輸到每個服務，同時期望合作夥伴也支持相同的功能。
從長遠來看，難以關閉或刪除帳戶會失敗
企業龐然大物擅長讓客戶關閉或刪除他們的賬戶變得異常困難。 當搬家非常困難時，這種技術很有效——亞馬遜和 Facebook 就是這種情況。
但是，如果您在一個相對較小的網站上努力爭取其忠實客戶，那麼您可能無法成功實現它，至少不能長期實現。 如果您很難取消定期付款，那麼整體影響甚至會更加有害，就像訂閱經常發生的情況一樣。 （事實上，這就是訂閱也難以出售的原因——這不僅僅是每月付款的承諾，而是由於提前取消而難以在以後取消訂閱而無需支付額外費用。）
事實上，正如設計師在隱藏臭名昭著的個人資料設置以刪除帳戶方面做得越來越好一樣，客戶也在尋找在迷宮中導航的方法，這通常得到博客中易於發現的教程的無限智慧的支持。 如果不是這樣，客戶會求助於他們認為最有效的工具：拒絕不尊重他們意圖的服務——通常是通過將電子郵件標記為垃圾郵件、阻止通知和減少使用該服務。 它不會在一夜之間發生。 但慢慢地，如採訪所示，這些客戶保證不會向他們的朋友或同事推薦這項服務。
令人驚訝的是，當關閉帳戶非常容易時，情況恰恰相反。 就像通知一樣，用戶選擇繼續前進可能有充分的理由，而且通常與服務質量無關。 試圖說服客戶留下來，詳細概述您提供的所有美妙好處，可能會達到錯誤的目標：尤其是在公司環境中，已經做出決定，因此關閉帳戶的人實際上可以'在改變方向方面做的不多。
對於 Smashing Membership，我們努力讓聲音保持尊重和謙遜，同時在離職時也表現出一些我們的個性。 我們解釋數據會發生什麼以及何時將其不可撤銷地刪除（7 天），提供恢復計劃的選項，允許客戶導出他們的訂單並保證不與第三方共享數據。 令人驚訝的是，許多取消會員訂閱的人最終將其推薦給他們的朋友和同事，因為即使他們自己不使用它，他們也覺得它對他們有一些價值。
推遲導入聯繫人，直到用戶對服務感到滿意
當然，如果不整合用戶的社交圈，我們的許多應用程序並不是特別有用，因此要求客戶邀請他們的朋友不要在早期感到孤獨或被遺棄似乎是合理的。 但是，在這樣做之前，請考慮鼓勵客戶使用該服務一段時間的方法，並將導入聯繫人推遲到用戶更傾向於這樣做的時候。 默認情況下，許多客戶會阻止早期請求，因為他們尚未對該應用程序建立信任。
在帳戶關閉後在有限的時間內保存用戶數據
錯誤發生了，對於意外的錯誤點擊，以及在非常糟糕的一天后刪除所有個人數據都是如此。 因此，雖然我們需要提供下載和刪除數據的選項，但也要提供在短時間內恢復帳戶的選項。 這意味著數據將在帳戶被刪除後保存，但在寬限期過後將被不可撤銷地刪除。 通常，7-14 天就足夠了。
但是，您也可以為用戶提供一個選項，以通過電子郵件請求請求立即刪除數據，甚至單擊按鈕。 是否應該告知用戶他們的文件最終會被刪除？ 可能是。 最終決定可能取決於數據的敏感程度：它越敏感，用戶就越有可能想知道數據已經永遠消失了。 匿名數據是個例外：大多數時候，客戶根本不會關心它。
提供用戶友好的隱私政策變更摘要
沒有什麼是一成不變的，因此您的隱私政策和默認隱私設置可能需要調整，因為新的個性化功能或跟踪腳本的更改。 每當發生這種情況時，與其在冗長的文本段落中強調隱私的重要性，不如提供清晰、用戶友好的更改摘要。 你可以通過強調過去的情況和現在的不同來構建摘要。 不要忘記將法律術語翻譯成更易於閱讀的內容，解釋更改對用戶的實際意義。
坦率地說，大多數用戶似乎並不關心隱私政策的變化。 在 2018 年源源不斷的政策更新通知之後，默認反應通常是立即同意。 一旦他們注意到主題行或電子郵件正文中與隱私政策相關的任何內容，他們就會立即接受更改，甚至在滾動到電子郵件底部之前。 然而，存儲的數據越私人，審查更改所花費的時間就越多，而這些更改通常非常令人困惑和不清楚。
注意：如果您正在尋找有關如何與您的用戶和訂閱者分享隱私政策更改的更多靈感，Really Good Emails 的人們已經收集了一些與 GDPR 相關的電子郵件設計的絕佳示例。
制定溝通策略以防出現違規行為
在用戶數據被洩露後，沒有人想要破壞。 在這種情況下，制定清晰而有力的溝通策略至關重要。 準備好解釋，以防某些用戶數據被洩露。 Mandy Brown 在A List Apart 上發表了一篇精彩的文章“消防演習：危機中的溝通策略”，解釋瞭如何進行設置，以及在進行設置時需要考慮的一些事項。
隱私設計
聽起來訪問網站是一項很普通的活動，用戶應該對社交登錄、導入聯繫人和 cookie 提示等功能感到舒適和熟悉。 正如我們在本系列中所見，有許多重要的隱私注意事項，而且通常情況下，客戶對共享他們的個人數據有顧慮、疑慮和擔憂。
當然，這個系列的範圍可能會更進一步，我們甚至還沒有研究過密碼恢復、應用內隱私設置設計、浮動聊天窗口和彈出窗口、性能和可訪問性考慮，或者設計隱私體驗最脆弱的用戶——兒童、老年人和弱勢群體。 但是，圍繞隱私做出設計決策時的關鍵點始終相同：我們需要在嚴格的業務要求和尊重設計之間找到平衡，以幫助用戶控制和跟踪數據，而不是收集我們可以收集的所有信息和將客戶鎖定在我們的服務中。
找到這種平衡的一個很好的路線圖是採用隱私優先的最佳實踐框架，稱為隱私設計 (PbD)。 早在 1990 年代就出現在加拿大，它是關於在編寫一行代碼之前預測、管理和防止隱私問題。 隨著歐盟數據保護政策的到位，設計隱私和數據保護已成為所有用途和應用程序的默認設置。 這意味著可以應用它的許多原則來確保您的網站或應用程序符合 GDPR 和更好的隱私用戶體驗。
從本質上講，該框架期望隱私是一種默認設置，並且是一種主動（而非被動）措施，將在設計的初始階段和整個產品生命週期中嵌入到設計中。 它鼓勵為用戶提供細粒度的隱私選項、尊重的隱私默認設置、詳細的隱私信息通知、用戶友好的選項和明確的更改通知。 因此，它適用於我們在本系列中概述的指南。
我強烈建議閱讀 Heather Burns 的一篇文章“如何使用隱私設計框架保護您的用戶”，其中她提供了在數字服務中實施隱私設計框架的詳細指南。
那從哪裡開始呢？ 大變革從小步驟開始。 在設計階段的初始研究和構思中包括隱私，並決定默認值、隱私設置和敏感接觸點，從填寫 Web 表單到入職和離職。 盡可能減少收集的數據量，並跟踪第三方可能收集的數據。 如果您可以匿名化個人數據，那也是一個好處。
每次用戶提交他們的個人信息時，都要跟踪問題是如何構建的以及數據是如何收集的。 當您幾乎可以肯定客戶會接受時，及時顯示通知和許可請求。 最後，以易於理解的摘要形式通知用戶隱私政策的變化，並讓導出和刪除數據或關閉帳戶變得容易。
最重要的是：下次你想添加一個複選框或提供二元選項時，想想我們生活的美麗的模糊和非二元世界。通常有兩個以上的可用選項，所以總是提供一個出路，無論選擇多麼明顯。 您的客戶會欣賞它。