【PRD框架V2.1】全新的设计理念，更赞的阅读体验

2022年5月31日，正式发布了PRD框架2.0语雀版本，新版本划分了六大核心模块，详细定义了需求描述的所有元素和细节。

[ri-post id="132" thumb="none"]

预览《PRD框架V2.0》语雀版

[ri-post id="437" thumb="none"]

[ri-post id="154" thumb="none"]

[ri-post id="433" thumb="none"]

之前的PRD框架是在语雀上进行设计的，虽然我比较推荐用语雀来写需求文档会更方便高效，可是很多小伙伴都习惯用墨刀，所以花了洪荒之力设计一个全新的PRD框架2.0墨刀版本。

预览《PRD框架V2.1》墨刀版

在开始介绍之前大家可以点击直接预览体验一下

PRD框架墨刀版本设计了两种表现类型，一种是使用墨刀组件设计，可以不拘一格自由灵活，充分发挥想象力，一种是结合在线文档设计，编写高效提升体验，总体视觉更美观。

墨刀组件

使用墨刀组件的优势是灵活，前提是对各种组件用法非常熟练，那么设计起来就很得心应手。

• 表格，可以让人可以结构化的阅读，提高信息的高效传递，既是一种可视化交流模式，又是一种组织整理数据的手段。
• 动态组件和母版，在设计中会存在大量需要重复使用的模块，我会将组件转为动态组件和母版，减少在不同页面重复的去设计，提高设计效率。另外还有一个好处，就是在有限的面板空间内，可以实现多种页面状态和内容滚动效果，这样可以展现更多的设计内容。
• 菜单和导航，主要作用是不让PRD的阅读用户不会迷失方向，框架的导航设计是否非常高效合理，决定了阅读体验是否能得到提升。

在线文档

使用在线文档是为了弥补原型工具欠缺的文档编辑特性，不管是墨刀还是Axure，或者是其他原型工具，强调的都是画图能力的效率提升。但PRD框架强调的是文档书写编辑的重要性，因此在文档编辑方面，在线文档会更适合编写PRD。

框架里，我使用了三种在线文档：语雀、腾讯、石墨，顺序也代表了推荐程度

• 语雀，在PRD框架介绍里，我直接使用了语雀的文档内容，只要在语雀文档里设置为超级宽屏，文档内容的展现效果直接满分。

在设计文章推荐时，我本来想用墨刀组件来设计，尝试后放弃了。使用墨刀组件设计卡片来显示文章标题、子标题、封面图等等，得一个一个去设计，工作量非常大，非常繁琐。也尝试了腾讯文档和石墨文档，体验都不好，最后选择了语雀，可以直接生成一个文章卡片，文章标题、子标题、封面图都自带，非常赞。

• 腾讯文档，在线文档里，我大量使用了腾讯文档，首先推荐是腾讯文档的表格，用起来方便高效，显示效果很简洁美观，编辑改动很简单，支持各种Excel的高级功能。在表格这方面大家可以去试试语雀和石墨，总体不会差太多，根据自己需求和习惯做选择

文档的表现能力不是特别满意，两边空白特别大，显得图片和文字很小，没有跟语雀一样的超级宽屏模式，或者是我没找到如何设置。目前我建议如果用到大量文字描述和图片的，比如架构图，流程图之类的，推荐使用语雀。

• 石墨，其实石墨的文档能力并不弱，是我除了语雀知识库之外，最常用的文档工具。石墨其他特性跟腾讯文档基本有的一拼，编辑书写各方面体验也不错，同样是免费的。但是！！！！！！！在墨刀里直接嵌入石墨，第一次加载网页时始终会显示一个很大的登录框，而且是每次切换刷新都会显示，这点让我很有强迫症。这样用户会在阅读文档的时候出现很强的阻断感，极大的影响了阅读体验。

功能需求描述

在写需求文档时，大家问题点最多和痛点最大的其实就是功能需求的编写和展现。要么是功能需求写得非常多，缺乏合理排版，开发阅读起来效率降低；要么是不知道如何下手，写得漏洞百出，结果被开发一顿DISS，每次需求评审都过不了。

这次用原型工具设计PRD框架，很好的解决了这些问题。

功能模块

功能模块的设计，可以支持N级功能模块规划，基本可以满足绝大部分的工作场景，通常功能模块达到4级就已经是很复杂的系统了。

左边显示模块菜单，右边显示子功能列表，一屏可以显示20个子功能，超出后会显示滚动条，可以通过下滑展示更多的功能。

子功能

子功能包含功能描述、流程图、业务规则、字段定义和详细需求。

不管是新手还是老手，我比较推荐在写需求时，先把功能描述和流程图定义出来，在没有原型的情况下可以很快梳理出功能的核心业务逻辑和流程。

字段定义，对应的是开发数据库建模的工作，如果产品对字段的定义存在模糊、多意和歧义的情况下，那么就会造成跟开发之间的沟通成本和理解成本。

很多时候，产品验收功能时，觉得开发这个数据不对，其实是在字段定义时，理解的就不一样，最终才会导致错误偏差的结果。

我总结了多年开发和产品的经验，提供了一种产品定义字段的解决方案，可以帮助你把字段定义更清晰，要点清晰且减少疏漏。

详细需求，功能需求到底应该怎么写，除了流程图和字段定义外，产品更多接触到的是原型页面和交互。很多新人在写功能需求时都会出现很多问题，比如：流程不清晰、交互细节丢失、字段描述含糊不清、各种提示文案等等。

子功能往往会包含多个操作和功能页面，在详细需求里在同一个页面内就可以阅读所有的功能详细需求，可以满足前端后端测试对需求的阅读需求，整体结构化设计有效提升开发阅读效率，提高开发对信息的准确理解和吸收程度，也更容易发现业务问题和需求遗漏。

PRD框架逐渐会对不同功能的需求写法给出对应的案例。

一个查询功能，需求需要定义清楚：查询条件、列表字段、交互说明、提示说明。

在PRD框架中，对每个需求模块都进行了合理的划分，大家只需要在对应的模块里编写具体的需求，具体写法可以参考框架中写好的案例。

目前墨刀版本可能对使用墨刀的小伙伴会友好一些，很多小伙伴都在催什么时候出Axure版本。后面肯定也会设计Axure版本，只是设计墨刀这个版本已经消耗了我的洪荒之力，我需要休整一小段时间。

我会先针对墨刀版本，做两套视频教程，包含如何使用PRD框架的视频教程，以及如何设计PRD框架的视频教程。

如果你觉得PRD框架对你有用，请支持下我，有你的支持，才可以设计出更棒的PRD框架。

主题授权提示：请在后台主题设置-主题授权-激活主题的正版授权，授权购买：RiTheme官网