原章：The Keyboard Derby
2005 年秋天，iPhone 仍以祕密代號 Purple 開發。當時市場上的智慧型手機以 BlackBerry 的實體鍵盤為代表，而 Apple 已把產品方向押在大面積觸控螢幕上，沒有預留一套實體鍵盤作為退路。
問題是，軟體鍵盤一直做不好。一次 Demo 裡，Scott Forstall 甚至連自己的名字「Scott」都無法順利打出來。管理層因此做出罕見決定：暫停約十五名 Purple 軟體工程師原本的 Safari、Mail、SpringBoard、Notes 等工作，所有人暫時變成「鍵盤工程師」。
團隊迅速做出大量原型：縮小版電腦鍵盤、不同字母配置、類似摩斯密碼的點滑組合，甚至像鋼琴一樣同時按多鍵的版本。Ken 自己也做了五個，但全部丟棄。
Richard Williamson 給了最關鍵的早期批評：大家的按鍵都太小。Ken 接受後，開始做大按鍵、每鍵包含多個字母的方案。但新的問題隨即出現：若不同字母要用點、滑、長按等不同手勢輸入，使用者每打一個字都必須思考操作方式，認知負荷太大。
Ken 最後保留幾個學到的條件：大按鍵較容易按；重新排列字母很糟；QWERTY 的熟悉度有價值；手勢應盡量單純。於是他做了一個「大按鍵＋QWERTY 邏輯＋只需點擊＋字典協助」的版本，讓軟體去猜使用者真正想輸入的字。
| 故事節點 | 嘗試 | 失敗／發現 | 留下來的判斷 |
|---|---|---|---|
| 全員鍵盤競賽 | 大量不同輸入模型 | 多數有創意但不容易快速準確輸入 | 創新不能只看新奇程度 |
| Ken 前五版 | 不同造型與手勢 | 全部不夠好 | 失敗原型仍能累積設計條件 |
| Richard 的大按鍵 | 一鍵多字母 | 比較好按，但手勢與字母配置增加認知負荷 | 降低操作負擔比單純加大按鍵更重要 |
| Ken 新版 | 只點擊，由字典推測意圖 | 軟體開始承擔原本由使用者承擔的判斷 | 讓電腦替人處理複雜度 |
這是一個真正沒有既定答案的設計問題。大家知道「必須有觸控鍵盤」，卻不知道它應該長什麼樣。此時如果只開會討論，很容易讓聲量、職位或抽象論點取代真正使用經驗。
Apple 讓想法變成 Demo，再讓 Scott 一個一個實際使用。Ken 因無法把自己的字典程式整合進共同 Demo 工具而被排到最後，甚至差點沒有展示機會；他最後主動喊出自己還有一個版本。
Scott 試著快速輸入自己的名字，Ken 的軟體成功從模糊按鍵組合推測出正確結果。Scott 接著連問一串字典、機率與按鍵設計問題。Demo 後不久，他決定讓 Ken 成為鍵盤 DRI，其他人回原專案。
這個版本還不是最後出貨的 iPhone 鍵盤，但它像前面的 Black Slab 一樣，確立了新的方向：觸控輸入不能只要求人更精準，軟體必須主動理解人的意圖。
Ken 把整個競賽看成 Apple 創意選擇的典型：做具體原型、彼此試用、直接批評、保留強的部分、丟掉弱的部分，再做下一版。
當領域還沒有答案時，好的團隊不是假裝先有完整方法論，而是建立一個讓多種可能性快速變成可比較實物的環境。