你有没有遇到在梳理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氪经授权发布。
