使用者體驗的細節設計——關於校驗的問題

編輯導語：細節設計對於提升使用者體驗方面十分重要，本篇文章作者針對校驗的細節設計問題進行分析。透過列舉具體案例進行分析，講述了校驗的設計型別和考察的維度等，一起來學習一下吧，希望對你有幫助。

為了讓產品或者服務能夠正常使用，產品經理總是會設計各種規範，控制和引導使用者按照設計者的意圖去進行操作。

譬如在各種輸入框做校驗，如果不符合規範則會有相應的提示。

這不是一個複雜的事情，但卻是一個很影響使用者體驗的部分，細節才真正體現產品的實力。

所以校驗的設計是很重要的，我們今天就聊一聊這個話題，重點是聊一聊校驗設計的邊界問題。

必要的鋪墊還是要有，所以講一講校驗設計的基礎。

為什麼要做校驗？剛才講過了，是為了讓使用者可以順暢的使用產品和服務。

譬如最簡單最常見的使用者註冊，大家現在都習慣用手機號註冊，那麼在手機號輸入框的部分，使用者輸入之後一般會先對這個輸入的內容進行格式校驗，這樣能最大程度保證系統發出驗證碼的時候使用者是能收到簡訊的。

所以這種校驗本身就是為了讓使用者更好的繼續使用產品和服務。

校驗有哪些型別？一般就三種：一種是規範校驗，一種是一致性校驗和安全性校驗。

規範性校驗就是前面講的手機號校驗這種，根據固定的要求進行校驗，產品經理會給出這些規範，一般也就是字元型別、字元長度這樣的規範。

一致性校驗指的是實名校驗、銀行卡校驗這種的，使用者在輸入資訊之後會呼叫第三方的權威資料來源進行校驗，看輸入的資訊是否是真實的。

當然做一致性校驗之前一般都會做規範校驗。

安全性校驗的話一般涉及到賬號、敏感資訊和交易（資金流動）的時候會出現，譬如使用微信支付或者支付寶支付的時候需要輸入交易密碼來驗證是本人發起的交易。

但校驗是有邊界的，做不做校驗、做到什麼程度是有一些判斷標準的，我們重點聊一聊這部分。

校驗設計

主要是考察三個維度，一個是必要性，一個是可行性，一個是成本可控。

必要性，這是最重要的考察維度，原則上規範性校驗和安全性校驗應驗盡驗，能校驗的都要做校驗，至於一致性校驗則要看情況。

規範性校驗雖然在開發和測試過程中會繁瑣一點，但是對使用者友好。

當然，這就要求產品經理在所有需要校驗的地方都標出校驗規則，不難但是繁瑣。

譬如同樣是輸入框，姓名輸入框和手機號輸入框校驗規則是不一樣的。

譬如類似的輸入框校驗規則最好保持一致，如需要輸入公司名稱和公司地址，其實沒必要做特殊要求，那麼校驗規則就可以保持一致，這樣的話校驗規則的型別就會盡可能的少，便於記憶和管理。

如果是後臺系統的，最好也都做一下校驗，避免在app端出現不必要的錯誤。

安全性校驗那肯定是必須的，涉及到賬戶、敏感資訊和資金安全的都是必須校驗的。

一致性校驗以實際使用場景和設計意圖為準，譬如前面講到的繫結銀行卡這個操作，那麼是必須要做一致性校驗的，因為後續會涉及到交易或者資金流動。

但也有不做校驗的，譬如微信支付的親屬卡。

親屬卡的操作流程是這樣的：

我的->服務->錢包->親屬卡->贈送->選擇贈予物件（關係屬性）->在好友中選擇物件->設定支付額度->輸入交易密碼。

整個過程中實際上只在最後做了安全性交易，並沒有做親屬關係是否真實的一致性校驗。

為什麼不做？沒有必要做，實際上對於微信來說根本不關心使用者選擇的物件是不是真的是使用者的親屬，微信設計這個功能的本意就不包含關係是否真實的考慮。

只要校驗密碼是對的，就表示這種關係的繫結是使用者本人的意願，這就可以了。

雖然從功能本身來說是，的確使用者可以繫結任何好友，但是從實際的使用場景來說使用者真的會給一般的朋友開通這個親屬卡的功能嗎？

不存在的，只有親屬和戀愛物件這樣的親密關係才會給予開通，這是關係屬性決定的。

再好的朋友也不可能每個月給零花錢吧？所以根本沒有必要校驗關係的真實性。

所以關於一致性的校驗是以實際場景為準的，當然還包含了設計意圖的考慮。

可行性，這也是很重要的考察維度，如果想校驗但是做不到或者校驗難度太大，那就肯定不校驗了。

我舉兩個例子：

還是剛才前面的微信親屬卡的這個例子，假設微信覺得有必要校驗使用者繫結的親屬關係是否真實，微信自己肯定沒有這個資料來源可以校驗真實性，第三方有沒有，有的，公安機關的資料庫裡肯定有這個資料來源。

但是公安機關也肯定不會開放給微信使用的，所以微信即便是想校驗也做不到，那肯定就不校驗了。

類似的，在個稅app裡申報個人所得稅的時候，如果父母（其中有一位即可）超過60週歲是可以申報贍養老人專項扣除的，申報的時候只需要填寫父母一方的身份證資訊即可。

這種情況下，如果要校驗的話是有可能做到的，稅務機關和公安機關同屬國家機關，理論上是可以協調的。

當然實際有沒有校驗我就不知道了，我不可能為了測試去繫結別人的身份證。

再譬如信貸系統中的風控系統，會設定很多風控規則，來判斷哪些使用者符合要求，哪些使用者不符合要求。

有些組合的風控規則過於複雜，一個點一個點設定操作過於繁瑣而且可能還不能滿足需求。

這種情況下可能會讓風控人員直接輸入表示式（邏輯程式碼）來實現，一般人根本看不懂這個。

這種表示式的校驗就屬於校驗難度太大的型別。能不能校驗？理論上可以的，但是難度太大，出規則的難度大實現的難度也大，那就沒有必要，還不如人工校驗更簡單一點。

成本可控，這是必須要考慮的，公司是商業組織，必須考慮資金成本的問題。

像繫結銀行卡、或者身份證實名認證、活體識別這種呼叫三方資料來源進行校驗的必然是要付費的，付費就涉及到一個成本控制的問題。

當然實際上來說對於是否採用付費方案的考慮是幾乎沒有的，因為前面兩個維度的重要性壓過了這一條，只是在根據不同的安全性或者合規性要求採用不同的驗證方案而已，儘可能控制成本。

譬如使用支付寶進行支付只驗證交易密碼，但如果查詢公積金（支付寶小程式）的話就會要求做人臉識別，就安全性的要求來說肯定是支付>查詢的，畢竟支付涉及到資金的流動，而查詢只涉及到資訊保護的問題，但是因為不同主體對合規性的要求不同，所以做法不同。

就實際來說，校驗這個部分並不起眼，因為不可見，但是對於使用者體驗是有很大的影響的，而校驗規則是否合理、是否全面和細緻就是一個比較重要的關切點，所以要多做考量。

對於做不做這個問題大家其實不會有太多爭議，但是對於怎麼做、做到何種程度其實大家的認識是不一樣的，我覺得大家可以重點從可行性和成本控制這個部分去考慮，儘可能在系統層面多做一點，保障使用者體驗。

本文由 @產品人玄青 原創釋出於人人都是產品經理。未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議