手势密码怎么设置

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

最近在负责一款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）

人人都是产品经理（）中国最大最活跃的产品经理学习、交流、分享平台