从功能看产品逻辑系列（一）该如何思考手势密码？
我非常清楚要不要加一个功能，不是我说了算，不是身边的同事说了算，只有用户说了才算。我一直问自己，你做了用户调研了么？你有数据分析么？
很遗憾，这些我都没有做。我们的产品对象是成千上万个商户，每个商户包括几个门店，几十个门店的都有，每个门店又包括不等的店长、收银员，所以说产品使用者的数量虽然比上不足，但比下有余。有这么多的用户，我为什么不利用这些去做个调研再来决定做不做呢？
也许我会说，乔布斯在设计iPhone4的时候还会去问用户需要怎么做么？张小龙在设计微信的时候会去调研用户需要及时通讯，需要语音对讲，需要摇一摇吗？
But，两位在产品界被誉为神话式的人物，是不可能被轻易模仿出来的。我要说的是一个共通性，产品人的产品论。
产品人的产品论
每个产品人都有一套他自己的产品论。这不是看来的，学来的，而是切切实实从做产品的过程中积累来的。作为一个pm，你有一套产品论，我有一套产品论，他有一套产品论。
我以为，一个功能是否需要调研须经过深思熟虑才能做决定。不是每立项一个功能，就是去做调研，这只会白白浪费时间。也许你会持不同意见，可当你发现调研得来的数据虽然时常帮助了你，但有时却仅仅只是验证了当初的想法而已的时候，你该去总结思考一下了，这个数据结果对我来说真的需要花费这么多精力才能明确么。
通常来说，我不想将时间常浪费在一些不必要的数据问题上面，毕竟，我每一天都在想产品，一整天都在想产品，睡前在想，醒来也在想，不是刻意的去想，而是不由自主的去想，想多了，脑袋也累。我时不时的会希望某一个时间，给自己放一个假，啥也不想，去旅游，去放松，这样当我再回来看我的产品的时候，可能思考的结果又不一样了。这让我想起了曾经上学的时候写作文，可能当时会觉得写的很好，可一旦过了一个月、两个月再回头看的时候，会突然觉得写的很搞笑。人常常就是这样，某个时间段的思维被固化了，常需要在以后的某一天才会开窍。
废话说了这么多，该回到正题了。
手势密码的使用场景
好了，我想说的是我们现在做的是一款收款工具，这其中当然得涉及到跟钱有关的事情，为了商户的账户安全，我们的做法是用户每次打开app，都需要输入账号密码才能登录。试想这样几个场景：
场景一：
我是商家，现在我的pos机系统（这个是用来配合pc端的收款系统使用）出故障了，怎么办，这时我需要掏出我的手机，打开app，输入密码，收款。收完了，关闭手机。顾客这么多，都在等着付款，我还需要输入复杂的密码，进入程序也太慢了吧。
场景二：
收完款了，我退出了程序。过了一会，新来了一位顾客，我打开程序继续收款，啊~我又需要输入密码了，好麻烦啊。
场景三：
一天工作结束了，看看我今天的收单数据吧。什么东西啊，我就是想看看收单数据，又要输入密码。
三个场景，我们总结出来共同的缺点：慢、麻烦。
慢，我怎么解决呢。以下是我的大致想法。
麻烦，怎么解决呢？同理了。
好了，既然初步定了这么个功能，是该考虑怎么去实现了。
手势密码存在本地还是存在服务器呢？
存在本地？当然可以，给它二次加密。只是我通过手势密码登录后，我的数据怎么得来呢，毕竟我没有登录账号密码啊。所以，咋办呢。让我的账号密码也缓存在本地，同时设置我的清除缓存功能不去干掉它，这样不就可以了吗。不安全？那再来个二次加密吧。
存服务器，当然也可以。我们让一个账号匹配两个密码呗，通过缓存我的账号，手势密码登录，我也可以照样获得我的账号数据，同时还不用将我的密码存在本地。
我使用的方法是存服务器，毕竟如果将两个密码都换存在本地，我还是觉得不安全。所以在这里我也只讲述客户端与服务器的逻辑交互了，存在本地的话其实也同理，只不过是客户端直接去做判断。
手势密码涉及到哪几个环节？
设置手势密码
修改手势密码
清空手势密码
既然知道了这几个环节，我们就该整理出实现这几个环节包括的内容出来。
设置密码 = 添加手势密码
修改手势密码 = 匹配手势密码 + 删除手势密码 + 添加手势密码
清空手势密码 = 删除手势密码
所以，无非就是涉及到这三种形式
Type1 添加
Type2 删除
Type3 匹配
常见流程：
客户端与服务器怎么去做交互？
设置手势密码。用户先绘制第一遍手势密码，然后再绘制第二遍手势密码确认，这时客户端会判断第二次输入的是否正确，如果错误，清空数值，要求用户重新操作。如果正确，客户端通知服务器此时进行的是type1添加密码，同时将用户设置的各个点的数据传给服务器保存下来。这样设置操作就算完成了
修改手势密码。用户首先绘制原手势密码，客户端通知服务器此时进行的是type3匹配，同时将数据传给服务器比对，输入正确的话，服务器返回成功消息，于是用户有权限开始进行下一步操作了，下一步操作即为添加密码。
当用户点击清空手势密码。客户端返回类型type3给服务器，告诉服务器我现在是在进行清空密码操作，于是服务器收到请求后，直接将手势密码清空就完成了。
嗯，手势密码功能总算是做出来了，我是不是还应该判断一下我打开app时弹出来的界面是手势密码登录界面还是账号密码登录界面。
怎么做，我打开app时将账号传给服务器，让服务器判断一下此账号是否存在手势密码，如果存在，那就显示手势密码界面，如果不存在，那就显示账号密码界面。如果手机端不存在账号信息，那就直接账号密码登录。
总算搞定了，那还有没有考虑没到位的地方？
对了，我应该加一个次数限制吧。比如说，输入6次，就不准再输入了，只能使用账户密码登录。
为什么要加入次数限制这一条件？
这样想，如果允许用户无限次输入，那对于居心不良的人来说，是不是就可以随意破解了。也许你会说，设置的种类这么多，破解那得多难啊。然而，对于程序来说，这种密码的破解却很简单，所以出于安全性考虑，为了杜绝一切可能破解的因素，我们还是有必要加入次数限制。
因此，我们怎么去做。让服务器去判断次数，或者直接在本地判断次数，都是可以的，输入错误6次，即清空密码。在这里，我要说明的是，我为什么做直接清空而不是限制用户在多长时间内不准输入，每个人的思考点都会不同，也没有谁一定对谁一定错，存在即合理。
作者：Cw（微信号：小七的road）
关键字：产品经理, 产品逻辑, 功能, 客户端
版权声明
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符，请点击 举报 进行投诉反馈！
