1 驗證是驗證什麼？爲什麼要驗證
驗證所存在的需求場景，就類似於人之間打招呼的場景。
首先打招呼前，需要讓機器明白即將作出一系列指令的主
體，即要打招呼的是“人”而不是“機器”，所以其驗證
目的之一是：對操作者是否爲人的身份驗證。
當機器知道了這就是要打招呼的對象後，爲了滿足整個行
爲的順利完成，得需要讓機器知道“你”是否有打招呼的
意願，即驗證目的之二是：對操作者是否本人意願操作的
驗證。
所有的驗證實質都是在滿足以上的目的。
02 流程可視化設計思路
於短信驗證流程是比較常規固化的基礎流程，在設計思路
上爲由抽象場景得出任務流程，再由任務流程具象交互界
面的思路。其中具象交互界面的思路會拆分爲考慮“展現
形式”以及“頁面元素”，以更好地優化體驗操作。
03 場景與流程
場景洞察
目前短信驗證的場景大部分存在於賬號登錄/註冊場景，
修改個人重要信息場景等。
對於這些場景，我們需要洞察的要點主要爲：
1.場景觸發——觸發這個場景的需求原因是什麼？
2.場景目的——這個需求實際是爲了解決什麼問題？
3.場景任務——解決這個問題用戶需要執行的任務是什麼
？
基於任務的得出，即可以得到用戶實際操作的一系列行爲
觸點，下面需要基於這些行爲梳理流程。
流程梳理
流程梳理主要藉助泳道圖的方式，以流程時間節奏以及參
與角色作爲橫豎維度劃分，梳理如下：
（由於本文主要討論前臺頁面設計，其中對後臺及第三方
短信平臺的行爲沒有作細緻展開。）
前臺頁面的設計，我們主要關注“用戶”和“前臺客戶端
”兩條豎軸的內容。
1.用戶豎軸
由此可見用戶主要的行爲分爲四步：
1）輸入手機號
2）獲取驗證碼
3）輸入驗證碼
4）提交
這四個行爲決定了頁面的功能呈現。
2.前臺客戶端豎軸
主要決定了一些需要在前臺展示的基礎狀態，梳理如下：
其中，流程和狀態的梳理只需一次性覆盤，後續的類似短
信驗證場景都可以快速地查看複用；但對於頁面細節的展
示，還是需要根據實際項目場景來分析，所以下面將詳細
介紹對於“展現形式”和“頁面元素”的思考。
04 展現形式的抉擇
頁面形式or彈窗形式
首先，先了解兩種形式的特性：
1.頁面形式
特點：內容承載範圍足夠大，信息承載能力強；體量重、
給人感覺穩定性更高；一般一頁只展示輸入驗證的功能，
無其他內容干擾。
2.彈窗形式
特點：多爲模態彈窗；輕量化、響應快；可以不中斷用戶
的當前核心操作，令用戶聚焦中心更集中以儘快完成驗證
進入下一步任務。
瞭解特性後，我們還需要明確的問題是：短信驗證最終的
展現形式，並不是由驗證流程決定，而是以其所存在的任
務場景來定。因爲驗證行爲一般不會單獨存在，肯定會有
前後任務場景的觸發，以更好地服務於場景目的的達成。
舉個栗子說明
某用戶換了新手機號碼後，爲了在京東上更好地獲得訂單
支付的短信提醒，需要修改綁定手機號的信息，因此需要
利用新手機號短信驗證的手段達到目的。
代入場景洞察分析要點來看：
爲了滿足“重新綁定手機號”任務的執行完整性與正確性
，短信驗證的操作步驟需要介入用戶輸入操作場景，它應
跟手機號輸入信息共同考慮。
在場景基礎上結合用戶訴求，可發現：
1）當用戶需要重新綁定手機號的時候，肯定需要在產品
中有一個穩定可找到的入口。因爲這個需求場景不是一次
性的，可能會產生多次，且修改手機號的信息相對爲個人
的重要信息，用戶會更嚴謹地對待這個修改需求。由於該
場景任務存在的必要性，該訴求的關鍵詞是：穩定性。
2）當在做短信驗證的時候，用戶希望能更聚焦，直接地
完成，認知上來講因爲只有修改這一件事情，不應該被其
他東西所打擾。基此的關鍵詞是：無干擾。
可見：結合前面梳理的形式特性，重新綁定手機號的場景
任務更適合利用頁面形式來展現。
那麼，對於彈窗形式，因爲其輕量快速響應，大部分會適
用於一些不好被打斷的場景任務。比如在某個一次性的H5
活動頁中，用戶需要通過以短信驗證手段，登錄賬號來領
取抽獎獎品。這個場景下選擇彈窗形式，讓用戶有一種就
差這一小步我就能馬上領到獎品的意識。若是頁面形式的
，則會讓用戶感覺該驗證步驟形式太重，擔心是否領取步
驟會很長或是否有成功領到獎品。
由於以上僅舉例頁面形式的場景，這裏再給大家總結一下
要點：
分步驗證or不分步驗證
由於短信驗證流程也算表單設計的其中一種，在做表單設
計時有一個體驗建議是：一個頁面最好只做一件事情。
回顧上面總結的“用戶”豎軸，用戶的四個行爲組成的任
務爲：
輸入手機號→獲取驗證碼→輸入驗證碼→提交
這裏實際是要確定兩件事情：手機號信息和驗證碼信息。
在體驗過不同競品後的感觸是：一步兩步其實對於實際操
作負擔並沒有那麼嚴重。因爲我一心只想着快點完成這個
短信驗證流程，從而登陸首頁或者成功修改信息。而分步
驗證的目的則正好是爲了達到高效專一。所以從體驗設計
來講分步會比不分步更優。