如何把產品的癢點變成爽點?來看這個實戰案例

新康眾用戶體驗設計部 – 伊格:在細節(體驗)決定「成敗」的今天,設計該如何尋找支點撬動產品體驗,甚至於是行業體驗?

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位,至此新能源車牌號輸入完畢。

如何把產品的癢點變成爽點?來看這個實戰案例

場景六:演示特殊類車牌號的輸入方法

特殊車輛在我們的日常生活中/汽車行業相關業務中接觸到的概率較少,但我們也應當儘可能的滿足其輸入場景。點擊自定義按鈕後,彈出系統默認鍵盤,此時車牌號輸入框中內容清空,文案變為「請輸入自定義內容」,用戶將信息輸入完成後系統不做強制校驗。

如何把產品的癢點變成爽點?來看這個實戰案例

最後,我們又通過定性的方式,基於兩個輸入場景對組件的輸入效率進行了模擬預估,得出結論:使用「專用組件」輸入車牌信息,相比較於使用「系統鍵盤」輸入效率均大幅度得到了提升。

總結

俗話說「藝術產生情緒,設計解決問題」。設計是需要基於一定的規則體系之內,倘若設計脫離了商業/行業規則,缺少了解決問題的能力,那麼其結果就可能變成了一個耐人尋味的藝術品。

在細節(體驗)決定成敗的今天,如何將「癢點」變為「爽點」,如何通過細微的設計優化改良產品的用戶體驗甚至於影響到整個行業的體驗,這正是我們作為產品人、體驗設計師該深耕發力的地方。


分享到:


相關文章: