Day 21〈side project 的定位：決定要服務誰，也決定放棄誰〉 講的是那份定位文件裡的四個決定，最後定下來的，是日常行銷工作已經離不開 AI 的那個人。那四個決定怎麼變成他每天看到的畫面、讀到的文案，我是從對外的首頁開始動手的。

他被新的首頁帶進來，一進到後台，看到的還是原來那個樣子。前台改得再多，這個落差擺在那裡，原本要的效果就達不到。所以後台也得照著那份文件再改一次。

我對自己後台不滿意的地方

動手之前，我把用起來不順的地方一條一條寫下來。它們長這樣：

• 儀表板上四塊大數字，總連結數、活躍數、總點擊、今日點擊，看完不知道要做什麼。
• 橫向的導覽列已經排滿，再加一個功能就會撞牆。
• 手機版是硬塞的，新增按鈕的位置很怪。
• 統計裡寫著 UV，沒有任何說明。
• 自訂網域那一區寫著 Phase 1、Phase 2。
• 方案、API 金鑰、時區、品牌設定散在四個地方。
• 列表上的操作按鈕小到會按錯。

七條看起來是七件事。我原本也打算一條一條修。

但它們不是七件事

當時是真的一條一條修了，一個畫面接著一個畫面跟 Claude 討論怎麼改，討論到第三個的時候隱隱覺得不對，我每次做決定用的其實是同樣那幾句話。

每次要在畫面上多放一個東西，我都會先問一次，這個東西回答了打開後台的人哪一個問題，答不出來就不要放上去。每次也都會說一次，後台可以主動提醒他哪一條連結最近沒有動靜，但接下來要不要處理、怎麼處理，留給他自己決定，toui 不必自作主張。

這幾句話跟正在討論的是哪個畫面無關，它們是我的判斷標準。定位我寫成了文件，這一層卻沒有，每一輪對話都是新的，標準只留在我的腦袋裡，所以同一個標準在不同的地方被我講成不同的結果。有的地方我說資料還不夠就先不要放，有的地方我又說即使一筆資料都沒有，位置也要留著。我停下來，把那幾句話寫成了六條。

這些原則不是出於我的刻意設計，而是做到一半，從自己重複的話裡歸納出來。整理出來、回頭看那張清單，七條全部對得上去，各自是違反其中某一條的症狀。

上一篇最後一個決定就是用原則而不是符號，那是態度；下面這六條，則是同一個態度落到他每天要操作的 UI 上。

畫面要配得上用戶的動機。 儀表板那四塊數字之所以沒用，是因為它回答的不是他的問題。他打開後台想知道的是「我現在的活動 OK 嗎」「哪一條連結在動」，而不是「我總共有幾條連結」。這條原則後來也決定了另一件事，一張卡片要佔多少版面、講多少細節，由它現在有沒有動靜決定。已經沉寂的連結就不必再擺一個「近七天 0」在那裡佔位置，那個數字雖然真實無誤，但對他一點用也沒有。

術語可以用，但要備好投錢箱。 統計裡的 UV 這個縮寫指的是不重複訪客，同一個人看三次只算一個。這個詞對懂的人是最快的溝通方式，換成白話反而累贅。擔心會不會有人看不懂術語的解法不應該是拿掉術語，而是設計分層。既然受眾主要是行銷人，多數的人都懂，就像公車上多數的人都刷悠遊卡上下車一樣。但總會有人沒有卡片、只有現金，這時投錢箱備用就非常重要。落到畫面上就是 UV 照樣顯示，但第一次出現的地方要有指引，幫助少數不懂的人。

絕不把內部用語當成對外溝通語言。 自訂網域那一區當時寫的是，Phase 1 只支援子網域，根網域會在 Phase 2 推出。Phase 1、Phase 2 是我們自己的排程編號，用戶沒有那個脈絡，也沒有理解的義務。把它翻成「即將推出」也沒有比較好，那只是把一個他看不懂的階段，換成一個我還不知道什麼時候做得到的承諾。所以那半句是整個拿掉的，畫面上只留現在做得到的事，「目前支援子網域，例如 go.example.com」。

分開操作與設定，照用途歸類而不是照資料表。 方案、API 金鑰、時區這些是一次性設定，該收進一個統一的地方；每天在做的事才留在主畫面。公司名稱本來放在「團隊資訊」底下，因為它在資料庫裡屬於 teams 那張表，一開始設計時沒多想就這樣放了。但用戶會去動它，是為了讓自己的名字出現在 QR Code 頁面上，所以它現在在品牌設定底下。

設計要看使用情境，不是一律手機優先。 全站的人有一半以上從手機來，但後台頁面的瀏覽有將近九成在桌機。所以註冊、第一次使用、快速縮連結這些流程照手機優先做；活動分析、批次上傳這類深度操作以桌機為主，但仍得確保在手機上可以正常運作。

畫面上的東西要交代得出來歷。 新用戶還沒有建過任何活動的時候，那個空畫面最容易讓人想擺一份漂亮的示範數字，但他看到的第一個問題會是這些數字哪裡來的，真要示範就明講那是範例。排序也一樣，系統自己把某一張卡片排到最前面，他會問這個為什麼排在這裡，而這個問題我們答不出來，因為活動與活動之間的點擊數沒有共同的分母，推得兇的跟做得好的數字上長得一樣。答不出來的東西就不要放上去，位置留給他自己決定。

最後這一條跟前面五條不太一樣，清單上找不到它的症狀。前面說的那三個畫面，我每一次都講到它，卻從來沒有把它當成一個問題寫下來。

七條各自有了對應的原則之後，調整的角度就變了。我不再是逐一修七個地方，而是拿六條原則去檢測每一個畫面。後面每個元件的決定都從這些原則衍生出來，不必再一一討論。這個轉向省下來的時間比任何一個畫面的優化都多。

起手不是挑顏色

後台這一輪的順序，是跟首頁那一輪學的。首頁開始動手的那天，我不是打開設計工具挑喜歡的顏色。

第一步是重新議定首頁到底要說什麼，也就是上一篇那個主張，究竟要用什麼話講給他聽。主張定了，視覺才有東西可以服務。如果反過來，先做出一個漂亮的版面再想文案要塞什麼，那個漂亮就沒有根，改到後面一定會亂。

這件事花上不少時間，因為明明在做視覺設計，卻不斷用對話在確認想法與原則，沒有任何頁面、圖像產出。但那幾天的成果決定了後面每一個畫面，也成了 toui 的設計資產。現在首頁講話的方式，就是那幾天定下來的。

你今天就能用的

如果你手上也有一個要改版的東西，我會建議照這個順序。先把用起來不順的地方全部寫下來，不要急著修。寫完之後找它們的共同原因，像我那七條很可能只是幾條原則的不同症狀。原則寫下來之後，先把訊息決定下來，再動視覺。

改版不是把畫面重畫一次。