智慧車行需求設計
出門在外時,自駕游找不到停車位折騰了不少時間,面對這樣的游客顧慮,想必大家應該想到了游客的一些需求。作為產品經理,應當如何優化導航APP,讓大家更好地出行?本文結合該應用場景,進行產品設計分析,一起來看看吧。
產品設計核心流程:
剛過的新春,寵游客的重慶封閉了道路只為游客有更好的視野,再現了人山人海。那自駕游的大家,在停車的時候,遇到了一些啥情況呢?
一、應用場景
你知道哪里有停車場不?
那個停車場可以停多少車?還有沒有車位呢?
1.5元還是2元一個小時?
這是最常見的詢問方式了吧?只不過當前,導航系統都可以導航出來,就不再使用詢問的方式了。但是,導航搜索出來的停車場依舊沒有剩余車位和計價方式。嘿嘿,各位地圖導航的產品們,這就是需求喲 [偷笑]
這里司機師傅最關心的就是:哪里有停車場?停車場還有多少車位?停車費怎么計算?
既然都是智慧車行了,這些當然都需要提供。產品設計最核心當然是完善整個業務場景。
生活中一個小的問題,通過互聯網的方式來解決,就需要產品經理來轉化,將問題和解決方案融合起來。但問題只是整個解決方案的冰山一角,要解決方案能夠完整運行,就需要將整個業務的全貌找出來。停車場本身的信息,在這個問題里是沒有體現出來的,那么怎么做,才能完整整個業務流程呢?
梳理完整解決方案參與的角色及其所需要的功能(用例圖),然后串聯著整個業務流程(業務流程圖),將相關的所有因素串聯完整。
二、用例圖
智慧車行用例圖
司機知道哪里有停車場,停車費可接受,也能夠停進去之后,就會進行停車,然后去處理自己的事項。輔助這個決策,就需要知道 停車場位置、收費標準、是否有停車位。
隨著當下車牌識別技術的成熟,很多車庫已經無人值守。這就是信息化的便捷、效率。做以上的業務分析,本身在停車開車的場景下是閉環的。但在現實中是不夠的,很多停車場是小區的,是園區的,是公司的,那就需要更為完善的支持,提供停車月卡、年卡服務。
另外,若是小區物業的車或公司領導的車,是需要有特殊權限的,需要進行額外管理。
三、業務流程圖
智慧車行業務流程圖
整個停車場管理業務最小閉環業務流程包含:停車場管理流程、停車流程、開車離開流程。
停車場管理流程主要是維護好停車場基礎信息,如位置、停車位數量等;并設置好收費標準,為后續的費用管理奠定基礎。
司機開始停車,遇見門衛管理。門衛確認掃描信息,然后開門允許停車。是停車的流程。
司機辦完事情,開車離開。在車庫門口掃描,系統計費,然后繳費;經門衛確認后開門,開車離開。是開車離開的流程。
在真實的系統設計中,需要完善月卡辦理后的流程、以及設置白名單的流程,也就是離開掃描時,需要判斷資費類型,然后確定結算的處理方式。系統內部設計會復雜很多,但業務流程實際上就是這樣。厘清業務,對于系統設計,至關重要。
四、操作狀態圖
在停車業務場景中,業務流程相對比較簡單,比較清晰,也沒有太多狀態、操作需要管理。但在擴展的月卡管理上,就有較多的狀態操作需要管理。
通俗一些來說,月卡常出現的場景包含:辦卡、繳費、欠費、停用;而涉及系統的管理,就需要增刪改查等操作。如此,就包含了5個主要操作,也就包含了5個狀態。使得整體業務復雜度增加。在不同的月卡狀態,可以做哪些操作,就變得比較復雜和不好記憶。在頁面交互上,會在不能操作的情況進行對應按鈕的置灰或者隱藏,但如何在設計時候更明確的表達并向下宣貫,這個就很重要了。
設計下面的操作狀態圖,是不是就很明晰了。
月卡操作狀態圖:
月卡狀態在不同的操作下,進行了狀態的修改,實現了月卡數據流轉的核心流程,實現系統構建的完善。
月卡不同狀態有哪些操作:
月卡在不同狀態下有哪些操作,一是反向檢查流程是否有遺漏,二是明確的告訴下游開發、測試各個狀態下有哪些操作。相比于口述或者文檔表達,這里清晰明確。
在一開始的設計中,月卡操作狀態圖中的黃色連線,實際上是遺漏了的。
對應狀態可以進行的操作,有個簡便的處理方法:將所有的操作都放置到狀態下,然后把這個狀態下不可執行的操作刪除掉,最后統一整理即可。
五、交互設計
信息實體字段梳理
基于整個業務場景的分析,主要實現4個信息實體的管理:停車場管理(含車位管理)、月卡管理、白名單管理、出入記錄。其中,停車場管理、月卡管理、白名單管理為管理事項,而出入記錄才是使用最頻繁的模塊。
出入記錄
在臨停車輛出的時候,需要計算費用。系統可以通過出入記錄的費用計算和最終繳費經費作比對,以便對于門衛進行經濟方面的核查。
停車場管理
停車場和停車位是綁定的基礎信息,一次性維護。一般只會在停車場進行改造或者維修的時候進行調整。
這里實際引出來,車位的狀態里面還包含停用的情況,需要繼續完善需求。
月卡管理
月卡管理主要明確哪些車輛是通過月卡通過門禁的。這里需要注意是,開門時,若月卡已經欠費需要按照臨停規則處理,程序實現時需要做異常流程兼容。
白名單管理
白名單管理主要明確哪些車輛可以特殊權限通過。這里需要對有此權限的人員在業務中加以管理,謹防以權謀私。當然,這些情況都可以通過數據匯總統計的方式來進行監控。由數據來監察業務執行情況。
六、數據追蹤
經歷以上五個部分的逐步完善,整體需求就很明晰。在本身的設計邏輯上,不會存在巨大的漏洞,并通過整個過程的反復檢查,逐漸細致到每一個需求功能點。但,可能還是存在漏的可能!
如,第五步所示,出入記錄就缺少“費用”字段,這是在設計之初遺漏掉的,但在詳細設計時,發現并得以補充的。也就有了當前這一步,數據追蹤。
在系統實現中,所有的字段都是有意義的,需要明確字段在哪些場景會用到,最終在哪些場景消失。選用幾個字段,在每個場景中再去檢核一次,就會發現最后的遺漏。甚至于能發現業務不合理的地方,從而優化業務。
1,在停車位管理中,增加了“是否私家車位”,當前業務并沒有串聯該字段,也就是系統還需要繼續完善,或者在設計中去掉該字段;
業務中可能存在,私家車位就相當于白名單的情況,那就是創建車位時,選擇是 私家車位,就同時創建一條白名單;也有可能,辦理月卡就綁定車位,那就是月卡創建時,選擇車位就好。這就需要依據業務的具體情況來定。
但,即使因為這個變動要修改,系統變化始終可控的,并不會影響產品主框架。
2,錢是串聯整個業務的,那么,就用“費用”這個字段來檢核整個流程。
繳費發生在2個場景,一是臨停車掃描出停車場的時候(這里檢核出入記錄少字段的情況),二是月卡繳費的時候。線下業務每月需要做賬,那么線上,就可以出具臨停車繳費記錄、月卡繳費記錄,并做相應的統計??梢院途€下費用做核對,也可以依據該表單進行后續的數據分析,如:停車位的使用情況、月卡占比,以及同比環比的比較,從而挖掘出來,是否可以擴展一些停車業務。
數據追蹤的字段選擇,不必要太多個,也不一定非得專門挑選。這里主要是用字段這個角度,再次來檢核一遍整體的設計,完成設計本身的自閉環。
智慧車行的整體設計還并沒有完成,需要完成PRD文檔的撰寫,方便信息的傳遞和存檔,用于產品成長的追根溯源。
以上,在產品設計環節,并不一定需要每個環節都按部就班,隨著經驗的豐富、邏輯能力的完善,產品在接觸到這個業務的時候,就已經有了產品的大框架。這也是產品本身的提升和增效。終歸來講,業務流程的梳理,始終是非常必要的。
為何經歷產品經理這么嚴謹的思考,經過開發、測試反復驗證,仍有產品在上線后不符合使用者的預期,需要不斷的迭代。就是在于業務的分析不徹底,整體的流程未和現實業務相匹配。當然,本身也存在,線下業務因為種種復雜原因,需要進行特殊調控的情況。
保持開放的心態,盡可能的保證產品大框架的穩定性,終歸產品會在版本迭代中升華,面世中有那么多優秀產品就是明證。
當然,本期題為“智慧車行”,這里智慧體現遠遠不夠,或許,大家可以加一些柴火,燒的更旺。等你們喲~
本文由 @壹叁零壹 原創發布于人人都是產品經理。未經許可,禁止轉載。
題圖來自 Unsplash,基于 CC0 協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
還以為是賣車的車行hang。。。。