Pace

我手機上每一個健康 App 都用同一套邏輯：先訂一個目標，然後拿我跟它比。步數、卡路里、閃環、連續天數。少一天就一個紅點，少三天連續天數斷掉 —— 連明天再打開的理由也一起斷了。

這是一個設計決定，不是自然法則。某個地方有人決定了「動機來自量測」，而對某一種使用者這確實有效。但對已經很累的人，它的作用是相反的：照顧自己變成另一份考核，本來要幫你的東西，變成又一件你做不好的事。

所以題目定得很窄，而且很尷尬：做一個完全不打分的健康 App，而且要讓人明天還想打開它。

尷尬的是後半句。拿掉連續天數、完成度、紅點，等於同時拿掉這個品類用來把人拉回來的所有機制。取代它們的東西只能是情感性的，不能是懲罰性的 —— 而那難設計得多，因為你沒辦法靠量測走到那裡。

那個問題是：使用者沒出現的時候，你要做什麼？這個品類每一個 App 的答案都一樣 —— 標記它、斷掉連續、把缺口顯示出來。缺口被當成使用者需要看到的資訊。

Pace 的答案不同，而光是這一點分歧，就長出產品裡幾乎所有其他決定。如果空白的一天不是失敗，那就沒有東西要標記；沒有東西要標記，時間軸就可以直接把空白留在那裡；時間軸把空白留著而不加註解，每週回顧就不能是完成率 —— 它只能是一段文字。

所以下面這張對照表不是功能清單，是同一個立場一路推到底。

把順利的流程做得溫柔很容易 —— 一切都好，文案當然暖。一個產品真正的教養，只在出事的時候才看得出來。而 Pace 的斷點很明確：語音辨識失敗，App 得告訴你它沒聽清楚。

那一刻，整個定位不是成真，就是裝飾。

所以我寫了兩個版本。

A 讓小太陽留在畫面上。「嗯…我剛剛沒聽清楚 / 不是你的問題，再跟我說一次好嗎？」兩條出路：再說一次，或改用打字。

B 是標準的系統錯誤。紅色警告三角。「語音辨識失敗 / 請確認網路與麥克風後重試」一條出路：重試。

差別不在語氣，在責任歸誰。A 把責任攬在自己身上，而且多給了一條路；B 把問題丟回給使用者，請他自己去檢查設備。以 Pace 的立場 —— 不懲罰、不指責 —— A 應該是答案，B 是對照組。

難的是怎麼測而不把結果弄髒。我不能把兩個版本給同一個人看。 任何人看到「溫柔版」旁邊擺著「中性版」，幾秒內就會推理出自己在參加一場比稿，然後開始回答他以為你在問的問題 —— 他會告訴你溫柔的那個比較好，因為那顯然是你想要的答案。資料到這裡就報廢了。這叫 demand characteristic，而且是自己造成的。

所以原型做成三個各自獨立的入口 —— A 一個、B 一個、乾淨的順利流程一個。每位受測者只拿到自己那一條連結。那幾個版本裡，Demo 切換面板不是被藏起來，是整個從頁面上移除，所以介面裡沒有東西可以找、也沒有東西會被察覺。從裡面看，每一個版本就只是這個產品本身。

八個人跑完，分在三條連結上。

A 勝出，而大家給的理由是那個角色。 他們反應的不是文字寫得比較好，是小太陽還在。B 的紅色三角回來的形容是「被罵」—— 同樣的資訊，但產品從一個陪你的東西變成一台回報故障的系統。這才是值得帶走的發現：一個以「我不會評價你」為前提的產品，失敗畫面就是那個前提被檢驗的地方，而守住承諾的是在場，不是禮貌。把文案改軟、底下還擺一個警告三角，是救不回來的。

還有一個人要了一個沒人設計過的東西。 他錄到一半說錯，想要一個「這則就不要留了」的方式 —— 而且不要是刪除，不要被算成什麼。這件事後來發現是同一條產品原則從另一個方向走過來：如果空白的一天不是失敗，那一句你不想留的話也不是。「先不留這則」 現在就在原型的存檔鍵底下。這是整個專案裡唯一一個不是我想出來、而是使用者要出來的畫面。

三個分頁，結構就這樣。今天是你現在在的地方，日子是你說過的所有話、可以搜尋，回顧是這一週，寫成一段文字而不是一張圖表。

值得解釋的決定是：記錄不是其中之一。按下語音鍵之後，聆聽 → 小太陽回應 → 收下，這三段是同一個畫面的三個狀態，不是你要在之間跳來跳去的頁面。

這不是為了整齊。記錄一旦變成一個目的地，它就變成一件任務 —— 一件你要「去某個地方做」的事，於是也就變成一件你可能落後的事。讓它維持成一個在原地開始、也在原地結束的動作，才不會有交作業的感覺。同一個道理後來寫進設計原則，叫「一個主行動」。

在多數產品裡，空狀態是剩下來的東西 —— 最後才畫的那個畫面，給「還沒有資料」的情況用。在這裡它是論點本身，因為「空白的一天」正好是這個品類其他人都在懲罰的那件事。

所以它是我寫得最小心的一頁。今天什麼都沒發生，它說的是：今天還沒有紀錄。想到什麼，對我說一句就好。 沒有徽章、沒有紅點、也沒有溫柔的催促。在時間軸裡，沒有記錄的那天寫的是這天也留白了，然後就停在那裡。

每週回顧是同一個主張放大。它很容易就寫成「七天完成五天」。但它是先數了有的，然後把那句話直接講出來：剩下兩天的留白，也是你的一部分。 這一句話就是整個產品的立場壓縮成一行 —— 而它成立的唯一原因，是畫面上沒有任何其他東西在反駁它。

取代分數的是小太陽。你說一句，它回一句 —— 簡短，而且是針對你剛才那句話。這就是整個產品建立在上面的那個交換：用回應取代評分。 數字告訴你排在哪裡；一句回應只告訴你，有人聽見了。

設計系統就一張板，而它存在的理由是：「要溫柔」不是一份規格。放著當感覺，大概撐三個畫面，就會有人在錯誤狀態伸手去拿紅色，整個立場悄悄垮掉。

六個部分：色彩、情緒光譜、字體、元件、狀態、原則。

其中兩件是承重的。情緒光譜有五個有名字的狀態，沒有數字 —— 疲憊、平淡、還行、輕盈、充滿能量。有順序，因為情緒本來就落在一個區間上；但絕不換算成分數，因為一旦變成「5 分之 2」，這個 App 就又在給你打分了。還有，色票裡沒有紅色。 能用的最強的顏色是一個陶土色，而那也正是主要行動用的顏色 —— 所以錯誤永遠不可能比邀請更大聲。在 token 層級就把紅色排除掉，後面就沒有人需要記得這條規則，這張表自己會擋。

最下面那四條原則，是我會直接交給接手的人的東西：不懲罰空白 · 回應取代評分 · 一個主行動 · 暖而不刺激。它們寫成指令而不是形容詞，所以真的可以拿來解決「這一頁到底該怎麼做」的爭論。

第三章那組對照，需要 Figma 原型做不到的東西。要測一則失敗訊息，就得讓失敗真的發生 —— 在受測者沒有選擇的時間點發生，然後再說一次會成功。在點擊式原型裡，那是一個受測者「刻意去點」的熱區，那不是同一種體驗，也測不到同一件事。

所以我把它做出來了。Figma MCP 讀設計檔、Claude Code 產元件、Cloudflare Pages 上線。 沒有 GitHub、沒有工程師、沒有交接 —— 從一個畫完的 frame 到一條可以發給別人的網址，在同一個工作段落裡完成。

這是我最希望團隊看到的那一段流程，所以這裡寫的是它實際改變了什麼，而不是它聽起來像什麼。

原型跟設計檔意見不合，而輸的是設計檔。 問候語會依時間讀早安／午安／晚安。靜態的 frame 只能定格在其中一個，所以 Figma 裡它永遠是「晚安」；跑起來之後才看得出，問候語是一種行為，不是一串文字。卡片也一樣：Figma 裡各自獨立的「幕」，在這裡是同一個畫面的狀態 —— 因為紀錄要真的累積起來，你才判斷得出時間軸讀起來像日記還是像日誌。

還有一次 review 改掉了設計。 已存檔的確認卡，標題寫著這則已存到你的日子裡 —— 那是通知，過去式，事情已經做完了 —— 底下卻擺著兩顆按鈕：先不留了、知道了。一個問句被放在一句陳述底下。文案已經把決定關上了，按鈕還在提供選擇。現在只剩一顆，而且回頭把 Figma 的元件一起清乾淨，沒讓兩邊繼續漂移。

這件事對團隊的價值不是快。是「這個測得了嗎」不再是一個排程問題。 失敗路徑之所以存在，是因為做它花一個下午而不是一個 sprint —— 如果它要花一個 sprint，我就會憑直覺出溫柔版，然後永遠不會知道答案。

存在而且可以驗證的部分：一個誰都能打開的線上原型、一套我自己寫完又真的照著做的設計系統，以及一組設計成「結果會有意義」的對照測試。

最後這一項出現在這裡是有原因的。AQUILA 那個案子我最後悔的就是沒有先量基準線 —— 我看行為、覺得夠了，事後才發現沒辦法證明改版真的變好。這個專案我先做量測、後做畫面。這是那次的修正，也是這一章能對「哪一版有效」講出任何話的唯一原因。

重做一次我會改的：

八個人分三組，每組只有兩三個。 我把對照設計得夠乾淨，然後找同學跑完 —— 一半做得講究，一半做得方便。八個人能給你的是一個一致的理由（他們都指向同一件事，而且理由一樣），這有價值；不能給你的是一個比例。下次我會把這句話直接寫進報告裡，而不是留給讀者自己去判斷手上拿的是哪一種。

我測了失敗畫面，卻沒測它在保護的那件事。 從最危險的畫面開始是對的，但這個產品真正的主張是「一個不打分的 App，明天還是會被打開」—— 而那件事一次坐下來測不出來。它需要以週為單位，唯一誠實的方法是把它交給某個人，過一陣子再回去問。

語音輸入是腳本模擬的。 原型裡的辨識是假的，點一次播下一句。要測文案，這樣沒問題，甚至更乾淨。但要測「人到底願不願意在有其他人的房間裡對手機說話」，它什麼都證明不了。