My Secret Rainbow

#31 从 PRD 到设计稿，如何避免设计遗漏带来的坑？

篇首语

本期文章的这个话题源于与一位设计师的咨询。前段时间她刚刚经历了一次与主管的阶段性绩效 review，结果却让她有些失落。

她的主管给了她一个不太理想的评价，这其中有一点是日常做设计的过程中，总是会出现一些丢三落四的问题。要么是界面流程有遗漏，要么就是某些特殊状态没考虑清楚。无论是对接的业务方还是直接主管，都提到了这个问题，认为这个问题对项目的整体质量和速度都带来了一些影响。

对于这个问题，这位设计师她自己其实也有意识到，但还是会觉得有些委屈。在日常工作中，新需求一个接一个，很多时候产品需求文档也都还只是个初稿就提给设计了。加上项目的时间都十分的紧张，的确会出现一些考虑不全面的问题。

设计的前期其实都还好，但一旦进入到设计评审环节，研发团队加入进来后很多问题就都暴露出来了。而作为设计师提案者，自然也受到了大家的很多质疑。这些问题更多是由于PRD的不完善引起的，但最后却落在了设计身上，似乎一切问题都成了设计的责任。

这种情况我相信应该很多设计师都曾遇到过。当我们从 PD 手上接过产品需求文档开始进入设计时，方案的合理性和逻辑问题就不可避免的转移到了设计师身上。如果我们在设计的过程中没能发现问题，那么一旦设计稿输出了，无论是产品的功能还是使用的体验，作为设计师我们都会有不可推卸的责任。

如今的产品，复杂度越来越高，特别是哪些涉及到特定的业务逻辑的产品设计，难免会在设计的过程中遇到一些考虑不周或有所遗漏的情况。面对这样的情形，想要完全避免错误的确是件很难的事情。但我们还是可以借助一些流程和方法来尽可能的帮助自己减少这些问题的发生。

在本期的文章中，我想从产品需求文档（PRD）和设计需求文档（DRD）这两份文档出发，来和大家聊一聊在设计过程中的一些思路和方法，帮助我们能够更好地把控设计过程，在设计交付的时候更好地应对来自各方的挑战。

PRD vs DRD

在我们日常的设计工作中，很多设计师会遇到“设计遗漏”的问题，实际上，这种问题与两个非常重要的文档密切相关：PRD（产品需求文档）和 DRD（设计需求文档）。

对于设计师而言，理解这两类文档并做好 PRD 向 DRD 的转化非常重要，它将直接影响到我们的设计能否完整且准确地满足产品需求，避免设计遗漏的发生。

注：在文章以下内容中，产品需求文档和设计需求文档将使用 PRD 和 DRD 进行表述。

PRD 和 DRD 有什么区别

PRD 是我们在设计工作中最常接触的一类文档，产品经理会从业务和市场的角度描述产品的需求，在PRD 中详细列举产品的目标、功能、用户场景和技术约束。有些产品经理还会附上一些自己线框图，来表达自己对产品设计的一些想法。

在 PRD 文档中，虽然产品经理详细的描述了需求，为设计师的工作提供基础方向，但它始终不是专门面向设计师的交付。大家可以想一想，对比我们在设计交付给研发环节时的设计说明文档，其实 PRD 对设计工作的“友好度”是很差的。

这就意味着，如果我们的整个设计过程是完全依赖 PRD 去完成，这个过程是并不顺畅的，因为它的“格式”与我们的设计工作并不兼容。

为什么会出现这种情况呢？这里有非常核心的一点，PRD 是从产品和市场的视角出发，描述的是业务层面的需求，它所关注的是产品要实现什么功能、满足什么样的用户群体以及如何推动业务目标的达成。

如果设计师完全按照 PRD 所描述的功能需求一步步执行，那么在设计过程中很可能会遗漏掉一些关键的设计细节，或者由于对需求的理解不够深入而产生考虑不周全的问题。这是因为 PRD 仅仅提供了业务层面的框架，忽视了设计中的需求，这就是为什么设计工作中经常会出现设计遗漏的原因之一。

而设计需求则是完全是从另一个视角出发，更多地关注用户体验、交互逻辑、视觉设计等细节问题。可以说，PRD 是宏观的方向，而设计需求则需要更微观和具体的落地。所以，如果我们只是单单对照着 PRD 去进行做设计，就会容易遗漏掉一些关键的设计细节或是思考不全的问题发生。

这里我们再来说说 DRD（设计需求文档）。这是我认为在设计过程中非常重要但又基本处于缺失状态的部分。它的核心目的是在 PRD 提供的关键信息基础上，将产品需求转译成设计视角下的需求描述，从而为设计执行提供明确的指导。

