在做心情日記平台的時候，同意流程是我改寫次數最多的一段。不是因為技術困難，它沒有任何技術困難，而是因為我一開始把它當成法務要求，後來才發現它是產品設計問題。
這篇講的是一個看起來很小、但決定整件事是否成立的判準。
這個系統收集什麼
先說清楚範圍，否則後面的討論會失焦：
- 日記內容，也就是使用者寫下的原始文字
- AI 從中分析出的情緒分數與壓力指數
- 選擇性的健康資料：步數、心率、HRV（心率變異性）、睡眠
第一項是關鍵。心情日記是一個人最私密的書寫，而且它跟其他敏感資料有個差別：病歷可以去識別化，日記不行。一個人寫下的生活細節，本身就是識別資訊。
為什麼一個勾選框不夠
最常見的做法是一份使用者條款加一個「我已閱讀並同意」。
條號值得說清楚，因為這三件事常被混在一起講。「同意必須針對特定目的」出自 GDPR 第 4 條第 11 款對同意的定義；「不同的處理行為應該可以分開同意」寫在前言第 43 段；而第 7 條列的是同意要成立必須滿足的條件，其中第 4 項最吃重：判斷同意是否自由給予，要特別看服務的提供是不是被綁在一個並非履約所必需的同意上。台灣個資法第 7 條第 2 項也要求特定目的外利用的同意必須「單獨所為」。這個產品在台灣，但兩套規範的方向一致，取較嚴格的來設計不會有壞處。
一份包山包海的同意書兩件事都不合格。使用者同意了「使用這個服務」，但沒有分別同意「我的日記可以拿去訓練模型」。這兩件事的性質差太多，不該被綁在同一個勾選框裡。
所以我拆成三段：
- 資料如何被使用：收集什麼、怎麼儲存、絕不做什麼
- AI 模型訓練同意，獨立的一題
- 年齡確認，未成年另有流程
真正的判準：拒絕之後會發生什麼
拆成三段其實不難，多數人做到這裡就覺得完成了。
但分離式同意如果拒絕會導致功能受限，那個同意在法律上就不算是自由給予的。使用者面對「不同意就不能用」的選項時，他做的不是同意，是接受條件。
這一條把設計的難度整個換掉了。它的意思是，如果我想要那份訓練資料，我不能用產品體驗當籌碼。
所以第二段的介面明確寫著：選擇「不同意」不會影響你使用任何功能。而且這不是話術，系統裡沒有任何一條路徑會因為這個選項而變窄。
這個決定有實際代價。允許使用者拒絕，等於主動放棄一部分本來可用的訓練資料，而做這個產品的人正好非常需要繁體中文的心理健康語料。這個代價是這個決定的價格，我認為值得付。
未成年的雙重驗證
13 到 17 歲的使用者走一條額外的路：系統寄出確認連結到家長或監護人的信箱，家長點擊之後 AI 功能才解鎖。
這裡有個設計上的選擇值得說明。解鎖的是 AI 功能，不是整個服務。未成年使用者在等待家長確認的期間，仍然可以寫日記、看自己的紀錄。
理由跟上一節同源：把整個產品鎖住，會讓「等家長點連結」變成一道勸退牆，而真正需要保護的是未成年人的日記被送進模型這件事，不是未成年人寫日記這件事。
轉換率的代價
三個步驟取代一次點擊，註冊轉換率一定會掉。這是真的，我沒有量化過掉了多少。
但這個成本的性質跟其他產品成本不同：它是這個產品能不能誠實存在的條件。一個要求使用者交出最私密書寫的系統，如果在同意流程上取巧，那它在其他地方的承諾也不值得相信。
可以帶走的部分
如果只能記一件事：判斷分離式同意是否真的分離，不要看介面有幾個勾選框，要看使用者全部拒絕之後還剩下什麼。
如果拒絕之後產品變得比較難用，那就不是分離式同意，只是把一份同意書切成三頁。
HeartBox 完整案例研究裡有這個決定與另外六個工程取捨的完整過程，包含它們各自放棄了什麼。