本文講述了業(yè)務(wù)調(diào)研、系統(tǒng)整體方案設(shè)計、系統(tǒng)細(xì)節(jié)方案設(shè)計一整套B端PM的標(biāo)準(zhǔn)工作流程。

B端產(chǎn)品本質(zhì)是：解決組織痛點，實現(xiàn)商業(yè)價值。

B端產(chǎn)品經(jīng)理，既要有對宏觀的把控能力，又要有對細(xì)節(jié)的專注力。

沒有細(xì)節(jié)的高度，會變成一個華而不實的空架子。B端產(chǎn)品的方案需要遵循以業(yè)務(wù)為中心，自頂向下的設(shè)計思路，從抽象到具體，逐漸勾勒出B端產(chǎn)品的輪廓。

一、緣起：業(yè)務(wù)調(diào)研

1. 概述

無論是一個項目還是一個真正的產(chǎn)品，都要明確的說出這個項目的目標(biāo)或愿景是什么，這是產(chǎn)品的靈魂。

深入一線，深刻理解業(yè)務(wù)，是B端PM診斷業(yè)務(wù)問題，做出正確決策的前提；B端產(chǎn)品面向企業(yè)用戶，產(chǎn)品目標(biāo)是更好的支撐業(yè)務(wù)運轉(zhuǎn)，調(diào)研目標(biāo)是分析業(yè)務(wù)現(xiàn)狀和業(yè)務(wù)問題為方案設(shè)計提供支撐，最終解決企業(yè)的業(yè)務(wù)問題，提升運轉(zhuǎn)效率。

B端用戶是一個組織或者是機(jī)構(gòu)，所以調(diào)研對象有涵蓋組織中的不同人員，從高級管理人員到一線執(zhí)行人員，關(guān)鍵角色都要覆蓋.

2. 執(zhí)行步驟

1.2.1 步驟一：找到&引導(dǎo)目標(biāo)客戶

客戶需求=預(yù)期-現(xiàn)狀

a預(yù)期高于現(xiàn)狀時：客戶有明確的改進(jìn)預(yù)期，通常會比較積極的配合需求調(diào)研。

在問題場景中，我們要識別外因還是內(nèi)因，外因可能包括包括參觀考察、競爭對手動向、熱點及新趨勢；內(nèi)因可能是自身業(yè)務(wù)的新需求或者遇到的問題；

B預(yù)期等于或低于現(xiàn)狀：客戶對變化表現(xiàn)不積極，對需求的調(diào)研表現(xiàn)出消極的態(tài)度，直接的調(diào)研方法無法獲取需求。

在機(jī)會場景中，需要對客戶的現(xiàn)狀進(jìn)行深入了解，提出客戶可能為之心動的新預(yù)期，從而讓他們進(jìn)入預(yù)期高于現(xiàn)狀的狀態(tài)。比如我們可以從以下幾方面引導(dǎo)：

• 新業(yè)務(wù)&新機(jī)會：與該領(lǐng)域領(lǐng)先企業(yè)的差距，從差距中尋找機(jī)會場景；跑在前面的同行的所作所為；他山之石可以攻玉，借鑒其他行業(yè)的商業(yè)邏輯；
• 新技術(shù)：了解新技術(shù)發(fā)展，從實際場景出發(fā)，技術(shù)可以解決什么問題&帶來什么機(jī)會？
• 新人群：每一代人有不同的特點，你服務(wù)的對象有什么習(xí)慣、什么價值觀？

1.2.2 步驟二：選擇客戶組織中的調(diào)研對象

• 對客戶的組織架構(gòu)要有所了解，著重關(guān)注三類人，包括項目發(fā)起人、出資人和項目實施部門負(fù)責(zé)人；
• 選擇干系人代表，如果有多個干系人則從中選擇一位或多位典型的代表人以便聚焦；每個具體干系人，他的專業(yè)背景、職業(yè)背景、價值觀、組織地位、工作經(jīng)驗等方面都有一定的特殊性，選擇一位或多位代表就能覆蓋各種有差異性的人；然后，了解干系人的基本信息，比如說他的職業(yè)角色是什么樣的？他的個人特點是什么樣的？他的聯(lián)絡(luò)方式是什么？
• 除了要關(guān)注干系人的影響度以外，還要關(guān)注他與項目的相關(guān)度；
• 關(guān)注具有一票否決的關(guān)鍵干系人，我們必須分析它的關(guān)鍵需求，提出針對性的雙贏的解決方案。

