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

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

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

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

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

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

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

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

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

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

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

一致性校驗指的是實名校驗、銀行卡校驗這種的，用戶在輸入信息之后會調用第三方的權威數據源進行校驗，看輸入的信息是否是真實的。

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

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

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

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

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

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

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

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

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

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

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

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

親屬卡的操作流程是這樣的：我的->服務->錢包->親屬卡->贈送->選擇贈予對象(關系屬性)->在好友中選擇對象->設置支付額度->輸入交易密碼。

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

為什么不做？沒有必要做，實際上對于微信來說根本不關心用戶選擇的對象是不是真的是用戶的親屬，微信設計這個功能的本意就不包含關系是否真實的考慮。

只要校驗密碼是對的，就表示這種關系的綁定是用戶本人的意愿，這就可以了。

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

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

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

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

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

我舉兩個例子：

還是剛才前面的微信親屬卡的這個例子，假設微信覺得有必要校驗用戶綁定的親屬關系是否真實，微信自己肯定沒有這個數據源可以校驗真實性，第三方有沒有，有的，公安機關的數據庫里肯定有這個數據源。

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

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

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

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

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

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

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

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

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

像綁定銀行卡、或者身份證實名認證、活體識別這種調用三方數據源進行校驗的必然是要付費的，付費就涉及到一個成本控制的問題。

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

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

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

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

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

題圖來自 Unsplash，基于 CC0 協議