从功能看产品逻辑系列(一)该如何思考手势密码?

我非常清楚要不要加一个功能,不是我说了算,不是身边的同事说了算,只有用户说了才算。我一直问自己,你做了用户调研了么?你有数据分析么?

很遗憾,这些我都没有做。我们的产品对象是成千上万个商户,每个商户包括几个门店,几十个门店的都有,每个门店又包括不等的店长、收银员,所以说产品使用者的数量虽然比上不足,但比下有余。有这么多的用户,我为什么不利用这些去做个调研再来决定做不做呢?

也许我会说,乔布斯在设计iPhone4的时候还会去问用户需要怎么做么?张小龙在设计微信的时候会去调研用户需要及时通讯,需要语音对讲,需要摇一摇吗?

But,两位在产品界被誉为神话式的人物,是不可能被轻易模仿出来的。我要说的是一个共通性,产品人的产品论。

产品人的产品论

每个产品人都有一套他自己的产品论。这不是看来的,学来的,而是切切实实从做产品的过程中积累来的。作为一个pm,你有一套产品论,我有一套产品论,他有一套产品论。

我以为,一个功能是否需要调研须经过深思熟虑才能做决定。不是每立项一个功能,就是去做调研,这只会白白浪费时间。也许你会持不同意见,可当你发现调研得来的数据虽然时常帮助了你,但有时却仅仅只是验证了当初的想法而已的时候,你该去总结思考一下了,这个数据结果对我来说真的需要花费这么多精力才能明确么。

通常来说,我不想将时间常浪费在一些不必要的数据问题上面,毕竟,我每一天都在想产品,一整天都在想产品,睡前在想,醒来也在想,不是刻意的去想,而是不由自主的去想,想多了,脑袋也累。我时不时的会希望某一个时间,给自己放一个假,啥也不想,去旅游,去放松,这样当我再回来看我的产品的时候,可能思考的结果又不一样了。这让我想起了曾经上学的时候写作文,可能当时会觉得写的很好,可一旦过了一个月、两个月再回头看的时候,会突然觉得写的很搞笑。人常常就是这样,某个时间段的思维被固化了,常需要在以后的某一天才会开窍。

废话说了这么多,该回到正题了。

手势密码的使用场景

好了,我想说的是我们现在做的是一款收款工具,这其中当然得涉及到跟钱有关的事情,为了商户的账户安全,我们的做法是用户每次打开app,都需要输入账号密码才能登录。试想这样几个场景:

场景一:

我是商家,现在我的pos机系统(这个是用来配合pc端的收款系统使用)出故障了,怎么办,这时我需要掏出我的手机,打开app,输入密码,收款。收完了,关闭手机。顾客这么多,都在等着付款,我还需要输入复杂的密码,进入程序也太慢了吧。

场景二:

收完款了,我退出了程序。过了一会,新来了一位顾客,我打开程序继续收款,啊~我又需要输入密码了,好麻烦啊。

场景三:

一天工作结束了,看看我今天的收单数据吧。什么东西啊,我就是想看看收单数据,又要输入密码。

三个场景,我们总结出来共同的缺点:慢、麻烦。

慢,我怎么解决呢。以下是我的大致想法。

麻烦,怎么解决呢?同理了。

好了,既然初步定了这么个功能,是该考虑怎么去实现了。

手势密码存在本地还是存在服务器呢?

存在本地?当然可以,给它二次加密。只是我通过手势密码登录后,我的数据怎么得来呢,毕竟我没有登录账号密码啊。所以,咋办呢。让我的账号密码也缓存在本地,同时设置我的清除缓存功能不去干掉它,这样不就可以了吗。不安全?那再来个二次加密吧。

存服务器,当然也可以。我们让一个账号匹配两个密码呗,通过缓存我的账号,手势密码登录,我也可以照样获得我的账号数据,同时还不用将我的密码存在本地。

我使用的方法是存服务器,毕竟如果将两个密码都换存在本地,我还是觉得不安全。所以在这里我也只讲述客户端与服务器的逻辑交互了,存在本地的话其实也同理,只不过是客户端直接去做判断。

手势密码涉及到哪几个环节?

设置手势密码
修改手势密码
清空手势密码

既然知道了这几个环节,我们就该整理出实现这几个环节包括的内容出来。

设置密码 = 添加手势密码
修改手势密码 = 匹配手势密码 + 删除手势密码 + 添加手势密码
清空手势密码 = 删除手势密码

所以,无非就是涉及到这三种形式

Type1 添加
Type2 删除
Type3 匹配

常见流程:

产品经理

客户端与服务器怎么去做交互?

设置手势密码。用户先绘制第一遍手势密码,然后再绘制第二遍手势密码确认,这时客户端会判断第二次输入的是否正确,如果错误,清空数值,要求用户重新操作。如果正确,客户端通知服务器此时进行的是type1添加密码,同时将用户设置的各个点的数据传给服务器保存下来。这样设置操作就算完成了
修改手势密码。用户首先绘制原手势密码,客户端通知服务器此时进行的是type3匹配,同时将数据传给服务器比对,输入正确的话,服务器返回成功消息,于是用户有权限开始进行下一步操作了,下一步操作即为添加密码。
当用户点击清空手势密码。客户端返回类型type3给服务器,告诉服务器我现在是在进行清空密码操作,于是服务器收到请求后,直接将手势密码清空就完成了。

嗯,手势密码功能总算是做出来了,我是不是还应该判断一下我打开app时弹出来的界面是手势密码登录界面还是账号密码登录界面。

怎么做,我打开app时将账号传给服务器,让服务器判断一下此账号是否存在手势密码,如果存在,那就显示手势密码界面,如果不存在,那就显示账号密码界面。如果手机端不存在账号信息,那就直接账号密码登录。

总算搞定了,那还有没有考虑没到位的地方?

对了,我应该加一个次数限制吧。比如说,输入6次,就不准再输入了,只能使用账户密码登录。

为什么要加入次数限制这一条件?

这样想,如果允许用户无限次输入,那对于居心不良的人来说,是不是就可以随意破解了。也许你会说,设置的种类这么多,破解那得多难啊。然而,对于程序来说,这种密码的破解却很简单,所以出于安全性考虑,为了杜绝一切可能破解的因素,我们还是有必要加入次数限制。

因此,我们怎么去做。让服务器去判断次数,或者直接在本地判断次数,都是可以的,输入错误6次,即清空密码。在这里,我要说明的是,我为什么做直接清空而不是限制用户在多长时间内不准输入,每个人的思考点都会不同,也没有谁一定对谁一定错,存在即合理。

 

作者:Cw(微信号:小七的road)

关键字:产品经理, 产品逻辑, 功能, 客户端

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部