1.2.3 步驟三：確認(rèn)調(diào)研方法

• 第一點，基于KPI分解，KPI指標(biāo)體系通常直接體現(xiàn)了管理者的核心關(guān)注點，因此可以實現(xiàn)數(shù)據(jù)歸類，然后逐一切入，以發(fā)現(xiàn)潛在的關(guān)注點和阻力點；
• 第二點，基于工作主題分析，管理者通常會涉及多個不同的工作主題，比如說負(fù)責(zé)物資供應(yīng)的經(jīng)理會涉及采購倉儲等不同主題，先梳理被訪談對象的工作主題，以便訪談分而治之；
• 第三點，根據(jù)工作階段分解，有些管理者的工作可能會比較單一，如銷售主管，那么可以針對工作階段進(jìn)行分析，比如說售前、售中和售后；
• 第四點，干系人關(guān)注點整理，橫向評估不同干系人之間的訴求，分析各個干系人的關(guān)注點之間是否存在沖突，制定相應(yīng)的策略。

1.2.4 步驟四：給客戶講個好故事

1.2.4.1 給誰講故事

我們要向客戶證明系統(tǒng)的價值，而且向影響力越大的用戶證明，項目成功的概率就越高。

在大大小小各行各業(yè)的項目里都很難實現(xiàn)，每個干系人都滿意的完美結(jié)局，所以需要折中和平衡，項目其實就是一個博弈的游戲，重要的是要獲得足夠多的籌碼，也就是需要找到關(guān)鍵的籌碼持有者，贏得足夠多的籌碼就可以贏得項目，并且你不可能獲得所有的籌碼。

1.2.4.2 故事怎么講

1.2.4.2.1 問題和機(jī)會

客觀的從業(yè)務(wù)的角度來描述問題。

• 業(yè)務(wù)態(tài)：從業(yè)務(wù)的角度而不是系統(tǒng)角度來描述，問題-機(jī)會-成本-效益；
• 客觀性：描述問題想要有說服力，就保持客觀，不加主觀判斷；

1.2.4.2.2?影響了誰

要清晰到具體的人。描述的問題，給誰帶來了什么樣的影響；注意推理合理，層次清晰，具有說服力；

1.2.4.2.3?產(chǎn)生的后果

要匹配讀者的視角，與你講述對象的視角匹配。比如關(guān)注目標(biāo)愿景的一般是高層，高層會關(guān)注的問題企業(yè)經(jīng)營、管理模式、業(yè)務(wù)模式；

1.2.4.2.4?解決方案

說明主要的策略以及推薦這個方案。一切知道為什么的人，都會知道應(yīng)該怎么辦，用一句話來提煉你方案的價值；

3. 注意事項

1）識別背后的問題

客戶容易說出方案，而不是問題，我們應(yīng)該識別背后的問題。

因為，就算我們完美的滿足了客戶提的方案，最終未必會得到完美的反饋，因為客戶是問題專家，而非解決方案專家，他提出的方案未必能夠完美的解決他遇到的問題；

2）產(chǎn)品經(jīng)理得學(xué)會功能排序

能用的功能用戶希望都有，人性本就是貪婪的，如果能多實現(xiàn)功能，那用戶一定會讓你實現(xiàn)，這時候產(chǎn)品經(jīng)理讓用戶對想要的功能路線進(jìn)行排序，確定他們最看重的東西，或者明確一下用戶可能會失去的東西，比如說加載速度變慢，操作流程變長，再來讓其判斷最想要的功能是什么；

3）站在用戶的立場

我們在建議解決方案時，應(yīng)該站在用戶的立場，說明這種方案的優(yōu)點，我們要作為問題的解決者，而不是需求的傳遞者；

4）始于故事，終于數(shù)據(jù)和邏輯

B端的產(chǎn)品無外是問題，機(jī)會，成本，效益四個關(guān)鍵點；在引導(dǎo)客戶時，我們應(yīng)清晰描述整個軟件系統(tǒng)解決什么問題？創(chuàng)造什么機(jī)會？帶來什么價值？對于一些放之四海皆準(zhǔn)的定性描述，其實沒有什么卵用，因為它失去了指向性，我們最好采用上文提到的故事方式，始于故事，終于數(shù)據(jù)和邏輯。

