編輯導語：B端産品的業務通常會涉及到多個角色，需要各個部門和團隊的分工協作和及時溝通。信息架構圖和泳道圖能夠有效地提高工作效率以促進業務的完成，本文作者介紹了有關信息架構圖和泳道圖的相關内容，感興趣的一起來看看吧。

當思考某個産品時，尤其B端産品涉及多個角色，這意味着存在大量跨部門和跨團隊的協作溝通，而這些都可能造成處理漏洞、效率低下和重複的風險，也會增加成本。

這時各類圖的運用就能幫助解決此類問題，如：信息架構圖、泳道圖、流程圖等。

一、信息架構圖

定義：指對某一特定内容裡的信息進行統籌、規劃、設計、安排等一系列有機處理的想法。

信息架構圖是産品的骨架，它能直接看到産品模塊/功能等信息。

首次畫信息架構圖都會誤以為是一張簡單的思維導圖而已，殊不知畫信息架構挺考驗一個産品人的能力。

Tip1：畫信息架構秉承方法論MECE原則

以某行政業務為例：如差旅功能分在角色模塊也行，屬于人的類目，分在事的模塊也行，因為也屬于事的類目。

分類不清晰的産品會給使用者造成認知模糊，每次找某個東西都會不清楚到底去哪裡找。這樣極大的降低了操作效率。

此外，一款分類不清晰的産品，後續疊代，耗費的成本更高。如增加某個新功能，加在哪裡？怎麼加？這個新功能和以前的功能是否兼容？

Tip2：MECE原則驗證方式

從産品中拿某個功能去看，大家能快速知道放到哪個模塊裡，大抵就是正确的。

如：大家用微信，如果日常要繳一個水電費，大家第一直覺是微信裡“我”的模塊。不太可能是微信裡的“發現”的模塊。

有效的進行功能分類，相互獨立，且符合用戶的認知。

在産品初期，很大程度上就規避了風險，尤其一些疊代幾輪後的産品，想再做一些改動很難，因為礙于開發成本太高。這或許是很多公司明知道産品不好，但又很無奈的原因之一 。

二、泳道圖

一種反映流程中人與人或部門與部門之間關系的圖表，

這種繪圖方法能夠快速而輕松地繪制和追蹤流程，可以展示出一個商業過程之間的關系，并展示為那個過程負責的功能闆塊（比如說部門）。泳道圖專注于價值活動之間的邏輯關系，更好地展示每個價值活動的責任。

1. 産品人的用途

1. 分析表達需求；
2. 講清楚業務和系統、系統和人的關系；
3. 摸清楚系統邊界、開發成本。

2. 泳道圖的事件流構成單元

1）目标：事件流的最終目标是什麼

它是可操作的、戰略性的、功能性的嗎?

涉及哪些組織單位，希望分析到何種程度的細節以發現問題?

2）主流程：事件流的正向流程

為了實現目标，流程被定義為實現特定最終結果的一系列任務，如獲取新客戶。

對于所分析的每個流程，最終結果是什麼?

3）角色：參與者的角色以及角色之間的關系

哪些組織單位參與？

該過程的輸入來自哪裡？

誰接受該過程的輸出？

4） 參與者：明确所有事件流的參與者

如：系統也是一個事件流的一環節參與則。

5）開始與結束：事件流的起點和終點

6）信息的流向：要完成的任務，順序

是否有任何空隙或步驟缺失?

是否有重複工作?是否存在重疊，即幾個人或團隊執行相同的任務或活動? 是否存在低價值的活動?

7）異常流程：時間流的逆向流程

以某跨境物流平台為例：

1.0版本泳道圖，一個新用戶在平台下單需要操作13步，如這樣一個産品讓大家去用，大抵基本不會用，更何況是tob的用戶。基于産品的利益相關者分析可以判斷，産品的角色的劃分是否合理且滿足需求。

2.0版本泳道圖，泳道圖直觀的展示：用戶需要操作的步驟5步，平台需要呈現的界面，後台需要的開發支持，清晰明了。角色分為：新用戶，平台，後台

（非嚴格标準泳道圖畫法，重點表達産品和業務邏輯）

3.0版本的還在死磕中。

泳道圖是底層的系統核心，做産品不能脫離了業務。它幫助展示出一個商業過程之間的關系，便于做有效決策。

信息架構圖，是一個産品的雛形，信息有效的分類且相互獨立，對用戶而言能提升操作效率，對企業而言能低成本持續疊代。

本文由 @番茄 原創發布于人人都是産品經理，未經許可，禁止轉載

題圖源自 Unsplash，基于CC0協議

,

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!

查看全部