B端產品日記——表單設計

3 評論 1.6萬 瀏覽 93 收藏 13 分鐘

編輯導語:表單在很多工作和項目中都會用到,在一個項目中,會涉及到大量的數據、信息等等,這時候用表單進行記錄是很重要的;本文作者詳細的介紹了在B端產品設計的工程中運用到的表單設計,我們一起來看一下。

人們眼中的天才之所以卓越非凡,并非天資超人一等,而是付出了持續不斷的努力;1萬小時的錘煉是任何人從平凡變成世界級大師的必要條件?!窭峦枴懂愵悺?/p>

在過去幾個月中,筆者一直在B端審核系統、流程管理系統、業務管理后臺、電銷系統中來回游走;下面將工作中積累的一些經驗和思考梳理匯總,希望能夠輸出為有用的分享,得到更多的前輩指教與更多的同道交流。

初遇表單這個問題,往往會直接跳過,但是最近幾次B端產品設計過程中,卻深深感受到表單設計的痛苦。

現實情況是——絕大多數的企業員工往往把時間埋沒在海量的表單中。

一、表單的使用場景

表單在B端產品中,是最為常見的一種信息展現方式;不論是傳統行業還是泛互聯網行業的產、銷、供、管等場景中,都涉及到大量的業務信息和數據,表單是最為簡單直觀的表現載體。

表單的概念并非互聯網原創,在傳統行業中,紙質化的表單就占據了非常重要的工具地位;B端產品通過為表單增加屬性,使得一個個任務表單能夠在動作——狀態機中流轉,就能夠實現業務的線上化開展和管理。

二、表單的基本結構

B端產品的表單,常常由以下三部分構成:列表、功能和搜索。

表單設計屬于B端產品頁面設計中的一種,在B端產品頁面中,常見的信息元素都可以劃分為:展示項和操作項。

在表單中,列表項常常被認為是展示項,功能和搜索歸類為操作項;其中搜索又可以理解為一類特殊的操作——不對表單信息產生影響的獨立操作。

1. 列表

列表是承載表單信息的主體,單一列表常展示某種狀態或某幾種狀態的數據。

設計時注意以下三點:

1)提取信息展示的維度

列表由字段構成,但并非所有的信息字段都需要在列表中進行展示。

原則上,設計時需要調研并確定:業務上針對當前表單中,需要關注的信息維度。

例如在質檢場景中,產品批次、抽樣數量、業務員信息等,屬于質檢表單中應該呈現的信息;而其他更多與質檢業務無關的產品屬性則不需要體現和關注。

列表只展示當前頁面使用者所需關注信息的最小集合——尤其是當內容不同時會引起用戶不同操作的字段,應該給出更高的展示優先級。

2)注意排序條件和分頁

常見的列表排序維度有:時間維度、處理優先級維度等。

時間維度常常使用的是列表中數據生成的時間,例如訂單列表中,可以依據訂單生成的時間順序展示訂單;這種設計便于用戶先處理創建時間早的任務,符合現實中先到先處理的邏輯,避免壓單或超時。

處理優先級維度,是指系統依據一些限定條件,為列表任務增加了優先級屬性,例如處理人員相同時,可以為vip客戶的訂單提高處理優先級,在列表中較前的順序展示,保證先被受理,提升客戶體驗。

3)設計技巧

列表表頭除了展示字段名稱信息之外,本身也可以擴展一些排序的屬性,例如當列表默認為依據“創建時間”順序排列時,可以增加一個這樣的設計:點擊“創建時間”的列名,即可將列表切換為倒序排列。

這一技巧可以很好的支持用戶查看最新的列表數據,簡單便捷且沒有理解成本,在實際業務中非常有用。

此外,當列表需展示的字段較多時,也可以對相似的字段進行合并展示,例如:總處理量、待處理量和已處理量,這三個相似且有關聯的字段,可以合并展示;在字段名中通過“/”分隔三個字段名,在列表數據中展示為”3000/1500/1500″,這樣可以有效地縮小列表寬度、避免字段過多帶來的雜亂感。

如果擔心字段合并展示會引起用戶誤解,還可以在字段名后方展示“?”的提示圖標,鼠標懸浮即展示字段信息說明,以達到消除誤解的目的。

2. 功能

當表單中通過列表展示了用戶需要關注和處理的信息后,還需要依賴一些表單功能,幫助和支持用戶完成業務操作,實現B端工單正向、逆向以及異常狀態下的處理流轉。

1)列表功能圍繞

增、刪、改,3個方面設計。

常見的表單功能有:查看詳情、處理、駁回/刪除、轉單、掛起、抽取/獲取、追加數據等;可以根據用戶在當前表單期望完成的動作進行選擇,設計時,注意關鍵操作的二次確認機制,從設計角度降低用戶誤操作的概率,避免關鍵操作出現錯誤給業務帶來的負面影響。

2)除了將表單功能獨立于列表之外全局展示,還可以將功能與列表合并,在每一行列表數據后方展示對應可以進行的操作功能。

這種設計適合于同一表單中包含多種子狀態的任務,且需要對不同子狀態任務進行不同操作的業務場景。通過對功能生效范圍的調整,靈活支持業務操作。