4. 階段性產(chǎn)物

輸出業(yè)務(wù)調(diào)研報告，包括：

• 業(yè)務(wù)現(xiàn)狀梳理：戰(zhàn)略定位和戰(zhàn)略目標(biāo)、經(jīng)營策略、管控模式、組織架構(gòu)、業(yè)務(wù)流程
• 業(yè)務(wù)問題總結(jié)：關(guān)鍵業(yè)務(wù)問題梳理、問題解決思路(標(biāo)明優(yōu)先級)。

二、藍(lán)圖：系統(tǒng)整體方案設(shè)計

1. 概述

遵循自頂向下的設(shè)計思路，依次是設(shè)計核心業(yè)務(wù)流程，業(yè)務(wù)場景分析，應(yīng)用架構(gòu)，功能模塊演進(jìn)藍(lán)圖；隨著設(shè)計的深入以及業(yè)務(wù)的開展變化，功能模塊可能需要修正和調(diào)整，但只要業(yè)務(wù)的本質(zhì)模式?jīng)]有變化，功能模塊就不應(yīng)該出現(xiàn)結(jié)構(gòu)性的變化。

2. 核心業(yè)務(wù)流程梳理

2.2.1 執(zhí)行步驟

流程分析的過程中，我們可以遵循以下流程：明確系統(tǒng)角色分工 — 明確角色執(zhí)行的活動 — 確定各活動的順序執(zhí)行/并行執(zhí)行/異步執(zhí)行的協(xié)作關(guān)系 — 識別流程的分支 — 識別流程的流轉(zhuǎn)物，比如表單、單據(jù)等；

業(yè)務(wù)系統(tǒng)是對線下已有業(yè)務(wù)流程的固化、優(yōu)化和重構(gòu)，應(yīng)與客戶一起進(jìn)行關(guān)鍵業(yè)務(wù)流程的梳理：

• 聽：客戶敘述時不打斷，不陷入任何細(xì)節(jié)，以最簡的方式勾勒出主體脈絡(luò)，把分支、產(chǎn)物關(guān)系、異常、審批、規(guī)則都放一邊。
• 問：沿著流程向客戶提問，看是否存在分支情況，然后邊問邊修正，得到一個中間稿。除了分支之外，還要問協(xié)作之間的產(chǎn)物，然后進(jìn)行流程圖的補(bǔ)充；
• 讀：通讀流程，與客戶達(dá)成共識；

2.2.2 注意事項

業(yè)務(wù)流程的源頭是外部/內(nèi)部服務(wù)請求，所以業(yè)務(wù)流程圖只允許有一個起點，但可以有多個終點；在定義流程的起點和終點時，首先理清端到端的概念，實際就是服務(wù)請求從提出到滿足的全過程；判斷一個流程是否完整，應(yīng)該站在服務(wù)請求的立場，判斷服務(wù)請求是否滿足或者被拒絕。

劃分為主、變、支三種流程，主業(yè)務(wù)流是我們對系統(tǒng)的主訴求，變體業(yè)務(wù)流也是主流程的一種，但是不容易整合到一個流程中，支撐業(yè)務(wù)流是一些邊緣性的支持業(yè)務(wù)。

我們應(yīng)該在做需求分析時應(yīng)找出與系統(tǒng)邊界直接接觸的部分，進(jìn)行邊界識別；業(yè)務(wù)流程有兩種邊界，一個是職能邊界，也就是跨越我們未涉及的業(yè)務(wù)域，二是系統(tǒng)邊界，就不屬于系統(tǒng)的那一部分。

將業(yè)務(wù)流程作為一個最小的交付單元，制定迭代計劃，做完全部業(yè)務(wù)流程劃分后，根據(jù)是否為主營業(yè)務(wù)，對優(yōu)先級進(jìn)行劃分。

如果流程中涉及審批流程，不要用崗位名稱加審批的樣式，而應(yīng)該識別審批意圖，比如資金使用額度審批，因為不同組織可能審批的人不同。

2.2.3 階段性產(chǎn)物

