作為一名產品小白，初次接觸不熟悉的業務時，該怎樣快速投入有效的工作中？本文作者整理了一個B端產品設計思路框架，幫助產品新人建立一個讓自己理性、有邏輯、有框架地思考產品設計的思路，以便更好地進入工作節奏，希望這份“產品自查文檔”能對初入產品的你有所幫助。

作為新手產品小白，當一個業務極其不熟悉的項目向你撲面而來的時候，你是否措手不及？

小瑤同學最近剛參與一個成熟行業從0到1的項目，深感不易。

首先，在業務上，我要從了解行業，到了解行業細分領域，了解行業賽道的競品，目標客戶具體業務流程和訴求……摸透業務需求和場景并不容易。

其次，在產品上，我要能快速地上手產品設計，需要一定的方法論流程，習慣性地高效地做出產品設計。

因此，我認為有必要建立一個讓自己理性、有邏輯、有框架地思考產品設計的思路框架，以在又快又好的節奏下開展設計工作，提高工作效率。

后面的正文內容就是我在近期0-1的產品設計工作中慢慢建立起來的B端產品設計思路框架，可以把這份框架及內容變成一個自己的「產品設計自查文檔」。

這份文檔使用的場景和起到的作用是：

1. 產品設計階段：按照這個流程邏輯去思考項目/產品，在平常做0-1的功能設計或產品時，能夠起到輔助正確思考、圍繞目標做正確的事的作用
2. 項目結束階段：再次輔助自己對項目和產品的理解，回顧對比現在和過去對產品的思考，發現自己的成長
3. 項目匯報/溝通場景：有助于「匯報產品/項目/需求」，讓我們在各種「匯報」場景都能如魚得水。比如和領導老板匯報需求、需求評審、面試講述項目經歷等。

不過，這只是它的1.0版本，還需要經過很多迭代，在這里先經過大佬們的檢驗，期待朋友們提出建議~也希望它至少能帶給一些人在產品設計上的幫助~

以下是B端產品設計思路模板的結構框架，供朋友們提前了解。

一、項目背景

項目背景主要闡述我們設想要做什么樣的產品以及為什么要做這個項目/產品。目的在于對產品的來龍去脈有更足的把握。

1. 產品設想：我們要做什么樣的產品？

老板、領導們把任務交給我們，告訴我們要做什么，但我們真不一定已經理解我們要做什么樣的產品，或者可能只是聽了個會，但是并沒有具體描述產品的定位，而這一問題就是為了讓作為產品的自己清楚明白的知道產品的定位。

產品的定位，對于To B產品，包括：

1. 產品方向——行業垂直型？綜合泛行業？/小客戶？大客戶？/工具型產品？管理型產品？平臺型產品？/純SaaS？SaaS+增值服務？
2. 客群及對應方案——為什么樣的客戶提供什么樣的服務

理清楚這些，接下來就得思考為什么——我們（產品）的目標。

2. 目的：我們為什么要做這樣的產品？

作為產品小白，老板和領導們決定要做一個產品，但我們并不一定知道（或者只是以為自己知道）做這個項目的原因。

為什么要做這個項目/產品，即產品的目標，它決定了我們做產品的方向，是產品設計圍繞的核心。

（1）對公司的價值

對公司/部門的價值，是期望這個產品能創造的商業價值，理解了這些，才能知道如何做產品才能給公司/部門創造這樣的商業價值。

（2）客戶痛點和產品對客戶的價值

用戶需求是產品存在的根源、基礎，沒有用戶/客戶的需求，就不會有產品的存在。

因此產品對客戶的價值，無疑是最重要的，產品經理必須對客戶業務當前存在的問題、客戶痛點、設想產品給客戶帶去的價值了如指掌、熟記于心。這樣在后續判斷需求的必要性、重要性及優先級上也有強有力的依據。

掌握好客戶價值與商業價值的平衡，讓兩者價值同時最大化，才是在做正確的事。

二、項目指南針

這一部分梳理的是，目前項目的頂層設計、客戶的業務模式等如何，整理后在設計產品時能有清晰的指向標，所以取名“項目指南針”。

1. 產品規劃/藍圖（做法+原因）

（1）產品范圍

產品范圍是指當前已經確定的產品覆蓋服務的業務范圍，決定了產品做什么和不做什么。

