汽車行業:車牌信息輸入組件設計
本文結合生活中關于車牌信息輸入的實際體驗,發掘了系統鍵盤輸入的痛點,并展開了專用輸入組件的思考與設計。
序言
2007年1月9日,偉大的喬幫主(史蒂夫·喬布斯)在MacWorld大會上正式推出了第一代iPhone,至今已過去近13年了。為了帶來更好的用戶體驗,第一代iphone在硬件的設計上,摒棄了以往的物理鍵盤,開發了“虛擬鍵盤”結合手勢交互用于信息輸入,無疑是當時智能手機行業內的一大顛覆式改革。
我們聚焦于“虛擬鍵盤”本身來分析,“虛擬鍵盤”在日常生活的輸入場景中已經做的足夠的“好用”、“高效”,甚至于近乎完美。在“體驗經濟”愈演愈烈的今天,各行各業為了打造更好的輸入體驗,都圍繞著“虛擬鍵盤”并結合行業特性做著一些個性化的設計嘗試,比如我們今天我們要講的”汽車行業“。
行業聚焦
說到了“汽車行業”,我們首先從“汽車”本身開始說起,目前汽車共擁有兩個“身份信息”,一個是車架號(VIN碼)、一個是車牌號,在日常生活中我們最常接觸的就是車牌號,其次才是車架號。
從互聯網興起至今,各行各業為了營造更好的服務體驗,都走上了“互聯網+”/“移動互聯網+”的戰略路線,當然“汽車行業”也不例外。圍繞汽車本身衍生出了眾多對B端以及對C端客戶的汽車服務,如常見的“智慧停車、違章繳費、維修、保養、保險、車聯網…”一系列汽車服務,均可以在線上場景中體驗到。
我們在線上體驗汽車服務的同時,首先需聚焦于汽車本身,其核心要素之一就是“汽車身份信息”,在體驗流程中首先需要將車牌信息錄入系統,才能便于我們后續更好的對服務進行體驗(如:線上停車繳費、違章繳費、維保預約、保險理賠等眾多與汽車相關的場景)。
那么在“汽車行業場景”中使用“系統鍵盤”輸入車牌信息是否依舊還能達到“好用”及“高效”的體驗呢?
經過測試后得出了結論:在使用“系統鍵盤”輸入車牌信息時,雖然能夠完成輸入任務,但相比較于日常生活中的輸入體驗,使用“系統鍵盤”輸入車牌信息就顯得不是那么“好用”及“高效”了。
痛點分析
我們回到車牌本身來分析一下,使用“系統鍵盤”輸入車牌信息,從輸入體驗的角度來衡量,在“行業場景”下,“系統鍵盤”為何只被評定為“能用?”。
基于上述問題我們先從車牌開始說起,路面上常見的車是“私家車”和“警車”,從“國家車牌行業標準文件”中分析得出,常見的標準車牌是由“省份、城市、序號”三者組合而成的,其中具體信息又是由“漢字、英文、數字”構成的。
在“行業場景”下使用“系統鍵盤”輸入車牌信息,不夠好用、高效的兩個主要原因如下:
痛點一:輸入操作繁瑣
使用“系統鍵盤”在進行車牌信息輸入時,需要在漢字、英文、數字三者之間來回切換才能完成車牌信息的輸入任務”。
痛點二:無法達到標準化輸入
使用“系統鍵盤”輸入的車牌信息是否有效、是否符合國家標準最終還需要在輸入任務完成后依靠系統的校驗機制來驗證其有效性”。
上面所述的問題,雖然還稱不上是“痛點”,但是對于那些每天與車打交道的用戶而言也算是一個“不痛不癢”的問題,在細節(體驗)決定成敗的今天,細微的體驗問題我們也應當盡可能的讓其變得“完美”。
設計策略
基于上述問題,通過洞察分析我們發現了“設計機會點/發力點”,以“虛擬鍵盤”為抓手,明確了設計策略,開始著手設計符合行業特性的“專用輸入組件 ”。 在“行業場景”下通過“專用輸入組件”輸入車牌信息,圍繞“高效”(提高輸入效率)、“防錯”(定義防錯機制使得輸入的信息符合國家標準)兩個目標進行設計,從而使其在“行業輸入場景”下達到“好用”及“高效”的體驗。
目標與方法
基于上述的設計策略,我們明確了本次設計的核心目標 :解決輸入效率(提效)、解決輸入出錯(防錯機制)。
那么接下來我們分析一下國家對于汽車行業-車牌標準的相關政策與規則,從中挖掘達到設計目標的方法。
1. 認識車牌
在做分析之前我們需要對其關鍵因素(車牌)有一定的認知,下面所展示的車牌基本涵蓋了目前我國所有的車牌類型。其中包括常見的如“普通藍牌”、“普通黃牌”、“新能源車牌”、“教練車牌”、“警用牌”等。
2. 車牌分類
為了使車牌信息變得更具條理性,我們對其進行一次分類,分類的依據“是基于他們相互之間的組合規則與共性特征而決定的”。我們將其分為四大類:“普通車牌”、“特種車牌”、“新能源車牌”、“特殊類車牌”。
具體分類細則如下:
- 普通車牌:由 “省份/城市/序號” 組成的,其序號是由 “數字/字母” 構成的,這類車牌屬于 7 位數牌照。
- 特種車牌:由 “省份/城市/序號” 組成的,其序號是由 “數字/字母/漢字” 構成的,并且序號中 “漢字必須是車牌號的最后一位” ,這類車牌屬于 7 位數牌照。
- 新能源車牌:由? “省份/城市/序號”? 組成的,其序號是由 “數字/字母” 構成的,這類車牌屬于 8 位數牌照。
- 特殊類車牌:這類車牌因無共性規則,我們將其定義為特殊類。(這類國家特殊單位的車在我們的日常生活中/汽車行業內的工作中接觸到的機會也不會很多)。
3. 定義設計范圍
分類完畢后,我們定義一個設計范圍,因為在設計時我們往往很難通過一套設計方案來滿足所有車牌的輸入場景,所以在設計時我們會圍繞那些有規則的有共性特征的車牌進行組件的設計,從而滿足大部分的輸入場景。
根據車牌的分類規則,我們將“普通車牌”、“特種車牌”、“新能源車牌”三大類,定義在行業輸入組件的設計覆蓋范圍內。特殊類車牌雖然在日常生活中接觸到的概率較少,但是我們也應當盡可能的滿足其輸入場景,通過自定義車牌號的方式,調用“系統鍵盤”來完成其輸入任務。
4. 共性&差異
在明確了分類細節與設計范圍后我們對范圍內的三類車牌做一次共性與差異化的具體分析,以便于在組件設計時根據規則定義一些防錯機制(為了便于理解,防錯機制將會在Demo階段展示)
- 普通牌 & 特種牌:共性特征(組合規則一致、二者都屬于7位數牌照)差異(特種牌的序號中多了一個“漢字序號”,并且漢字序號必須是車牌號的最后一位)。
- 特種牌 & 能源牌:共性特征(組合規則一致)差異(特種牌屬于7位數牌照,且存在漢字序號,能源牌屬于8位數牌照,且不存在漢字序號)。
- 能源牌 & 普通牌:共性特征(組合規則一致)差異(能源牌屬于8位數牌照,普通牌屬于7位數牌照)。
5. 分析總結
通過上述的幾步分析,我們對國內的車牌有了一定的了解,并為其進行了歸納細分、定義了設計范圍、分析了范圍內各類車牌的共性以及差異,最后我們結合“國家車牌行業標準文檔”與上述幾步的分析結果,得出以下結論:
- 常見的標準車牌號是由“省份、城市、序號”組成的,省份位的字符必須是漢字(各省、自治區、直轄市簡稱),城市位的字符必須是英文(發牌機關代號:A~Z),序號位的字符必須是數字/字母組合(A~Z / 0~9),特殊序號位的字符必須是漢字(港、澳、掛、學、警)且漢字序號必須是車牌號的最后一位。
- 行業輸入組件定義為兩種:省份輸入組件(因國內省份較多所以將其作為一個獨立的組件)、車牌號輸入組件(該組件由英文、數字、漢字序號組成)。
- 特殊類車牌:這類車牌雖無共性規則,但需要滿足其輸入場景,通過自定義車牌號的方式,調用系統鍵盤來完成其輸入任務。
具體方案 – 省份輸入組件
省份輸入組件的結構分為兩部分:
第一部分是文字按鈕,點擊后調用“系統鍵盤”輸入自定義車牌信息。
(其一:滿足特殊類車牌號的輸入場景;其二:滿足一些自定義信息的輸入場景,例如我們通過調研了解到,汽車維修行業他們有時候不單單會錄入車牌信息,偶爾還會錄入一些特殊的車牌代號,比如灑水車001、警車003…)
第二部分是車牌號的省份簡稱(各省、自治區、直轄市簡稱)簡稱部分采用了國家地理行政區的劃分原則,對各區域內省份依次排序(排名不分先后)。
下面說明一下按照行政區劃分原則做為省份排序的好處:
以華東區為例,該區域包含了山東、江蘇、安徽、浙江、福建、上海這幾個城市,在同一個行政區內必然會有一/多個經濟體系相對發達城市;城市一發達,附近省份的外來車輛就會相對較多,例如在江蘇地區總會看到安徽地區的車輛一樣 。
現在的軟件基本都使用了定位技術,我們在外省進行車牌信息的錄入時,系統是會自動獲取并填寫當前所在地區的省份簡稱,以降低用戶使用鍵盤的輸入次數。如果我們是外地牌照車輛則需要將當前省份簡稱刪除,在修改為車牌的實際省份簡稱。
按照行政區作為省份排序的好處:在修改省份簡稱時,相鄰的省份在排序上會比較接近,這樣用戶在查找、選擇對應省份時比起按首字母排序/其他方式的排序,查找效率會相對更快。
具體方案 – 車牌號輸入組件
車牌號輸入組件分為三部分:
- 第一部分是自定義車牌號的文字按鈕 + 完成操作按鈕;
- 第二部分是漢字序號 + 數字序號的按鍵;
- 第三部分是英文序號以及刪除按鍵。
其中英文字母按鍵是由25個字母組成,缺少了字母 i ,因為大寫字母 i 與數字 1 的字體設計及其相似,導致兩者很難辨別,所以在“行業標準文件”中明確指出,字母 i 不可用于組成車牌信息。
當然“行業標準文件”中還指出了另一個字母,也不可用于組成車牌信息,他就是字母 O ,原因與字母 i 一樣,大寫的字母 O 與 0 及其相似,導致兩者很難辨別。
那么為什么我們的組件中還要包含字母 O 呢?
因為在過去字母 O 是作為公務車專用代號,存在于車牌號的第二位(城市代號位)俗稱“O牌特權車”,隨著O牌泛濫,特權肆意,有的省份就將 O 牌由公務專用改為了普通民用,還有的省份直接取消了 O 牌,當然還有部分省份還保留著 O 牌作為公務用車專用代號,所以我們的在組件設計中保留了字母 O (附圖,國慶期間恰巧抓拍的…)。
DEMO – 演示
為了更好的展示設計方案,以及便于大家理解其中的設計細節,下面我們通過DEMO的方式,定性的模擬幾種輸入場景,通過“專用輸入組件”并結合防錯機制進行車牌號的錄入。
場景一:車牌號省份簡稱修改
基于地理定位技術,進入信息填寫頁面系統會默認獲取到到當前地區的車牌省份簡稱,此時如果是外省車輛,則需要對省份簡稱做修改變更;其實車牌號第二位也能通過定位技術獲取到,但是目前我國存在一個城市擁有多個發牌代號的場景,例如蘇州市發牌機關代號“蘇E”、“蘇U”,包括一些直轄市也存在這種情況,所以這也是城市代號不默認獲取的直接原因;通過定位技術獲取信息本身是一種提效的策略,但是基于上述場景反而可能會適得其反。
場景二:輸入第 2 ~ 5 位車牌號
車牌號的第二位必須是英文,此時數字序號按鍵與特殊漢字序號按鍵為禁用狀態;當第二位車牌號輸入完畢時,數字序號按鍵變為可用狀態,此時無論輸入的第二位車牌號是否為字母 O 都必須將其禁用,因為字母O只會存在于車牌號的第二位。
場景三:輸入第 6 ~ 7 位車牌號 – 完成普通車牌的輸入場景
當第6位車牌號輸入完畢時,激活特殊漢字序號;當第7位車牌號輸入了英文/數字時,禁用特殊漢字序號;至此普通車牌號輸入完畢。
場景四:輸入第 6 ~ 7 位車牌號 – 完成特種車牌的輸入場景
當第6位車牌號輸入完畢時,激活特殊漢字序號,因為特殊漢字序號只會存在于車牌號的第7位;當漢字序號輸入完畢后,刪除按鍵除外的其余按鍵全部禁用,因為標準的特種車牌只有7位;至此特種車牌號輸入完畢。
場景五:輸入第 6 ~ 8 位車牌號 – 完成新能源車牌的輸入場景
當第6位車牌號輸入完畢時,激活特殊漢字序號;當第7位車牌號輸入了英文/數字時,禁用特殊漢字序號;當第8位車牌號輸入了英文/數字時,刪除按鍵除外的其余按鍵全部禁用,因為標準的新能源車牌只有8位;至此新能源車牌號輸入完畢。
場景六:演示特殊類車牌號的輸入方法
特殊車輛在我們的日常生活中/汽車行業相關業務中接觸到的概率教較少,但我們也應當盡可能的滿足其輸入場景;點擊自定義按鈕后,彈出系統默認鍵盤,此時車牌號輸入框中內容清空,文案變為“請輸入自定義內容”,用戶將信息輸入完成后系統不做強制校驗。
最后,我們又通過定性的方式,基于兩個輸入場景對組件的輸入效率進行了模擬預估,得出結論:使用“專用組件”輸入車牌信息,相比較于使用“系統鍵盤”輸入效率均大幅度得到了提升。
總結
俗話說“藝術產生情緒,設計解決問題”,設計是需要基于一定的規則體系之內,倘若設計脫離了商業/行業規則,缺少了解決問題的能力,那么其結果就可能就變成了一個耐人尋味的藝術品。
在細節(體驗)決定成敗的今天,如何將“癢點”變為“爽點”;如何通過細微的設計優化改良產品的用戶體驗甚至于影響到整個行業的體驗,這正是我們作為“產品人”/“體驗設計師”該深耕發力的地方。
作者:伊格,新康眾用戶體驗設計部
本文由 @伊格 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于 CC0 協議
大神,使和領呢,怎么考慮的?
正好用到,感謝。
是不是確認后的校驗、異常提示也要設計一下呢
寫的太好了。大神威武。
省份簡稱按首字母A~Z排序的話,會不會更快一點?
會的·
沒有必要 因為用戶更熟悉普通26鍵排列,按a-z排列反而要找一會兒
請問大神demo用什么做的
Principle
感謝
干活慢慢,很棒
看了將近20多分鐘。干貨滿滿收獲了很多,邏輯思路很清晰。通過行業組件為用戶帶來更好的體驗,從能用到很好用真的需要很深入的研究。高效-快捷-方便。值得學習
共勉 ??
挺好的車牌輸入法,思路也很清晰,值得借鑒