我們可以用業(yè)務(wù)流程表來呈現(xiàn)我們的分析結(jié)果，包括流程名稱、簡要描述以及優(yōu)先級（高、中、低）。

用泳道圖來描述完整的業(yè)務(wù)過程（包括線上和線下）。根據(jù)分析階段和讀者對象的不同，流程圖可以分為四級

1. 組織級流程，即部門間協(xié)作，以部門為泳道；
2. 部門級流程，展現(xiàn)崗位間的協(xié)作，以具體崗位為泳道；
3. 個人級流程，定位崗位的操作規(guī)程，沒有這種泳道；
4. 是子流程，如果個人級流程過于復(fù)雜，還可以再分層。

我們可以用跨職能流程圖/活動圖/時序圖來展示我們的分析結(jié)果；如果強(qiáng)調(diào)每個角色執(zhí)行的活動，就選擇跨職能流程圖/活動圖，如果強(qiáng)調(diào)各角色間的協(xié)作和交互關(guān)系，就選擇時序圖。

繪制跨職能流程圖/活動圖時應(yīng)該注意：業(yè)務(wù)流程繪制暫時不要考慮系統(tǒng)邊界，要畫出業(yè)務(wù)的全過程；活動的命名應(yīng)該采用動賓結(jié)構(gòu)，且主次活動根據(jù)讀者的不同只留一個；活動圖只有一個起點，但是可以有多個終點。

3. 場景分析&用戶故事

2.3.1 執(zhí)行步驟

這一階段的關(guān)鍵點：就是說清楚產(chǎn)品針對誰提供什么樣的支持。

上一部分，業(yè)務(wù)流程的繪制，沒有考慮系統(tǒng)邊界；這一部分，我們需要站在用戶視角，梳理用戶在哪些場景下需要系統(tǒng)提供支持，哪些不需要系統(tǒng)支持，哪些是需要系統(tǒng)進(jìn)行半支持的。

用戶故事的本質(zhì)，就是希望用戶或者是用戶代表以作為某某某角色，希望通過系統(tǒng)解決方案或是功能要求，以便達(dá)成什么什么樣的業(yè)務(wù)目的，它的本質(zhì)上是用戶視角。我們可以按照場景—挑戰(zhàn)一方案的邏輯進(jìn)行場景&用例梳理：

• 場景細(xì)化，將場景細(xì)化為事件流，整理出用戶預(yù)期的正常步驟，然后寫出變化的情況；
• 問題或挑戰(zhàn)識別，針對每一個步驟，站在用戶的角度來思考他們會遇到什么問題，面對什么樣的挑戰(zhàn)；
• 針對這些問題思考系統(tǒng)應(yīng)該提供什么功能。

2.3.2 注意事項

崗位和系統(tǒng)角色有時不是匹配的，可能存在一個崗位對應(yīng)系統(tǒng)的多個角色。

2.3.3 階段性產(chǎn)物

我們可以用用例圖來簡略描述業(yè)務(wù)場景，繪制用例圖時應(yīng)該注意的幾點：用例應(yīng)該是一個獨立的，可匯報可暫停的單元；角色和角色僅存在一種關(guān)系，也就是繼承，用泛化表示；用例和用例之間存在三種關(guān)系，包含關(guān)系表示的一定會執(zhí)行的公共子事件流，擴(kuò)展關(guān)系表示不一定會執(zhí)行的擴(kuò)展事件流，泛化關(guān)系表示公共的事件。

我們可以用業(yè)務(wù)場景分析方案詳細(xì)描述業(yè)務(wù)場景，包括：

• 場景概述，說明該場景任務(wù)的名稱，該場景任務(wù)執(zhí)行的目的，執(zhí)行該場景的前置條件，任務(wù)出現(xiàn)的頻率；
• 場景分析，以場景/任務(wù)、問題/挑戰(zhàn)、方案/所需功能的形式整理分析結(jié)果，描述該場景最預(yù)期的步驟及每個步驟的問題；該流程的擴(kuò)展事件流和相應(yīng)的問題；最后描述這部分問題、挑戰(zhàn)所需要的功能。
• ?主流程外，對特殊場景的支持，它不是一種正常執(zhí)行過程中的分支，而是一種例外情況（非必填）。

我們可以用例任務(wù)書來展示我們的分析結(jié)果，包括場景、任務(wù)名稱、任務(wù)描述、解決方案幾部分。

4. 應(yīng)用架構(gòu)設(shè)計

2.4.1 執(zhí)行步驟

識別出用戶場景之后，就應(yīng)該細(xì)化業(yè)務(wù)場景的事件，實現(xiàn)以用戶視角發(fā)現(xiàn)系統(tǒng)應(yīng)提供的功能。但是對于對于復(fù)雜的業(yè)務(wù)系統(tǒng)，我們首先要進(jìn)行子系統(tǒng)的劃分，來降低需求分析復(fù)雜度。

PM視角的子系統(tǒng)劃分和程序猿視角的子系統(tǒng)劃分是兩回事，程序猿站在技術(shù)實現(xiàn)的視角，而PM要站在用戶/業(yè)務(wù)視角來劃分子系統(tǒng)，這樣客戶容易理解，可以參與梳理過程，避免遺漏；

對于支撐管理業(yè)務(wù)的系統(tǒng)，最典型的就是先按照部門職能進(jìn)行劃分。

理想情況下，獨立的業(yè)務(wù)部門應(yīng)該有獨立的系統(tǒng)來支持工作；可以先畫出企業(yè)組織架構(gòu)圖，比如中型教育培訓(xùn)機(jī)構(gòu)的四個典型部門：分別是教學(xué)部、教務(wù)部、市場部、財務(wù)部。

對應(yīng)的子系統(tǒng)分別是：教學(xué)管理子系統(tǒng)、教務(wù)管理子系統(tǒng)、營銷管理子系統(tǒng)、財務(wù)管理子系統(tǒng)。

在此基礎(chǔ)上，再根據(jù)產(chǎn)品/服務(wù)進(jìn)行分解，以教學(xué)管理子系統(tǒng)為例，可以繼續(xù)劃分為教研支持、課堂工具、助學(xué)工具等；

此外，確認(rèn)子系統(tǒng)之間的關(guān)系，即“我”要“別人”提供什么？&“我”為“別人”提供什么？這一部分應(yīng)該由產(chǎn)品負(fù)責(zé)人和架構(gòu)師共同討論決定。

2.4.2 注意事項

對于已有的業(yè)務(wù)系統(tǒng)，我們先開發(fā)來支撐新的業(yè)務(wù)；就需要去了解哪部分是需要重新開發(fā)的，哪部分是需要改造原有的，哪部分是需要復(fù)用原有的。

2.4.3 階段性產(chǎn)物

我們可以用UML構(gòu)件圖來展示此部分的分析結(jié)果。

三、筑夢：系統(tǒng)細(xì)節(jié)方案設(shè)計

1. 概述

在應(yīng)用架構(gòu)的基礎(chǔ)上要為每個系統(tǒng)設(shè)計功能模塊，要問自己兩個問題，這個系統(tǒng)應(yīng)用于哪些業(yè)務(wù)場景？用戶可能在系統(tǒng)中做的操作有哪些？

2. 組織機(jī)構(gòu)模型設(shè)計

對于組織機(jī)構(gòu)模型這一部分來講，我們要考慮它當(dāng)前的業(yè)務(wù)，以及未來可能存在的業(yè)務(wù)擴(kuò)展——也就是各組織&角色是1對1、1對多還是多對多的關(guān)系，我們可以用E-R圖進(jìn)行分析結(jié)果的呈現(xiàn)。

3. 角色權(quán)限設(shè)計

需要明確不同角色能訪問哪些頁面，能看到哪些數(shù)據(jù)，以及能做什么操作。

3.3.1 功能權(quán)限

每個系統(tǒng)角色都對應(yīng)一個明確的權(quán)限集合，包括對菜單頁面元素等資源的訪問和操作權(quán)限。

如果用戶較多，我們可以對用戶進(jìn)行分組，將角色和用戶組進(jìn)行關(guān)聯(lián)。當(dāng)有新用戶只需要設(shè)置其所在的用戶組，就會將用戶組關(guān)聯(lián)的權(quán)限賦予新用戶。

如果用戶角色需要批量調(diào)整，只需要調(diào)整用戶組和角色的關(guān)聯(lián)關(guān)系；而不用重新變到每一個用戶和角色沒有關(guān)系。