如果產品范圍是由上級領導確定，我們還要知道這么做的原因是什么。

（2）產品演進藍圖

演進藍圖是指產品范圍要怎么一步步實現，最終要實現的樣子是如何。

其用于從0-1的產品或模塊，亦可以在做1到N產品前了解產品歷史時整理。

如此，我們就能夠知道本期產品所處位置，并且對當前開發的項目的產品延展性做出合理要求。

另外，與產品范圍的確定一樣，如果產品范圍是由上級領導確定，我們同樣要知道這么做的原因是什么。

2. 產品面向的客戶是？目標客戶定位是？為什么？客戶期望是什么？

用戶/客戶需求是產品存在的基礎，如果連面向的客戶/用戶是誰都沒有搞清楚，就無法透析產品的打法——思考為什么是這類客戶，而不是那類客戶，這類客戶有什么需求未被滿足，這類客戶為什么可以帶來商業價值等。

讀懂客戶是最基本的功課，也是最難的功課，讀不懂客戶就設計產品，一定會在做設計時遲疑，最好的情況也會降低效率。

定位了目標客戶，我們還要知道客戶對產品的期望是什么。

客戶的期望包含三類，第一類是執行層的期望，第二類是管理層的期望，第三類是決策層的期望。先了解這三類客戶的期望，然后再結合業務重點問題，在產品的不同階段滿足不同不同的客戶期望。

比如執行層關注業務處理效率，管理層關注業務結果和管理效率提升，決策層關注數據報表，通過報表的業務情況提供決策調整支持，這些需求都需要分階段不同程度地滿足：可能最開始業務管理的效率是企業迫切需要解決的問題，那么顯然管理層管理效率提升的需求優先級是最高的，據開發資源情況優先滿足。

3. 定位客戶的商業模式、經營策略是什么？

客戶的商業模式，是指企業運作的業務鏈路，以及各個環節的參與方在整個業務鏈路中所處的位置和各節點參與方之間的交易關系、盈利方式。

再說簡單點，即客戶與其上下游之間的連接關系和交易方式——客戶是如何賺錢的。

經營策略則是，在其與上下游合作盈利中，核心重點做法是什么。

明白客戶是怎么賺錢的，我們才能想辦法幫他提高賺錢的效率。另外，了解了商業模式，也才能基于業務流合理的設計產品架構及功能。

4. 組織架構

我們對產品范圍覆蓋的客戶業務進行概要的了解，將所涉及的業務中的部門和崗位羅列出來，明確企業客戶內部組織架構中，部門及部門職責定義、崗位角色及崗位職責定義是什么。

我們還可以對使用系統的部門、崗位和重點部門、崗位做標記，清晰定位其在組織架構中的位置，比如像下面這張圖中對組織架構的梳理，將門店運營中心、品牌與市場部、門店拓展中心標星，提醒我們理解其在業務運轉中是如何與各個部門協作的。

業務是血肉，組織架構則是撐起業務的骨架，沒有組織架構里的每一個部門、每個部門的每一個人，業務就不能運轉。

只有知道客戶的組織架構是如何的，也才能理解整個企業的運作流轉。

5. 業務概況

業務概況指的是，企業規模、經營狀況、戰略定位、資源能力等基本信息。比如了解一個公司的產品種類、產品銷售量、銷售金額、銷售產品占比等等。

這個一般都是具體項目確定實施之前去了解，如果是從0到1做標準化產品，也可以針對行業中的客戶群體多做幾個客戶的調研，了解大部分目標客戶的情況，或是了解調研SaaS產品的第一個實施交付項目中的客戶業務概況。（具體如何了解，結合實際情況即可）

有人可能會問，我們為什么要了解這些看似和產品無關的東西呢？

因為做B端產品，得從管理層、戰略層的角度理解業務，了解企業的基本經營情況，才能明白為什么有些企業的流程是這樣，而有些企業的流程是那樣。我們不僅要懂得它的作業流程，也要懂得為什么企業的作業流程是這樣，以打造更貼合客戶甚至行業業務發展的產品。

用一種推理的思維去理解，就像我們做C端產品一樣，要深度了解用戶，對用戶的特征、行為都做調研，刻畫出用戶的真實全貌，圍繞「用戶故事」做設計，才能做出“讓用戶為自己尖叫”的產品；B端產品設計同理，我們要深度了解企業，作出企業的「企業故事」，才能做出“讓客戶為自己尖叫”（客戶感到本企業使用產品后變得非常優秀）的產品。

