B端產品日記——增刪改查顯算傳

B端產品設計面向的用户羣主要是企業用户，在設計過程中，要從“服務、邏輯、安全、業務”四個方面考慮，常見 的功能我們通常概括為常説的七字箴言“增、刪、改、查、顯、算、傳”通過分析七類功能，實現業務邏輯的更加嚴謹，練好基本功，也避免因為PRD或者原型標註的不清楚增加溝通成本。

一、增：創建、新增、導入、添加1. 輸入方式

在做“增加”功能時，首先考慮數據的輸入方式，通過輸入設備輸入、表單導入亦或是通過其他業務同步，在很多會員管理功能中，會員的信息是可以通過規定格式表單導入批量添加的，其他業務同步這種情況最常見的就是我們在系統中添加管理員時，我們可以直接在已有的用户列表中選擇用户添加為管理員，自動生成管理員賬號；

2. 權限

權限可以從兩個方面考慮：

1. 誰可以增加，誰不可以增加；
2. 什麼時候可以增加，什麼時候不可以增加。

權限的問題同樣適用於下下面的其他六類業務

比如釘釘的審批是可以設置哪類員工可以發起審批的，而在企業審批過程中，審批內容是不能新增的。

3. 明確輸入字段類型

新增的內容由不同類型的字段組合而成，要對每個字段具體的類型給出明確的定義，雖然常用的字段開發人員可以自主的去設計，但是為了避免不必要的溝通，還是要儘可能的描述清楚，這關係到數據庫字段存取的設計、後台邏輯的編寫以及前端頁面的數據輸入方式以及展示形式。

常用的表字段：

• 文本（中文文本、英文文本等，可統一定義為字符串）
• 數字（整數、小數、正負數、阿拉伯數字、中文數字、羅馬數字等）
• 時間、日期（yyyy-MM、yyyy-MM-DD、yyyy-MM-DD hh:mm:ss、hh:mm:ss、hh:00等）
• 字典表（一般用於定義業務狀態，如結算狀態字典可定義“待結算”、“已結算”）

表字段信息説明：

• 字段必填、非必填；強業務關聯的數據或者其他必要信息設為必填字段；
• 字段唯一性；唯一的字段組合設置為表結構的主鍵；
• 字段長度；表字段長度的限制，主要是為了合理分配客户端的內存資源；
• 字段的默認值；對於固定確認的數據，可設置默認值，減少操作員的數據錄入工作量；
• 字段校驗；例如手機號、身份證號碼、銀行卡格式標註校驗，可根據業務情況説明校驗規則；
• 選項型，説明單選、多選；
• 專有名詞解釋説明，業務場景描述，協助開發人員理解文檔。

4. 準確使用信息輸入方式

不同的字段需要使用不同的輸入方式，通常字典值使用下拉或模糊搜索、時間使用選擇器、數字使用步進器以及手動填寫需要的文本框，運用正確的輸入方式確保因為數據格式問題導致的bug

5. 合理的限制媒體文件

合理的限制媒體文件的格式以及大小，考慮到媒體文件的上傳、加載速度，兼容問題，需要對媒體文件的大小、格式進行限制説明。

目前的視頻與圖片音頻格式的兼容性已經越來越強，規定常見格式即可，主要對大小進行限制，圖片一般限制在2M以內，音頻視頻或其他類型文件視業務場景而定

6. 規定輸入閥值/默認值/建議值

對輸入內容進行合理的建議，設置默認值或建議值給予用户合理的提示，提高數據正確性，設置閥值能避免極端垃圾數據的輸入

7. 設置及時完善的錯誤信息提示

用户輸入的過程中，需要對填寫的信息有及時全面的反饋，例如必填字段漏填、有格式校驗的數據填寫錯誤等.

8. 提高長表單的處理效率

• 對於較長的表單，流程分步操作，減輕用户的認知負荷和心理壓力；
• 對於相關的信息進行合理分組展示，高效填寫；
• 採取高效填寫的方式，避免出錯；例如銀行卡掃碼、拍照識別；小結：新增是業務開始的第一個環節，數據進入系統的源頭。若新增不順暢或者總是報錯，會導致業務流程頂部斷層無法繼續、用户體驗感極差，甚至有可能會導致項目驗收失敗。