大家不要忽视这个转译过程，它是设计师专业能力的重要体现。这个转译不仅仅是简单地将功能需求转化为界面，而是要通过设计师的分析，将产品需求与用户体验结合起来，从而在保证产品功能实现的同时，也能提供良好的用户体验。

很多设计师在日常工作中，常常被大家视为“执行工具”，这种误解很大程度上没有充分体现出这个角色在产品设计过程的价值。

如果设计师仅仅是按照 PRD 提供的信息进行设计，而忽视了将产品需求与用户体验进行充分的对接，那么设计工作的确像是一个工具人。而实际上，设计师的核心价值之一，就在于通过 DRD 这样一个过程，将业务需求和设计思考相结合，并确保设计方案的完整性和合理性。

在这里，有些同学可能会有疑问了。在设计交付的时候，大家通常都会附上一份设计说明文档，用于解释我们已经完成的设计方案。这个不就是 DRD 吗？事实上，这两者虽然看上去有些相似，但实际上是有很大的区别的。

DRD 与设计说明文档有什么区别

设计说明文档确实是设计工作中的一个重要环节，但它是用来解释已完成的设计方案。操作流程、交互行为、组件、pattern 以及界面排版都属于交付的内容，它的作用在于帮助研发团队理解设计方案中的细节以便于开发实施，用来确保设计方案在开发阶段能够准确地被实现。

但我们需要清楚的是，设计说明文档其实是一个“事后动作”。也就是说，它是设计工作完成之后的附加说明，并不是我们在产品需求转换为设计方案过程中对需求的分析和思考。

而我们前面提到的 DRD 则是“事前动作”。它是我们设计师在设计具体工作开始之前，更具业务需求进行的分析和思考。在 DRD 中，我们需要针对 PRD 中的需求进行分析，从功能的流程到界面的操作再到具体的字段进行详细的分析，并最终落地为一个个的设计需求点。而最终的设计工作则是针对这些设计需求点进行一步步的设计实施。

当我们跳过 DRD 这个环节，依赖 PRD 来进行设计时，我们的转译过程则会完全放在大脑中来进行。尽管很多时候我们可以依赖过往的经验来完成，但这种“隐性化”的设计思考往往就会导致很多的需求细节在设计执行的时候被遗落。

这就是为什么在最后的设计评审环节中，我们会被大家质疑甚至挑战的情况发生。就像篇首提到的那位设计师一样，很多时候这些都并不是设计能力的问题，而是缺少了在 DRD 环节对设计需求的转译。所以，我始终认为 DRD 环节的存在是非常必要的。尽管它看上去会花费我们一点时间去准备，但它同时也会帮我们提前规避掉一些不必要的问题发生，从整个周期来看它并不一定会项目的工期产生影响。

日常工作中的真实情况

这里我们再来回到工作场景中，看看真实的项目情况是怎样的。大部分情况下，一个项目的工作流是这样的：

1.产品经理根据公司业务方向做了一个产品方向，完成 PRD 初稿

2.产品经理拿着 PRD 初稿与设计、技术进行初步的需求评审并针对反馈进行调整

3.产品经理将修改后的 PRD 提交给设计团队进行产品设计

4.设计师基于 PRD 完成方案设计，与业务方、产品、技术进行评审

5.设计师根据反馈意见进行修改、调整，再次评审

在这整个过程中，通常会存在以下几类问题：

•产品经理 PRD 的完整度。很多时候产品经理为了速度会拿着一个不够完善的初稿就找设计师提需求，业务需求本身可能就存在这一些不完善的情况

•在产品设计的初期，研发团队虽然会参与进来，但这个参与很多时候都是很“浅”的。所以很多技术和逻辑问题都会堆积在设计评审的阶段才会真正被他们所关注到

•设计师照着 PRD 做设计，缺少对需求的转译，走到设计评审环节才暴露出很多早期该被发现的问题

这种工作方式是非常常见的，尤其是在当下节奏紧张、需求繁杂的环境下，大家很容易直接跳进设计执行阶段，快速完成界面设计并交付。

在这种情况下，PRD 成为了我们设计师唯一的参考文件，大家在拿到 PRD 后，便立即开始出设计稿、搭建原型，快速进入设计流程。这种仅仅依赖 PRD 的工作方式，导致许多设计上的遗漏和细节问题的出现。

DRD 包含哪些内容

我们前面说到，PRD 是产品经理对整个产品功能需求的描述，主要包含产品背景、商业目标、功能需求列表以及项目的里程碑和时间表等内容。这些内容基本上是从产品经理的视角出发，强调的是“我们想实现什么功能，以达到什么样的商业目标”。

而 DRD 则是对 PRD 的转译和补充，结合我们的设计策略和转译后的设计需求形成我们最终的设计需求文档。在这里，我们需要重点关注以下这些内容。

接下来，我们通过一个大家都很熟悉的例子——“注册登录”功能需求，来详细说明 DRD 的具体作用和内容。