三、業務概要流程

業務概要流程是指客戶所需支持的所有業務場景的最簡化拆解：主要流程最大化拆解，并對主要流程上的分支流程也進行最大化拆解，直到沒有新的業務場景可羅列。（類似MECE原則，但不需要細化）同時，從這些流程中拆解出對應所需的功能模塊。

為什么作為小白需要梳理【業務概要流程】呢？

1. 理解各個模塊之間的關系和業務價值

通常來說，我們作為新手，不會接觸所有模塊的需求以及核心模塊的需求，也并不一定有人清楚的告訴你，你要做的模塊是怎么來的，為什么要做，跟其他需求有什么關聯。項目相關的很多信息我們是不知道的，需要自己花更多的力氣去接觸和學習。

而思考概要流程的目的在于，在產品設計之前，對要做的產品的模塊如何而來做個拆解，以確保自己對各個模塊之間的邏輯、關系鏈路有深刻理解，這樣從上往下看，就知道底層的產品設計如何做。

2. 梳理并了解在產品提供支持的業務范圍內所需要對接的系統

一般來說客戶都有不少已在使用的現有系統，可能涉及系統的對接，因此我們可能需要了解系統處理的業務，從中我們也更能理解客戶的業務。

借用王戴明老師舉的一個例子來解釋一下：給你一個需求，告訴你要支持業務員在拜訪零售店時錄入訂單并傳送至ERP系統發貨。

這里面的主要流程是【業務員拜訪零售店】→【業務員錄入訂單】→【ERP系統接到訂單】→【倉庫發貨】→【零售店收貨】。

而【業務員拜訪零售店】這個場景需要【門店管理】【客戶管理】【業務員管理】模塊來支撐，【業務員錄入訂單】需要【商品管理】【價格管理】模塊支撐等等。

由此我們可以梳理出如下形式的業務概要流程圖，理解業務流程的同時，理解抽象出的模塊是怎么來的，還能了解需要對接的系統在其中的價值、意義。

四、細節業務流程圖

細節業務流程是整體業務流程的拆分，是針對整個業務下某一流程的展開。

對細節業務流程的梳理除了讓我們進一步理解業務流程，找出細節業務流程中不解之處，還能讓產品設計的流程邏輯更縝密、完整，避免不必要的邏輯漏洞（或發現產品設計中是否有邏輯缺陷）。

這里就如下圖所示，把各個模塊的細節業務流程梳理出來即可。

五、功能結構圖

依據跨角色和跨階段的流程圖，就能夠梳理出所需要的功能結構圖，這樣也對自己的需求做了結構化處理。（結構圖這里就不實例了，太基礎）

六、頁面流轉與需求列表

當功能結構和流程都已梳理完成，可以進入頁面流轉及具體頁面的設計，這時可以同時將一些不確定做不做或者本期是否做的需求列在需求池中，以便后續查詢。

當然，我們也可以把確定做的需求列入需求池，在【業務場景】【需求價值】【開發成本】【優先級】等字段做必要的記錄。以此要求自己對每個需求都考慮清楚，對其了如指掌，保證每個需求有憑有據，在任何人對需求提出疑問時都有較充分的理由支撐。

對于需求池，這里提一下需求池的含義及其意義和最近工作中逐漸建立的需求池模板。

需求池是需求管理的一個高效的形式，用它記錄產品的各種各樣的需求，可以高效管理需求。

需求池中的需求，可能是產品功能設計之始的競品分析、產品思考、用戶調研而得，也可能是產品迭代中業務、運營、市場、領導等提的需求非常之多，因此需要經常更新和整理。

需求池的意義在于：

1. 保證每一個需求被記錄，不遺忘需求，對每一個需求提出方都能夠有交代
2. 輔助產品經理對每一個需求進行歸類、理性分析（價值、成本、優先級），讓需求寬進嚴出，協助版本規劃
3. 讓每一個需求都有它的生命周期，有頭有尾，能追根溯源，也能看到它的演變，幫助產品經理逐漸建立健全產品全貌
4. 了解每一個需求的進度，讓產品經理對需求了如指掌，讓工作更清晰

