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 比较性页面
适合竞品分析和比较设计方案。显示解决相同设计问题的多种方法，强调优劣，并得出结论。可以用于可用性测试。
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 交付件的未来
形势不重要，内容要包含：产品、涉众、组织上下文、方法趋势
重点始终是产品和用户。