本質(zhì)上講，一套軟件系統(tǒng)就是對不同數(shù)據(jù)對象的增刪改查的合集。

3.3.2 數(shù)據(jù)權(quán)限設(shè)計

角色在頁面能查到的數(shù)據(jù)范圍就該角色的數(shù)據(jù)權(quán)限，能查到的數(shù)據(jù)范圍不是指能看到的數(shù)據(jù)字段，而是能查出來的數(shù)據(jù)集合。比如針對訂單列表頁，數(shù)據(jù)范圍可能是某個城市的訂單也可能是某個賬戶下的訂單。

4. 頁面流轉(zhuǎn)圖設(shè)計

頁面流轉(zhuǎn)圖是向軟件產(chǎn)品的頁面設(shè)計更進(jìn)一步的方式，是一種很好的銜接方式。

可以基于頁面流轉(zhuǎn)圖進(jìn)行討論、修正，比原型畫出來再討論、修正，更高效。

頁面流轉(zhuǎn)圖描述的是：用戶完成某項工作需要訪問的頁面以及頁面的跳轉(zhuǎn)順序。

我們繪制頁面流轉(zhuǎn)圖時，都是針對某個單一角色在某個特定場景下的頁面訪問，和跳轉(zhuǎn)邏輯，從用戶的視角梳理一遍所有的相關(guān)頁面。每到一個新頁面時都要思考：需要先做一個頁面，還是可以復(fù)用原有頁面，最終整理出系統(tǒng)涉及的所有的頁面的初稿。

有一點需要注意的是：不是所有的頁面，都來自頁面流轉(zhuǎn)圖，有些頁面是獨立于總體流程之外的。

5. 原型界面設(shè)計

當(dāng)一套業(yè)務(wù)系統(tǒng)上線之后，后期迭代就基本不需要UIUE了。

前端工程師參考相關(guān)圖，就可以直接進(jìn)行前端頁面的開發(fā)，業(yè)務(wù)系統(tǒng)的產(chǎn)品經(jīng)理一般還是要自己做交互。

很多產(chǎn)品現(xiàn)在喜歡在界面設(shè)計啊，交互設(shè)計上有創(chuàng)新，其實沒必要。因為B輪產(chǎn)品的用戶需要的是——解決業(yè)務(wù)問題，提高效率。

交互體驗并不是他們最在意的，而復(fù)雜的界面和交互會增加研發(fā)的工作量。PS：axure還是最經(jīng)典的原型設(shè)計工具，然后用藍(lán)湖進(jìn)行一個實效性的溝通效果比較好。移動端的話可以用墨刀，比較高效，頁面流轉(zhuǎn)圖用墨刀也比較好制作。

保證B端交互效果的尼爾森原則（雖然網(wǎng)上已經(jīng)隨處可見了，但是為了大家看著方便，還是搬過來了）：

3.5.1 反饋原則

系統(tǒng)應(yīng)該在合理的時間，用正確的方式向用戶提示或反饋，目前系統(tǒng)在做什么？發(fā)生了什么？

人機(jī)交互的基本原則就是讓系統(tǒng)和用戶之間保持良好的溝通和信息傳遞。比如安裝程序時顯示進(jìn)度條，比如說上傳文件時顯示進(jìn)度條，比如說提交表單時，如果失敗，提示錯誤原因。

3.5.2 隱喻原則

系統(tǒng)要采用用戶熟悉的語句短語符號來表達(dá)意思，遵循真實世界的認(rèn)知習(xí)慣，讓信息的呈現(xiàn)更自然與辨識和接受，

在人機(jī)交互設(shè)計中程序的溝通和表達(dá)功能的呈現(xiàn)都要用最自然的用戶易于理解的方式，而避免采用計算機(jī)程序語言的表達(dá)方式。

3.5.3 回退原則

用戶經(jīng)常會不小心操作錯誤，需要有一個簡單的功能讓程序迅速恢復(fù)到錯誤發(fā)生之前的狀態(tài)。

軟件系統(tǒng)應(yīng)該有撤銷，重做這些功能。比如說word，美圖秀秀的撤銷，比如說點擊刪除關(guān)閉按鈕后，讓用戶的二次確認(rèn)，比如說電商平臺允許在一定的規(guī)則下取消訂單。

