如何讓使用者選擇 AI 何時以及多常與他們聯絡
使用者應該有權決定 AI 是否與他們聯絡、可以傳送哪些類型的訊息，以及這些訊息何時送達。一個實用的設計始於明確的加入選擇（opt-in），讓使用者設定時間表與頻率，將本質不同的訊息類型分開，並讓暫停和關閉控制項易於尋找。它還應說明所選的時區以及可能影響訊息送達的因素。這些控制項作出了明確的承諾；產品的排程與傳送系統必須能夠兌現該承諾。
從明確、非強制性的加入選擇開始
在使用者能夠理解自己同意了什麼時請求權限。用淺顯易懂的語言描述聯絡類型：例如使用者要求的提醒或定期更新。說明訊息將在何處送達以及傳送的頻率。避免僅使用未經說明的作業系統權限提示作為唯一說明；使用者在做出決定前需要知道應用程式想要傳送什麼。
美國 Web 設計系統（U.S. Web Design System）建議僅針對服務確實支援的管道收集聯絡偏好，並表示在可能的情況下應說明聯絡的條件與預期時程。套用到 AI 產品上，這意味著僅顯示真實的傳送選項，並說明每個選項的用途。請勿將通知偏好設定作為使用其他不相關功能的條件。USWDS: Contact preferences
將加入選擇視為使用者可以隨時重新決定的選項。Apple 的通知指南建議針對通知類型提供明確的加入（opt-in）或退出（opt-out）機制，以及在應用程式內管理通知設定的方法。產品可以遵循該原則，提供一個彙總目前選擇的設定頁面，而不是讓使用者必須在不相關的裝置設定中到處搜尋才能了解應用程式本身的排程。Apple: Managing notifications
讓排程具體明確
讓使用者選擇適合其日常作息的時段，例如工作日的下午 6 點到 8 點之間，或在選定日期的重複時間。一併顯示日期以及開始與結束時間。如果該控制項設定的是「聯絡時段」，請說明訊息是在該時段內的任何時間送達，還是在特定時間送達。若在指定日期沒有符合條件的訊息，請說明系統會跳過該天還是順延傳送該訊息。
實用的設計可以提供一些容易理解的預設選項，例如「每週一次」或「工作日」，同時在產品支援的情況下允許自訂排程。預設選項應對應到明確可見的排程，而非含糊的標籤。例如，「每週」應顯示所選的日期和時間，而「每週最多三次」應說明三次是上限還是目標。這是一項設計建議：平台文件支援排程傳送，但產品團隊必須自行決定並說明自己的傳送規則。
對時區保持精確。用特定地點名稱或裝置當前的本地時區來標記排程，並告訴使用者排程在他們旅行時是會隨之調整，還是固定在原本的時區。當夏令時間規則或政府時區規則變更時，單純的 UTC 偏移量可能會造成誤導。IANA 的時區資料庫記錄了各地區的規則，並透過更新來反映政治實體所做的變更，包括偏移量和夏令時間規則的變更。IANA: Time Zone Database
一個良好的確認訊息範例可能是：「您目前當地時間的每週二晚上 7:00。此排程將跟隨您裝置的時區。」只有在實作方式確實會追蹤使用者目前時區的情況下，該措辭才算準確。如果排程固定在所選時區，請改為指明該地點名稱。當使用者旅行或裝置時區變更時，顯示實際生效的排程並提供查看與檢視的方式。
分開訊息類型與管道
使用者可能想要某種類型的聯絡，而不需要另一種。讓可選的提醒、產品更新與其他不同類別保持獨立可選，而不是將它們打包成單一的「AI 通知」開關。請勿虛構沒有對應產品行為的類別，也不要將某個類別作為傳送使用者未選擇訊息的藉口。
這種劃分也符合平台的控制機制。Android 在現代版本中要求將通知分配給各個管道（channels），且使用者可以變更管道行為；Android 的指南建議使用能讓人自訂所接收通知的管道。應用程式可以用人們熟悉的術語為管道命名，例如「排程提醒」，並描述各管道包含的內容。Android Developers: Create and manage notification channels
保持管道清單簡潔明瞭，以便於理解。一個管道應代表使用者可能希望獨立做出的有意義選擇。產品本身的設定仍應說明內容與排程：作業系統層級的管道控制項可以改變通知是否顯示或如何顯示，但它們無法解釋應用程式的傳送政策，也不能取代產品內部的排程。
讓暫停、繼續與關閉控制項觸手可及
提供暫時暫停與永久關閉的開關。暫停功能應明確標示其持續時間——例如直到指定日期或直到使用者恢復——並顯示排程訊息是被跳過還是保留。關閉控制項應說明其影響的類別或管道，並立即確認變更後的狀態。繼續接收通知時，不應在未顯示後續處理方式的情況下靜默恢復先前的排程。
讓這些控制項可在通知設定畫面中取得，並在可行的情況下，透過通知操作按鈕或直接設定連結提供。Android 支援在通知中提供動作，並為使用者提供系統層級的方式來管理未來的通知；其控制項因裝置與 Android 版本而異。因此，應用程式內的途徑對於顯示完整排程及變更產品層級的偏好設定依然非常有用。Android Developers: Notifications
裝置層級的控制項仍然至關重要。使用者可以在作業系統層級關閉應用程式的通知或變更管道行為，這與應用程式本身的排程各自獨立。介面不應暗示應用程式內的設定可以覆蓋這些選擇。如果系統通知已被停用，請在使用者進入設定時清楚顯示狀態，並避免反覆提示他們重新啟用通知。
設定系統能夠強制執行的頻率上限
為使用者提供直接的頻率選擇：例如每天最多一則訊息、每週上限，或由使用者自行選擇天數。定義計算週期以及何謂一則訊息。如果有多個類別可以傳送訊息，請釐清該上限是按個別類別計算，還是套用於整個產品。按個別類別計算的上限仍可能累積產生龐大的總量，因此實用的設計通常也會包含一個整體上限。
只有在每個向外傳送的路徑都遵守上限時，上限才會發揮作用。根據相同的偏好狀態，檢查排程提醒、重試、延遲訊息以及由不同功能發起的訊息。如果某一則訊息被延遲，請決定它是會過期、在允許的時段內稍後送達，還是直接捨棄；並向使用者說明對其有影響的行為。除非使用者明確選擇該行為，否則請避免在裝置重新連線後一次傳送多則遺漏的訊息。
平台傳送並不等同於產品的發送決定。Firebase Cloud Messaging 指出，訊息通常會立即傳送，但裝置可能無法連線或傳送可能會延遲；該服務可以在其設定的生命週期內儲存訊息並在稍後嘗試傳送。這意味著產品不應承諾每則通知都會在準確的分鐘送達。它可以承諾在指定的時段內排程傳送，同時說明裝置與平台狀況可能會影響通知顯示的時間。Firebase: Set the lifespan of a message
這種區別也會影響頻率。如果通知已進入佇列且延遲送達，系統應檢查使用者在此期間是否已暫停或關閉該類別，以及傳送該訊息是否會超出目前的上限。誠實可信的設計會在使用者的最新選擇使過期的佇列訊息不再符合條件時，取消或隱藏這些訊息。
設計時可遵循的簡單決策順序
使用以下順序將各項設定轉化為使用者能夠理解的承諾：
列出產品實際能夠傳送的訊息類型，並使每個可選類別易於理解。
要求使用者主動選擇同意接收每個想要的類別與傳送管道。請勿預先勾選非必要的聯絡選項。
讓使用者選擇星期、時間或時段，以及最高頻率。註明該上限是整體上限還是按類別計算。
顯示時區，並說明當使用者的裝置時區變更時，排程是否會隨之調整。
使暫停、繼續和關閉控制項清晰可見，然後顯示目前狀態與下一次符合條件的聯絡時間。
在傳送前，重新檢查排程、上限、暫停狀態與類別偏好。將裝置端的傳送視為可能延遲，並以產品自身可控的範圍來描述產品所做的承諾。
簡潔的設定摘要能讓相關約定易於查驗：「排程提醒：已開啟。每週二和週四，當地時間晚上 7–8 點。上限：所有類別合計每週兩次。可隨時暫停或關閉。」確切的選項應反映真實的能力；如果產品無法強制執行所顯示的上限或無法可靠地遵循當地時間，則在呈現該控制項之前，應調整其實作方式或縮小其承諾範圍。