你有沒有遇到在梳理B端產品界面信息的時候，不知道該如何開始？
你有沒有在梳理到一半的時候，覺得前面整理的不對，想從頭開始？
我曾經都有過，因此我想了很多方法，期望盡可能整理出相對好用，又不反復修改的信息架構。
你知道嗎？其實在很多地方，譬如在寫ppt、寫文章、設計網站、繪制海報中，信息架構都是用得到的。
今天呢，知果想和你聊聊有關B端產品信息架構的事情。
這事兒說大不大，說小不小。我的實踐體會是，信息架構就像一個物體的骨架，有了好的骨架，我們才能更好的填充其里面的內容。
打個比方，對于一棟居民住宅樓來說，樓的整體結構決定了樓道、電梯、屋子、廳堂等部分的設計。而對于屋內臥室的結構來說，其結構決定了桌子、柜子、床的擺放位置等。
對于B端產品來說，信息架構設計的好壞，一方面決定了用戶在使用產品中的難易程度；另一方面也影響著后續當產品功能添加時，產品的延展性如何。
下面，知果將與你們分享關于B端產品信息架構設計的 6 大組織原則：
獨立組織原則是指節點與節點之間是沒有強烈的因果或先后關系，它們是相對獨立的。它們可以共同完成某件事情，但完成的期間互相不相關；也可以相互之間完全沒有關聯，彼此獨立。
例如，要把A任務分解成3個子任務，這3個子任務之間是沒有前后關系的，它們可以同時進行，它們都做完了，A任務就算完成了。
再例如，通常來說，B端產品中用戶信息模塊和消息通知模塊就是無相關關系的，我們在設計它們之間的結構關系時，就可以分別考慮。
包含組織原則是指節點與節點之間父與子的關系。我們看到的樹形結構，就是包含組織原則的其中一種視覺呈現形式。
例如，在云效系統的項目協作模塊中，包括了任務管理、需求管理、迭代管理、度量統計等子模塊。質量管理模塊中，包括了測試計劃、測試用例、缺陷管理等子模塊。
關聯組織原則是指節點與節點具有某種聯系，相互之間產生影響和牽連。
在我們日常生活中，大部分事物都不是獨立存在的，而是以一種關聯的形態出現。
例如，當一個外賣APP內商家的數量越豐富，食物越豐富且好評也越多的時候，用戶也會越多，反之亦然。
在B端產品中，一些數據是通過API的方式從其他系統讀取過來的。用戶也許無需知曉數據的來源，但我們設計者需要在架構圖上標注與明確這種聯系，同步到成員。
再例如，在DevOps系統中，產品經理A給研發工程師B下完任務后，在A的任務清單里可以看到新增了一條他創建的任務，與此同時，在B處也出現了一條新的研發任務。
B端產品中很多的數據信息具有時效性，比如操作日志、待辦事項、預定會議室數據等。因此，時間組織原則經常被用到。
列表內容的排序基本都遵循時間組織原則，將最近的數據往前靠。如果用戶想查詢幾天前的數據，則可以使用列表上方的篩選條件查詢相關數據。
B端產品中很多信息具有前后的流程關系，就需要用到流程組織原則了。
例如，員工A提交的請假審批流程，需要按照流程逐一審批才可結束。
再例如，在監控系統中，如果要給一個監視器添加告警信息，需要將監視器的其他基礎信息補充完整，才能去添加告警內容。
維度組織原則是指信息按照維度來分類，并呈現給用戶。在第4點中提到的時間組織原則就是維度組織原則中的一種。
在C端產品中常見的有，按推薦、按熱度、按最新、按點贊數等。
在B端產品中，維度組織通常與場景、數據性質有關系，最主要的還是看用戶需求。
例如，在DevOps系統中，一個測試工程師通常會跟進1-3個產品的測試，但他們最主要的需求是能在一個頁面上看到所有待處理的任務，而不是每個產品下有幾個待處理的任務。因此，信息組織的維度不是按產品，而是按任務狀態。
B端產品信息架構設計是碎片化需求轉原型的第一步，理清產品的信息構架，才有之后的交互設計、視覺設計等一系列行為。
關于B端產品信息架構設計的其他方面，例如信息架構設計的基本思路、信息架構的4大模式、什么是信息架構中的節點組織原則等，在我的書籍《B端思維》中都有涉及到。
書中還包括B端產品用戶界面導航如何設計、布局如何設計、信息如何呈現等均有詳細闡述。
好啦，知果今天的分享就到這里，我們下期見~
本文來自微信公眾號 “知果日記”（ID：gh_690a8b6479cb），36氪經授權發布。
