指紋支付的通病

最新 05-04

「mBack 系安卓手機」（正面按壓式指紋識別）很好用，但是它有一個不算硬傷的硬傷。

今天要講一個關於「mBack 系安卓手機」在指紋支付過程中的一個通病，仔細看看這篇文章，也許會幫助你避免去采坑。

P.S. 關於 mBack 後面我會詳細介紹。

起因

於我而言，將一台手機作為主力機的標誌是「在它上面登錄我的微信號」。

剛好上周我媽媽的手機壞了，我將手頭的 iPhone 寄回家給她用。於是我自己則開始打算將堅果 Pro 當做主力機用一段時間。

三天後，我在做 Android App 支付測試的時候，發現了一個 mBack 和指紋識別結合之後的交互問題，由於它涉及到「支付」。

我的微博原文：

Smartisan 的 Back 是輕觸 Home 鍵，在支付的時候，交互方式變成了輕觸是指紋識別而後支付，而 Back 被移動到屏幕上面，呈現為一個虛擬鍵。我剛剛在做付款測試的時候，本想 Back ，看看能不能從支付寶正常回到 App 裡面去，結果直接付款了￥699 ……..

所以我認為，我應該拿出來說一說。關於指紋識別，大家應該不陌生吧。

如上圖：mBack 有兩種最主要的操作方式：輕觸=返回（Back），按壓=回到桌面（Home）。魅族稱之為「用過就回不去的交互方式」，後來也被國內的很多廠商借鑒。

別忘了，之所以我最開始強調了一個概念「正面按壓式指紋識別」，意味著，這顆 Home 鍵是有指紋識別功能的。（下圖可以看清楚魅族的 Home 的功能）

當你單獨去看 mBack 和指紋識別的時候，它倆都是一種「用過就回不去的交互方式」，當時當它們應用到具體的支付場景中時，這個矛盾就出現了。

所以，我稱交互上採用與 mBack 同樣方式的手機為「mBack 系」。

當我在選擇支付寶或者微信支付後，會自動喚醒他們進行指紋識別，而此時，如果我不想支付，想要回退，在「肌肉記憶」的指導下，我很可能就會習慣性的輕觸 Home 鍵，以達到 Back 的目的，但是此時更高優先順序的指紋驗證會凌駕於輕觸 Back 之上，所以系統將我我心裡的 Back 判定成了通過「指紋識別」去執行支付操作。於是，我用 699 去測試一個功能的悲劇就出現了。

關於指紋支付和 mBack 的思考

Flyme 和 Smartisan OS 的 Back 操作是輕觸 Home 鍵、這個操作高頻高容錯率，通過指紋驗證去支付這個功能低頻低容錯率，並且指紋識別的優先順序高於 mBack 的優先順序。

Back 是一瞬間的操作，並且在系統裡面是一個高頻操作，習慣以後會形成肌肉記憶，當想要 Back 的時候會很自然輕觸 Home 鍵，基本上都不會去思考，那麼按照目前在支付場景下的邏輯就尷尬了，因為交互上出現了分場景的情況。如下圖所示，mBack 和指紋驗證出現交際的場景，恰好是支付的場景。

同一個交互存在兩種結果，一個是高頻高容錯率的 Back 操作、另外一個是低頻低容錯率的支付操作，很顯然，兩者在使用時候的心理壓力是完全不一樣的，因此後者所在的場景就很容易被前者的肌肉記憶所覆蓋，我想不止我一個人會遇到這樣的問題。在支付場景下，讓這兩者進行對抗，學習成本真的很高，另外退款成本也很大，很多虛擬服務壓根就不提供退款。

Flyme

Flyme 在支付場景下沒有做任何操作，Back 和 Home 都有可能觸發支付。

Smartisan

支付場景下，Back 被屏蔽，移動到了屏幕上一虛擬鍵的形式存在，這一點說明 Smartisan 意識到了這個問題，但是我認為它做得依舊不夠好。

解決思路

Back 是一瞬間的操作，手指觸摸到 Home 的時間可能只有零點幾秒種甚至更短，Home 鍵應該是可以識別手指的觸摸狀態（即，是否觸摸在 Home 鍵上），那麼按照這個想法，如果改成支付狀態下，輕觸 Home 鍵依舊是 Back ，觸摸不放開（兩秒，或者其它時間設定）被認定為支付。或者換一種方式，進入支付狀態，按兩下音量鍵去激活指紋識別，然後再進行支付，若不激活，則依然認定為 mBack。這樣是否可行呢？

說白了，就是在支付場景下增加一個判斷邏輯，去識別當前的觸摸和按壓操作是 Back 還是指紋識別，我個人認為，不要試圖去讓用戶學習有兩種結果的交互方式，邏輯上會很亂，特別是在兩者存在「優先順序」的情況下。