二、刪：刪除、禁用、停用

刪除也是常規性操作，既然數據有增加，就會有刪除的需求，我們思考的要點和新增的思路是一樣的，刪除操作是否有必要？誰可以刪除，誰不能刪除？什麼時候可以刪除，什麼時候不可以刪除？在哪裏刪除（入口）？刪除的內容是什麼，什麼內容不支持刪除？怎樣刪除，刪除關聯的數據項有哪些？其中有哪些異常情況？

通常説的刪除，包含兩種：

1. 物理刪除：真實刪除，從數據庫層面刪除了數據，查詢找不到該條數據，數據不可恢復；一般對於重要的基礎數據，不建議設置刪除功能，設計中要避免不可逆的操作；
2. 邏輯刪除：假刪除，只是從頁面對數據進行了刪除，數據庫將數據的狀態改寫為“已刪除”，可通過刪除後撤回或者數據庫備份恢復，產品設計中比較常用。

數據的前後業務關聯太強，不適合設計刪除功能，那應該如何對數據進行合理的處理呢？

個人理解的刪除需求的存在，可能存在以下幾種情況：

1. 過期無用信息：可以設計數據庫定時任務，根據實際的業務情況和指定條件，定期清理垃圾數據，適用於數據量較大的情況；
2. 信息錄入錯誤：邏輯刪除或者使用編輯功能修改數據；
3. 數據狀態改變，或需要中止業務：使用字典狀態來限制。

三、改：修改、編輯、覆蓋

改”可分為兩種表現，一是用户對原有數據的修改，哪些可以哪些不可以，可以修改哪些元素，哪些元素一旦確定將不予修改等；二是對設計的修改程序實現的方式，從一種方式更改為另一種方式程序是否易於實現。

1. 能否修改

• 修改的限制條件是什麼
• 用户ID不可修改。
• 用户狀態，需要有權限的人才能修改。
• 哪些參數可以修改，哪些參數不可修改
• 是否支持批量修改
• 修改是否涉及數據轉移

2. 保存機制

• 定時保存。
• 失去焦點時保存。
• 其他條件觸發，比如網絡變化等。
• 修改過程中如何取消修改
• 哪些參數可以修改，哪些參數不可修改

3. 修改是否可逆4. 修改方式子頁面修改

列表直接覆蓋，最直觀的EXCLE表格 列表內嵌子表格修改

四、查：查詢、搜索

大範圍的數據變動，導入表格批量修改。

常用的查詢方式有：

1. 同步查詢、組合條件查詢

設置默認查詢條件，常用有默認查詢日期、默認狀態查詢，有助於用户快速獲取需要的信息。

2. 精準查詢 or 模糊匹配

精準查詢適用於字段簡短準確的數據，用户記憶成本高於模糊匹配，而後者是查詢中比常用的形式。

例如根據身份證號碼查詢用户信息，只需要輸入1991，則查詢出列表中所有包含1991的身份證數據，可能查詢出來的結果為：4280861996054212或者4758261991024483。

按狀態值快速過濾，業務流程類比較常用。

自定義設置查詢條件；展示高頻查詢條件，低頻查詢條件按鈕收起隱藏，且允許自定義設置查詢字段。

提供查詢歷史記錄，有必要的情況下可根據歷史查詢詞條的熱度進行排序。

3. 定時器任務查詢

比較專業的範疇，請教了一下開發同學， 我們一般説定時器是指，按照某個特定的時間間隔執行某一段命令（無法深入説明了，抱歉）；

筆者項目中目前只運用過定時器請求流水，查詢餘額，有機會可以寫一下。

4. 查全局 or 查局部 ？

考慮到數據的安全性問題，可能有些產品設計上會限制查詢的界限，限制查詢出的結果只展示部分數據。

例如設置某些用户只能查詢特定條件下的數據，獲取過濾後的數據量。

五、顯：顯示、回傳、樣式

數據的顯示，根據需要做哪些顯示，顯示的方式是怎麼樣的，不同用户的權限是否一樣，不一樣的話數據如何表現，這裏的表現的是背後邏輯。

