需求講清楚之後，下一關是設計。這裡講的設計不是純美術，是畫面長什麼樣子跟程式架構怎麼搭這兩件事，要在真的動手寫之前先收斂成同一個版本，兩邊講的不是同一件事的話，寫出來的東西一定會在某個地方卡住，不是現在卡，就是之後卡。以前這是設計師跟架構師兩個人的事，現在變成我自己一個人要同時想這兩塊，還要讓兩塊對得上，這篇講我實際上怎麼做這件事，不是講理論上該怎麼做。
這件事一旦沒收斂好，後果比需求沒講清楚更麻煩。需求沒講清楚，頂多是做出來的東西方向不對，重寫邏輯就好。畫面跟架構沒對齊，常常是寫到一半才發現，畫面需要的資料，架構當初根本沒設計成撐得住那種用法，這種問題要回頭改的不是一段邏輯，是整個資料流的形狀，牽一髮動全身，代價高很多，這也是為什麼這個階段特別值得花時間先收斂，不是隨便畫完就急著動手。
一個新想法剛冒出來的時候，我不會馬上開一個正式專案去畫設計稿。Claude 自己內建一個做設計稿的功能，用聊的方式描述想法，它會直接在旁邊的畫布上生出對應的畫面，畫布用的是頁面跟版位這種概念，跟一般設計工具的操作邏輯很像。這個功能還可以先選一套既有的設計系統，同一套配色跟元件規則會套用到接下來畫的每個東西上，不用每次都重新講一次顏色跟間距要多少。
這一端我會定位成探索用，一個想法還很模糊，先用這個方式很快畫出幾個版本，看感覺對不對，這個階段錯了成本很低，改個描述重畫一次就好。這個階段我不會去管背後資料怎麼存、規則怎麼定這些事，純粹在想畫面本身順不順、資訊擺放的位置對不對，把架構面的事留到下一個階段再處理，這兩件事混在一起想，反而會拖慢單純想畫面這件事該有的速度。
選好的設計系統不是只在這一次對話裡才有效，是存起來之後，換一個新的對話、換一個完全不同的想法，都可以繼續挑同一套來用，這件事讓探索這個階段變得比較安心，因為就算今天畫的東西明天就丟掉重來，至少配色跟元件規則不用每次重新對一遍，重來的成本只剩下畫面本身的構想，不用連基本的視覺語言都要重建一次。
畫面本身是放在一個像畫布一樣的空間裡，裡面用頁面跟版位分層管理，一個頁面可以放好幾個版位，對應不同畫面或同一畫面的不同狀態，這種結構跟一般設計工具的邏輯很接近，熟悉那類工具的人幾乎不用重新學。差別在這裡是用講的方式生成畫面，不是一個元件一個元件手動拉，想調整的時候直接講要改哪裡，比自己動手拖曳快很多，尤其是在還沒定案、要一直改來改去的探索階段。
這種用講的方式生成畫面，有個地方要特別留意，講的越模糊，生出來的東西就越可能不是自己想像的樣子，這時候不是重講一次就好，是回頭檢查自己的描述是不是也一樣模糊，跟前面幾天講的逼問道理相通，講不清楚的地方，先弄清楚自己想要什麼，再重新描述，比一直重畫更有效率，也比一直怪工具畫不準更實際。
輕的工具解決的是「這個畫面長什麼樣子」，正式要做的產品還需要另一層，畫面背後的資料怎麼存、規則怎麼定、這次改動範圍在哪裡、哪些事故意不做。我自己在做比較認真的產品時，會準備兩份文件當作真正的依據，一份是寫清楚每個功能要滿足哪些條件的規格文件，一份是把畫面實際長相定下來的視覺原型，兩份都會標好精確的位置，寫程式的時候引用的是這份規格第幾行、那份原型第幾行，不是憑印象講一句「大概是那樣」。
這兩份文件解決的是不同的問題，規格文件講「這個功能要做到什麼程度才算數」，原型講「使用者實際上會看到什麼」，兩者都是真正的依據，不是其中一份為主、另一份參考用。規格文件裡我會明確列出這次要做的驗收條件、牽涉到哪些資料、有哪些規則要顧到，也會列一份「這次故意不做」的清單，把容易讓人手滑順便多做的東西提前排除掉，範圍才不會一路長大。
拿到一個功能要開始設計怎麼做之前，我會先讓一個完全乾淨、沒有預設立場的角色，把規格跟原型裡跟這個功能有關的內容全部找出來，原文逐字引用，附上在哪一份文件的第幾行，查不到的地方就寫查不到，不會因為想讓報告看起來完整，就順手补一個聽起來合理的細節。這個角色只做盤點，不做判斷，不會說「我覺得應該這樣設計」，只會說「規格這樣寫、原型那樣畫」。
盤點做完之後，才輪到做決定，這時候才會去想範圍要畫在哪裡、哪些技術上的選擇要先定案、哪些之前做過的東西可以直接沿用。把這兩件事分開，是因為盤點事實跟做設計決定，需要的判斷力完全不一樣，盤點要的是不要漏看、不要腦補，決定要的是拿捏取捨，混在一起做，很容易在盤點階段就不小心夾帶了自己的偏好，之後的決定等於是在驗證自己已經先入為主的想法，不是真的根據事實在判斷。
這個順序我自己一開始沒有分得這麼清楚，常常一邊看規格一邊就順手開始想這裡該怎麼做，後來發現這樣做出來的盤點結果，會不自覺只挑對我原本想法有利的部分講得詳細，其他地方輕輕帶過。逼自己先做一輪什麼判斷都不下的盤點，寫出來的東西才是真正中立的底稿，後面做決定的時候，才是真的根據完整資訊在選，不是根據自己已經選好答案之後、回頭找理由支持的那種假中立。
負責盤點的角色，我也會刻意讓它跟負責做決定的角色分開，不是同一個對話接著往下做，這個分開的動作看起來只是多了一道手續，實際上是整套方法能不能真的中立的關鍵。原因跟前面幾天講的一樣，同一個對話做完盤點，馬上接著做決定，腦子裡還帶著盤點過程中形成的印象，很難真正做到中立起跳，換一個全新的角色去做決定，才能確保決定是根據那份寫下來的盤點報告，不是根據盤點過程中殘留的模糊印象。
規格文件跟視覺原型是兩個人、或者兩個不同時間點寫出來的東西，實務上常常對不上。我自己遇過規格寫一個數值，原型畫的卻是另一個數值，這種時候我不會自己選一個看起來比較合理的版本就往下做，會把這個衝突明確記下來，兩邊各自寫清楚說了什麼，標成待確認，交給真正該拍板的人決定，不會因為想趕快往下走，就自己偷偷選一邊當作沒事發生。
這件事我自己覺得比想像中重要，因為這種衝突常常不是筆誤，是背後有兩個不同的思考路徑各自定案，隨便選一邊，等於把另一條路徑背後的考量整個丟掉，事後才發現選錯，要付的代價比當下記一張待確認的紀錄卡高得多。
更麻煩的是，這種衝突常常不會自己浮出來，兩份文件各自看起來都很完整、很有道理，得靠人主動去對照才找得到。我自己一開始沒有養成每個功能都交叉核對的習慣，只看規格就開始做，覺得原型應該只是輔助參考，後來吃過幾次虧，做到一半才發現跟原型畫的不一樣，回頭改的成本比一開始就核對一次高得多，才慢慢把交叉核對這件事，變成每次進到設計階段的第一個動作，不是選擇性做，是每次都做。
舉個假設的例子，規格寫某個等待時間預設是七天，畫面原型卻畫成十四天被預先選起來，這種數字上的落差，光看規格看不出來，光看畫面也看不出來，只有兩份放在一起交叉核對才會冒出來，這也是為什麼交叉核對這個動作本身不能省略，不能只選一份當唯一依據。我自己現在的做法是把這種落差寫成一張明確的紀錄，兩邊各自寫了什麼、出處在哪裡，先照其中一份權威度較高的走，但同時標記這裡有分歧，等真正該拍板的人看過再定案，不會因為兩份都放著沒人管，就放任這個落差一路帶到程式碼裡。
這張紀錄卡我會用固定的格式寫，衝突是什麼、兩邊各自的出處、我暫時選了哪一邊當作先走的版本、為什麼先選這邊。先選一邊往下走是為了不卡住整個進度，但標記分歧是為了不讓這個先選的版本，悄悄變成沒人質疑過的定案。這兩件事看起來有點矛盾，先往下走又同時說這裡還沒定案，但實務上這樣做才能兼顧速度跟正確性，完全卡住等對方回覆，很多時候比先走一步、事後修正的成本更高。
畫面上的顏色、間距、元件規則，我不會每次做新功能都重新想一遍，會定成一套固定的規則，之後每個新畫面都直接引用這套規則裡定義好的東西，不夠用才討論要不要新增。這件事跟前幾天講的判斷要寫成文件是同一個道理，只是這裡寫下來的是視覺跟互動上的判斷，不是文字上的判斷。
沒有這套固定規則，每個功能各自決定顏色跟間距要用多少，做出來的東西會慢慢變得不一致，使用者感覺得出來哪裡是後來想到才補上去的，哪裡是一開始就規劃好的。而且每次都重新想一遍要用什麼顏色，也是在浪費不需要浪費的判斷力，這種決定一次定案之後就該變成可以重複套用的規則。
新的功能要用到某個顏色、間距或元件時，我會先去對照既有的規則裡有沒有現成的可以用，有的話直接引用，不會另外生一個看起來差不多但命名不同的版本出來，這種看起來差不多的重複，久了會變成一堆意義相近但彼此不一致的東西，之後要改一個共通的設計決定，得到處找哪些地方用了哪個版本，非常麻煩。真的碰到現有規則不夠用的情況，才會另外討論要不要擴充，而且擴充也要寫進這套規則裡，不是就地解決完就算了，不留下任何紀錄。
這件事跟需求定義那篇講的名詞對照表是同一個道理，本質上都是對齊，只是這裡對齊的不是文字定義，是視覺跟互動上的定義。名詞沒對齊，會讓兩個人以為在講同一件事，其實理解不同；設計規則沒對齊，會讓畫面看起來出自不同人的手，兩者本質上都是溝通落差，只是發生的媒介不一樣，一個在語言層，一個在視覺層，但根源都是同一種疏忽。
我自己現在寫規格的時候，遇到任何跟畫面有關的描述，都會盡量直接引用設計規則裡定義好的名稱，不會自己另外造一個形容詞去描述顏色或間距，這樣寫程式的時候對照規格，可以直接查到規則裡對應的確切數值，不用猜測寫規格的人當初講的「淺一點的顏色」到底是哪一個，這種模糊形容詞看起來省事，其實是把猜測的工作丟給後面接手的人。
盤點事實這件事，跟前面幾天講的分級一樣，用中等等級的資源去掃、去引用就好，這個階段要的是不漏看、不腦補，不是要多聰明的判斷力。真正該花在強資源上的，是後面做決定那一段，範圍要畫在哪、技術選擇要怎麼定、衝突要怎麼處理，這些才是真正考驗判斷力的地方。
這樣分配下來，盤點這種偏機械性的工作可以跑得快，省下來的時間跟資源，留給後面真正要拿主意的階段，整體效率會比每一步都用最強的資源慢慢想過一遍高很多，也比每一步都想省資源隨便找個等級跑完，品質更有保障。這個分配方式套用到今天講的每一段都成立，找候選、盤點事實、掃描格式這類工作交給中等資源，判斷能不能擋、要不要定案、衝突怎麼處理這類工作交給最強的資源，這條分工邏輯從寫功能到審查程式碼到現在的設計階段，一直沒變過，換的只是套用的場景，邏輯本身很穩定。
輕的工具跟重的整套流程，怎麼選，我自己看的判準跟前幾天講的一樣，這個東西做錯了，代價有多大、多晚才會被發現。還在摸索方向、隨時可能整個推翻重來的階段，用輕的工具快速試錯就好，不需要為了一個可能明天就丟掉的想法，去寫一整份規格文件跟盤點事實。已經確定要做、之後會有其他功能疊上去、改起來代價越來越高的東西，才值得花時間走完整套流程，把畫面跟架構收斂清楚再動手。
我自己抓的具體判準是，這個東西之後會不會有別的功能長在它上面，這個判準比單純看功能大小或畫面複雜度準確得多，有些畫面看起來很簡單，操作起來也就那幾步，但背後是後續一整批功能的地基，這種東西真的不能只憑外觀簡單就輕率處理，判斷錯了，後面要付的代價通常會晚很久才顯現出來。一個獨立、之後不會被別人依賴的小東西，做錯了影響範圍就是它自己，用輕的工具試一試就好。一個之後會變成地基、其他功能會蓋上去的東西，一旦做錯，之後每一個蓋上去的功能都要跟著遭殃，這種東西一定要走完整套盤點跟收斂，因為修正的成本不是線性增加，是隨著蓋上去的東西越多，越晚修代價越高。
殺雞用牛刀跟拿著雞刀想殺牛，是同一種判斷力不夠的兩種表現，只是方向相反，兩種我自己都踩過。用輕的工具處理一個其實影響很大的功能，會漏掉真正該盤點的細節，等到寫進正式系統才發現架構撐不住，要整個重來。反過來，一個只是想試試水溫的點子，動用整套盤點跟紀錄的流程，時間都花在寫文件上，想法本身反而沒空間快速調整，兩種錯法造成的浪費不一樣，但都是浪費。
一時判斷不準的時候，我會寧可先當作影響較大來處理，寧可多花一點時間盤點，也不要事後發現漏了才回頭補，這種偏保守的取捨，長期算下來還是划算的。這個偏保守的傾向，是這陣子吃過幾次輕估代價的虧之後才慢慢調整過來的，一開始我常常低估一個小功能之後會被多少東西依賴，覺得應該不會有事，後來才知道那種「應該不會有事」的直覺，常常就是最容易出事的地方，越是憑直覺覺得沒問題的地方，越值得多花一分鐘確認一次。
老實講清楚這套做法的界限。盤點事實跟記錄衝突，能防的是資訊沒對齊、細節被忽略，防不住的是這個設計方向本身好不好、使用者到底喜不喜歡這樣的畫面，這種涉及品味跟產品直覺的判斷，沒有一套流程可以替我做，工具能做到的，最多是確保我在做這個判斷的時候，手上的資訊是完整、對齊過的，不是憑一知半解在猜測。
這也是為什麼即使有這麼多流程幫忙盤點跟記錄，最後這個設計方向要不要定案，我還是自己看過畫面、想過使用情境才拍板，不會因為流程跑完了、待確認的項目都清空了，就直接當作這個設計沒問題了。流程清空的是資訊落差，不是我自己該負的判斷責任。
還有一種限制，也是自己容易忽略的地方，這整套盤點跟記錄的方法，建立在規格跟原型本身值得信任的前提上。如果一開始的規格寫得很糟、原型畫得很隨便，盤點跟核對做得再仔細，也只是把兩份爛東西的落差找出來，找出來之後才發現兩邊都不對，這種時候該做的不是繼續盤點，是回頭去把規格跟原型本身寫好，這件事跟前面需求定義那篇講的道理一樣，工具能幫忙核對，不能幫忙生出原本沒有的品質。
我自己這陣子也遇過一種情況，盤點跟紀錄都做得很仔細，待確認的項目全部清空，回頭看畫面的時候，還是覺得哪裡怪怪的，說不出具體哪裡有問題，就是使用起來不順。這種感覺沒有辦法寫成一條可以檢查的規則，只能靠自己多看幾遍、實際想像使用情境去抓，任何工具在這裡都幫不上忙，這正是流程跟品味的分界線，流程負責讓我看到的東西是完整、對齊過的，品味負責判斷這個完整的東西，到底好不好。
這種說不出具體哪裡不對的直覺，我現在不會急著壓下去，也不會硬逼自己馬上講出一個理由來，會先記下來，就算暫時講不出理由，也標成一個待想清楚的項目，跟前面講的判斷卡放在一起處理。有時候放個一兩天再回頭看，會突然想通哪裡不對勁，有時候想了很久還是講不出所以然，那就承認這是純粹的偏好判斷，跟對錯無關，自己決定要不要照直覺調整。
具體講一下盤點這份東西的樣子，才不會流於抽象。我會要求裡面每一段都附出處，規格第幾行寫了什麼、原型第幾行畫了什麼，原文照抄，不改寫、不摘要成自己的話，因為摘要的過程本身就會不自覺加入詮釋，跟盤點只講事實的目的衝突。查不到的地方，直接寫規格沒寫、原型沒畫，不會因為找不到就跳過不提，找不到本身也是一個重要的資訊，代表這裡需要另外去確認。
這份東西寫出來通常不好看，一堆引用跟行號，讀起來很生硬，但這正是它的價值所在，生硬代表沒有摻雜任何自己的判斷在裡面，做決定的人可以完全信任這份東西講的都是原始資料，不用擔心裡面藏著盤點的人自己沒說出口的偏好。
我自己一開始會忍不住想把這份報告寫得漂亮一點，多加幾句銜接、多下一點結論式的判斷，後來發現這樣做反而讓報告失去了原本的價值。一份寫得很順、讀起來很舒服的盤點報告，會讓人誤以為裡面的判斷已經是定論，反而更容易被直接照單全收，跳過後面該做的決定那一步。醜一點、生硬一點，其實是提醒讀的人，這裡還沒做決定，你自己要接著判斷，不是已經幫你判斷好了，可以直接拿去用。
不是每次遇到類似的情況都要重新盤點一次。如果一個功能跟之前已經收斂過的某個決定高度相似，我會先去查有沒有現成的紀錄可以直接引用，有的話就沿用，不用重新盤點一次一模一樣的東西。這件事聽起來理所當然，但我自己一開始沒有這個習慣，每次遇到新功能都從頭盤點一遍，覺得每個功能都是獨立的新問題，後來才發現很多所謂的新功能，拆開來看跟之前處理過的東西高度重疊，只是換了個名字或情境再問一次。
判斷能不能直接沿用，我會看這次的情況跟之前記錄下來的判斷卡或決定，前提是不是真的一樣，前提有一點點不同，就值得重新盤點一次，不能因為表面上看起來像，就直接套用之前的答案，畢竟前面幾天也講過，看起來相關不代表真的適用，這條原則放在這裡一樣成立。
這也是為什麼那些紀錄卡跟盤點報告值得花時間留下來，不是寫完就丟。它們的價值不只在當下解決一個衝突，是慢慢累積成一份可以查的歷史，之後遇到類似情況，先查有沒有前例，比每次都重新想一遍划算得多，這跟需求定義那篇講的文件會被重複打開，是同一件事在設計這個階段的樣子。
累積久了之後，這些紀錄卡本身也會變成一種設計系統之外的隱性規則庫，記錄的不是顏色跟間距，是遇到某種情境時，過去是怎麼判斷的。新接手的人如果能看到這些紀錄，等於直接繼承了前面每一次判斷背後的脈絡，不用每件事都從頭問一次為什麼要這樣做，這對一個人獨立作業尤其重要，因為沒有旁邊的人可以隨口問一句當初為什麼這樣設計，紀錄卡等於是把那個隨口一問的答案，事先寫好放在那裡。
這件事我自己一開始沒有意識到它的價值，覺得寫這些紀錄很花時間，反正事後也不會有人真的回頭看。後來真的遇到自己都忘記當初為什麼這樣決定的情況，翻出舊的紀錄卡，才發現當初考慮的東西比自己現在想的還周全，如果沒寫下來，很可能會用現在比較片面的理解，推翻一個當初想得更完整的決定，那才是真正的浪費，比花時間寫紀錄卡浪費得多。
回到這整條路線的核心，一個人跑完整條線，設計這段是很直接的例子，因為以前這裡本來就是兩個角色，設計師顧畫面好不好用，架構師顧系統撐不撐得住，兩人中間常常要來回吵，吵完才有一版兩邊都能接受的東西。現在這兩個角色的工作都落在我自己身上，吵架這個動作沒有消失，變成我要自己跟自己的兩種身分對話，一邊想使用者實際上會怎麼用，一邊想系統要怎麼撐住這個設計，中間對不上的地方，一樣要吵出一個結果，只是吵架的兩邊，從頭到尾都是我自己一個人。
這種自己跟自己吵的過程，其實比找另一個人來吵還累，因為沒有人會在旁邊逼你把話講清楚，也沒有人會在你想草率結束的時候多問一句真的想清楚了嗎，很容易兩邊都各退一步，得出一個表面和諧、實際上誰都沒真的說服誰的版本。我自己現在的做法是，把畫面那邊的想法跟架構那邊的想法，分別寫成文字，逼自己看著兩份寫下來的東西對話，而不是憑印象在腦子裡各退一步，這樣至少留得下一個可以檢查的紀錄，知道當初是哪邊讓了步、為什麼讓。
今天講的這一整套，說到底是想解決一個很具體的問題，一個人腦子裡同時裝著畫面跟架構這兩件事，怎麼確保這兩件事真的對得上，不是各自在腦子裡想得很順，湊在一起才發現根本兜不攏，等發現的時候往往已經寫了不少程式碼，回頭改的成本比一開始就核對一次高出許多。
畫面跟架構都收斂完，接下來要面對的是完全不同性質的挑戰。下面講下一個場景，會進到實作階段，看規格跟原型都定案之後，怎麼確保寫出來的東西真的照著這份收斂完的版本走，不會做到一半又悄悄跑偏了方向，悄悄變成另一個誰都沒同意過的版本。
iThome鐵人賽
看影片追技術