起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識TOB產品七字箴言之增刪改查顯算傳
B端常見功能可以概括為七個字，即“增刪改查顯算傳”。那么在做這些具體的功能前，有哪些條件是我們需要提前了解的？這篇文章里，作者做了相應的梳理和闡述，一起來看一下。
一、功能的前置條件與后置條件
B端常見功能可以概括為“增刪改查顯算傳”，這些功能看似簡單，但也有不少坑點。在做具體的功能前，我們需要先了解這些功能的前置條件和后置條件。
1. 前置條件
1）按鈕權限限制：什么人可以操作這個按鈕？什么人不能操作？
這是由系統功能權限決定的，一般B端都采用RBAC模型，形成用戶-角色-權限的控制鏈路，將不可用的按鈕進行隱藏。詳見主頁《SaaS系統權限架構設計》。
2）業務場景限制
比如只有訂單創建人可以修改訂單，只有超管可以刪除已審批的訂單等，這些都是根據實際業務場景來定義的。那由于這類限制導致的按鈕不可用是采取隱藏方案還是禁用方案還是點擊報錯呢？
方案1：按鈕正常顯示，點擊報錯。相對簡單，不需要前端處理，統一由后端報錯；
方案2：按鈕處于禁用狀態，鼠標懸浮顯示禁用原因。交互體驗更好，但需要前端參與權限判斷；
方案3：按鈕隱藏。不太建議采用，因為在用戶看來，會懷疑是系統出了bug導致按鈕不見了。
3）關聯模塊限制：對本模塊和下游模塊會產生什么影響？
在設計各個功能前，產品需事先了解每個模塊間的關聯關系，比如刪除了訂單，對哪些模塊產生影響？訂單本身的刪除可能是相對簡單的，但由于要通知到各個關聯模塊（下游的工單、數據統計等），工作量可能就成倍增加了，需要再重新考慮下是否值得做這個功能。
2. 后置條件
1）完成操作后跳轉到什么頁面？諸如回到列表/回到首頁/回到上一個頁面/停留在當前頁面/跳轉到詳情頁/定位到下一條數據等等。
2）描述數據流轉關系以及對其他模塊產生的影響。
3）確定下是否需要記錄到操作日志中，供用戶查閱，防止后續的扯皮等。
二、新增設計
1. 新增方式
1）手動新增：包括通用表單和自定義表單。其中自定義表單常采用仿真手法，模仿現實生活中的單據樣式，比如發票、記賬憑證等。
2）導入：是批量新增的一種常見方式。
3）同步：主要包括從接口API同步和RPA（使用機器人模擬人工進行自動化操作）采集兩種方式。下圖是兩個系統關于這兩種方式的應用示例。
2. 注意事項
注意事項可參見主頁的以下文章，此處不再贅述：
- 單個新增：《如何提高表單的填寫效率和準確性》
- 批量導入：《B端Excel批量導入設計分享》
三、刪除設計
1. 刪除及替代方案
1）終止：通過狀態變化來達到“刪除”目的，適用于需要保留過程數據的場景。
2）清除：適用于自動清理垃圾和用戶不關心的系統數據。
3）編輯/撤回后編輯：適用于修正創建錯誤。
4）停用/禁用/作廢：適用于保留歷史數據但未來不可選的場景。
5）失效：跟停用相比，有明確的失效時間，適用于未來時間的停用。
6）刪除：包括邏輯刪除和物理刪除。一般情況下系統都是采用邏輯刪除，物理刪除需慎之又慎。
2. 注意事項
1）刪除入口：取決于是否希望用戶能直觀地看到刪除按鈕，比如公眾號的取消關注，也可以視為是一種刪除，但由于業務方不希望用戶取消，所以入口就隱藏得比較深。
2）刪除的二次確認：
① 是否需要二次確認取決于數據的重要性，比如搜索的歷史記錄，有些軟件就不會二次確認；
② 還需考慮權限問題，即刪除二次確認時是否需要高級別人員的同意；
③ 如果可恢復，需提示在哪恢復；
④ 交互上包括氣泡框確認、彈窗確認、彈窗掃碼確認、彈窗密碼確認、彈窗驗證碼確認、彈窗指紋確認等。
3）是否支持批量刪除：取決于數據的錄入方式，一般存在批量新增的，就會對應批量刪除。
4）刪除提示：根據刪除成功與否、刪除失敗的原因及解決方案、單個刪除還是批量刪除、是否可立即撤銷等進行對應提示。
四、修改設計
1. 修改方式
1）表單修改：修改頁與新增頁采用結構相同的表單。
2）在位編輯：鼠標懸浮時出現編輯框或單獨點擊編輯按鈕。
3）單行編輯：點擊編輯后對表單行進行編輯。
4）批量編輯：批量編輯所有行或單獨編輯某個字段。
5）分模塊編輯：常出現在長表單中，只針對單個模塊進行編輯。
2. 注意事項
1）修改是否需要二次確認
2）某個字段能不能修改？有沒有特定的權限？比如負責人只有主管才能修改等等
3）是否支持撤銷修改
4）其他注意事項：跟新增一致
五、查詢設計
1. 查詢概述
1）查詢方式：實時查詢 OR 定時查詢。
- 實時查詢：適用于小數據量場景，比如首頁卡片查詢我的客戶數量等等。
- 定時查詢：適用于數據量較大，關聯表較多或受限于第三方數據的情況，比如挑系統空閑時間跑任務，將數據固定下來，后續歷史數據直接讀取已經查出來的數據，提高查詢速度，降低服務器壓力。
2）查詢頻率：多久查一次，這取決于業務場景對數據及時性和準確性的要求。
3）查詢速度：查詢條件關聯的表太多會導致查詢速度過慢，此時就要考慮是否把部分功能進行遷移，比如拆分成2個頁面等等。
4）查詢范圍：是查全部還是局部？這取決于業務場景、用戶權限和系統性能。
2. 典型應用之搜索
1）搜索邏輯：精確搜索 OR 模糊搜索 OR 分詞搜索。
- 精確搜索：適用于敏感數據相關信息的查詢，比如通過手機號查詢特定員工的通話記錄等，為避免隨便輸個數字1就能將系統全部通話記錄都查出來，可能會設置為精確搜索。
- 模糊搜索：最常見的搜索邏輯，將包含關鍵詞的數據檢索出來。
- 分詞搜索：將給定的關鍵詞進行拆分，按稀有程度賦分，綜合得分越高排名越前。
2）搜索設計
搜索流程：輸入搜索詞→搜索詞的語義理解→搜索結果的召回和排序→前端展現。
涉及頁面：搜索入口、搜索推薦頁、搜索聯想頁、搜索結果頁、搜索中轉頁、搜索歷史頁、高級搜索頁。
詳細內容后續會寫個專題補充，敬請期待~
3. 典型應用之篩選
1）交互樣式：包括表頭篩選、tab頁簽篩選和多條件組合篩選。
表頭篩選：交互與Excel相似，但如果列過多可能會忘記已篩選過的條件。
tab頁簽篩選：不夠靈活，適用于高頻篩選條件的預置。
多條件組合篩選：包括篩選條件的自定義外顯、高級篩選、自定義保存篩選方案、且或條件的篩選方式等等，更多細節后續會寫個專題補充，敬請期待~
2）查詢觸發方式：包括手動查詢、回車查詢、即時查詢。
- 手動查詢：點擊查詢按鈕觸發。
- 回車查詢：適用于文本查詢。
- 即時查詢：選中下拉框中的選項值后即開始查詢。對于用戶來說減少了點擊查詢按鈕的步驟，但對系統性能的考驗會更大，需要評估實際場景后決定最終方案。
六、顯示設計
1. 典型頁面之列表頁
表頭：需考慮是否可篩選、是否可自定義展示列、是否可自定義列寬、排序、字段提示語、凍結列、多行表頭、是否吸頂等。
正文：
格式：數字兩位小數右對齊（涉及計算的，需考慮除數為0等特殊場景下的顯示樣式）；字符串左對齊；定義時間格式，如YYYY-MM-DD等；定義內容過多時的顯示樣式
分隔線：包括橫向分隔線、縱向分隔線、無分隔線和斑馬紋分隔線等
信息層級：是否存在總分層級等
合計行：常見于數據統計頁，一般位于首行或末行（吸底）
分頁：每個頁面展示的數量條數需考慮業務的平均數和上限。比如用戶在使用跨頁勾選時，如果分頁數量太少，則操作的次數勢必較多，體驗較差；但如果分頁數量太大，可能計算量過大導致頁面卡頓。
2. 典型頁面之詳情頁
詳情頁樣式的自定義程度一般都比較高，此處就不截圖了，僅討論下詳情頁的承載容器。
選擇依據
1）根據需要承載的信息量來選擇：頁面>抽屜>彈窗。
2）根據頁面需要的連貫性來選擇：如果需要體現流程變化，則更適合用當前頁刷新；如果需要展示與當前頁相關的拓展信息，則更適合用彈窗和抽屜；如果要跟當前頁的信息做比對，則更適合用抽屜。
3）根據是否要保留原頁面內容來選擇：需要保留的，選擇新開頁簽、抽屜或彈窗。
七、計算設計
常見的計算包括偏業務側的報表公式計算，也包括偏技術側的算法模型。
1. 報表計算
報表計算可進一步分為有業界統一標準的（比如財務報表的計算公式）和無業界統一標準的（比如線索轉化率的計算）。
1）業界有統一標準的：重點在于給出各公式的計算邏輯和涉及的參數
像這種有業內統一標準的公式計算相對來說比較簡單，摸清楚競品的整個計算邏輯就行。
當然，用戶其實跟開發一樣，對此類計算邏輯可能只知皮毛，一旦數據有問題，就可能質疑取數邏輯和取數過程。因此，在產品設計上需要提供清晰易懂的取數規則說明以及數據的加工溯源。
此外，為了避免數據的大規模修訂，此類計算在上線前的測試必須慎之又慎，且必須拿用戶的真實數據進行最終測試和驗收。如果是業內有統一標準的，可以直接用競品去測，看自己產品的計算結果是否與競品一致。
2）業界沒有統一標準的：重點在于跟業務方的口徑確認
相較而言，這類沒有明確標準的報表字段計算邏輯的確認更考驗產品的數理邏輯和溝通能力。
這里提醒以下幾點：
① 必須明確誰是能最終決定口徑的人。因為此類報表可能涉及的人員眾多，線下都沒有達成統一，一旦上線，如果對使用方的利益造成影響，勢必會受到質疑。
② 產品對整個數據庫的字段需有一定的了解，需要將客戶的訴求轉化成數據庫的表字段，絕對不能讓口徑存在模棱兩可的可能性。如果只是用中文而不是表字段去闡述此類口徑，最終開發設計出來的大概率會跟業務方的實際需求存在差異。
③ 為了避免后續的反復扯皮，所有的計算結果必須能溯源，比如點擊數字查看詳情。也方便業務方糾正自己原有的口徑，意識到“哦~原來還有這種情況我忽略了，這個不該統計的，這個應該統計的”。
④ 最好能將統計口徑形成文檔，讓業務方確認（包括微信等聊天軟件回復等等）。
⑤ 核驗計算結果。由于業內沒有統一標準，建議將用戶的真實數據拷貝到另一個環境中去測試，看數據結果用戶是否認可或者先只是小范圍上線，待用戶驗證后再大規模上線。
2. 算法模型
常見的算法模型包括：
1）聯結學派。比如神經網絡，包括圖像識別、機器翻譯等。此類算法最明顯的問題就是模型可解釋性差，模型對數據量的要求比較高。因此，神經網絡算法適用于有著海量數據且對算法解釋性要求不高的業務。
2）符號學派。比如決策樹模型。當條件為XX的時候，走到哪個分支。
3）進化學派。比如基于強化學習的推薦算法等。
4）貝葉斯學派。比如垃圾郵件過濾系統，根據已知的垃圾郵件，推導出垃圾郵件的一些典型特征。接下來如果我們先驗地知道一封郵件包含的特征和垃圾郵件類似，我們就可以做出推斷，這封郵件有很大概率是垃圾郵件。
5）類推學派。比如隱語義模型，可以根據“用戶×物品”矩陣，去想辦法構建出“用戶×偏好”矩陣和“物品×偏好”矩陣。在得到這兩個矩陣之后，就可以使用線性加權求和的方法來計算用戶和物品的推薦分數。
常見的應用包括推薦算法、風控算法、標簽算法等。
舉個例子，小紅書發現頁算法機制CES：CES評分=點贊數×1分+收藏數×1分+評論數×4分+轉發數×4分+關注數×8分系統會根據得分決定后續是繼續推薦還是減少推薦。
八、傳輸設計
1. 傳輸目的
1）確保數據源頭的唯一性，不重復生產數據
比如一家公司的2個系統都要使用組織架構，那勢必用1套組織架構即可；
再比如公司各個模塊都會產生商品數據，但使用方不同，開票員要用商品信息開票，銷售要用商品信息創建訂單，會計要用商品信息做賬，如果讓他們各自維護一套，那么維護成本就比較高，而且數據難以互通。此時就需要確保各個模塊的數據能夠互通，且滿足各個模塊自身的需求。
2）使用別人家的數據
比如CRM系統，銷售線索需要從百度、抖音等渠道接入，這就涉及到了數據的傳輸，需要對對方系統接口進行一定的了解，知道哪些數據能獲取，哪些數據在傳輸上可能會有延遲，并針對延遲字段進行特殊處理。
3）復用現有的輪子，避免重復造輪子
專業的事情交給專業的人，外購還是自研產品經理一定要有自己的想法。能夠復用盡量復用，即使付費購買，可能也比自研開發+后期維護的成本低。餅攤得太大，可能會被撐死。血淚的教訓…當然，老板可能不聽勸。
2. 傳輸方式
包括接口、中間件、message等。但每種方式都可能存在數據傳輸失敗的情況，因此要考慮補償機制。
3. 傳輸安全
由于有些數據比較敏感，因此必要時可進行脫敏傳輸。
4. 傳輸速度
為了提高用戶體驗，當然傳輸速度是越快越好。但這必然是有瓶頸的，所以如何平衡用戶體驗和傳輸速度呢？
1）壓縮：比如微信上傳圖片時，如果不勾選原圖，圖片會被默認壓縮。
2）預加載：比如閱讀類APP，用戶看第一章的時候，就開始自動加載第二章的內容。
3）智能加載：比如當網絡條件好的時候，加載高質量的圖片，反之加載低質量的圖片。
4）異步處理：比如當網絡條件不好的時候，如果你給某篇文章點了贊，這個操作并不會因為網絡異常而失敗，而是被記錄了下來，顯示為操作成功。等網絡恢復正常后，再將此行為上傳到服務器，從而完成了點贊行為。這就是讓產品去解決問題，而不是讓用戶去解決問題。
作者：D.lemon，公眾號：檸檬的產品小記
本文由 @D.lemon 原創發布于人人都是產品經理。未經許可，禁止轉載。
題圖來自Unsplash，基于CC0協議。
該文觀點僅代表作者本人，人人都是產品經理平臺僅提供信息存儲空間服務。
好文 收藏
收藏從未停止，學習從未開始