从功能看产品逻辑系列（一）该如何思考手势密码？

最近在负责一款app的功能迭代，在此版本里我加入了手势密码功能。我一直在思考这样一个问题，我们的产品已经有了账号密码功能，到底还需不需要加手势密码了？

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

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

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

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

产品人的产品论

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

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

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

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

手势密码的使用场景

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

场景一：

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

场景二：

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

场景三：

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

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

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

A: 用手势密码吧，至少速度上比输入密码快。

B: 这样也太草率了吧，有没有更快的方法？

A: 那就不使用密码，直接进入app。

B: 这样是不是不太安全啊，这可是涉及到商户的钱啊

A: 怕啥，支付宝不是也涉及到钱吗，不还是可以直接进入么。你想想他们是怎么解决这个问题的，他们是在涉及到钱的最后一个环节才添加密码功能

B: 对哦，我也许也可以借鉴一下。我再想想，啊~不行，支付宝和我们的产品面向的用户群及目的不一样啊。支付宝虽然涉及到钱，然而却不是一款使用频次很高的收款软件啊。如果我们的产品总是在最后一步开启密码功能，在这么高的使用频率下，效率不是提高，而是成倍的降低。

A: 是啊，还是放在第一步进入时开启密码吧，这样更合理。还有没有其他更快的解决办法呢？

B: 额，指纹解锁？好像还不太广泛适用。还有别的什么？算了，想不出来...

麻烦，怎么解决呢？同理了。

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

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

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

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

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

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

1. 设置手势密码
2. 修改手势密码
3. 清空手势密码

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

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

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

• Type1 添加
• Type2 删除
• Type3 匹配

常见流程：

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

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

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

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

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

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

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

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

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

 

作者：Cw（微信号：小七的road）

本文由 @Cw 原创发布于人人都是产品经理。未经许可，禁止转载。