使用产品设计文档更好的文档和团队沟通

您可能熟悉在公司或初创公司担任产品设计师的典型过程：正在开发一种新产品，并为其提供设计解决方案。 然后你提出一些设计方案，然后在 1-3 个人面前推销它们以收集反馈。

有时这个过程工作得很好，但有时却不行。 例如，有些人忙于完成自己的任务，没有花足够的时间为您的设计提案提供清晰简洁的反馈。

也可能发生这样的情况，即使您的流程很好，您仍然希望通过写下决策、跟踪迭代和总体设计流程来正式化流程，尤其是在当前由于 COVID19 导致我们发现自己在远程工作的时代。

记录过程有很多好处。 例如，它使您的工作更加可见，创造了从更多人那里获得反馈的机会，改善了整体沟通，并清楚地展示了如何在所有上下文和考虑因素的情况下设计功能。

英雄设计师的陨落

2018 年左右，我在一家在拉丁美洲运营的公司从马德里担任远程产品设计师，参与了这个过程中来自墨西哥和巴西圣保罗的其他团队。

在我开始在这家公司工作之前，我的职业生涯中有很多不同的经历，在新闻媒体、设计工作室、社交网络、移动操作系统等许多不同领域的小型和大型环境中工作，创办了一家电子杂货初创公司，甚至与其他小型初创公司一起做一些自由职业。

在那些年里，我一直采用同样的方法，你让一些人坐在同一个房间里，推销你的解决方案，提供一些屏幕、流程、获得一些反馈，然后再次展示。 经过一些迭代后，您的工作将准备好进入开发阶段。

但是，这种相同的方法停止了工作。 加入团队后不久，我意识到仅在视频通话中宣传我的设计是不够的。 我正在创建很多提案，但我无法获得我的利益相关者和队友的最终批准。 我很困惑，不停地问自己：发生了什么事？ 我不是在设计最好的解决方案吗？ 我不是在交付高质量的工作吗？ 每一个问题都让我对自己失去信心。 问题是我需要让我的流程适应这种环境。

当我意识到我的过程不起作用时，我开始阅读很多关于如何远程工作的文章，海鸥效应（当有人进入你的工作，严厉批评它然后飞走），如何其他公司正在接近远程协作，以及他们如何通过写下来正式化他们的流程。 在阅读了所有这些材料后，我想知道开发人员是如何面临同样的问题的？ 他们如何以几乎异步的方式在远程环境中进行协作？ 他们如何达成最终协议？ 我发现，事实上，开发者社区已经有一个非常适合他们的流程：它被称为拉取请求。

拉取请求允许您通过记录更改并使用其他人的反馈来验证您的决定，从而在更大的代码库中引入更改。 通过这种方式，您引入的更改与代码已有的所有标准和连接完美结合。 这正是我需要实现的目标，但当然是采用设计时尚的方法。 让我向您介绍产品设计文档。

产品设计文档

产品设计文档 (PDD)是将您要解决的问题、上下文和最终解决方案转换为迭代或基于阶段的方法的文档。

这意味着您可以将整个设计过程记录在一个文档中，该文档可以与您公司的任何人共享，它将作为您做出的产品决策的知识库。 听起来很酷，对吧？ 让我们深入了解细节。

总体概念

PDD 可以用 4 个主要概念来描述：元数据、上下文、阶段和反馈。

• 元数据只是有关文档的有用信息，例如标题、日期、状态等。

• 上下文是其他人需要阅读的内容，以了解您提出的设计建议，将其视为您需要实现的描述、问题、摘要或目标。

• 阶段是您设计的不同迭代，通常开始关注更广泛的解决方案，并在每个阶段关注更具体的细节。 每个阶段都基于前一个阶段并处理收到的反馈。 这是一种结构化的方式，可以达到最终解决的问题不会再次出现。

• 反馈是指您从其他人那里收集到的所有意见、评论、请求和建议。 您可以从利益相关者或团队成员那里收集反馈。

有了这四个概念，您可以创建不同的 PDD 变体以满足您的需求，每个公司/项目都是不同的，对我有用的，不必以相同的方式为您工作。 但是，如果您在 PDD 中涵盖这 4 个主要概念，那么它几乎可以在任何情况下工作。

