从功能看产品逻辑系列(一)该如何思考手势密码?
最近在负责一款app的功能迭代,在此版本里我加入了手势密码功能。我一直在思考这样一个问题,我们的产品已经有了账号密码功能,到底还需不需要加手势密码了?
我非常清楚要不要加一个功能,不是我说了算,不是身边的同事说了算,只有用户说了才算。我一直问自己,你做了用户调研了么?你有数据分析么?
很遗憾,这些我都没有做。我们的产品对象是成千上万个商户,每个商户包括几个门店,几十个门店的都有,每个门店又包括不等的店长、收银员,所以说产品使用者的数量虽然比上不足,但比下有余。有这么多的用户,我为什么不利用这些去做个调研再来决定做不做呢?
也许我会说,乔布斯在设计iPhone4的时候还会去问用户需要怎么做么?张小龙在设计微信的时候会去调研用户需要及时通讯,需要语音对讲,需要摇一摇吗?
But,两位在产品界被誉为神话式的人物,是不可能被轻易模仿出来的。我要说的是一个共通性,产品人的产品论。
产品人的产品论
每个产品人都有一套他自己的产品论。这不是看来的,学来的,而是切切实实从做产品的过程中积累来的。作为一个pm,你有一套产品论,我有一套产品论,他有一套产品论。
我以为,一个功能是否需要调研须经过深思熟虑才能做决定。不是每立项一个功能,就是去做调研,这只会白白浪费时间。也许你会持不同意见,可当你发现调研得来的数据虽然时常帮助了你,但有时却仅仅只是验证了当初的想法而已的时候,你该去总结思考一下了,这个数据结果对我来说真的需要花费这么多精力才能明确么。
通常来说,我不想将时间常浪费在一些不必要的数据问题上面,毕竟,我每一天都在想产品,一整天都在想产品,睡前在想,醒来也在想,不是刻意的去想,而是不由自主的去想,想多了,脑袋也累。我时不时的会希望某一个时间,给自己放一个假,啥也不想,去旅游,去放松,这样当我再回来看我的产品的时候,可能思考的结果又不一样了。这让我想起了曾经上学的时候写作文,可能当时会觉得写的很好,可一旦过了一个月、两个月再回头看的时候,会突然觉得写的很搞笑。人常常就是这样,某个时间段的思维被固化了,常需要在以后的某一天才会开窍。
废话说了这么多,该回到正题了。
手势密码的使用场景
好了,我想说的是我们现在做的是一款收款工具,这其中当然得涉及到跟钱有关的事情,为了商户的账户安全,我们的做法是用户每次打开app,都需要输入账号密码才能登录。试想这样几个场景:
场景一:
我是商家,现在我的pos机系统(这个是用来配合pc端的收款系统使用)出故障了,怎么办,这时我需要掏出我的手机,打开app,输入密码,收款。收完了,关闭手机。顾客这么多,都在等着付款,我还需要输入复杂的密码,进入程序也太慢了吧。
场景二:
收完款了,我退出了程序。过了一会,新来了一位顾客,我打开程序继续收款,啊~我又需要输入密码了,好麻烦啊。
场景三:
一天工作结束了,看看我今天的收单数据吧。什么东西啊,我就是想看看收单数据,又要输入密码。
三个场景,我们总结出来共同的缺点:慢、麻烦。
慢,我怎么解决呢。以下是我的大致想法。
A: 用手势密码吧,至少速度上比输入密码快。
B: 这样也太草率了吧,有没有更快的方法?
A: 那就不使用密码,直接进入app。
B: 这样是不是不太安全啊,这可是涉及到商户的钱啊
A: 怕啥,支付宝不是也涉及到钱吗,不还是可以直接进入么。你想想他们是怎么解决这个问题的,他们是在涉及到钱的最后一个环节才添加密码功能
B: 对哦,我也许也可以借鉴一下。我再想想,啊~不行,支付宝和我们的产品面向的用户群及目的不一样啊。支付宝虽然涉及到钱,然而却不是一款使用频次很高的收款软件啊。如果我们的产品总是在最后一步开启密码功能,在这么高的使用频率下,效率不是提高,而是成倍的降低。
A: 是啊,还是放在第一步进入时开启密码吧,这样更合理。还有没有其他更快的解决办法呢?
B: 额,指纹解锁?好像还不太广泛适用。还有别的什么?算了,想不出来…
麻烦,怎么解决呢?同理了。
好了,既然初步定了这么个功能,是该考虑怎么去实现了。
手势密码存在本地还是存在服务器呢?
存在本地?当然可以,给它二次加密。只是我通过手势密码登录后,我的数据怎么得来呢,毕竟我没有登录账号密码啊。所以,咋办呢。让我的账号密码也缓存在本地,同时设置我的清除缓存功能不去干掉它,这样不就可以了吗。不安全?那再来个二次加密吧。
存服务器,当然也可以。我们让一个账号匹配两个密码呗,通过缓存我的账号,手势密码登录,我也可以照样获得我的账号数据,同时还不用将我的密码存在本地。
我使用的方法是存服务器,毕竟如果将两个密码都换存在本地,我还是觉得不安全。所以在这里我也只讲述客户端与服务器的逻辑交互了,存在本地的话其实也同理,只不过是客户端直接去做判断。
手势密码涉及到哪几个环节?
- 设置手势密码
- 修改手势密码
- 清空手势密码
既然知道了这几个环节,我们就该整理出实现这几个环节包括的内容出来。
- 设置密码 = 添加手势密码
- 修改手势密码 = 匹配手势密码 + 删除手势密码 + 添加手势密码
- 清空手势密码 = 删除手势密码
所以,无非就是涉及到这三种形式
- Type1 添加
- Type2 删除
- Type3 匹配
常见流程:
客户端与服务器怎么去做交互?
- 设置手势密码。用户先绘制第一遍手势密码,然后再绘制第二遍手势密码确认,这时客户端会判断第二次输入的是否正确,如果错误,清空数值,要求用户重新操作。如果正确,客户端通知服务器此时进行的是type1添加密码,同时将用户设置的各个点的数据传给服务器保存下来。这样设置操作就算完成了
- 修改手势密码。用户首先绘制原手势密码,客户端通知服务器此时进行的是type3匹配,同时将数据传给服务器比对,输入正确的话,服务器返回成功消息,于是用户有权限开始进行下一步操作了,下一步操作即为添加密码。
- 当用户点击清空手势密码。客户端返回类型type3给服务器,告诉服务器我现在是在进行清空密码操作,于是服务器收到请求后,直接将手势密码清空就完成了。
嗯,手势密码功能总算是做出来了,我是不是还应该判断一下我打开app时弹出来的界面是手势密码登录界面还是账号密码登录界面。
怎么做,我打开app时将账号传给服务器,让服务器判断一下此账号是否存在手势密码,如果存在,那就显示手势密码界面,如果不存在,那就显示账号密码界面。如果手机端不存在账号信息,那就直接账号密码登录。
总算搞定了,那还有没有考虑没到位的地方?
对了,我应该加一个次数限制吧。比如说,输入6次,就不准再输入了,只能使用账户密码登录。
为什么要加入次数限制这一条件?
这样想,如果允许用户无限次输入,那对于居心不良的人来说,是不是就可以随意破解了。也许你会说,设置的种类这么多,破解那得多难啊。然而,对于程序来说,这种密码的破解却很简单,所以出于安全性考虑,为了杜绝一切可能破解的因素,我们还是有必要加入次数限制。
因此,我们怎么去做。让服务器去判断次数,或者直接在本地判断次数,都是可以的,输入错误6次,即清空密码。在这里,我要说明的是,我为什么做直接清空而不是限制用户在多长时间内不准输入,每个人的思考点都会不同,也没有谁一定对谁一定错,存在即合理。
作者:Cw(微信号:小七的road)
本文由 @Cw 原创发布于人人都是产品经理。未经许可,禁止转载。
为什么不是限制用户在多长时间内不准输入?而是直接清空密码
怎么会有清空手势密码,设置里面不是有个关闭手势密码吗?直接关掉就可以了
营业员收银为什么要密码呢?退款才需要把?进账也需要么。
是的,app里面其实涉及到好几个关于商户利益的功能,因为重点不想讲为什么密码,所以并没有去细说
修改手势密码有没有必要要加一种使用登陆密码修改的方式,为了那些把手势密码也给忘了的用户?
如果忘了手势密码,直接账号密码登录,再点击关闭清空密码
如果六次密码都是错的?后面是如何办?
直接退出登录,再用账号密码登录,登陆后提示是否重新设置手势密码
为什么不是锁定账号要求验证,而是把密码清除?
1 你的验证码输入多次都是错误,默认你已经忘记验证码了;2 如果你能通过普通登录,登陆成功(本身登录的行为就是验证是否是你本人操作),说明是你本人操作,提示重新设置验证码就行
1 你的验证码输入多次都是错误,默认你已经忘记验证码了;2 如果你能通过普通登录,登陆成功(本身登录的行为就是验证是否是你本人操作),说明是你本人操作,提示重新设置验证码就行。
貌似大家设计的流程都差不多,楼主好像忘了用户主动关闭和开启手势密码的流程了!
没有哦,我简化了,关闭就是清空了,回到原始,在关闭的时候给予用户提示
用户想再次启用的时候,就必须重新设置,关闭手势密码和清空收拾密码还是有很大差别的吧
在客户端请求清空手势密码时,是不是要验证密码先?
给予提示即可
没联网怎么办
没联网没数据,提示没联网