重新定義未來

星期一上午八點十五分，Biogene產品實驗室的玻璃門還沒完全打開，裡面已經傳出一陣爭論聲。

「如果我們把個人化服務分成三個層級，那麼最基本的層級究竟要提供什麼？」

「一般健康資訊。」

「那跟市面上免費的健康網站有什麼不同？」

「至少我們可以依照使用者的目標，整理適合他的資訊。」

「問題是，我們怎麼知道什麼適合他？」

最後一句話落下，整間實驗室安靜了幾秒。

白板上畫著三個同心圓。

最外層，是一般健康資訊；中間層，是依照使用者主動提供的目標與生活習慣，調整內容；最內層，則是整合經過授權的基因特徵與其他相關資料，提供更具個人化程度的分析。

這是 Project Sovereign 團隊提出的第一版服務架構。

技術上並不複雜；真正困難的是，每一層都必須有清楚的價值。不能讓最外層只剩下毫無差異的通用資訊，也不能把最內層設計成只有交出最多資料的人，才能獲得完整服務。否則，所謂的自由選擇，只是把使用者推向公司最想要的那個選項。

陳榆寧走進實驗室時，正好聽見產品經理說：「我們是不是可以把有限授權版本的功能做得比較簡單，讓使用者在體驗後，自然願意升級？」

她把手上的文件放到桌上。

「你說的升級，是升級服務，還是升級授權？」

產品經理愣了一下。

「兩者都有可能。」

「那就要分開討論。」

榆寧拉開椅子坐下。

「使用者可以付費購買更好的服務，但不能因為付了費，就被默認同意提供更多資料。反過來說，使用者即使願意提供更多資料，也不代表我們可以把所有服務都包裝成只有完整授權才能使用。」

她看著投影幕。

「我們必須先回答：如果一個人不願意提供基因資料，Biogene 還能為他做什麼？」

這個問題，沒有人能立刻回答。因為過去幾年，Biogene 最擅長的，就是把更多資訊連結起來。它的優勢建立在資料整合、模型推論與個人化服務之上。現在，他們卻要反過來思考：如果資訊不完整，甚至有些資訊永遠不會被提供，產品該如何存在？

榆寧拿起白板筆，在三個同心圓旁邊寫下另一句話；不要先問我們需要什麼資料，先問使用者想解決什麼問題。

她放下筆。

「我們重新開始。」

從使用者的問題開始

下午，產品團隊找來十二位不同背景的既有使用者，進行一場小型研究。這不是正式的市場調查，也不足以代表所有客戶，但榆寧想知道，在公司討論資料主權與模型架構時，真正使用產品的人，究竟在想些什麼？

會議室裡沒有基因序列圖，也沒有演算法簡報，桌上只有幾張情境卡。

第一張：「你想改善自己的生活習慣，但不希望提供基因資料。」

第二張：「你願意提供部分資料，換取更貼近個人需求的建議，但希望每項用途都能分開選擇。」

第三張：「你已經完成基因檢測，卻不希望資料被用於商品推薦或商業研究。」

第四張：「你願意參與研究，但希望知道研究目的、使用期限，以及如何退出。」

榆寧讓參與者依照自己的想法，選擇最接近的情境，再說明原因。

一名三十多歲的工程師首先開口：「我不是不相信你們。我只是覺得，很多健康建議其實不需要知道我的基因。」

另一名女性接著說：「我做基因檢測，是想了解自己，不是要讓每個合作品牌都知道我的健康傾向。」

坐在角落的一名中年男子則提出不同的看法：「如果你們真的能提供有價值的服務，我願意授權。可是我不希望每次打開平台，都要重新研究一遍法律條款。」

他停了一下。

「我希望你們把選項弄清楚，而不是把責任全部丟給我。」

這句話讓榆寧特別留意，因為它指出了另一個常被忽略的問題。選擇權不只是讓使用者有權按下「同意」或「不同意」；如果授權選項複雜到一般人無法理解，那麼形式上的自由，仍然可能掩蓋實際上的不平等。

榆寧問：「那你希望怎麼做？」

男子想了一會兒。

「告訴我，不提供這項資料，我還能得到什麼服務。提供之後，我會多得到什麼。還有，什麼事情你們仍然不能保證。」

他說完，其他人也開始點頭。

一名年輕女性補充：「不要把完整授權寫成最佳選擇。因為對我來說，最好的選擇可能就是不提供。」

會議結束後，榆寧沒有急著整理成一份漂亮的簡報。她先把所有人的意見逐條輸入文件。最後，她在最上方寫下研究結論：使用者需要的不是更多選項，而是能夠理解選項的能力。

她將這份文件寄給逸晨。不到十分鐘，逸晨便回覆：「這可能比我們目前的模型架構更重要。」

榆寧看著訊息，笑了笑。

她知道，這次他們終於問對了問題。

服務不必從資料開始

隔天，逸晨召集技術與產品團隊，會議桌上放著一張新的流程圖。這一次，流程不是從基因資料開始，而是從使用者主動提出的目標開始。

例如：有人希望建立規律運動的習慣，有人想改善睡眠作息，有人希望理解營養資訊；有人只是想知道，自己可以如何更有系統地照顧健康；這些目標並不必然需要基因資料。許多問題可以先從使用者願意提供的資訊開始，例如生活作息、個人偏好、可支配時間，以及他自己設定的目標。如果需要更進一步的分析，系統才說明可能需要哪些額外資訊，以及這些資訊能夠支持什麼程度的判斷。

逸晨說：「我們要把服務流程倒過來。」

技術長看著流程圖。

「以前是先取得資料，再決定能提供什麼服務。現在是先確認需求，再判斷需要哪些資料。」

「對。」

「那麼我們必須重新定義模型的輸入。」

「不只輸入──」

逸晨指著流程圖的另一端。

「還有輸出。」

他拿起筆，在系統輸出旁邊加上三個標籤：可以判斷、無法確定、需要更多資訊。

「我們過去一直把模型的價值，放在它能回答多少問題。」

他說。

「但對使用者來說，有時候最重要的，是知道哪些問題不能只靠目前的資訊回答。」

技術長沉思片刻。

「這代表我們必須讓模型更清楚地表達不確定性，而不是只輸出一個看起來很精準的結果。」

「沒錯，產品介面也要跟著改。不能在結果頁面上放一個看似精確的數字，下面再用很小的字說明限制。」