撰稿编者按：你与否曾也为别人的错误重大决策背过锅？怎样才能够更为细致，且保持自己的脚踏实地去做设计呢？第一集该文中，作者向他们详尽介绍了产品设计文件格式，传授了怎样恰当保护它，推荐想要自学更为系统管理自己设计的群体阅读。

你与否曾为设计计划的透过而努力？你与否想要让自己的设计流程更为规范化？新冠肺结核带来的远距组织工作模式与否给你造成了许多麻烦事？这首诗将天主教会你怎样管理你的设计文件格式。

公司或者孵化器企业中的产品设计师标准工作流程对你来说可能非常熟识：开发这款新产品首先需要提供设计解决计划。顺利完成设计决议案后你可向 1-3 个人阐释你的决议案，并获取意见反馈。

有时那些组织工作能较好顺利完成，有时则不然。举个范例，有些人大部分的时间都耗费在怎样顺利完成自己的组织工作上，因此没有足够多的时间对你的设计决议案提出明晰简约的意见反馈。

特别是在新冠禽流感暴发期间，他们不得不展开远距组织工作，即使你的组织工作顺利完成得足够多轻松，你也希望历史记录下每一步的设计重大决策，持续跟踪插值并继续优化设计，从而规范化设计组织工作流程。那些事情会经常性发生。

历史记录设计过程有许多的益处。举个范例，这能建模你的组织工作内容，缔造更多获得别人意见反馈的机会，加强整体沟通交流工作效率，明晰地刻画出那些设计关键点是透过什么样的设计路子被缔造出来的，Vaubecourt那些设计关键点可以解决什么样产品需求等。

一、英雄人物设计师的失利（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、谷歌文件格式或是实际生活中遇到案例中选一个来做模板。记住：每个模块的命名习惯完全可以按照你自己的习惯来。

如果你不喜欢用项目概要这个词，你可Vaubecourt需求这个词，或者是其他更为贴近于此内容定义的词。你需要保留的主要概念是创建不同的阶段，从而使你得以专注于每个阶段，你可以将 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 协议