這些細節設計SaaS系統務必要統一
在做產品設計時,我們都知道要保持一致性才能讓我們顯得更專業。那這個一致性,包含了哪些東西?都有哪些細節?作者給我們分享了Saas產品都需要統一哪些信息,可以讓我們的設計看起來更專業。
滿足用戶業務流程的需要是B端SaaS系統設計的首要目標,也很容易在一些細節設計上沒有C端產品那么嚴謹。
而且一些龐大的SaaS系統需要多位產品經理協作完成,很容易在一些基礎術語命名和細節交互上不一致。
雖然這些細節不會影響系統功能的使用,甚至一些用戶對此都不敏感。但是作為邏輯嚴謹的產品經理,以下這些細節設計一定要在系統層面保持統一,最好作為系統級的產品規范來要求。
一、通用操作按鈕命名統一
(1)“增刪改”操作按鈕
“增刪改”我比較習慣的命名方法是新增、編輯和刪除。
新增:還有叫添加、創建的比較多。
編輯:通常還可以叫做“修改”
刪除按鈕一般沒有別的名稱。
(2) 內容保存和取消按鈕
對于內容保存的操作按鈕,我比較習慣使用“保存”和“取消”的叫法。有的系統不叫做“取消”,叫“返回”。
(3)二次確認框操作按鈕
操作的二次確認框的按鈕,常用的有“確認/取消”、“是/否”、“繼續/返回”等,個人比較推薦“確認/取消”的組合。
(4)停啟用狀態及操作按鈕
停啟用的狀態及操作按鈕,普遍統一使用的是“啟用/停用”。有時候我們會看到有有些系統的狀態叫“啟用中”、“生效中”、“在用”等。“停用”的狀態也叫作“已停用”、“停用中”、“已禁用”等。
(5)查詢按鈕
我個人偏愛“查詢”,還有叫作“搜索”、“檢索”、“查找”等。
(6)登錄/退出
還有比較常見的是“登入/登出”。
二、數據字段命名統一
(1)日期 vs 時間
XX日期和XX時間的欄位命名,建議采用以下原則:
內容只顯示日期的欄位叫“XX日期”:e.g. “就診日期:2021-3-26”;
日期加時間或者只顯示時間的叫“XX時間”:e.g. “就診時間:2021-3-25 15。
(2)類別、分類和類型
在標準詞語的釋義上,這三個詞各有側重點,這里我只介紹一下我個人的理解和使用習慣。
類別和分類在詞義上就明確的將事物進行歸類的意思,相對來說類型只是強調事物的共同點和特性。類別強調將事物按照某種標準進行歸類,分類則只要按照某種邏輯進行歸類就可以。
我個人使用的話,如果有確定的標準,則用類別;如果不是依照某種標準進行的歸類,則用分類;在已有類別和分類之外,需要按照其他特性進行區分,則使用類型。所以我個人基本上是按照類別>分類>類型的順序在使用。
(3)同意/批準/通過、拒絕/駁回/不通過
這些按鈕都是在審批流程相關的功能經常用到的。根據需要審批的業務場景,特定的描述可能更加合適。
但我個人傾向還是在術語上進行統一,比如我基本上會使用比較通用且語義上比較柔和的“通過/不通過”。
這樣的好處是在做報表和數據分析時,不需要先對這些描述進行對照,直接根據這兩個狀態值就對整個系統的流程結果進行篩選。
三、專業術語統一
所做的SaaS系統是哪個專業領域,對應的專業術語一定要準確和統一。拿我熟悉的醫療系統舉個簡單的例子,最常用的“醫生”字段,我們不能出現像“大夫”、“專家”、“治療師”等通俗表達,而且在職稱和官方表述中都使用“醫師”。所以在系統層面最好統一使用“醫師”。
四、頁面命名規范統一
頁面的命名,建議遵循以下兩個原則:
(1)業務功能頁面直接以業務本身命名:“西藥字典”、“出差申請”,以名詞或者動賓結構為宜。
(2)維護界面:單純的數據維護功能界面叫“xxx維護”,帶有其他功能的綜合性功能界面可以叫“xxx管理”。
五、基礎交互統一
(1)查詢:下拉框篩選選項,條件為空時查詢全部 or 選擇為“全部”選項時查詢全部數據。
(2)查詢:查詢條件是都有單獨標題 or 統一使用暗提示。
(3)操作:哪些狀態變更操作需要有二次確認框,系統需要有統一的規范,一般包括刪除、啟用、停用等。
提示語可以采用通用的文案,這樣也就不會因為頁面其他元素的調整而需要調整提示框文案。例如:請確認是否要刪除所選內容?
專欄作家
吳之貓,微信公眾號:有不知,人人都是產品經理專欄作家。健康管理小碩,醫療健康產品汪+文藝貓。
本文原創發布于人人都是產品經理。未經許可,禁止轉載
題圖來自Unsplash,基于CC0協議
該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。
- 目前還沒評論,等你發揮!