01. 设计策略

之前在专栏中曾和大家讨论过一些关于设计策略的话题。每一个业务都有自己的长期目标和短期目标，而我们每天面对的是一个个具体的设计需求。很多时候我们会陷入到具体的需求中而忘记了我们的设计要解决什么问题。

因此，在开始具体设计工作之前，我们首先要弄清楚这个项目要解决业务的那个目标问题，又是如何解决的，从而延展到设计层面我们应该应对这些问题的策略是什么。这些是我们设计方向，如果发现产品方案并未能很好的解决业务目标问题，我们需要在这个时候就与产品经理进行沟通，避免后续的无效工作。

02. 设计视角的产品流程

我们日常从产品经理的 PRD 中获取的产品流程图，很多时候都是纯功能导向的。它们描述了详细的产品逻辑，但很多时候与我们需要完成的界面设计并非一一对应的。

例如下图中的这个注册登录举例，它详细的标明了界面中所需要的字段和逻辑，但这并不是一个页面级别流程图。对应着它来进行设计就很容易出现逻辑遗漏或错误的问题发生。

所以，在这里我们首先需要重新绘制页面级的流程图。通过这个过程来帮助我们自己理清楚整个功能模块的页面逻辑，同时也明确我们需要设计哪些页面，避免复杂逻辑和状态下的页面缺失。

我们还是用上面的那张流程图为例，通过梳理我们会清楚的知道在这个功能模块中我们需要设计的页面有 6 个，其中某几个页面还需要考虑到多种不同状态下的界面信息变化。而这些就是我们这次需求的整体界面范围。

03. 设计视角的界面需求描述

在 PRD 中，产品经理会对每一个功能界面进行详细的说明，例如下面的这个登录界面。但这里还是依旧那个问题，产品经理对界面的描述还是基于产品视角的，有的甚至只是对流程图的文本化。同样也会很容易出现逻辑遗漏或错误的问题发生。

所以，我们还需要对界面需求描述从设计的视角进行重新的梳理。在这里我会重点关注两方面：

01. 组件层级

我们需要对界面中需要使用的组件进行完整的需求分析。例如在这个界面中。

•登录方式默认为「密码登录」，用户可以点击 tab 或左右滑动屏幕进行切换

•手机号仅支持 11 位中国大陆手机号，输入框失焦后会即时校验，如果不满足要求则进行报错。

02. 页面层面

我们前面提到过，如今的产品复杂度更高，一个界面中往往隐含着多个业务逻辑，稍不注意就会有所遗漏。在这个「密码登录」界面中，在页面层面我们还需要考虑到其他几种形态。

•键盘唤起状态。手机号输入默认使用数字键盘，密码输入框默认使用全键盘

•对话框状态。当用户未勾选「用户协议」并点击「登录」时，需要用的对话框提示用户，同时使用「同意并继续」按钮来完成勾选协议加登录操作

•Toast 通知状态。对于登录成功、网络状态等情况使用 toast 对用户进行通知。

除此之外，我们还可以根据团队的工作模式做一些补充性的描述，例如使用的组件、业务模块或是动效风格等，对所有需要关注的设计需求点进行梳理和总结。

当这个梳理工作完成之后，我们基本上就从设计的视角对业务需求做了一轮完整的梳理。从操作流程到界面模块，再到具体的交互细节，如果我么发现这其中有不理解或不合理的地方，我们可以在具体的设计执行工作之前与各方进行沟通，达成一致后再开工，将所有可能出现的问题控制在前面，同时也尽可能的避免在设计过程中出现遗漏的问题。

写在最后

DRD（设计需求文档）看似只一项具体任务，但实际上，我认为它是工作模式的一种优化。它要求我们在设计之前，先进行充分的分析和思考。这种模式的改变，不仅能够确保我们设计交付的整体质量，还可以帮助我们设计师更好地理解业务需求。

DRD 它不仅仅为设计工作提供了明确的指导，同时也为设计交付时说明文档提供了一个基础。在时间紧迫的情况下，很多设计师会发现自己在撰写说明文档时手忙脚乱，但如果我们在设计初期就通过 DRD 对需求进行了系统的分析，并记录了详细的设计思路和决策依据，那么在交付阶段，DRD 就可以作为设计说明文档的初稿，节省大量时间和精力。

虽然看起来，DRD 似乎给我们在设计环节中增加了一定的工作，但从项目的整体来看，这个投入还是非常值得的。提前识别和规避问题，可以有效地减少了后续设计和开发过程中的返工和调整，让整个流程也更加顺畅。

如果大家在日常的工作中也遇到过类似的问题，不妨按照这个思路来尝试一下，看看这对你是否能提供一些帮助。当然，如果大家对此也有自己的一些心得和看法，欢迎联系我来一起讨论。