一、问题说明:
程序员小姐姐:询问关于记录的修改和删除都是实现同一个功能,并没有多大的差异,那么修改和删除有必要实现嘛。(是否需要两个按钮,还是混合在一起)
就针对这个问题,进行了一下对话,简单说明了一下角色在产品中的应用。



这里我们来举例说明:
首先是用户操作的习惯的问题:
按照上图所示,目前大部分的后台基本都是标准界面样式,对应操作下面是常用的查看、编辑、删除,或对应不同功能还有审核、下载之类的。用户进入后,选择对应的操作会比较直观。


其次是考虑到使用场景的问题:
进入到页面里面操作也是多了一步操作,如果当前用户已知是需要编辑,那么进入详情页直接启动编辑,这样会有误操作的情况发生。虽然我们可以说权限是开放给用户的,用户自己操作错了,我们也没办法控制。但这个想法不对,应该说我们有途径可以避免用户操作错误,那么就从源头进行规避。

还有就是权限的问题:
前期如果是规划好权限,那么在列表和在详情页面都好设定。如果是后面增加的权限,那么在列表处增加判断和在详情也增加判断,对于研发来说工作量就有比较大的区别了。还一个,在列表处设定权限,方便一次操作一件事情,都混到里面去操作,也比较容易引起误操作。
二、简述说明:
2.1为什么说要切换角色去思考:
我们常说切换角色去思考,那么切换的角色是在什么场景下?去解决什么事情,得到什么样的结果?带着这三个问题去思考,才会得到你想要的答案。
开发者角色:最核心点是要解决问题,不管产品在界面上提报了多少需求,需要搞清楚产品要的内容是什么,对应的场景是什么,通过什么操作,解决什么问题,得到什么结果。然后还要顺带考虑下,10个需求能不能改为8个,可以让我有空观看下自己的发际线是不是又后移了。
那么针对操作下面有查看、编辑、删除三个功能需求,其中查看、和编辑是一样的界面,一个是只能看不能写,一个是能写还能存,那么至少要写一个样式表出来,而且查看的时候说不一定就会要编辑,进入编辑也可能只是查看,那么就归属到一起好了。至于删除嘛,里外都一样(但这里会有多一步的操作,如果误编辑了,然后又点了删除,那么是该先保存,然后在删除,还是不保存直接删除呢?)。

2.2用户角色:
首先用户进入到后台的目的性都比较强,较少的会出现就是来看看顺便操作一下什么。其次对于后台来说,数据类的信息一般不会轻易调整,都是要对应负责的。特别是一些订单、用户信息之类的,一旦改动,后续就有很多的麻烦。所以一般客服查看订单,就是为了查看订单信息,不会有其他的操作。
还要在讲一个问题:在一个界面上进行查看和编辑,如何进行区分?这里说用权限区分,只有查看权限的就只能查看,有编辑权限的,就可以既查看又能编辑。但如果说在加上审核、下载这些呢?还是在一个页面同时进行实现吗?对于研发来说,这样就比较麻烦,对于用户来说,如果拥有多个权限,就要小心的避免点击下载时,不要修改了东西,不然就有数据出错的情况。如何避免?试想一下,会不会很混乱?
2.3角色的场景定义:
两种角色的情况上面已经简要做了说明,其实最大的问题是谁在场景的场景去思考和使用。在说一个日常的小例子:我们日常都会点外卖的馄饨、汤面什么的对吧,都会用一个比较结实的塑料盒装。商家的要求是:结实,包装严实,不要撒汤。用户的要求是:包装严实、不要撒汤、打开容易。关键词是包装严实、不要撒汤,这里一般都会站在商家的角度去考虑:盖的是很严实,很密封了,不会撒汤。但有多少考虑了用户:打开容易?回忆下是不是这个情况,每次打开,都要小费劲一下,如果盒子的质量比较好(比如点了酸菜鱼),那么可有的费劲了。

三、解决问题:
3.1实际在生产中我们常见的场景:
收货地址是全部显示还是只显示到街道和详细地址,对于商家来说要有省、市、区、街道、详细地址5个字段的展示,区分下是不是包邮地区;对于用户来说也是省、市、区、街道、详细地址5个详细输入,这里判断是不是包邮,在结算的时候会有定义;对于快递公司和快递小哥来说这个就可以有区分了。快递公司分出省市区就可以进行快递的定义,快递小哥是按照片区来划分的,主要是看街道详细地址。
3.2一个后台要返程三种角色定义:
超级管理员(什么权限都有,一般就一个人,基本是不会管事的)、领导者(一般拥有审核、权限分类、数据查看等重大、重要操作事宜,较少会细致的操作详细内容)、使用者(底层角色,这里会划分多个模块的角色,通常都是细节操作),还要做权限操作太麻烦了,干脆所有人都可以全部操作,出了问题去找对应人的角色不就好了,能这样操作吗?

3.3思考:
目的和意义:切换角色的目的在于不同场景的考虑,如果你是研发者,那么你在做研发的时候你要思考用户使用这个功能的场景、用途、要解决的问题,不能都是1和0的表现方式。现在是对单一场景进行思考,如果是多个场景混合在一起使用,比如涉及到中台应用,那怎么区分呢?
能够解决什么问题:要解决的不是界面展示更不是功能呈现,而是解决场景使用的问题。

如果你依然在产品的世界里迷茫,不知道自己或产品的世界,可以加入我们,可以与大神一起交流并走出迷茫,小白可进群免费领取学习资料,看看前辈们是如何在产品的世界里傲然前行!有想学习产品技能的,或是打算转行产品,还有想在产品工作中想提升自己能力的,正在学习的小伙伴欢迎加入学习。
产品交流QQ群:536530648
微信公众号:laohuse0632
色色老师微信号:PM-PPP(加这个微信号拉入微信群)
网友评论