“顯示”的 思考要點主要有：顯示這個是否有必要？針對不同人顯示內容是否相同，不同權限顯示是否相同，不同角色顯示是否相同？顯示包括哪些元素？（btn、數據、文本、圖表、圖片、視頻）什麼時候顯示，什麼時候不顯示，顯示多久？數據在哪裏顯示，怎樣顯示？用户對所使用的產品的一切感受，也都是通過“顯示”感受到的。因此，儘量做到：可讀/易用、一致性、消除用户焦慮、及時反饋、數據安全

1. 顯示方式

• 顯示的層級關係（父子級嵌套關係）
• 顯示內容的優先級（必要字段、重要字段、排版、呈現方式）
• 功能操作前、操作方式、操作過程展示、操作結果展示

2. 顯示權限

• 敏感數據如何顯示，如何配置（隱藏、權限設置）
• 功能操作前、操作方式、操作過程展示、操作結果展示

3. 顯示規則

• 顯示的順序，按照創建時間順序、修改時間、類別
• 列表的是否支持快捷操作，篩選、排序、搜索
• 列表顯示樣式、一頁顯示數量，分頁顯示數量，響應式佈局

4. 顯示邊界問題

• 顯示的元素數量範圍，文本過多如何顯示
• 內容為空怎麼顯示
• 哪些錯誤、錯誤提示顯示方式和內容
• 哪些內容是固定的，哪些內容是服務端返回的

詳細問題可參考我之前一篇中提到的設計方法：《B端產品日記——表單設計》

六、算：算法、計算

算”指計算規則，是指用系統的方法描述解決問題的策略機制。其能對一定規範的輸入，在有限時間內獲得所要求的輸出。比如熱門文章=點擊數*1+評論數*2+分享數*3諸如此類的背後計算的數值；此類規則約定之後可以節約很多時間。比如，財務系統的工資條，根據考勤數據可自動算出基礎工資數據，這樣目的是節省人力成本。

1. 計算規則

• 多久算一次
• 參數的限制
• 數據變化的規則：實時更新、自動拉取、推送、隔天更新等
• 需要什麼哪些條件
• 數量變化規則

2. 計算邏輯

• 哪些數據參與計算
• 需要什麼統計
• 哪些信息需要默認保存，自動填充？

七、傳：數據傳輸

“傳”指的是數據的傳遞，不同服務器之間的數據傳遞，考慮到用户體驗的時候ajax的傳遞，還有一些api的數值傳遞等。最近5G話題火熱，大部分人對5G的印象是速度快。其實，5G的應用亮點是低時延和高帶寬，速度快反而是其次。這裏提到了“傳”的三個要點：時延、帶寬、速度。

1. 傳輸安全

• 用户可感知類：脱敏傳輸並脱敏顯示、可執行文件加後綴等；
• 不可感知類：加密傳輸、接口安全、服務器隔離（敏感服務器不直接面向用户）。

2. 傳輸速度

• 壓縮：比如微信發送圖片，不勾選原圖，圖片就會被壓縮傳輸；
• 預加載：比如閲讀類App，用户看第一章，他就會預加載第二章。用户讀起來就不會有等待加載的過程，不會打斷爽感。

3. 異步加載

• 偏移動端：按模塊加載並顯示給用户，不要等整屏內容都加載完再呈現，避免讓用户焦慮。
• 偏PC端：儘量避免整個頁面刷新，減少服務器壓力，和用户等待時長。

4. 傳輸數據要求

• 傳輸內容格式支持：文本、圖片、視頻、數據等
• 哪些需要傳，哪些不需要傳？手動傳，還是自動傳
• 傳輸的內容和方向
• 上傳文件是否有格式限制、大小限制？是否要顯示格式信息，格式提示
• 上傳文件後是否顯示文件名，怎樣顯示
• 上傳後是否允許重複上傳，覆蓋上傳，取消上傳
• 是否可以批量上傳，批量上傳後如何顯示
• 上傳後是否可以刪除、批量刪除，如何刪除？

本文由 @蘇木 原創發佈於人人都是產品經理。未經許可，禁止轉載

題圖來自Unsplash，基於CC0協議