8-12章是本書的第二部分：設計交付件
交付件與工件（圖表）的關系：
在項目實施過程中，作者撰寫一個文檔（設計規范），而不是多個文檔，并進行版本迭代。便于維護、持續性等。
8.1 優秀交付件的組成要素
易于理解、相關性、可行性
8.1.1 優秀的交付件要言之有物
1、主題--交付件本身要有首要主旨比如項目面臨的挑戰、新的視角、設計中的難點和解決方案等。交付件也要有目的，比如交流設計理念、獲取反饋、加速決策過程等。
2、開始、中間和結束--確認之前的工作進展、新版本交付件的改進、下一階段設計行為。（現在我使用的模板缺少確認之前的工作和明確下一階段的工作）
3、沖突、對比和比較--交付件可以使用的對比方法：時間、不同方法、沖突優先級、需求的二義性。（？）
4、人物--確保工件之間使用同一種可視化語言，基于同樣的假設，為同樣的目標努力。試著把工件看成“人物”。
5、設計文檔中的故事講述--確保從未接觸項目的人，能夠通過文檔了解項目的狀態、主題、設計決定、面臨的問題（我的模板里缺少面臨的問題，設計決策與活動的關聯）
8.1.2 優秀的交付件要鼓勵對話
以下為鼓勵對話的技巧：
1、目錄
2、明確的問題--交付件的有問題工件旁邊、文檔開頭、結尾列出。這些問題分為：闡明設計問題、找出差距、對方法進行驗證。
3、決策--需要決策時候：列出選項、描述每個選項的含義、提供建議。
8.1.3 優秀的交付件是注重實效的
確保交付件的可行性：使用命令口吻、使用關鍵摘要作為文檔的前言、給每頁文檔都明確指定一個目的或者結論。
文檔除了主題，還要帶有目的。
8.2 交付件的剖析
1、容器假設--工件的容器和注釋等 ? 2、格式假設--多頁文檔
交付件可以打破以上假設。
8.2.1 主題頁面和其他標識性元素
主題頁面：客戶、項目名、交付件名、作者、交付日期、版本
可根據需要選擇使用2.1 還是整數的版本號。也可以選擇寫上日期、deadline等
文檔元數據--背景、文檔變量-頁碼等、創建可視的層次結構（相當于模板之類的吧）。
8.2.2 前頁
1、版本歷史--版本編號、日期、作者、改動內容和理由。除了整個文檔的歷史，每個頁面也可以有微型歷史、版本注釋
2、目錄--反應文檔的結構
8.2.3 摘要
文檔的第一個內容頁要作為摘要的存在，描述文檔重點、總結觀察結論、列出要詢問涉眾的主要問題。尤其是在評審會議上，要保證能5分鐘內，向涉眾交代完文檔重點。
8.2.4 簡介與上下文
簡介不需要“5分鐘內了解內容”，注重“我想告訴大家什么內容”。
1、以章為單位進行簡介
2、基于項目的簡介--進度
（有項目管理的感覺）
8.2.5 章
1、劃分章的結構--劃分結構技巧：花點時間思考、支持什么主題和目標、畫圖、與內容合作者商量、向文檔使用者展示圖片、為以后的內容留出空間
2、明確結構--可使用內容占位符、能根據實際情況的變化進行調整、為項目團隊設定期望
3、章涵蓋封面內容表--章也可以有簡介
8.2.6 后續步驟
文檔以后續步驟結尾，說明從這里到下一步驟的理由。
后續步驟可以是：驗證活動、詳細闡述、方向性決策選擇
好的后續步驟要素：有人負責、可測量有限制、具體
后續步驟的迭代要寫進文檔。
8.2.7 最終產品
8.3 頁面布局
8.3.1說明性頁面
說明性頁面詳細說明了一個設計工件的詳細情況，使用注釋指出重要元素并描述細節。
8.3.2 評價性頁面
提供對設計工件的批評，還有嚴重性或優先級。在競品分析和專家評審中有用。評價應該給出一個關鍵的結論，基于評價提供見解。
8.3.3 介紹性頁面
介紹應該提供一種概況，將大范圍的內容縮小顯示。介紹指出重點和主要里程碑，將詳細內容聯系到較大主題或者消息上。（本頁面在項目中的相關內容）
8.3.4 比較性頁面
適合競品分析和比較設計方案。顯示解決相同設計問題的多種方法，強調優劣，并得出結論?？梢杂糜诳捎眯詼y試。
8.3.5 決策頁面
決策頁提出問題，提供足夠的信息尋找答案，并為做決策提供標準。
8.4 展示交付件
簡單的同事評審將有助于避免以自我為中心的交付件。
展示交付件與展示工件的基本框架相同：
8.5 交付件的生命周期
判斷交付件成熟度的標準：內容與占位符的比例、與項目計劃的關系、為項目目標服務。
8.5.1 構思：文檔開發
與將要合作編寫文檔的人們一起討論。找出總體結構（目錄）和將在每節中使用的頁面布局。
8.5.2 誕生：首次亮相
新文檔的初始版本應包含：可能性、體現計劃保持、說明挑戰限制和參數
8.5.3 青春期：仍然需要繼續成熟
執行先前版本的結論，驗證反饋，指導下一版本的內容。
8.5.4 成熟期：所有內容出現
所有占位符被實際內容取代。仍然可以新加內容和更新。
隨著項目的進展，有些內容會漸漸不被當前項目階段重點關注，這些內容的總結保留下來，詳細內容可以刪掉，從而把重點放在新的內容上。
8.5.5 生命結束：束之高閣
設計不更新設計文檔，有可能團隊其他環節的成員需要查看。
8.5.6 維護：保持健康
維護更新的內容：實現過程中的設計改動、實際過程中文檔不夠、產品中的更新。
可在項目啟動會上問清楚 ?誰是使用文檔的人們 ，維護文檔的人等等。
8.6 交付件的未來
形勢不重要，內容要包含：產品、涉眾、組織上下文、方法趨勢
重點始終是產品和用戶。