下面是近期工作建立的適用于我工作的需求池模板，用EXCEL建立好表頭字段，需要記錄需求時，按字段思考、填寫，即可。

對于頁面流轉，可以通過【功能】【角色】【場景】的方式來梳理，不容易遺漏邏輯。最后可將這些頁面匯總至一個表，供開發了解，一目了然。

當然，如果已經熟悉B端設計工作，其實在腦子里也能想好應該有哪些頁面，直接列出來就好了。

但話說回來，這一步驟主要在于窮盡用戶使用功能的場景，這樣我們就能在做頁面具體設計的時候，思考每一個需求的成本和價值，將每一個具體需求（元素、邏輯等）都設計到位。

以某公司課程培訓功能為例設計頁面流轉，參考如下：

1. 頁面流轉圖

功能：課程培訓

角色1：企業

場景1：創建、編輯和發布課程

場景2：

場景3：

場景n：…

角色2：員工

場景1：…

場景2：…

場景n：…

2. 頁面匯總表

最后可以將上述流轉頁面的所有頁面匯總到一個表中，頁面開發一目了然

七、權限設計

無論是標準化To B產品還是定制化To B產品，都會涉及功能/菜單權限、數據權限的設計。

雖然現在多數標準化To B產品設計都是在自定義角色時添加功能權限，但功能權限可能會預置一套，且需要分析哪些角色要用到哪些功能，具體到增刪改的按鈕和查詢的權限，所以需要提前思考功能/菜單權限如何拆分，數據權限又如何控制。

下面就分三類權限設計分別介紹下如何梳理權限設計的思路，提高設計效率。

1. 功能/菜單權限設計

設計功能/菜單權限時，可按照下面的模板梳理不同角色需要的菜單、頁面、操作元素的權限，思考并梳理一般性的角色（標準化產品中的通用角色/定制化產品中的指定角色）需要哪些操作

2. RBAC權限模型

RBAC權限模型是迄今為止最普及的權限設計模型，全寫Role-Based Access Control，翻譯過來即基于角色的訪問控制。

（1）RBAC權限的定義

首先還是要解釋一下RBAC權限：每個用戶都要被賦予一個或多個系統角色，每個系統角色都對應一個明確的權限集合，包括對菜單、頁面元素等資源的訪問和操作權限。

一句話概括RBAC權限的作用，當用戶基數增大，角色類型增多時，RBAC權限設計能夠將具有相同屬性（相同權限）的用戶分配相同的角色及角色下的權限，提高權限管理員的工作效率。

（2）RBAC權限模型的模式

將RBAC權限設計展開，它包括RBAC0、RBAC1、RBAC2、RBAC3四種模式。其中RBAC0位核心模型，RBAC1、RBAC2、RBAC3都為建立在RBAC0上的擴展模式。

這里簡單介紹一下四種模式，主要根據業務需要選擇合適的模型來思考設計，具體就不再展開，網上有很多資料具體講解該模型：

RBAC0模型：在最核心的模型中，用戶和角色是多對多的關系，角色和權限也是多對多的關系

RBAC1模型：RBAC1模型引入角色繼承的概念，即子角色可以繼承父角色的權限。

如下圖，在某個大部門中，規定總監的權限不能超過總經理的權限，部門主管的權限不能超過總監，若采用RBAC0模型，權限分配失誤時，將出現總監擁有總經理沒有的權限，RBAC1模型則能夠解決這個問題：創建總經理角色并配置權限后，總監角色繼承總經理角色的權限，并可支持在總經理擁有的權限上刪除權限。

RBAC2模型：RBAC2基于RBAC0增加了角色的約束控制，主要包括：

1. 角色互斥：同一用戶只能分配到一組互斥角色集合中的其中一個角色。該約束控制運用于責任分離的場景。
2. 基數約束：指一個角色關聯的用戶數量/一個用戶可關聯的角色數量/一個角色對應的訪問權限數量受限制
3. 先決條件：指想要有某個上級角色的權限，需要先擁有下一級的角色的權限

RBAC3模型：統一模型，RBAC0、RBAC1和RBAC2模型的整合具體的RBAC權限設計思路可參考紛享銷客、銷售易，現成的產品體驗，成熟、龐大的系統，易用性強，親自實操記得更牢，這里就不再贅述~

