在产品设计中,如何把产品的所有正常流和异常流思考全?

在产品设计时感觉自己考虑的挺全面了,需求评审、原型评审啥的也没问题,但是一进研发阶段,就会遇到产品流程考虑不全面、场景考虑不全等一些问题,请问在产品设计时如何规避掉这些问题?
阅读全文
请先 登录 后评论
  • 0 关注
  • 0 收藏 53 浏览
  • 略问用户 提出于 2020-10-21 11:23:27

19 个回答

xxxxxa

正常流程需要清晰的逻辑思维,多画画导图和流程图吧。至于异常情况,嘿嘿,是时候祭出我的大杀器了交互设计自查表.jpeg

请先 登录 后评论
xxxxxa

这个问题我也答一下吧,其实主要是说一下自己这一路走来,怎么慢慢去完善,让坑更少的。

刚开始做产品的时候,只懂得画原型图,然后写文档,实际的那些规则没有写,有的甚至都没想。比如测试问我,登陆的时候支持哪些,字母、数字和下划线,特殊字符是否可以,这些一开始都没有去想,测试问到了,有些问题就很快给了一个答案,因为做的不是0-1,是1-2的产品,所以基本上就说延续1.0的规则就好了。后来做一个0-1的版本,页面,设计,前端都做完了,后台做的时候,过来问我,列表的排序规则是怎样的,发生时间变化之后呢,我因为事先么有想过,当时还问了一句,这些也需要产品定的吗,得到肯定回答之后,我就说我想一下,待会给你规则,然后回去细想,看了竞品之后把规则定下来。

上面的场景就是我刚开始半年做产品遇到的情况,感谢那些可爱的同事们的包容,现在看来最基本的东西都没想好就给他们拿去做了,貌似测试跑去跟总监抱怨还被说了——难道电话号码是11位的我也要写在文档上吗,总监的意思是先测定好的,没定好的产品这边去确定。虽然现在很少遇到这些问题了,但是过往的那些经历才让我越发注重一个流程的完善。

首先,最主要的,自己本身要对业务很熟悉,这个功能要解决的问题一定要清楚,了解需求的来源

第二,再现场景,只有通过场景描述才能够尽量少的遗漏一些流程,把所有的场景都描述出来,每个场景对应的流程也就清楚了

第三,复查和复述,一般还是查场景,因为查流程容易乱,很多时候是主流程的分支,多了就乱了,所以还是通过复查场景,一般用脑图的工具就好

最后,产品经验,做产品久了,很多通用的东西还是很容易清楚的,特别是同一行业,你一个工作两三年经验的产品,不可能不知道注册登陆的整个流程和异常吧,所以积累还是很重要!

请先 登录 后评论
xxxxxa

这位大哥,首先你问的这个问题非常好,今天我过评审的时候,我自认为这个项目都过了十来遍了,觉得该想的场景/流程都想进去了,但是临门一脚,还是崴了点,没办法,毕竟我们本来就是挖坑小能手,虽然经常给别人挖坑,但是,难保哪天不湿鞋,毕竟常在河边走嘛。

-----------扯远了,赶紧回来吧--------------------------------------------------------

我的解决方案

1.需求文档的重要性,每次当原型产品设计的时候,需求文档必须跟上(我就一直吃这个亏,因为跟的业务线多,所以就偷懒,更多的时候是写一些注释在原型上),其实自己写文档的过程,本身就是你很细致的推演你的产品,只有当你用心写文档的时候,你才会发现许许多多的问题,包括场景/流程,甚至会精确到小小的字段/按钮。

2.尽量与同公司同组的产品经理多沟通(如果你们公司只有你一个,那你就多过个几十来遍),当局者迷,旁观者清。古人诚不欺我~~~

3.过需求/原型评审的时候,尽量讲得细一些,毕竟你的需求/原型,你最熟,你讲起来就跟随着自己的思路/惯性滔滔不绝,其它人可能已经听得昏昏欲睡,所以在这点上,可能要适度把握一下。

