在线需求文档-美团小程序功能设计（需求文档）

产品需求文档(PRD)定义了产品的功能、逻辑、交互等关于产品的一切,工程师基于此进行开发,测试基于此写测试用例,它的重要性不言而喻。这里说说写 PRD 的一些建议和注意事项

一些大厂的产品经理还在用 word 写需求文档,他们会在文档顶部说明修订时间、作者以及大致的更新内容,看起来很规范。确定最终版后,使用邮件或 IM 将文档发送给相关的开发、测试人员。

使用 word 写文档有以下缺点

wiki 系统中, Confluence 是不错的选择,支持全文搜索、每次保存都有记录,无需手动撰写版本记录,支持树状层级结构,权限控制也可以做到非常细致,这里强烈推荐。当然,如果你们团队使用 Teambition、Tower 等在线协作工具,可以直接使用其自带的文档管理工具。

我曾见过上百页的 word 版需求文档,打印出来简直就是一本书。它的缺点很明显:传递起来太过笨重,在文档内查找定位繁琐,最重要的是,开发人员讨厌这种复杂冗长的文档。

我的建议是,利用好 wiki 系统的树状层级结构,将不同的功能模块进行合理划分,放在不同的目录树中。未来有新的需求,直接在对应的目录下新增文档即可。

虽然大家都讨厌需求变更,但在实际项目中却又无法避免。需求变更后,最先做的则是更新需求文档,即使没有需求变更,产品也是不断更新迭代的,对应的产品文档也需及时更新。

很多产品经理经常忽略这件事,以至于一段时间过后,产生很多需求文档和产品线上版本很多不一致的情况,团队有新成员加入或有人离职,又增多了很多解释和说明的成本。

我们先假如产品需求文档(PRD)是一个产品,那么该如何做出一个拥有良好用户体验的PRD?

首先先来考察下PRD的用户群体(User Persona):主要是开发人员,在繁忙的开发任务中最希望看到“简洁易懂”的产品需求文档。

梳理下PRD的功能:

传达出产品需求;

管理记录产品迭代过程;

各部门共享产品信息,以促进沟通;

因此一个好的PRD的原则是:

结构清晰

语言简洁易懂

实时共享

具体我们该如何制作?

答案很简单――一个PRD文档即可

现在,越来越多的产品经理采用将文本说明和原型结合成一个PRD文档的方式,因为之前的word+原型的方式管理起来繁琐,而且还容易产生信息疏漏。

将原型和文本说明统一,直接分享一个链接,开发人员就能看到所有信息,是理想状态。

多级导航结构展示PRD信息

通常来讲,一个产品需求文档里包含“产品概述”、“流程图”、“功能详情和原型”,“全局说明”,“非功能性需求”。

如何把这些内容清晰有条理地呈现在一个文档里呢?使用一个网页般的多级导航结构即可。

1、产品概述

产品概述部分用于展示文档修订历史、版本说明、开发周期、和产品介绍。

「文档修订历史」用来记录产品经理对该PRD文档的修改状况,也方便成员能及时了解到PRD是否有改动;

「版本说明」展示上线产品各版本的核心功能;

「开发周期」用于梳理开发、测试、上线的预计开始和结束日期。

「产品介绍」用来记录产品名称、简介、用户画像、使用场景、产品定位等等。

(墨刀“PRD模版A”中的“版本信息”模块,by 小龙)

2、流程图

流程图是产品经理梳理产品逻辑和功能的一个思维Map,一般会有“功能结构图’、“信息结构图”、“任务流程图”。

「功能结构图」 展示产品的功能模块,一般展开用户可见的最小单元。

「信息结构图」则是以信息为维度,用来描述有哪些数据字段,展现用户信息/行为信息等。

「流程图」记录着用户使用产品的路径,也是一种产品线路图,展示着产品的所有页面及对应关系,有助于产品理解。

(墨刀“PRD模版A”中的“结构图”模块,by 小龙)

3、功能详情和原型

这个模块是开发人员查看频率最高的模块了。目前一种快捷高效的呈现方式便是“原型”+“注释”。

图文互补,把图片传递不了的信息用文字补充清楚,比如产品的一些使用逻辑,方便同事理解。

使用墨刀的话,可以创建一个大的画布,然后把墨刀制作的原型页面粘贴到画布里,并添加文字注释,在关键位置有一些边界条件的说明。

或者,直接在产品原型项目里通过“批注”添加注释。

(“PRD模版A”中的“交互原型”模块,直接嵌入了墨刀原型,by 小龙)

4、全局说明

这个页面用来展示整个产品的设计规范,一些通用的规则可以附在这里。

对于这点,使用墨刀制作的方便之处在于:

可以直接把有关设计规范的原型项目通过网页链接的方式嫁接过来,还能点击“标注”查看各元素的细节信息。

( 墨刀“PRD模版A”中的“全局说明”模块,by 小龙)

5、非功能性需求

对于不同类型的产品,非功能性需求会有各种差异,一般会涉及到的有:

性能需求