示例结构

在了解了主要概念之后，我将与您分享我在该公司期间一直使用的结构。 它有以下几个部分：

• 标题应该简洁、清晰并且易于与您已有的其他 PDD 标题区分开来。
• 状态指示您的文档现在处于哪个阶段：
• 草案
  仍在努力定义上下文。 还没准备好反馈。
• S30、S60、S90
  解决方案的不同阶段（30%、60%、90%）（稍后会详细介绍这些阶段）。
• 完全的
  所有反馈都已得到解决，并且没有遗漏点。 PDD 完成。
• 摘要是对您需要设计的问题的描述，通常链接到您可能拥有的其他有用的相关阅读材料。
• 目标是您的解决方案需要关注的关键点，这是您将不断审查的清单，以确保您走在正确的轨道上。
• S30 （或Stage 30% ）是您根据摘要和目标提出的第一个提案，关注更广泛的解决方案而不是细节，可能通过提供低保真线框或类似技术。 在这个阶段，提出的解决方案可能会采取完全不同的方法，并且预计会出现主要反馈。
• S60 （或Stage 60% ）是您完成 60% 的解决方案，并应用来自 S30 的反馈。 它的细节比 S90 少，但清楚地表明了您的解决方案的意图。 您提供了一个包含更多案例和一些流程定义的高保真线框。 您可能会收到一些反馈，主要集中在遗漏的案例和小的意外情况。
• S90 （或Stage 90% ）是具有 90% 完成度的解决方案并应用来自 S60 的反馈的阶段。 此阶段专注于您设计的最精细细节，包括所有不同的场景、角落案例、视觉设计，甚至原型。 预计会有一些小的反馈。

您可能会问自己，我是否需要遵循相同的顺序和阶段命名约定？ 好吧，不，你没有。 您可以将阶段从 S30、S60 和 S90 重命名为：探索、建议、解决方案。

您还可以更改排序，以便最精炼的作品（S90，解决方案）位于文档的顶部，阅读流程从最后阶段进入早期阶段（S30，探索）。

模板

使用为最常见的写作平台提供的模板之一快速开始。 请记住：部分的命名约定是完全可定制的。 如果您不喜欢Abstract ，只需使用Brief 、 About或任何适合您需要的东西。 您需要保留的主要概念是创建不同的迭代以专注于每个阶段，您可以将 S30 重命名为 Exploration，将 S60 重命名为 Proposal，将 S90 重命名为 Solution。

• 纸
• 概念
• 谷歌文档
• 现实生活中的例子

使用 PDD 的主要好处

1. 每个决定都有记录。
   这意味着即使您离开公司/项目（迟早会发生），周围产生的所有知识都将永远留在公司中，因此其他人可以查看它并从您离开的地方进行迭代。

2. 改善沟通。
   在 PDD 上让您的团队中的不同人员提供反馈有助于每个人保持一致并了解所做的决定。

3. 限制利益相关者的无休止的变化。
   每个阶段都关注问题的不同角度，从更广泛的解决方案到狭窄的解决方案。 这使人们可以一次专注于一个问题，在最后阶段帮助他们。

4. 该产品是协作构建的。
   我们让工程、设计和其他团队参与解决方案，使他们成为其中的一部分，而不是利益相关者定义特定的解决方案。

最后的笔记

结束关于这家偏远公司的故事，我在那里工作了几个月，我能够在至少 5 个不同的项目上实施产品设计文档。 我的挫败感减少了很多，我能够就我的设计建议达成共识，因此产品继续发展。 从那以后，公司发展了很多，我在此期间所做的一些工作仍在使用中。

PS：我在 2019 年开始写这篇文章，然后在 2021 年我看到 Abstract 正在创建一个用于记录设计过程的产品，所以我决定回到正轨并完成它。 看起来它仍然是一个相当相关的话题。

参考书目

• 如何在远程团队上运行设计练习 Hannah Hearth
• 避免海鸥效应：Lauren Moon 的 30/60/90 反馈框架
• 您如何设计设计文档？ 约翰·斋藤
• Brendan Fagan 设计文档的力量
• Matt Colyer 介绍笔记本