4.把每一帧的界面做出来(每一种可能存在的界面),走流程,做推演,在这个过程中,也会发现好多问题的。(这个很费时间

其实我认为,这种情况就像失误一样,是无法避免的,只能减小其误差,而且作为一名职业的产品经理,从你的岗位上来说,你要切换成普通的小白用户,真的非常困难,除了像乔布斯、马化腾、张小龙、阿德老师、荣辉老大这类的大神。既然做不了大神,那我们就努力做个敬业的小神吧,别人推演5遍,我就推演10遍,别人只在原型上边旁注,那我就多花点时间写写需求文档等等...

-END,这个问题好难,希望大家能集思广益,其实我答题的真正目的,是为了让更多的大神看到我拙劣的答案,耐不住调教一番的心思而给出很好的解决方案。

请先 登录 后评论
xxxxxa

谢邀~

说句实话,没有一个人能够做出一个密不透风、完完全全的产品系统。首先我们必须得接受这个现实,然后我们去思考如何完善整个产品的逻辑系统,尽全力去完善修正产品流程。

针对你所描述的情况,既然需求评审、原型评审都没有问题,进入研发就出现各种流程不全、场景考虑不周,那么你们是如何进行需求、原型的评审的?难道研发人员没有参与么?如果参与了,那么从研发的角度如果有缺失应该也会当场和你“撕逼”啊,如果没有,那又是什么原因呢?··

从产品的角度,我们自己设计产品,上面@//相识的回答解释比较清楚了,自己做到极致就好,不必强求。

我从我们自己的产品开发流程的角度简要叙述下:

产品评审根据产品研发流程不同会不太一样,每个公司都不太一样。大公司、小公司做法更不尽相同,本人处于创业公司,也经历过混乱的阶段。一般情况,创业公司追求的是速度,讲究的是快速试错快速迭代,因为不会有太多的会议,主要看市场、用户的反馈。

产品需求这个东西很多时候并不只是是产品来提的,很多时候这个需求往往是老板、或者运营、或者市场都会提出产品的需求,所以很多时候产品做的事情就是找各种资料、竞品或者访谈等等去证明需求是真还是伪需求(或者是少部分人的需求),然后给出满足这个需求的价值评估。产品自己提出的需求同样的也是经过这个过程。老板说可以干,咋们就开干!

接着就是产品灰度原型(相对于高保真原型)评审,里面就包含产品功能和交互的评审了,这时候就是涉及到产品各种产品流程了,包含哪些功能,各自的交互是如何的?如何运作起来满足用户的需求?在这个评审里面应当包含所有参与产品的人员:产品、运营、设计、技术(前后端)、测试、甚至市场等等人员。

这个过程一般会开2~3次会议,在3天之内搞定,有时候顺利的话一天就定了,然后就是开发和测试了。

宁可在产品灰度原型多花时间,大家讨论清楚每一个细节,技术评估可行性、实现难度等,从而寻求满足需求的最优解。就可以进入开发了,一般情况都会比较顺利,不会有很大的变动。毕竟是经过所有参与人员的思考的。

产品场景、流程不清晰,首要的是产品要站出来承认错误,思考原因在哪里,自己尽全力还是会出现这个问题,就得发挥集体的智慧了。

共勉~

请先 登录 后评论
xxxxxa

虽然没被邀请,但还是忍不住来回答一下,楼上的交互自查表挺有用的(我曾经也这样总结过),不过就基本事件流&备选流而言,这出说法应该是来自‘测试’相关职能。

异常流的思考也是一个PM对细节把控力度,场景化思考能力的体现,也是UX优化的一方面~

另一方面,就如其他答主所说的,需求评审、PRD、交互流程这些需下功夫把控~

撸主应该主要关心的是备选流(异常流),那我就贴一下我的个人的吧:

Clipboard Image.pngClipboard Image.pngClipboard Image.pngClipboard Image.pngClipboard Image.png

请先 登录 后评论
xxxxxa

谢邀~ 由于周末时间,所以刚看到,前边回答的好多,估计没几个人能看到了,不过还是要答一下~

在产品设计中把系统的各种情况想全,我觉得需要两个必备的基本条件,还有一个方法;

第一,熟悉业务流程

做产品的话,正向流程不遗漏的话,需要你能知道整个业务流程,可以还原使用的场景,只有你能知道业务人员如何使用这个新的功能,你才能做到不遗漏,当然设计完之后要按照场景不断的演练你的产品设计,来查缺补漏;

第二,熟悉系统的逻辑

当你熟悉场景,知道要如何设计这个新的流程后,那么每个任务需要哪个系统或者哪个模块来完成?使用到的这些模块的逻辑是什么样的,是否可以满足你,如果你进行了修改,是否会影响到其他的产品,如果其他人修改了,是否会影响到你?在每个系统的关键节点(一般是转变状态的时候),容易出现异常的流程,需要注意;

一个方法,就是记录

记录下各种需要检查的异常状态;

记录下哪些系统或者算法是公用模块,如果你修改会影响到谁,或者谁修改了会影响到你的产品;

记录下各种系统的非正常逻辑或者为解决某一个业务需求加的逻辑;(容易出坑的地方,因为业务流程改变后,此处逻辑就会造成影响)

按照以上方法,我觉得可以避免大部分的遗漏~

请先 登录 后评论
xxxxxa

看了一下以上同学的回答,Pmcaff真的高手如林。

我也小试牛刀,说说我的方法,不是对的,但是对于我来讲是适合的。

1、我习惯于场景法:

     拿到一个需求从这个需求的场景入手了解,什么角色第一个进入什么场景,有哪些动作,前置约束是什么,这些动作的产物是什么,后置约束是什么。这个角色出场动作是什么。这些问题思考情况,你说明你非常了解业务,这时候你去规划的产品/系统/平台,则就会合理很多,坑自然也就少了;

2、我善于导图和UML:

      我在同时处理多个需求时,我喜欢用思维导图,把我手里的需求画在同一个导图界面。好处是我能时刻记录到需求的细节,且还能有系统协作间的惊喜减少产品重复造车。UML是需求确定后,我可以快速的绘制数据库架构,表间关系,字段从属关系等等。这就让我的思路更加的细腻,密不透风。当然,这也是灭RD的“屠龙刀”。

算是,抛砖引玉吧,我不曾写PRD好久了。。。

请先 登录 后评论
xxxxxa

1:楼下的表非常不错,有这样情况的XDJM,可按此表将自己的业务逻辑列出来,其实80%都大同小异,没太大工作量。

2:然后连续1个月,每天看表背下来,每次做完前端功能对着表,来回检查,至少经历20个这样的功能。

3:然后,然后你就可以丢掉表了,这些成为了意识中的一部分。

4:额外多说一句,你准备的再充分,百密终有一疏,关键是平时形成一套框架逻辑,将这些深深印刻在你脑中。

请先 登录 后评论
xxxxxa

楼上都回答的很好呀`~~

那图就毫不客气的收藏了~

如何让自己正向反向都能考虑清楚,那个自查表其实蛮靠谱的,就是估计很多时候会忘记。那么我说两点比较简单的~

1.做的多了,自然就能考虑清楚了。。(好吧,这句是废话~)

2.任何一个方案,都会有流程图,基本流程图清晰的话,那么逆向也会是比较清晰的~

3.异常情况,异常情况是比较恶心的~

我是这么处理异常情况的,一般我写异常提示的时候,都是弄个表格,把你能想到的都写进去~ok,这时候,你估计已经想不出来啥了~  这时候,把你的正向流程走一下,这时候看看有没有啥正向出问题没有考虑进去的。最后,把你的方案给总监看一下~   经验比较丰富的人,可能扫一眼就知道缺啥了~  他会给你提出来,然后,你再移交给开发,ok,收工~(这是web端)

APP端的话,我觉得上面两位大神贴的图,很靠谱,可以参考。

请先 登录 后评论
xxxxxa

这个问题非常好,我曾经也想过画出类型楼上同学的自查表,但因为太懒放弃了。。。

这个也是不断踩坑的过程,每次遗漏犯错我都会归类,然后记在脑子里。

这种情况测试那边会经常反馈,我会定时看聊天记录,不断反省。

当然出错的原型和文档会修改,下次做的时候心里默念几遍要注意的点。

自己做的原型至少要过上十遍,然后再入评审,评审会议之前会先发给技术看,让他们看完再参加会议。

其中暴露出来的问题马上改掉,最终才确定需求。

另外和技术的沟通很重要,拉上之前做这个模块的人不断去过这个场景。

很多时候已经不是你原型和产品设计上的坑了,而是整套系统之前埋下的坑,这事儿不到做的时候难易察觉,如果有察觉的人,那一定就是技术了~  

请先 登录 后评论