最近在負責一款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. 當用戶點擊清空手勢密碼?？蛻舳朔祷仡愋蛅ype3給服務器，告訴服務器我現在是在進行清空密碼操作，于是服務器收到請求后，直接將手勢密碼清空就完成了。

嗯，手勢密碼功能總算是做出來了，我是不是還應該判斷一下我打開app時彈出來的界面是手勢密碼登錄界面還是賬號密碼登錄界面。

怎么做，我打開app時將賬號傳給服務器，讓服務器判斷一下此賬號是否存在手勢密碼，如果存在，那就顯示手勢密碼界面，如果不存在，那就顯示賬號密碼界面。如果手機端不存在賬號信息，那就直接賬號密碼登錄。

總算搞定了，那還有沒有考慮沒到位的地方？

對了，我應該加一個次數限制吧。比如說，輸入6次，就不準再輸入了，只能使用賬戶密碼登錄。

為什么要加入次數限制這一條件？

這樣想，如果允許用戶無限次輸入，那對于居心不良的人來說，是不是就可以隨意破解了。也許你會說，設置的種類這么多，破解那得多難啊。然而，對于程序來說，這種密碼的破解卻很簡單，所以出于安全性考慮，為了杜絕一切可能破解的因素，我們還是有必要加入次數限制。

因此，我們怎么去做。讓服務器去判斷次數，或者直接在本地判斷次數，都是可以的，輸入錯誤6次，即清空密碼。在這里，我要說明的是，我為什么做直接清空而不是限制用戶在多長時間內不準輸入，每個人的思考點都會不同，也沒有誰一定對誰一定錯，存在即合理。

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

本文由 @Cw 原創發布于人人都是產品經理。未經許可，禁止轉載。