设计纲要是一份描述设计问题和为目标、原则和需求奠定基础的文档。在确定设计问题和方向这样的项目初期起作用。
9.1 优秀设计纲要的组成部分
9.1.1 清晰的阐述问题
可以用一句话来概括设计目标，但是设计港沿需要包含更多要求、约束、目标等信息。可以使用图表：站点地图、流程图、概念模型、人物角色等。
9.1.2 用范例支持陈述
设计纲要阐明问题并概括预期的解决方案。为读者提供一些可参考的切实内容。
1、范例的来源--值得参考的其他权威站点、其他类型的产品、其他项目或者生活经验
2、使用范例--一个陈述多个范例、一个范例多个陈述等等都可行
9.1.3 可追溯性
早期的设计决策会影响后期的设计决策，这些决策有层级结构。
1、每个设计决策都能追溯到一个设计目标。有些需求来源于外部因素或者约束，会产生看似随意反直觉的设计决策，这些决策也可以影响项目的成功与否。需要提供决策的相关基本原理。
2、对早期材料进行编号，方便引用，引用的时候除了使用编号还要简单的描述下内容。
9.1.4 明确指出界限
界限能使工作务实，避免无休止的讨论。阐释界限的典型方式是-时间和特性
1、进度表--根据目标和期限限定能做的事
2、特征--识别团队要解决问题的哪些部分。带有优先级的特征列表是一个好起点。1）使用屏幕--评估工作量。2）通过用户场景--场景的复杂性、相关性、输入、输出、结果 --评估工作量。（用屏幕数量来评估工作量和工作时间貌似更准确。）
3、额外的约束--哪些成员能参与项目等后勤约束、企业文化约束
9.1.5 计划
设计纲要应该描述项目团队实现目标的具体计划。比一定囊括所有的最后里程碑。包含：活动内容、交付件、人员。（和项目开发计划差不多）
9.1.6 不断完善
要提炼并详述愿景和原则，来提供更具体的设计方向。方法：文档结构支持改动、文档的内容是有用的。
（omnigraffle中的变量能支持改动文档结构）
9.1.7 奠定项目基调
项目纲要的正式程度、结构和完善对项目团队的沟通方式设计了期望和标准。帮助进行项目管理。
（文档写的条理清晰，大家才容易当回事，而不是忽视。按照这本书写的工作内容，其实设计工作和现在的产品经理、项目经理的工作范围是有很大交集的。）
1、考虑显示工具
2、范例：展示进展汇总表
9.1.8 工作量要适度
设计纲要的工作量要适度，影响因素：目的、总体预算（工时）、输入、预计的价值。
工作量投入时间的合理起点是总体设计预算的20%。搞了影响后续工作，少了会没时间思考。（看来我给自己留的思考时间少了点）
9.1.9 交流优先级
利用文档的布局和结构来暗示相对重要性。（比如位置、颜色等）
9.1.10 展示设计纲要的技巧
1、预先就概念达成共识--先编写纲要目录，与相关人员进行讨论，收取反馈，然后开始写设计纲要。
2、谨防自以为是--在会议中，将自己的设计理念为起点，跟人讨论构造设计余下的部分。从设计理念出发看待设计问题。利用设计历年来验证项目目标。
3、不要缩减后勤开支--花时间在描述范围、活动、交付件以及和其他成员的讨论上。
9.2 设计纲要解析
设计纲要的内容是推动设计项目的一系列原则。
9.2.1 组织设计纲要
9.2.2设计目标、主题与原则
一套原则可以确定设计方向，他们为项目的远景目标提供不同视角。设计方向为设计者提供灵感和建议。
需要考虑的事项：分类、优先级、语言（命令行动词）、草图、远景目标陈述
9.2.3设计的上下文与范围
确定范围，避免越界。定义界限时要考虑：特异性、来源、权重。
9.2.4 设计理念
指出设计方向。保持最小工作量，逐步验证自己的理解，尽早让项目团队参与进来。
设计理念应该帮助读者了解：体验、设计挑战、范围。
如何防止设计理念失控：重点集中在一个屏幕上、保持草图性质、避免死守某个特定方向
9.2.5 需求摘要
提取主题、使用祈使句、从用户角度进行表达。
9.2.6 约束摘要
约束多半是技术性的，也可能是操作性的、后勤方面的。知道它们来自哪里以及影响。
设计过程中会出现新的约束，要能跟踪约束，并保持更新。
9.2.7 项目进度表
设计纲要除了定义项目目标，也需要支出实现目标的项目计划。可以使用甘特图来描述活动和结果。
甘特图包含：有意义的时间线、程度适当的细节、外部输入、参与承诺、相关外部因素
9.3 单页幻灯片的挑战
能在一页总结目标、远景目标、方向、约束、方法。方便涉众打印出来放在醒目位置，时时提醒。