3.5.4 一致原則

同樣的情景環(huán)境下，用戶進(jìn)行相同的操作，結(jié)果應(yīng)該一致，系統(tǒng)或平臺的風(fēng)格體驗也應(yīng)該保持一致。

我們應(yīng)該遵循慣例，不要盲目的標(biāo)新立異。比如說office軟件，各個產(chǎn)品就設(shè)計風(fēng)格和界面布局就保持了高度的一致。

3.5.5 防錯原則

系統(tǒng)要避免錯誤發(fā)生，要好過出錯后再給提示。

進(jìn)行設(shè)計師首先要考慮如何避免錯誤發(fā)生，其次再考慮如何檢查校驗異常。有時候為了防止用戶重復(fù)提交，然后第1次點擊之后就只會，比如說，調(diào)整二次確認(rèn)對話框中的是否兩個按鈕。所以很多情況就把否放在前面。

3.5.6 記憶原則

讓系統(tǒng)的相關(guān)信息在需要的時候顯示出來，減輕用戶的記憶負(fù)擔(dān)。

比如說很通用的APP或PC的搜索引擎會記錄用戶的搜索歷史。

3.5.7 靈活運用原則

現(xiàn)在用戶中中級用戶往往最多出高級相對較少，系統(tǒng)應(yīng)該為大多數(shù)人設(shè)計，同時兼顧少數(shù)人的需求，做到靈活易用

系統(tǒng)就要做簡單易用，讓所有的中級用戶用起來得心應(yīng)手，也應(yīng)該提供必要的幫助，讓入門級的初級用戶順利上手，還需要支持靈活的個性化設(shè)置，讓高級用戶以進(jìn)階的方式使用系統(tǒng)。比如說word的，強(qiáng)大的配置功能。

3.5.8 簡約設(shè)計原則

對話中不應(yīng)包含無關(guān)的或沒必要的信息增強(qiáng)或強(qiáng)化一些信息，就意味著弱化另外一些信息。

重點太多就相當(dāng)于沒有重點，所以要把握好突出標(biāo)記的尺度。

3.5.9 容錯原則

錯誤信息應(yīng)該用通俗易懂的語言來表明，而不是向用戶提示錯誤，代碼提示錯誤，信息是要給出解決建議。

就比如說在填寫表單的時候，不要等到提交的時候再提示用戶錯誤，而是在填寫的時候就，嗯，說明，填寫要求，對不符合格式要求的，直接給提示。

3.5.10 幫助原則

對一個設(shè)計良好的系統(tǒng)用戶往往不需要經(jīng)過培訓(xùn)就能輕松的上手使用，但是提供幫助文檔依然是很必要的幫助信息應(yīng)該與檢索，通過明確的步驟引導(dǎo)用戶解決問題，并且不能太復(fù)雜。

B端產(chǎn)品的復(fù)雜性要比c端高很多，所以對于B的人品來講，幫助文檔依然是有必要存在的。

6. 業(yè)務(wù)報表設(shè)計

業(yè)務(wù)報表的核心價值是掌握事實，然后發(fā)現(xiàn)問題，分析原因，產(chǎn)生對策。

產(chǎn)品經(jīng)理要和業(yè)務(wù)人員一起關(guān)注完整的體系化指標(biāo)建設(shè)，設(shè)計有實用價值的報表。

觀察分析問題的視角和思路是報表設(shè)計核心，絢麗的交互只是次要的外表。

產(chǎn)品經(jīng)理要參與業(yè)務(wù)分析工作，建立業(yè)務(wù)分析監(jiān)控體系，并負(fù)責(zé)實現(xiàn)線上化。

前三個環(huán)節(jié)是產(chǎn)品經(jīng)理要直接負(fù)責(zé)的環(huán)節(jié)，包括構(gòu)建分析體系，定義觀察指標(biāo)設(shè)計呈現(xiàn)形式；后三個環(huán)節(jié)是報表用戶使用報表的過程，包括跟蹤指標(biāo)變化，分析變動原因，根據(jù)處理問題。

