对不同岗位的人而言，关注需求文档的哪些方面呢？本文作者分享了设计师、程序员眼中理想的需求文档，大家可以一起了解一下。
写需求文档对于无论在哪个领域工作的产品经理来说都是必须要做的工作，我相信大部分产品经理在写需求文档上有自己的一套心得，回忆我自己刚入产品岗没几年那会儿，更多属于能写但自己总觉得没有系统性且一些例如交互细节或边缘case都常常会遗漏，直到现在我也一直在思考什么样的需求文档算好的。
其实对于文档的评判，像设计师或程序员更有发言权，因为他们是文档的消费对象。那这篇文章就讲讲我如何看待需求文档以及目前我正在用的框架，如果大家有好的经验也可以在评论区分享。
关于需求文档有一点我相信能和大家达成共识的，就是一篇理想的文档是设计师和研发通过文档就能指导他们的工作开展，他们需要知道的文档上都能找到，理论上文档交付出去后在研发过程中不需要产品经理就能顺利推动了。虽然这是理想状态，但以此为目标其实就成功一半了。
那什么样的文档对于文档的阅读者：设计师、程序员来说就能达到上述说的理想状态呢？
我们可以分角色来看：
针对UI这一点要求需求文档内的原型包括原型内的每个元素都能清晰的展示出来，这个看上去基本都能做到对吧，但我在早期做产品的时候经常会忘掉画一些元素，比如空状态、表格翻页组件等。
除此之外，还有一些前端界面的交互，比如有些按钮会涉及到禁用，那么禁用状态就要出设计图，还比如有些按钮点击后需要加载，加载样式需要设计等，数据呈现规范也是一个容易忽略的要素；比如有些字段的长度限制，不同的长度限制会影响到设计，通常特别长的字段设计师把这个字段单独用一行呈现，如果特别短那么就有可能一行放多个字段，还比如字段过长是截断还是…替代超过的部分，这些都会涉及到设计稿的输出效果，如果不约束沟通成本就会增大。
通常设计师出设计稿后会给到前端程序员而他们会将高保真UI和产品需求文档一起结合着看，我通常会在设计稿更新后把他们更新到需求文档上，这样程序员就直接可以在文档上看，不用在两个文档上来回切：对于交互层面的需求描述过去会经常出现一个问题：自己觉得交互描述差不多了，但中间会有一些细节缺失或描述的模棱两可。
举个例子：比如描述一个开关的组件，差的描述：点击开关后开关关闭；好的描述：单机开关后开关变为关闭状态的icon样式，当然正常情况下开关操作一般会有很多较验，比如某些情况下开关有依赖关系，点击后不能触发会报错，那什么情况下出现报错，不同的报错的提示语是什么，这个就涉及到和后端交互的逻辑了，还比如有些字段是写死的，不需要和后端交互，这类细节理想状态下都需要写明确。
数据留痕指的是这个需求当中要有哪些数据是要记录在数据库的，当然怎么记录，表怎么设计这个产品通常不管也没能力管，但记录什么产品要定义，有些情况下如果需求目标表明确其实后端同学也是可以根据自己的理解记字段，但在我的经验当中，如果产品不去约束很多时候研发会遗漏一些字段。
和前端的交互逻辑大部分产品经理其实也不用考虑，但要看业务，比如像我之前做的前后端需要实时音视频交互的需求就需要需求文档中描述清楚例如断网之后包括断网重连的交互要求，还包括有的系统并发比较大的，那数据进出的优先级可能也要产品来定义，这也是后端和前端交互层面的东西。关于这个层面可能对于做面向toB产品的产品经理要求比较高，对于toC的话还是主要注重和用户交互层部分的需求描述。
清楚了上述几个查阅文档角色的需求后其实就可以考虑怎么输出一份有框架性的需求文档了，这里还要说一下文档中的需求背景和目标的描述在我看来也挺重要的，某些情况下即便文档中有描述且在需求方看来没啥问题，但理解会存在偏差，文档想表达A但程序员理解成B，那么在这个情况下如果能明确需求目标和背景，程序员有了这层认知，那就能一定程度上减少偏差了。
这里我也分享下目前我采用的文档框架（偏toB一些），供大家参考：
1.需求背景或目的：简短描述，为了避免出现一些需求理解的偏差
2.需求要点：分要点概括本需求涉及的内容，明确需求边界
3.流程图：某些业务流程复杂或涉及到多系统多角色交互的需要流程图
4.交互原型：通常我会把描述直接通过卡片形式贴在原型边上，这样预览起来更直接一点。
5.功能点描述：涉及的所有交互都要描述，哪怕再简单的“点击弹框右上角的关闭icon后弹框隐藏”。也包括一些边缘场景极限场景等。
6.业务逻辑（规则）描述：在toB领域会涉及很多角色间的协作，数据流转，写这个目的也是为了方便研发人员理解需求以及后续测试可以参照业务逻辑规则编写用例和测试。
7.字段表：整理出需求中涉及后端记录的字段，字段名称、字段所在页面、字段描述（字段留存规则）。
以上就是我对一份好的需求文档的理解。
养成一个好的文档书写习惯，一方面对产品本身是一个通过系统性的再梳理发现问题的过程，另一方面对下游对接的研发和设计同学是提高他们效率降低出错率的核心物料。
本文由 @产品萧书 原创发布于人人都是产品经理。未经作者许可，禁止转载
题图来自Unsplash，基于CC0协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。