B端产品基本功-信息架构图
先问大家一个问题：按照产品的工作流程，前面我为大家介绍了 需求调研、UML系统建模。那接下来，我们应该做什么？
很多同学应该会说——「绘制原型图」。然后开始沉溺于原型图布局样式交互的细节，不可自拔。
熬了好几个大夜，最后拿着高保真原型去汇报。结果到了老板那边，却被一次次拍回来，接着又加班熬夜继续调整原型。时间久了，产品觉得老板太事儿了，天天抠原型图。产品这活儿没法干，要跑路。但是站在老板角度来看，整体的页面交互流程不顺畅，细节原型图里的关键元素缺失……这种原型方案确实没法通过。
而之所以出现这种情况，就是因为我们没有提前梳理信息架构图。梳理信息架构图，就是通过「思维脑图」的形式 展示产品完整的页面交互流程、每个页面的关键元素。因为思维脑图 修改维护简单，并且可以展开折叠。所以可以方便我们快速的进行整体review和调整，发现设计上的漏洞。 信息架构图确认没问题之后，再绘制原型图，就能有效避免来回返工的问题。
因此重点的事情说在前面
先梳理信息架构图，再绘制原型图。不要一上来就画原型！！！
先梳理信息架构图，再绘制原型图。不要一上来就画原型！！！
先梳理信息架构图，再绘制原型图。不要一上来就画原型！！！
一 什么是信息架构
这种说法有些抽象，下面介绍下我的理解。
在用户体验要素中，信息架构属于第三层-结构层。结构层需要做的事情，是将产品需求转化为产品与用户之间的互动形式和规则。
所以信息架构，决定了产品包含的元素与元素之间的关系，也决定了用户具体如何使用产品。
因此我对信息架构的理解：产品呈现给用户看到的 「导航结构」『页面信息』「页面操作」『页面跳转交互』等。
为了让大家更直观的理解，下面放一张我之前梳理的的信息架构图。主要是从菜单开始，一步步到具体每个页面上展示的信息、操作、页面与页面之间的交互。
二 如何梳理信息架构图
信息架构是面向用户的，目的是为了让最后呈现出来的产品能用户用得好用的爽。
优秀的信息架构，需要具备易读性、一致性和拓展性。
举例：菜单的层级结构，不能弄的太零散。每个功能都拆一个单独的菜单出来，这样会导致菜单太多且乱，用户使用不便利。在详情页设计时，不能把页面布局弄的太满，如果后面详情页内容扩展时还需要整个页面重新设计开发，拓展性就会有较大问题。
所以 梳理信息架构的前提是：需求调研做到位了。即我们清楚了用户需要看到什么信息，需要进行什么操作，各个操作步骤之间的流程关系是怎么样的，未来用户还希望要什么。
在梳理信息架构时，我常用的构建方式是 自下而上
基于前一步 UML系统建模我们其实已经完整的梳理出了 产品的功能、实体的属性等等信息。其实我们已经清楚了 用户需要在产品上看到什么信息，进行什么操作等。
接下来我们需要做的就是按照用户的使用场景和习惯，拼出来相关页面。
举例：针对👆 代理商处罚线上化的产品，我们前面梳理出了 实体关系中 有 违约记录、处罚记录，那相应的围绕这2个实体我们需要有列表页和详情页承接。
具体列表页展示实体上的那些属性信息，需要我们来判断 哪些是核心关键必须让用户在列表就看到的。而详情页 要展示全部属性信息，但是这些信息如何分类布局，用户看起来更方便。举例 违约相关信息放1个板块，违约对应的处罚信息放另一个板块。
对于B端产品而言，信息架构的设计会相对简单。我们只要使用主流广泛接受的信息呈现即可，例如B端产品其实主要就是 列表页+详情页，列表页 核心内容就是 搜索、筛选、列表内容、列表操作。而 B端的操作也逃不出 增删改查这4个核心基础。
三 信息架构图和功能架构图的区别
产品功能结构图的重点是梳理产品的功能逻辑与功能模块。信息架构图的重点是梳理具体页面及页面的字段信息。
举个栗子大家就能懂，下面是微信的功能架构图和信息架构图。
以上就是关于信息架构，我个人的思考。欢迎大家评论交流
B端产品基本功 文章被收录于专栏
通过理论知识+实战经历+学习建议，全方位的分享B端产品经理必备的基本能力。
投递飞鱼科技等公司7个岗位 >