產(chǎn)品經(jīng)理需要理解用戶使用報表的方式，然后和用戶持續(xù)的溝通；不斷的優(yōu)化報表的設(shè)計，只有從用戶使用報表和分析問題的角度考慮才能設(shè)計出優(yōu)秀的報表產(chǎn)品。

3.6.1 構(gòu)建分析體系

之所以設(shè)計報表，就是因為要對某個業(yè)務(wù)訴求進(jìn)行監(jiān)控和分析。

在構(gòu)建分析體系之前，要明確分析的目的是什么——即我們需要通過分析發(fā)現(xiàn)哪些方面的問題。

然后再思考我們應(yīng)該采用什么方法來識別診斷這些問題，可能的困難是什么。

構(gòu)建分析體系必須建立在對業(yè)務(wù)的深刻準(zhǔn)確的理解之上，要和一線管理團(tuán)隊多溝通；可能很多問題的分析框架和思路已經(jīng)被一項工作中發(fā)現(xiàn)并有效實踐了，一定要善于發(fā)掘，并參考借鑒。

3.6.2 定義觀察指標(biāo)

理清了分析框架和思路，下一步要確定觀察指標(biāo)，設(shè)計具備明確業(yè)務(wù)含義的指標(biāo)來考量業(yè)務(wù)。一般會從幾個大方面拆分出幾方面的觀察指標(biāo)，然后考慮是否將指標(biāo)進(jìn)一步的拆解為二級升級三級指標(biāo)，從而在更精細(xì)的維度觀察分析業(yè)務(wù)，更準(zhǔn)確的反映業(yè)務(wù)特征。

3.6.3 設(shè)計呈現(xiàn)形式

確定了觀察指標(biāo)以后，我們就要思考以什么樣的方式來呈現(xiàn)這些指標(biāo)，以便用戶能夠準(zhǔn)確快速的理解掌握指標(biāo)及變化特征。比如說是采用數(shù)據(jù)表呢，還是柱狀圖呢，這個環(huán)節(jié)要核實用戶都討論尋找最佳的呈現(xiàn)方式。

可能，作為一名業(yè)務(wù)管理人員，各種核心數(shù)據(jù)都是了然于心的。看見當(dāng)前數(shù)字都就知道有什么異常，管理人員需要的只是干凈的界面和能夠?qū)崟r更新的，準(zhǔn)確數(shù)字，其他炫酷的交互效果不需要。

3.6.4 跟蹤指標(biāo)變化

管理要用數(shù)據(jù)說話，報表數(shù)據(jù)就是診斷和決策的依據(jù)。管理人員要認(rèn)真對待分析報表中各種數(shù)字的變化波動，如果只是走馬觀花的瀏覽報表，看不出任何問題，報表就失去了意義。

作為一名管理人員必須要對數(shù)字非常敏感，能夠快速感知并解讀數(shù)字背后的變化和問題，這是出色管理人員必須具備的素質(zhì)。

3.6.5 分析變動原因

如果指標(biāo)發(fā)生了明顯的波動，需要跟進(jìn)分析波動的原因，分析工作可以由數(shù)據(jù)分析師完成，團(tuán)隊最好每周分析上周的數(shù)據(jù)走勢變化背后的原因，以便及時準(zhǔn)確的掌握業(yè)務(wù)變化情況。

3.6.6 跟進(jìn)處理問題

分析出問題后，下一步就是給相關(guān)部門或人員安排工作解決問題也就是報表設(shè)計的初衷，報表設(shè)計的第3個環(huán)節(jié)設(shè)計呈現(xiàn)方式。除非有很特殊的充電需求，其他都強(qiáng)烈地采用成熟的報表引擎，比如說之前我們用了e-chart；

需要注意：管控點、指標(biāo)、報表是三個概念。

不同領(lǐng)導(dǎo)、不同企業(yè)可能用同一管控點、不同的指標(biāo)和不同的報表，來實現(xiàn)同一管控目的。

所以，最重要的是把握用戶想要什么信息，它的管理意圖是什么？

管控點和報表之間是存在斷層的，實際管控點和指標(biāo)之間可能是多對多的關(guān)系，部分指標(biāo)是可以復(fù)用的。

作者：黎小明；微信公眾號：PM黎小明

本文由 @黎小明 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理。未經(jīng)許可，禁止轉(zhuǎn)載

題圖來自Pexles，基于CC0協(xié)議