事件
2004 年，英國設計協會（British Design Council）在觀察了多家頂尖設計機構的工作流程之後，歸納出一個幾乎所有成功設計都共享的結構——Double Diamond（雙鑽石）。這個模型看似簡單：Discover → Define → Develop → Deliver。但它最深刻的洞見，不在於四個步驟，而在於「為什麼要做兩次」。
兩顆鑽石解決兩種不同的錯誤
人類面對問題有一個根深蒂固的認知偏誤：解題的衝動遠強於理解問題的衝動。拿到一個需求，大腦馬上開始生產解法，而不是先質疑需求本身是否正確。
雙鑽石強迫你克服這個偏誤，把設計過程切成兩個完全不同的挑戰：
第一顆鑽石——解對題目 - Discover：放大視野，進入 problem space 的野外探索。不預設問題的形狀，觀察使用者、收集資料、讓意外的訊號進來。 - Define：收斂至一個精確的 problem statement。這一步的品質決定後面所有工作的方向性。
第二顆鑽石——用對方法 - Develop：在已確認的問題框架內，盡可能探索解法空間。強迫生成多種 alternative，不讓第一個 idea 直接晉級。 - Deliver：收斂至可執行的方案，迭代測試、優化、出貨。
這兩顆鑽石分別對抗兩種致命錯誤：第一種錯誤是解錯題（doing the right thing wrong）；第二種錯誤是只做第一個想到的解法（doing the wrong thing efficiently）。
跳過鑽石的代價
歷史上充滿了跳過第一顆鑽石的案例。
Kodak 的工程師在 1975 年其實已經發明了數位相機，但公司的問題定義框架是「如何賣更多底片」，而不是「人們真正想要什麼樣的記憶保存體驗」。他們在第二顆鑽石（如何製造更好的底片）上做得極為精良，卻從未認真走過第一顆鑽石，重新定義問題。
Segway 被發明者 Dean Kamen 認為會「取代汽車」，但實際問題定義階段若更嚴謹，會發現都市交通的真正障礙不是短途移動工具，而是基礎設施、停放空間與使用者習慣。Segway 在第二顆鑽石（工程執行）上無懈可擊，第一顆鑽石卻幾乎是缺席的。
跳過第二顆鑽石的案例同樣常見。微軟在 2000 年代中期推出的 Zune，定義了正確的問題（對抗 iPod 的市場），卻在 Develop 階段直接複製 iPod 介面邏輯，沒有探索差異化的解法空間，最終在「正確問題」上給出了「第一個想到的答案」。
Atomly 的現場課
這個原則在 Atomly 自身的產品迭代中留下了具體印記。v0.4 的 bug fix 階段，面對 Counter View 的視覺化問題，團隊直接跳入 Deliver——ship 了第一版 hard-coded SVG 方案。這是典型的「跳過 Develop」：問題定義是對的（Counter View 需要結構化視覺呈現），但沒有 generate alternative，第一個 idea 直接變成唯一 idea。
後來 viz JSON 的多型化重構，本質上就是補做了 Develop 階段——探索不同的資料結構方案，最終選出更具彈性的架構。代價是：本可以在第一次就做對，卻變成了技術債再還。
實務啟示：任何設計決策前，強迫自己 generate 至少 3 個 alternative，但要設定 timebox（例如：30 分鐘的發散，不能無限 explore）。 發散不是目的，是確保收斂品質的手段。
雙鑽石的更深層邏輯
雙鑽石背後隱藏的哲學，是對「第一直覺」的系統性不信任。
認知科學告訴我們，人類的 System 1 思維極善於生成「夠好的答案」——但「夠好」往往是「局部最優」的偽裝。雙鑽石是一個強制啟動 System 2 的流程設計，在每個收斂點之前，都強制插入一段「我可能是錯的」的緩衝區。
這也是為什麼雙鑽石不只適用於產品設計，它適用於任何需要做決策的場景： - 醫療診斷：先 Discover 所有症狀 → Define 真正病因（而非第一個看到的症狀）→ Develop 多種治療方案 → Deliver 最適處置 - 商業策略：先 Discover 市場訊號 → Define 真正問題 → Develop 多種戰略選項 → Deliver 資源配置 - 個人決策：先 Discover 自己真正的需求 → Define 真正的問題 → Develop 多種人生路徑 → Deliver 選擇