錯誤一：用錯誤的單位描述目的地
在建構聊天中,最浪費回合的原因來自瞄準錯誤的高度,而且方向恰好相反。有些人要求的比自己想要的少──「改善設計」、「讓它更好」、「這感覺還不太對」。這些都是沒有目標的診斷,所以下一個版本只能靠猜:它可能加深頁首顏色,可能換字型,可能重新排列導覽列,而你要等到看到結果才知道究竟發生了什麼事。另一些人則矯枉過正,要求的比應該給的還多──他們指定了 session cookie,或是 CSS grid,或是載入骨架元件,因為他們略懂一二,想幫上忙。這種失敗比較安靜,但代價一樣高。一旦你指定了實作方式,通常就已經指定錯了,或者頂多把解決方案的範圍縮小到你個人已經知道的那些──除非你是專業開發者,否則這個範圍會比建構者自己嘗試的還要窄。而且如果你指定的函式庫或模式最後證明是錯誤的選擇,那就變成你引入的錯誤,一個建構者從結果出發原本永遠不會犯的錯誤。
解方就在這兩種失敗模式之間:說出你正在看的東西,以及你想看到的改變,而不是產生它的機制。「訪客應該不用建立帳號就能預約」勝過一整段關於 session cookie 的說明,因為你真正想要的是消除那個摩擦點,而達成的方法可能有三種你根本沒想過。「價格表令人困惑」單獨來看還是太薄弱──哪裡令人困惑?──但「使用者看不出年繳方案比較划算,把折扣放在價格旁邊,而不是埋在小字裡」就給了建構者具體可以依循的東西。如果你不知道修正後應該長什麼樣子,那也沒關係;說出哪裡有問題,讓它提出形狀。行不通的是沒有錨點的模糊不滿,因為那會讓接下來的每個版本都變成猜謎遊戲。
| 與其這樣說…… | 不如這樣說…… |
|---|---|
| 「改善一下」 | 「主視覺文字在照片上很難閱讀──提高對比度」 |
| 「修一下遊戲手感」 | 「跳躍飄浮感太久;讓它更俐落一點」 |
| 「隨便加個驗證機制」 | 「玩家需要帳號才能保存分數」 |
| 「讓它快一點」 | 「圖庫頁面載入圖片時會停頓一下,顯示佔位圖而不是空白畫面」 |
| 「這個區塊不好」 | 「推薦見證區塊看起來像是隨便加的──讓它和價格區塊有一樣的份量」 |
錯誤二:對摘要做出反應,而不是實際查看
第二種常見的失誤,是針對聊天對變更的摘要做出回應,而不是針對實際的變更。有人讀到「把行程表移到獨立頁面,並加深頁首顏色」,腦中形成一個畫面,然後針對這個畫面而不是實際網站寫下意見回饋。多數「這裡做錯了」的抱怨,最後其實是「我還沒打開預覽」──結果其實沒問題,或接近沒問題,反對意見其實是針對一個假設。點開預覽再打字大概只要花三十秒,省略這一步是不必要回合數最大的來源。就算是在會議中用手機審閱,也先瞄一眼預覽──針對「描述的描述」給意見回饋,誤差會迅速累積。
相關的錯誤是把不相關的請求捆綁在同一則訊息裡,導致無法判斷究竟是什麼造成了什麼。你完全可以把好幾個要求疊在一起,一次拿到全部結果──一次同時修好頁首、搬動行程表、收緊行動版導覽列的建構,審閱起來比三個各自獨立的差異要容易,因為你是在評估網站的一個連貫狀態,而不是三個對照移動目標的變化。問題出在請求彼此不相關的時候。把行程表頁面的全面改版和全站色彩變更捆綁在一起,如果結果感覺不對勁,你根本無法判斷是哪個變更造成的──是頁面因為新版面而難以閱讀,還是因為新的配色?釐清這一點需要再發一則訊息,再跑一整輪才能孤立出變數。把「行程表頁面的所有事項」放在一則訊息,「色彩方向」放在下一則,即使沒有什麼阻止你把它們合併;每個版本都保持乾淨可比對,你可以還原或調整需要調整的那一項,而不必因為某個部分沒做好,就丟掉整個原本不錯的版本。
錯誤三:把每個版本都當成用完即丟
第三種錯誤是忘記版本卡片不是收據,而是一個可運作的物件,結果略過了它實際提供的東西。每個完成的回合都會產生一張卡片,附有可即時運作的預覽──是實際運行中的實例,不是截圖,所以在裡面按下按鈕的效果,跟在正式環境按下去一樣。還有一個程式碼分頁可以瀏覽每個變更過的檔案,如果你有足夠技術背景想抽查特定內容(這個表單真的送到正確的端點了嗎?),不用等聊天回覆確認,這就很有用。下載讓你取得原始檔案。而操作選單則是版本不再只是草稿的地方:發布上線、如果是應用程式就建構原生安裝檔、上架到商店、把整個東西存成範本供未來建構使用,或獨立部署。
略過這一切的人,最後會試著回想舊版本的按鈕是不是藍色的,而不是直接打開舊版本看──因為把卡片當成用完即丟的後果正是如此:對明明還在一鍵之遙的東西依賴記憶。版本 4 不會在版本 7 上線時被封存或凍結。它的預覽仍然在運行,程式碼分頁仍然可以瀏覽,操作選單仍然可以使用,而且永遠都是這樣。比較兩個版本不是讀差異表的練習,而是同時打開兩個預覽,在各自裡面點來點去。卡片還帶有這個建構的驗證紀錄──那是在交付給你之前,確認它確實可以運作的自動化檢查──而且是針對該特定版本的,這也是舊卡片保持存活很重要的另一個原因:如果版本 6 驗證乾淨而版本 7 沒有,你有兩者可以比對,而不是只有一句「修好了」的聊天訊息要你相信。
同樣「把工作流程當成可以略過而非使用」的傾向,也表現在忽略每次建構後聊天所提出的後續建議上。這些建議並非泛用的填充內容;它們是從建構本身歸納出來的,所以往往能抓到你自己審閱時會漏掉的東西:沒人設計過的空狀態、沒有確認送出的表單、在桌面版沒問題但在行動版擁擠的頁面。採納它們並非必要,但瀏覽一下不花什麼成本,而且如果你沒時間親自點過每個頁面,它們是相當合理的品質檢測替代方案。
