2.1.錐體中的箭頭進一步螺旋。
2.2.您現在更加確定自己了解問題空間。
2.3.您的原型為您的解決方案提供了越來越多的信心。
2.4.每次迭代時，設計文件都會變得更加清晰和詳細。
3.1.當被要求對系統進行更改時，大多數入門級工程師會直接進入編碼階段。
3.2.技術設計過程可以幫助每個人就大改動的設計達成一致。
3.3.正確完成、參與和領導技術設計工作是有益和有價值的。
3.4.個人、深思熟慮和協作的小組討論。
3.4.1.研究、頭腦風暴和寫作構成了深入的工作。
3.4.1.1.外界干擾是深度工作的“殺手”
3.4.1.2.避免一切形式的交流。
3.4.1.2.1.關閉聊天。
3.4.1.2.2.關閉電子郵件。
3.4.1.2.3.禁用通知。
3.4.1.2.4.坐在不同的地方。3.4.2.設計討論和對設計文件的評論構成了協作的一部分。
3.4.2.1.有形的輸出是設計文件。
4.1.設計漏斗的基礎始於探索。
4.1.1.在開發設計解決方案之前，您需要了解問題空間和要求。
4.1.2.探索既是一項個人運動，也是一項團隊運動。
4.2.定義問題。
4.2.1.第一項任務是定義和理解要解決的（或那些）問題。
4.2.2.你需要知道問題的邊界，這樣你才能知道如何解決它，並避免構建錯誤的東西。
4.2.3.用你自己的話向利益相關者重新表述問題，詢問你的理解是否與他們的理解一致。
4.2.3.1.如果有多個問題，請詢問哪些問題是最高優先順序的。
4.2.4.乙個完善的問題描述將導致乙個完全不同的解決方案，工程師可以專注於並優先考慮。
4.3.開始調查。
4.3.1.不要只是從問題定義過渡到“最終”設計。
4.3.2.考慮相關研究、替代解決方案，並權衡每個選項的利弊。
4.3.3.你提出的設計不應該是你的第乙個想法，而是你幾個想法中最好的。
4.3.4.網上有很多資源可以了解其他人如何解決類似的問題。
4.3.5.行業會議是另乙個需要檢查的資源，幻燈片或錄音通常在網上發布。
4.3.6.不要忘記學術研究，並使用**末尾的參考文獻部分來尋找更多閱讀材料。
4.3.7.與您正在探索的問題領域的專家交談。
4.3.7.1.在與外界交流時，請注意不要洩露公司的專有資訊。
4.3.8.批判性地思考。
4.3.8.1.乙個特別常見的錯誤是複製與您的問題相似但不完全相同的解決方案。
4.3.8.2.你的問題不是谷歌的問題（即使你為谷歌工作），即使它們看起來很相似。
4.4.進行實驗。
4.4.1.實驗將使您對自己的想法充滿信心，揭示設計權衡，並澄清問題空間。
4.4.2.不要沉迷於你的實驗**。
4.4.2.1.你需要盡可能多地學習，盡可能快地習。
4.5.給我一些時間。
4.5.1.好的設計需要創造力。
4.5.2.設計需要深思熟慮。
4.5.3.你不會在你被鎖定的整個時間段內“設計”
4.5.3.1.你的大腦需要時間來放鬆。
4.5.3.2.休息一下，給自己喘息的空間。
4.5.3.3.讓你的思緒放鬆和徘徊。
4.5.3.4.散步，泡茶，閱讀，寫作，繪畫。
4.5.4.設計是一項一天 24 小時都在進行的工作，所以要有耐心。
4.5.4.1.你的大腦總是在醞釀想法，創意在一天中隨機出現（甚至在你睡覺的時候）。
4.5.5.簡單的設計方法並不意味著你可以永遠這樣做。
4.5.5.1.Design Spike 是管理創意工作和可交付成果之間緊張關係的好方法。
4.5.5.1.1.Spike 是極限程式設計 （XP） 的術語，指的是有時間限制的調查。5.1.大綱。
5.2.現狀和背景。
5.3.更改的目的。
5.3.1.軟體團隊通常擁有比他們同時可以處理的專案更多的專案。
5.4.需求。
5.4.1.以使用者為導向的需求。
5.4.1.1.更改的性質是從使用者的角度定義的。
5.4.2.技術需求。
5.4.2.1.包括解決方案必須滿足的硬性要求。
5.4.2.2.技術需求通常是由互操作性問題或嚴格的內部準則引起的。
5.4.2.3.還可以在此處定義服務級別目標。
5.4.3.安全性和合規性要求。
5.4.3.1.明確討論了確保安全的必要性。
5.4.3.2.此處通常包含資料保留和訪問策略。
5.4.4.其他。
5.5.潛在的解決方案。
5.5.1.編寫本節對您和您的讀者來說都是乙個工具。
5.5.2.目的是迫使你不僅思考你的第乙個想法，還思考其他想法以及它們之間的利弊。
5.5.3.描述合理的替代方案以及您拒絕它們的原因。
5.5.4.描述乙個潛在的解決方案將預先解決“為什麼不呢？評論。
5.5.5.如果您出於錯誤的原因否定了解決方案，審閱者就有機會找到錯誤，甚至找到您沒有考慮過的替代方案。
5.6.建議的解決方案。
5.6.1.描述已確定要採用的解決方案。
5.6.2.比概要中的簡要說明更詳細，並且可以包括突出顯示更改的圖表。
5.6.3.如果您的提案包含多個階段，請說明解決方案如何從乙個階段進展到另乙個階段。
5.7.設計與建築。
5.7.1.系統組成圖。
5.7.2.UI UX 更改。
5.7.3.*改變。
5.7.4.API 更改。
5.7.5.持久層更改點。
5.8.測試計畫。
5.8.1.不要提前定義每個測試，但要說明你計畫如何驗證你的更改。
5.9.發布時間表。
5.9.1.描述用於避免複雜部署序列的策略。
5.9.2.記錄需要設定的功能開關，以控制新版本的部署。
5.9.3.想一想你將如何確定你發布的更改是否生效。
5.9.4.發現問題時如何回滾。
5.10.遺留問題。
5.10.1.清楚地列出設計中尚未回答的緊迫問題。
5.10.2.徵求讀者意見並解釋您的“已知未知”的好方法。
5.11.附錄。
5.11.1.新增更多有趣的細節。
5.11.2.新增相關的工作參考。
5.11.3.進一步閱讀。