3. 數據權限設計

定義：角色在頁面中能看到的數據范圍（數據集合）。比如針對某個列表頁，能看到的是某個區域下的數據，也可能是某個賬戶下或某幾個賬戶下的數據。

實現方案：

（1）方案一

通過組織機構樹控制：當前節點能夠看到其子節點下的數據。該方案實現方式較復雜，但靈活性強。如下圖，各個賬號分別對應能看到的數據范圍由他所在的組織機構位置及其他額外數據控制（如限制某一賬號只能查看當前節點）決定

圖源：《決勝B端》

這種通過組織機構樹來設計數據權限的方式，表現在原型設計上，通常為如下所示。在角色權限配置中，可配置該角色的權限為【本人】【本人及下屬】【本部門】【本部門及下級部門】和【全部】

（2）方案二

通過客戶地區控制：根據該賬號所在區域判斷，方式簡單，容易實現，但靈活性差

八、報表設計指南

報表設計涉及到客戶管理層、決策層對業務管理工作的分析，報表功能往往決定了企業對產品的評價，決定企業是否付費，是非常重要的留存功能。

其次，如果是SaaS產品，不同行業、不同公司都可能會有不一樣的指標，因此考慮哪些可以納入通用指標需求，難度較大。所以需要有一個指南來帶著自己思考，以免頭大的同時，讓自己對思考流程越來越熟悉，達到熟能生巧的水平。

由于在0-1的設計中，我并沒有參與報表模塊的設計，因此也只是在閱讀了相關資料后，整理“如果我來設計報表，我會如何設計”的思路思考，僅供參考分享。

1. 設計核心

從角色用戶使用報表和分析問題的角度考慮問題

2. 設計思路

（1）業務體系構建

1. 明確目的：明確報表分析目的，需要監控和分析什么問題，為什么要監控和分析這些問題，他們屬于何種業務訴求？→通過一線業務人員、管理層訪談得出
2. 建立方法：采用何種方式、何種指標識別這些問題？→可以通過一線人員總結出的分析框架、思路分析、參考得出（或者已經有明確指標那就最好了）

（2）指標設計

這一步設計具有明確業務含義的指標，先設計大的指標，然后再考慮是否拆分成更小的指標，以便能從更精細的角度全面、深度衡量結果。粗細拆分的必要性主要取決于行業業務復雜度、公司業務成熟度、產品所處階段等。

（3）設計呈現形式

呈現形式設計核心：考慮每種指標用哪種形式能夠讓用戶最快速、準確地掌握指標信息柱形圖？折線圖？環形圖？只需要表格呈現數字？

（4）報表交互設計產品參考

作為一個菜雞小白，我們掌握的報表交互樣式大概率少之又少，無論是在產品設計還是平常，都應該多看多積累成熟系統的優秀交互設計，下面是推薦的參考產品和專業文件。

1. 軟件產品參考
2. Tableau–學習數據可視化
3. SmartBI/帆軟FineReport–學習成熟表樣、數據呈現形式
4. 商業文件/報告
5. 《華爾街日報》、上市公司財報

這些財報里面的形式都非常規范、講究、專業，倘若可以參考這些報表，運用到報表設計當中，則能體現產品經理報表設計的專業性。以上是對報表設計思路的初次思考，它肯定還需要非常多次的迭代，且報表設計較為復雜，如有機會接觸報表設計，希望自己積累到一定程度的時候，還能夠出一個專題整合，系統講述一番，分享給大家~

九、結語

這份產品設計思路模板只是引導我們高效思考的工具，并不是每一點都必須完整思考，在實際工作中我們可能只需要用到其中部分指引輔助思考，或者超出該文檔模板思考范圍（這個就可能涉及模板的優化迭代了），具體運用還是要根據實際情況靈活變化。但能肯定的是，以上一步步的分析，使得我們可以在每個環節把問題聚焦、分解，對著文檔一個個尋找自己對產品、項目梳理的漏洞，專注分析眼前的某一個問題，搞清楚弄明白后，繼續專注于下一個問題，實現分階段各個擊破。

全文參考資料

1. 《決勝B端》——楊堃
2. 《SAAS產品經理從菜鳥到專家》——王戴明
3. 《B端產品新人的第一個項目》課程——王戴明