用产品设计文档改善文档和团队沟通

前端小工
337 阅读9分钟

在公司或初创企业中担任产品设计师的典型过程可能是你所熟悉的：正在开发一个新产品，为其提供设计方案。然后，你在一些设计方案上下功夫，并在1-3人面前推销这些方案以收集反馈意见。

有时这个过程很顺利，但有些时候却不顺利。例如，有些人忙着注意完成他们自己的任务，而没有花足够的时间为你的设计方案提供清晰和简洁的反馈。

也可能发生这样的情况：即使你的过程是好的，你仍然希望通过写下决定、记录迭代和一般的设计过程来正式化这个过程，特别是在目前由于COVID19，我们发现自己在远程工作的时代。

记录这个过程有很多好处。例如，它使你的工作更加明显，创造了从更多人那里获得反馈的机会，改善了整体的沟通，并提供了一个清晰的图片，说明一个功能是如何在所有的背景和考虑中设计出来的。

英雄设计师的陨落

2018年左右，我作为一名来自马德里的远程产品设计师在一家在拉丁美洲运营的公司工作，在这个过程中涉及到来自墨西哥和巴西圣保罗的其他团队。

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

在那些年里，我一直遵循同样的方法，你让一些人坐在同一个房间里，提出你的解决方案，提供一些屏幕、流程，得到一些反馈，然后再次提出。经过一些迭代，你的工作就可以进入开发阶段了。

然而，这种非常相同的方法不再奏效。在加入团队后不久，我意识到仅仅在视频通话中展示我的设计是不够的。我创造了很多提案，但我无法得到利益相关者和团队成员的最终批准。我很困惑，不断问自己。到底发生了什么？我不是在设计最好的解决方案吗？我没有提供高质量的工作吗？每一个问题都让我对自己失去信心。问题是，我需要调整我的流程以适应这种环境。

当我意识到我的工作流程不可行时，我开始阅读大量关于如何作为一个设计师远程工作的文章，海鸥效应（当有人进入你的工作，严厉地批评它，然后飞走），其他公司是如何对待远程合作的，以及他们如何通过写下他们的流程来正式化。读完这些材料后，我想知道开发人员是如何面对这个同样的问题的？他们是如何以一种几乎异步的方式在远程环境中进行协作的？他们是如何达成最终协议的？我发现，事实上，开发者社区已经有一个对他们来说相当有效的过程。这就是所谓的拉动请求。

拉动请求让你在更大的代码库中引入变化，将它们记录下来，并通过其他人的反馈来验证你的决定。通过这种方式，你引入的变化与代码中已经存在的所有标准和连接完美地结合起来。这正是我需要实现的，当然是以设计的方式。让我向你介绍一下产品设计文件。

产品设计文件

**产品设计文件（PDD）**是一份将你想解决的问题、背景和最终解决方案转化为迭代或阶段性方法的文件。

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

总体概念

一个PDD可以用4个主要概念来描述。元数据、背景、阶段和反馈。

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

  • 上下文是其他人需要阅读的内容，为了理解你提出的设计方案，可以把它想成是你需要实现的描述、问题、摘要或目标。

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

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

有了这四个概念，你可以创建不同的PDD变体来满足你的需求，每个公司/项目都是不同的，对我有用的东西，不一定对你有同样的作用。但如果你在PDD中涵盖了这4个主要概念，它就有可能在几乎任何情况下发挥作用。

结构实例

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

  • 标题应简明、清晰，并易于与你已有的其他PDD标题区分开来。

  • 状态表示你的文件现在处于哪个阶段。

  • 草稿
    仍在努力定义背景。尚未准备好接受反馈。

  • S30, S60, S90
    你的解决方案的不同阶段（30%、60%、90%）（关于阶段的更多细节将在后面介绍）。

  • 完成
    所有反馈都已解决，没有遗漏。PDD已经完成。

  • 摘要是对你需要设计的问题的描述，通常链接到你可能有的其他有用的相关读物。

  • 目标是你的解决方案需要关注的关键点，这是一个检查表，你将不断地回顾，以确保你在正确的轨道上。

  • S30（或30%阶段）是你根据抽象和目标提出的第一个建议，重点是更广泛的解决方案，而不是细节，可能是提供一个低保真线框或类似的技术。在这个阶段，所提出的解决方案可能会采取完全不同的方法，而且预计会有重大的反馈。

  • S60（或60%阶段）是你的解决方案完成度的60%，应用了S30的反馈。它的细节比S90少，但清楚地表明了你的解决方案的意图。你提供了一个高保真的线框，涉及更多的案例和一些流程的定义。你可能会收到一些反馈，主要集中在遗漏的案例和小的意外情况上。

  • S90（或90%阶段）是将解决方案完成度提高到90%的阶段，并应用S60的反馈。这个阶段主要关注你的设计中最细微的细节，包括所有不同的场景、角落案例、视觉设计，甚至是原型。预计会有一些小的反馈。

你可能会问自己，我是否需要遵循相同的顺序和阶段命名惯例？嗯，不，你不需要。你可以把S30、S60和S90的阶段改名为只是。探索、建议、解决方案。

你也可以改变顺序，让最精炼的工作（S90，解决方案）在文件的顶部，阅读流程从最后阶段到早期阶段（S30，探索）。

模板

从提供的最常见的写作平台的模板中选择一个快速开始。请记住。各部分的命名规则是完全可定制的。如果你不喜欢_摘要_，就用_简介_、_关于_或任何适合你需要的东西。你需要保持的主要概念是创建不同的迭代，以专注于每个阶段，你可以把S30改成探索，S60改成建议，S90改成解决方案。

使用PDD的主要好处

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

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

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

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

最后说明

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

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

参考书目

avatar
文章
阅读
粉丝