有了这些产品设计文档，我再也不用背锅了！

编辑导语：你是否曾经也为别人的错误决策背过锅？如何才能够更加严谨，且保持自己的初心去做设计呢？本篇文章中，作者向我们详细介绍了产品设计文档，讲解了如何正确维护它，推荐想要学习更加系统管理自己设计的群体阅读。

你是否曾为设计方案的通过而努力？你是否想要让自己的设计流程更加规范化？新冠肺炎带来的远程工作模式是否给你造成了一些麻烦？这篇文章将教会你如何管理你的设计文档。

公司或者初创企业中的产品设计师标准工作流程对你来说可能非常熟悉：开发一款新产品首先需要提供设计解决方案。完成设计提案后你需向 1-3 个人阐述你的提案，并获取反馈。

有时候这些工作能很好完成，有时则不然。举个例子，有些人大部分的时间都花费在如何完成自己的工作上，因此没有足够的时间对你的设计提案提出清晰简洁的反馈。

特别是在新冠疫情爆发期间，我们不得不进行远程工作，即使你的工作完成得足够完美，你也希望记录下每一步的设计决策，持续追踪迭代并继续优化设计，从而规范化设计工作流程。这些事情会经常性发生。

记录设计过程有很多的好处。举个例子，这能可视化你的工作内容，创造更多获得他人反馈的机会，加强整体沟通效率， 清晰地描绘出这些设计要点是通过什么样的设计思路被创造出来的 ，以用这些设计要点可以解决哪些产品需求等。

一、英雄设计师的失败（The Fall Of TheHeroDesigner）

2018 年左右，我作为一名远程产品设计师，在马德里为一家拉丁美洲的公司工作，我们的团队里还有来自墨西哥、圣保罗和巴西的成员。

在我开始为这家公司工作以前，我有过很多不同领域的工作经验，包括新媒体、设计工作室、社交网站、移动操作系统、成立在线零售公司等等，甚至从小型创业公司接一些自由职业者的工作。

这些年我始终遵循着相同的工作方法。提出方案，被一些人选择，提供一些界面、流程，获取反馈，然后再提出方案。在多次迭代之后，方案才能进入开发阶段。

然而，这些极为相似的方法现在没办法达成目的了。在加入这个团队不久后，我就意识到，通过电话会议提出想法是不够的。我设计了很多提案，但是我没办法从老板和队员那里得到认可和通过。

我感到非常迷惑，我不停地问我自己：发生了什么？是不是因为我没有设计出最好的方案？是不是因为我没有提供高质量的工作内容？所有的问题都在一遍又一遍地打击我的自信心。

问题在于我应该使我的工作流程更加适用于周遭的环境 。

当我意识到了我之前的工作流程是不适用的，我便开始阅读大量关于如何成为一个远程设计师的文章，例如海鸥效应（当有人进入你的工作时，你会严厉批评它，然后让它飞走）相关文章，其他公司如何处理远程协作的相关文章，以及他们如何规范流程并记录下来。在读过所有这些材料后，我想知道开发者如何面对同样的问题。

Pull 请求（开发者之间的一种协作功能） 允许你记录每一次更改 ，从而在更大的代码库中引入更改， 并使用其他人的反馈来验证你的决策 。

从这个角度来说，这个由你提出的改变将完美地结合已有代码的固定点和其间链路。这就是我需要达到的，当然，是以一种流行的设计方式。接下来我将介绍，什么是产品设计文档。

二、产品设计文档（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 探索的内容 。

3. 模板

从 Paper、Notion、谷歌文档或是实际生活中遇到案例中选一个来做模板。记住： 每个模块的命名习惯完全可以按照你自己的习惯来 。

如果你不喜欢用项目概要这个词，你可以用需求这个词，或者是其他更加贴近于此内容定义的词。你需要保留的主要概念是创建不同的阶段，从而使你得以专注于每个阶段，你可以将 S30 命名为探索，将 S60 命名为提案，将 S90 命名为解决方案。

三、使用产品设计文档的主要好处（Keybenenfitsofusingpdd）

1. 每一个决定都被记录

这意味着即使你离开了这家公司或这个项目组，所有的相关信息都会永远留在公司里，当有人来接手时，他可以从你留下的设计方案中了解项目，更好地继续完善它。

2. 加强沟通

产品设计文档将会收集所有团队成员的反馈，这使得每一个人都对项目了如指掌，并了解到方案是如何被决定的。

3. 限制利益相关者永无止尽的修改欲

在每一个设计阶段，我们关注问题的角度不同，逐渐明确设计方案。这样一来，人们就可以一次专注于单个问题，从而帮助他们收束发散的思维，提升专注力。

4. 产品设计是通过合作完成的

与让利益相关者直接决定的解决方案不同，我们让工程、设计和其他团队参与解决方案的制定，使其成为方案解决的合作者。

四、写在最后（ Finalnotes）

结束了远程办公时遇到的项目，我可以继续在这里工作一些时间，以保证我可以完成至少 5 个项目的产品设计文档。我的挫败感大大减轻了，我能够让大家就我的设计方案达成共识，从而使产品继续迭代。因此，这个公司大大地得到了提升，而且我在那段工作时间内设计的方案现在也依然在被使用。

p.s. 我在 2019 年开始写这篇文章，在 2021 年我看到 Abstract 正在开发一款用来管理设计流程的产品，所以我决定把之前这篇文章写完。看来这还是一个很前沿的话题啊。

本文翻译已获得作者的正式授权（授权截图如下）

原文：https://www.smashingmagazine.com/2021/04/better-documentation-team-communication-product-design-docs/

作者：Ismael González

译者：郑伊妮；审核：刘倩茹、李泽慧、张聿彤；编辑：孙淑雅

本文由@TCC翻译情报局 翻译发布于人人都是产品经理，未经许可，禁止转载。

题图来自 Unsplash，基于 CC0 协议