3. 搜索

搜索其實是對列表數據的查找,實際業務中,列表數據量級往往比較大,增設搜索功能,可以幫助用戶快速找到目標數據。

1)搜索項的設計原則

在使用中,索引本身應該是0思考成本的,否則就失去了索引的核心價值。

圍繞這一點,有兩個設計時的原則:寧少勿多和高頻前置——即不要揣測用戶需要,而是實際調研,只設置有限的、會被真實使用的搜索項,并且最常使用的展示位置盡量靠前。

在搜索項的設計中,產品經理應當克制,數量超過10個的搜索項,使用起來就十分困難了。

2)當搜索項不可避免得比較多時,可以進行分類展示,降低尋找成本

常用的有兩種分類方式:

①信息維度

常見的有列表信息自有屬性維度的分類和任務屬性維度的分類,例如:

  • 訂單信息自有的屬性包括:客戶姓名、產品名稱/編號、商品類別、價格范圍、訂單創建時間等;
  • 任務屬性則包括:訂單處理狀態、處理人、處理時間、處理結果等。

②條件類別維度

例如可以按照時間類、名稱類、狀態類等將訂單列表的搜索項分為:

  • 訂單創建時間、訂單失效時間、訂單處理時間;
  • 客戶姓名、處理人姓名、商家名稱;
  • 訂單狀態、商品狀態、訂單處理狀態等。

任何信息都是存在信息結構的,產品經理需要發現這些結構,并借助信息自有的結構進行組織設計,讓信息本身說話。

3)兩個注意要點:

  • 注意不同搜索條件之間的關聯關系,可以利用條件聯動,縮小用戶選擇的范圍;例如必要時,產品分類和產品編號就可以設計為聯動。
  • 搜索條件之間是交集的關系,注意不要邏輯重復,相同搜索結果的條件,只保留一個即可;例如產品名稱和編號。

4. 基本結構的自定義延伸

在商業B端產品中,可以通過擴展自定義配置項,來適配不同企業、部門、業務的需要。

必要時,可以將表單列表字段、搜索項和操作項都設計為可配置,支持不同用戶在一定范圍內選擇自己需要的信息、搜索條件;甚至可以自定義配置搜索項順序,以及決定操作項的停/啟用。

再延伸一些,可以將搜索項展示順序設計為依據使用頻率自動調整。

當然,在使用自定義設計中,要慎重而行,調研清楚必要性再做,避免殺雞用了宰牛刀。

三、表單的權限設計

除了上述基本結構外,還需要理清表單權限。在權限設計中,常通過兩個維度來考量:功能權限和數據權限。

B端產品的權限設計是相對獨立也比較重要的一個模塊,基于整個系統的權限體系。

在表單權限設計中,應注意:

1. 表單中功能的單一權限控制

功能項權限控制中,注意權限劃分的粒度,配套使用的一組功能,可以通過一個權限統一控制,避免權限冗余,降低權限配置的復雜度。

例如:工單掛起與取消掛起,就可以統一控制。

2. 列表和搜索項的數據權限

通過數據權限區分不同主體、不同部門、不同業務線的列表查看范圍,注意搜索時,也應保證數據權限劃分有效,避免出現搜索時,列表查看范圍擴大了的數據泄露風險。

四、關于表單設計的PRD如何寫

常見的表單設計PRD組織方式有兩種:

1. 針對單一表單逐項說明

針對單一表單,通過逐一說明列表、功能、搜索項和權限來組織PRD結構,可以清晰全面地將表單內容和邏輯描述清楚。

2. 多個同類表單,可以合并說明

實際工作中,由于常依據任務狀態對表單進行拆分,涉及到一組表單的批量新增。

這種場景下,一組表單需展示的信息往往比較相似,在輸出PRD時,可以先統一說明共性,再突出說明表單間的差異點。

例如:可以先統一說明該組表單中共有的列表字段、功能項和搜索項,再針對有差異的表單單獨說明特有功能——如此,可以提高PRD的輸出效率,避免重復信息分散PRD讀者的注意力,便于技術人員理解和把控需求。

 

本文由 @非魚 翻譯發布于人人都是產品經理。未經許可,禁止轉載

題圖來自Unsplash,基于CC0協議

給作者打賞,鼓勵TA抓緊創作!
更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 關于表單的PRD編寫,用python開發時,建議是不是可以結合研發看的更方便的形式,在PRD中寫明表單中的字段名稱、描述、類型、約束、創建、修改。
    字段名稱:就是表單中某個字段的名稱
    描述:對于這個字段的描述,比如某個字段是【附件】,那么描述就可以針對這個字段的一些說明和限制,例如只能上傳3個附件,每個附件大小不超過10m
    類型:這個字段的類型,包括string,select string,number,date,圖片,附件等
    約束:unique或者不是非unique,這個字段是不是唯一不可重復值,比如工單編號等字段
    創建:required或者optional,必填或者非必填
    修改:optional或者不能修改

    這樣子后端就很清楚每個表單有什么內容,并且產品對其的要求是什么,具體的表現形式可再由UI、前端和產品決定。

    回復
  2. 經常更新呀

    回復
  3. nice

    回復