系统需求

运营需求

安全需求

统计需求

财务需求

……

这部分就要自己按需要调整。

总结

PRD作为一种重要的公司内部沟通的文档,能把必要的信息汇集在一个逻辑清晰的结构里是提高工作效率的一个优势。语言上的简洁易懂,再结合可视化的结构图和原型,都是为了增强易读性,让沟通更高效。

把PRD当作一个小产品去打磨一下,不是浪费时间,一个好的PRD文档可以继用很久。

墨刀新出了两种产品需求文档的模版,这两种PRD里的各级页面内容、导航和交互都为大家设计好了。

现在大家可以点击“创建项目”,从墨刀模版中选取“产品需求文档A”或者“产品需求文档B”,点击“使用模版”,再按照自家产品需要做一些更改就okay!

通过墨刀的分享链接还能直接让公司内部人员在线实时同步PRD的更新,不用再担心信息滞后或者文档不兼容问题。

让我们着手开始创建或者优化您的产品需求文档吧～

希望采纳!谢谢!

配图来自  “运维派”以及墨刀官网截图

墨刀连接:

一.需求背景

二.需求目的及明细

三.业务流程

3.1业务流程

3.2页面流程

四.功能详细设计

4.1交互设计

4.2原型

五.考核指标

六.总结

公司最近想把用户约见这个场景在微信小程序上做深做透,基于这个业务诉求,设计聚餐投票的功能,便微信群用户在线下聚会前,能先在线上把大家喜欢的美团店铺汇总在一起,然后投票决策聚会去吃哪个店,可以节约用户的时间成本。

使用投票聚餐一定是针对的一个小群体,这个小群体一定是有一定关系的,如;同事,朋友,同学,家人等,基于上述理论对用户-场景-需求分析:

需求目的:完整的投票聚餐功能,选择商户到统计投票。解决用户在聚餐选择商家时意见不统一或者想要统计大家意见时的需求。

创建流程 :

编辑流程 :

1.我的

在我的页面中新增入口图标,点击后可进入投票聚餐

2.新增投票页

页面分为新增投票模块以及历史投票模块,历史投票模块以时间顺序排列

创建投票:创建投票后进入选择餐厅页面

编辑:点击编辑后,重新编辑此次记录,进入确认页面,可重新发起投票

3.选择餐厅页

选择餐厅页面分为3个模块,顶部的搜索模块,排序模块以及商家展示模块。

排序模块分为4种筛选模式:

按照美食种类分类,其中默认为全部美食,用户点击后出现下拉菜单,用户可选择美食分类(如:食品保健,特色菜,福建菜等)

按照地理位置进行排序,分类模块按城市区域地理性标志划分,默认选择为附近

为用户筛选的常用关键字排序,分为:智能排序,离我最近,好评优先,销量最高,默认为智能排序

按照餐厅服务以及用餐人数为用户进行筛选,默认状态为关闭

确认添加:点击确认添加后,进入确认页

添加商户:点击加号添加商户,再此点击取消添加商户

搜索:点击搜索页进入搜索页面

已添加商户:点击后进入展开已添加商户,可以对已添加商户进行删除

4.确认页

确认页分为主题元素,商户展示模块

主题默认为系统填写,用户点击后可进行修改

生成投票分享好友:点击后进入好友页

添加喜欢餐厅:点击后进入选择餐厅页,无人员限制

删除商家:点击后删除商家

5.结果页

模块分为主题模块,商户展示模块以及出现在商户暂时模块下面的统计模块

投票:点击投票按钮投票,再次点击取消投票;用户若已选择商户,在点击其他商户的投票按钮将自动取消已选的上加商户。

随机功能:场景为当出现平票时为用户随机一家商户,没有操作权限,任何人都可以操作,但点击一次后默认10分钟后才能再次点击,随机结果将一直展现,直到下次随机出现新的结果

回首页:点击后返回首页

添加喜欢餐厅:点击后进入餐厅选择页,选择完毕后直接进入到结果页。

1.考察用户日活增长指数:当天日货量-前一天的日活量/前一天的日活量x100%。投票聚餐是有分享属性存在的,纯在分享属性,进入小程序的用户数应相应增多。

2.对投票聚餐的入口,新增投票以及生成投票分享好友进行埋点,统计访问人数,分别计算转化率。是考核功能的转换率,用户流入入口的数据,是判断这个需求是真需求还是伪需求的根本。

3.使用流程转化率:新增投票访问人数/投票聚餐的访问人数x100%,生成投票分享好友访问人数/投票聚餐的访问人数x100%。此数据是对流程的考察,用户是否觉得流程好用,从此数据能够得出一定的结论。

总结

投票聚餐是针对于当代年轻人常出现的聚餐场景,由于每个人都有自己的喜好而出现的意见不统一的需求,因此诞生出来的功能。此功能要包含完整的投票流程,从选择餐厅-投票,并需将选择餐厅的分类功能尽量做详细,给用户更多的参考意见。此功能完成后,用户日活应有一定程度的增长。