产品日常工作规范之需求设计(第二篇)

本文是一个系列文,主要是将我自己目前产品工作中踩过的坑和遇到的困难进行反思和总结,然后将其输出为一个工作规范。同时也因为我现在负责公司产品组管理的工作,制定相关的规范和准则,一来可以约束自己,形成良好的工作方式和流程;二来可以约束团队,方便新人工作和成长更加具有科学性和条理性。初步定的内容和模块大概有三个大模块,九个小细项,希望我能坚持写完。

前言

本文是产品日常工作规范的第二篇——需求设计,其中的内容是承接上文需求收集之后产品要做的一些事情,其中的主题内容与公司、团队实际情况关联很大,所以不具有普适性,只是一些个人心得总结罢了。

需求设计大概有以下几个大的步骤:
a. 输出站点地图;
b. 输出产品原型;
c. 输出产品需求文档 or TAPD;
d. 设计交互及UI;

以上内容视需求的内容和范围略有调整,例如小需求并不需要复杂的站点地图或者不需要产品需求文档,目前我们公司也没有相关的交互和UI,所以这些步骤可能需要省略。但是产品原型和TAPD应该是每个需求都必须输出的内容。

a. 输出站点地图

站点地图表面上的意思就是指对一个站点的信息做一个指导,让陌生的用户可以快速的了解此站点。产品在设计一个需求的功能的时候,往往会很直白地,想当然地觉得这个地方我应该加一个搜索,加一个选择,加一个筛选等,这样很容易就会造成一些功能的缺失,不具有严谨性和周全性。

所以我建议再需求设计阶段,在设计原型之前最好能输出站点地图,站点地图的格式一般用mindjet或者xmind等输出,也可以用流程图来输出,通过场景的分析然后给出相应的站点地图。

例如:客户登录系统之后->进入个人中心->点击头像或者账号->修改密码->填写内容并提交->修改完成。这个是客户的一个使用路径,但是在设计产品的时候,个人中心不仅仅只有头像和账号还有一些记录,但是如果不提前规划好这些相关的关键的站点地图,很容易就忽略掉个人中心应该有的东西。

站点地图可以确定后续原型设计,文档设计及交互UI的范围,对于绝大数需求来说都是必做的第一步。表现形式用脑图和流程图组合是最佳的。

tapd_69625718_ba<x>se64_1564048696_83.png

b. 输出产品原型

  1. 根据站点地图找到相应的的设计页面的类型(表单,列表,详情还是弹窗),同时确认一共有多少个页面,他们之间的流转关系是怎么样的。
  2. 当确认了要画某个页面的时候,首先确认整个页面的大框架有哪些,例如搜索区,展示区,分界区,然后搭好了框架之后再确认每个框架内分别有什么东西,由粗到细,一步一步完善。
  3. 原型的设计讲究高效、简洁、干练,花最少的时间和精力在其中,高保真一般用不上也不建议花太多时间去弄高保真原型,至于提高速度的方法,一方面是软件使用的熟练,另外一方面就是模式的使用,模式就是可以重复使用的方式和方法。所以多用一些可复用的东西,母版,组件,元器件等。
  4. 原型中可以简单地将页面的线框和主题内容表现出来,如果有很细的交互或者说明要补充,可以采用相应的便利贴展示,但是如果怕一些细节会遗漏,最好是写相关的用例产品原型说明,这些内容可以放在需求文档中,也可以放在TAPD中。对于这种细节最容易导致争议和返工,所以在需求评审的时候需要将这些细节也进行评审,方便开发提前知道相关的要求,避免顾此失彼的情况出现。

c. 输出产品需求文档 or TAPD

由上面的输出产品原型的步骤可知,一些用例产品原型说明会放在产品需求文档 or TAPD中,除了以上内容之外,还有项目的背景,业务的流程,关键逻辑的说明,一些非关键因素的补充等。

关于产品需求文档,我的看法是:以公司当前的情况来说,用WORD去写不太符合实际,很多需求都是简单的一些调整和涉及到多系统的更改,如果每一个需求都写相关的文档会花费很多的时间,同时也会有很多无用的信息一直在编辑、传递。我更加倾向于高效的做法是,产品向开发和测试分享相关的业务需求同时和他们一直指定相关的解决方案,然后由产品将一些细节落实,将一些不规范的东西约束,这样实际开发中可能会存在一些很细节的东西不能满足产品的要求,但是起码的大需求和大方向是不会错,效率也会高很多。

其中关键的几步分别是:

  1. 分享相关的业务需求和内容,让开发和测试知晓并参与方案的决策;
  2. 产品设计相关的业务流程和原型,撰写相关的文档等;
  3. 开发和测试参与评审,同时对一些细节和未定的内容做一个确认;
  4. 产品规范流程,原型,文档等,此处的文档可以理解为TAPD的用户故事;
  5. 开发在开发过程中,如果有什么内容更新可以在TAPD中补充,同时在下方的评论追加一些补充的内容和提要;
  6. 测试可以根据TAPD完整的知道这个事情的起源和过程,同时尽快制定相关的验收计划和清单。

d. 设计交互和UI

设计交互和UI是在原型设计之后,交互和UI根据原型和一些产品文档之类的进行交互或者UI的设计,这一块的流程需要UI和产品进行多次深入的沟通和交流。

但是目前公司没有UI和交互,所以这一块的东西更多的是让产品对日常原型的设计和开发完的成果做一个把控和验收,因为一般开发的时候用的都是通用的框架和设计语言。

写在最后

第三篇的内容主要是讲需求研发,此文的主体大纲是参考李宽的B端产品经理必修课中的内容来写的。初看此文,我感觉讲得东西都是大同小异没有什么花样,实际到了我要去践行并带领团队的时候,我发现其中的一些观点和内容其实处处凸显了作者丰富的经验及阅读量,此书可算得上是B端产品的一本很好的指导书了。

希望大家以后在遇到相关的书籍的时候可以沉下心,带着目的和思考去阅读,这样的话收获会很大也很容易与作者形成共鸣,加深对某些观点和看法的理解。

此处再次感谢@李宽,7月份的工作,此书对我的帮助巨大,也推荐大家去购买并阅读此书。

--本文到此结束感谢您的阅读--
随缘打赏,佛系产品
0%