s90|有了这些产品设计文档，我再也不用背锅了( 二 )

二、产品设计文档（The Product Design Doc）产品设计文档（PDD）将你要解决的问题、场景和最终解决方案转换为基于迭代或阶段的方法。
这意味着你可以将整个设计过程归档到一个单独的文档里，并将它分享给同事，从而为你的设计方案提供强大支撑。这听上去是不是很酷？来，让我们讨论一下细节。
1. 内容总览一个产品设计文档需要包含 4 个重点内容：元数据、背景、阶段、反馈。

文章插图
（1）元数据（用来描述数据的数据）是关于文档的基本信息，例如标、日期、状态等。
（2）背景可以帮助其他同事理解你的设计方案，你需要像考虑描述、问题、概要或你要实现的目标一样考虑它。
（3）阶段是指设计的迭代过程。一般来说，一开始会更关注整体解决方案，在之后的迭代阶段中会越来越注重细节。每一次迭代都会基于上一次的成果和他人的反馈做调整。这是一种达成最终目标的结构化方法，已解决的问题不会重复出现。
（4）反馈指的是所有从其他人那里收集到的观点、意见、要求和建议。你可以从利益相关者及队友那里获得反馈。
基于这四个要点，你就可以创造不同的产品设计文档来适应你的需求。每一个公司、项目都是不同的，也许这适用于我，但不一定适用于你。但是如果你的产品设计文档包含了这四个要点，大概率能适用于任何情况。
2. 案例结构在理解了要点之后，我会把我在这个公司工作时使用的产品设计文档结构分享给你。它包含了以下这些内容。

文章插图
（1）标题应当简洁明了，并且易区别于其他已有的产品设计文档。
（2）文档状态需明确展示，例如以下文档状态：草稿：还处在明确设计背景的阶段中，还不能收集反馈；S30 / S60 / S90：设计方案中前后阶段之间，设计方案的不同完成进度（30% / 60% / 90%）；已完成。
（3）项目概要是对你的设计需解决的问题的描述，通常可以链接到其他有用的相关阅读材料。
（4）设计目标是你在设计过程中最需要关注的一些问题，它可以以列表的形式存在，同时你需要时常查看它，以确认你处于正确的方向及阶段上。
（5）S30（完成 30%的阶段）所展示的产品设计文档应该包含基于项目概要和设计目标所做的初版设计方案，它应该关注大致设计方向，而非细节。也许提供一个低保真框线图或者类似的竞标产品就足以了。
这个阶段可能会产生很多完全不同的方案，并收到一些重大反馈。
（6）S60（完成 60%的阶段）所展示的产品设计文档，是基于前一阶段收集到的反馈问题，完成设计方案的60%。比起 S90 的产品设计文档，本阶段的文档可以粗糙一点，但是需要明确方案的内容。
你需要提供高保真线框图，以及不同页面状态和一些流程设计。在这个阶段你收集到的反馈，很大可能是关注在是否有状态及页面的缺失。
（7）S90（完成 90%的阶段）所展示的产品设计文档，是基于前一阶段收集到的反馈，提升方案完成度到 90%。这个阶段将会关注你的设计细节，包括所有不同的页面、支线状态、视觉设计，甚至是高保真设计稿。在这个阶段，你期望会收集到一些不是很重要，不会影响到主要设计方案方向及流程的反馈。
你可能会问自己，我需要完全遵循这个阶段命名规范吗？不，并不是的。你可以重新命名这三个阶段为：探索 – 提案 – 解决方案。
你也可以改变这个产品设计文档状态的排列顺序：首先展示 S90 的解决方案，最后展示 S30 探索的内容。