業務訂單的設計流程詳解(2)
本文主要說明訂單功能在產品設計中常見的信息架構與設計思路,希望幫助未接觸過訂單模塊的產品經理對于設計流程有大致的了解。
一、訂單信息設計
在完成了流程和狀態的設計之后,需要進一步確認訂單包含的所有信息
1. 確認訂單編碼生成規則、標識
訂單編碼有一個最常見的也是最簡單的組成方式,標識+時間戳+隨機編號,如果是企業內部的訂單或者預計訂單量不會非常龐大的話,完全可以使用這套規則來生成訂單,這樣內部人員在看到訂單編碼的時候就能迅速分辨出訂單類型和訂單日期。
- 標識:可以為純數字,可以為英文組合
- 時間戳:一般為YYMMDDHHMM格式,
- 隨機編號:一組隨機數字,根據上面時間戳的末位和訂單預計生成量來決定使用多長的隨機編號
如果是外部訂單,為了不容易被發現規則,以上3個元素的位置可以任意組合。
現在主流平臺的外部訂單大多都已經不使用以上組成方式,一來是因為這種編碼方式太過直白,容易暴露例如訂單量等公司內部信息,二來是因為當要在短時間內生成大批量訂單的時候,為了確保訂單編碼不重復,就要重復比對歷史訂單。隨機碼越長時,對服務器造成的壓力也就越大。
2. 訂單編碼的重要原則
(1)唯一不重復
無論生成規則如何設計,最重要的就是一點,保證訂單編碼的唯一性。
(2)安全
訂單編號不能暴露出公司的信息
(3)控制長度
訂單號的主要作用是查詢,在某些需要輸入或者用戶念出來的情況下,訂單號長度并不是越長越好。
(4)盡量保持純數字
純數字的檢索在數據庫訂單查詢時效率要高于文本型(字母加數字)
以淘寶訂單為例,84034576013582XXXX,
總共18位,前14位為序號,15-16位買家ID的倒數1-2位,17-18位買家ID的倒數3-4位
3. 確認字段及字段規則
訂單的字段往往包括幾大模塊
- 基本信息:包括訂單編號、用戶名稱、提交時間等等
- 商品信息:包括商品名稱、數量等等
- 支付信息:包括總金額、支付金額、優惠金額等等
在開始設計各個端口的線框圖原型之前,最好將所有字段用表格或者腦圖羅列出來,避免后續設計過程中遺漏了重要的字段。
二、訂單操作設計
1. 基礎操作-增刪改查
對訂單的操作本質上跟對數據庫的操作一樣,常見的基礎操作無非就是增刪改查、提交、取消這幾個。
在設計操作時,最重要的有幾點:
- 操作的條件——需要滿足什么樣的條件下才能進行當前操作?訂單處于什么狀態?相關的其他數據處于什么狀態?
- 操作的影響——這一步操作完成之后,訂單會發生什么樣的變化?會影響到哪些功能和數據?
- 操作的結果——操作的時候會得到什么結果?會遇到什么樣的異常狀態?需要怎么處理?這是設計時常常會遺漏的部分,最好把所有可以預想到的結果梳理出來,避免后面開發的時候發現問題。
- 操作的可撤銷性——操作是否可逆?如果不可逆是否考慮增加二次確認讓用戶充分了解操作的后果?
2. 操作權限
訂單具備業務承載作用,是安全性要求很高的數據。雖然在實現層面不需要對訂單模塊單獨開發一套權限功能,但是一定要明確不同權限用戶對訂單的操作。
三、訂單列表設計
對訂單的內容完成了設計之后,就要開始進行列表的設計。
1. 列表字段
同樣是訂單列表,移動端和PC端的表現形式相差很遠,但是在把訂單字段全部列出來的情況下,第一步需要做的就是把重要且必須的信息抽出來組合成表單。
在這里說幾個常見的移動端和PC端設計上的區別
(1)內容展示量
相比起PC端,移動端每一屏能展示的內容更少。在常見的電商平臺移動端里,就算是大屏手機一屏幕最多也就展示2-3個訂單,所以在展示字段和確認布局的時候就要更加嚴格,不能什么字段都往上塞。
(2)操作側重點
移動端的特性決定了訂單列表的更多作用是查看最近的訂單和快速操作,PC端則是在這個基礎上承載了更多,例如對歷史訂單的查找和管理功能。
淘寶的PC端有多個篩選條件、排序等功能,而移動端則是只能按照訂單時間順序排列,頂端也只有一個輸入框對商品標題或訂單號進行搜索。
2. 列表操作
對列表的操作可以分為幾類:查詢、篩選、排序。
以下為各類操作需要注意的點
- 查詢——要區分開精準搜索、模糊搜索,對文本類一般為模糊搜索,而對訂單編碼類的則是精準搜索;
- 篩選——注意選項是否可多選,是否有全選的選項(等于空選項);無論是查詢還是篩選,操作所指向的字段最好能與列表中的字段對應得上。例如對訂單金額進行了篩選,可是訂單列表中卻沒有出現訂單金額的字段,用戶會對搜索結果感到困惑,不知道對列表的操作是否已經生效了。
- 排序——常見的排序是對時間字段進行正序或倒序排列,如果需要對文本類型的字段進行排序,最好是先了解數據庫的排序規則;
小結
常見的訂單設計從梳理流程開始,到訂單字段、列表的設計就算是結束了。但是還有很多更加復雜的功能尚未提及,在實際系統構建過程中需要注意靈活運用,靈活設計。
#相關閱讀#
本文由 @PM林鹽 原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
非常干貨,很細節