信息架构设计

很多新人拿到需求之后，第一反应就是打开工具开始画页面。画着画着就开始纠结——这个功能放在哪个导航下面？这个页面的层级到底算一级还是二级？用户从首页到这个功能，要点几步才能到？
然后就陷入了一种"边画边拆边改"的循环。
其实这些问题，本质上都是同一个问题：信息架构没有提前想清楚。
信息架构这个词听起来有点学术，但说白了，它就是回答一个问题——你的产品里有哪些内容，这些内容怎么组织，用户怎么找到它们。
就像你搬进一个新房子，在买家具之前，你得先想清楚哪个房间干什么用、动线怎么走。信息架构就是产品的"户型设计"。
今天就来聊聊，产品经理到底该怎么做信息架构。

一. 信息架构到底是什么

我先用一个最通俗的例子来解释。
你去一家超市买东西。
一家好超市，你进门就能看到分区指示牌：生鲜区、零食区、日用品区、酒水区。你想买牛奶，直奔生鲜区，几秒钟就找到了。
一家烂超市呢？牛奶放在零食区旁边，洗衣液跟饼干摆一个货架，你找个东西得把整个超市逛一遍。
这两家超市卖的东西可能一模一样，但"东西怎么分类、怎么摆放、怎么让你快速找到"，这就是信息架构的差距。
回到产品设计上，信息架构要解决的核心问题就三个：
  • 分类： 产品里有哪些内容和功能，它们按什么逻辑分组
  • 层级： 这些分组之间是什么关系，哪些是一级入口，哪些是二级、三级
  • 导航： 用户怎么在这些内容之间移动，怎么最快找到想要的东西
听起来很简单对吧？但我见过太多产品，功能做得很全，用户就是找不到。
问题几乎都出在信息架构上。

二. 为什么产品经理必须重视信息架构

很多新人觉得，信息架构不是交互设计师或者UX设计师的活儿吗？
在大公司确实有专门的信息架构师，但在绝大多数团队里，这个活其实是产品经理在干。
而且更关键的是——信息架构决定了你后面所有工作的基础。

影响一：决定导航结构

信息架构直接决定了你的产品导航长什么样。一级导航有几个Tab？侧边栏分几级？每个入口下面放什么？
如果信息架构没想清楚，你会发现导航越做越乱。今天加一个入口，明天塞一个功能，最后导航栏挤满了十几个选项，用户看着就头大。
我之前接手过一个B端后台，导航栏有23个一级入口。23个。用户每次找功能都要在导航栏里翻好久，使用体验极差。后来我们花了一个月时间重新梳理信息架构，把23个入口合并精简到了7个，用户满意度直接从3.2分涨到了4.5分。

影响二：决定页面设计

信息架构想清楚了，你画原型的时候就知道每个页面该放什么内容，不该放什么内容。
如果没想清楚，你经常会碰到这种情况——这个页面上要展示的东西太多了，塞不下；或者反过来，页面上空空的，又不知道该放什么。
本质上就是因为你没有提前规划好，每个页面的信息边界在哪里。

影响三：影响开发架构

这个很多产品经理不知道。
你的信息架构，会直接影响开发的技术架构。前端的路由怎么设计，页面组件怎么复用，数据接口怎么拆分，很多时候都跟你的信息架构有关。
如果你的信息架构中途大改，开发可能也要跟着大改。成本是很高的。
所以，信息架构越早确定越好，改动越小越好。

三. 信息架构设计的完整流程

好，道理讲完了。接下来聊聊具体怎么做。
我自己总结了一套五步法，基本上能覆盖大部分场景。

第一步：收集和整理所有内容

首先你要知道，你的产品里到底有哪些"东西"。
这些"东西"包括：功能模块、页面、内容类型、用户操作等等。
具体怎么收集？有几个来源：
  • 需求文档： 你的PRD里写了哪些功能
  • 竞品分析： 竞品的功能和页面有哪些
  • 用户访谈/调研： 用户最常用的功能是什么，最想要的是什么
  • 业务方反馈： 运营、销售、客服他们需要什么功能
把所有收集到的内容，全部列成一个清单。不需要分类，先全部倒出来。
我自己的习惯是用便签纸或者在线白板（比如Miro），一个功能写一张便签，全部贴出来。
举个例子，如果你要做一个电商App，你的清单可能长这样：
  • 商品浏览、商品搜索、商品分类、商品详情、商品收藏
  • 购物车、下单、支付、优惠券
  • 订单列表、订单详情、退换货、物流查询
  • 用户注册、登录、个人信息、收货地址管理
  • 消息通知、客服咨询
  • 会员等级、积分、签到
  • ……
先不要急着分类，这一步的目标就是"穷举"，尽可能把所有东西都列出来。

第二步：卡片分类法——让内容找到自己的位置

内容清单出来之后，下一步就是分类。
这里推荐一个非常经典也非常实用的方法：卡片分类法（Card Sorting）。
做法非常简单：
方法一：自己分
把每个功能/内容写成一张卡片（可以用便签纸或者在线工具），然后凭你对业务的理解，把它们分成几个组，给每个组取一个名字。
比如上面的电商例子，你可能会分成：
  • 逛： 商品浏览、搜索、分类、详情、收藏
  • 买： 购物车、下单、支付、优惠券
  • 管： 订单列表、订单详情、退换货、物流
  • 我的： 个人信息、收货地址、会员、积分、签到
  • 沟通： 消息通知、客服
方法二：找用户分（推荐）
如果条件允许，找5-8个目标用户，给他们一堆卡片，让他们自己分组，并给每组命名。
这个方法的好处是，你能看到用户的心智模型跟你想的是不是一样。
我之前做过一次卡片分类测试，发现用户把"收藏"和"浏览记录"放在了一组，而不是我预设的"商品"组。这让我意识到，用户觉得这两个功能的本质是"我看过的/我喜欢的"，是跟"我的"相关的，而不是跟"商品"相关的。
这种洞察，你坐在办公室里是想不出来的。
分类没有标准答案，但有几个原则：
  • 分组的逻辑要一致， 要么按功能分，要么按场景分，别混着来
  • 命名要直觉化， 用户一看名字就知道里面有什么

第三步：确定层级结构

分完组之后，你要把这些组织成一个层级结构。
通俗地说就是画一棵树。
这棵树一般不要超过三到四层。层级太深，用户找东西要点太多步，体验就差了。
这里有一个关键原则：广度优先，而不是深度优先。
什么意思？就是宁可在同一层多放几个入口，也不要让用户一层一层往下钻太多次。
比如一个后台管理系统，与其这样设计：
系统管理 → 用户管理 → 角色管理 → 权限配置
不如这样：
用户管理（包含用户列表和角色管理）
权限配置（单独一个入口）
因为用户到"权限配置"需要的步骤少了两步。
不过也不能走极端。 如果一级入口超过了7-9个，用户的认知负担就太重了。
所以这里有一个平衡点：
  • 一级入口： 5-7个最佳，最多不要超过9个
  • 二级入口： 每个一级下面，5-10个都还好
  • 三级及以下： 尽量避免，如果必须有，考虑用面包屑或者搜索来辅助
我自己画层级结构的时候，一般用XMind来做，最终产出大概是这个样子：
电商App
├── 首页
│   ├── 搜索入口
│   ├── Banner运营位
│   ├── 分类快捷入口
│   ├── 推荐商品Feed
│   └── 限时活动入口
├── 分类
│   ├── 一级分类列表
│   └── 二级分类 + 商品列表
├── 购物车
│   ├── 商品列表（编辑数量/删除/选择）
│   ├── 优惠券/满减提示
│   └── 结算入口
├── 消息
│   ├── 订单消息
│   ├── 活动消息
│   └── 系统通知
└── 我的
    ├── 订单管理（待付款/待发货/待收货/已完成）
    ├── 收藏 / 浏览记录
    ├── 收货地址
    ├── 会员中心（等级/积分/签到）
    ├── 优惠券
    ├── 客服入口
    └── 设置
这张图，就是你后续画原型的"地图"。

第四步：设计导航方式

层级结构出来之后，下一步要想的是：用户怎么在这些内容之间导航。
常见的导航模式有这些，我按使用频率排个序：
底部Tab栏（最常用）
适合C端App，一般放3-5个最核心的一级入口。微信、淘宝、抖音都是这种模式。
优点是用户一目了然，切换方便。缺点是数量有限，超过5个就放不下了。
侧边导航栏
适合B端Web产品，可以放比较多的导航项，而且支持多级展开。
比如飞书后台、钉钉管理后台都是这种模式。
优点是容量大，支持多层级。缺点是占屏幕空间，在移动端不太友好。
顶部导航栏
适合Web端，导航项不多（5-8个）的情况。
很多官网和SaaS产品用这种模式。
搜索导航
当内容量很大的时候，搜索可能比分类导航更高效。
比如你在淘宝上找一个很具体的商品，你大概率不会一层一层点分类，而是直接搜。
我的建议是：不要只依赖一种导航方式。
最好的做法是主导航 + 辅助导航。比如底部Tab栏作为主导航，同时提供搜索功能和快捷入口作为辅助导航。
用户找东西的方式是多样的，有人喜欢按分类找，有人喜欢搜，有人喜欢从最近使用里找。你要让每种用户都能高效地找到想要的内容。

第五步：验证和迭代

信息架构不是一次定稿的，它需要验证。
验证的方法有几个：
方法一：树形测试（Tree Testing）
给用户一个任务，比如"请你找到修改收货地址的入口"，然后把你的信息架构（不带界面，只有文字层级结构）给用户看，让用户点选。
如果大部分用户都能快速找到，说明你的架构没问题。如果很多人找不到或者走错了路，就说明这个位置的分类或命名有问题。
方法二：内部走查
拉上团队里的同事，特别是设计师和开发，一起review你的信息架构图。
让大家站在用户的角度，挑毛病。这一步虽然简单，但经常能发现一些你自己忽略的问题。
方法三：上线后看数据
如果产品已经上线了，你可以看用户的行为数据：
  • 每个一级入口的点击率分布均匀吗？（不均匀说明分类不合理）
  • 搜索功能的使用率高吗？（太高可能说明导航找不到东西）
  • 用户到达目标页面的平均步数是多少？（越少越好）
  • 某些页面的跳出率是不是异常高？（可能是用户走错了路）
这些数据都能帮你持续优化信息架构。

四. B端和C端信息架构的差异

这个单独拎出来说一下，因为B端和C端的信息架构思路差别还挺大的。

C端产品

用户量大，使用场景多样，用户耐心低。
信息架构的核心原则是：简单、直觉、少思考。
  • 层级要浅，最好两层以内就能到达任何功能
  • 命名要通俗，用户一看就懂
  • 核心功能要有最短路径，不要让用户绕远
  • 善用搜索和推荐来弥补导航的不足

B端产品

用户是专业人士，使用频率高，功能多且复杂。
信息架构的核心原则是：清晰、高效、可扩展。
  • 可以接受更深的层级（三四层都OK），但要有清晰的面包屑和全局搜索
  • 按业务模块分组，而不是按功能类型分组
  • 要考虑权限——不同角色看到的导航可能不一样
  • 要预留扩展空间——B端产品功能会越来越多，架构要能容纳新功能
我自己做B端产品的时候有一个习惯，就是在做信息架构的时候，不只想当前版本要做的功能，还会想一下未来半年到一年可能会加的功能，提前在架构里留好位置。
不然每次加新功能都要改导航，用户的使用习惯就被打乱了。

五. 常见问题和实战建议

最后，分享几个我在实际工作中遇到的高频问题。

问题一：功能太多，导航放不下怎么办？

首先反思一下，是不是信息架构的分组有问题。很多时候不是功能真的太多，而是分类太细了。
然后可以考虑这些方案：
  • 用"更多"或"全部功能"来收纳低频功能
  • 提供"常用功能"自定义，让用户自己配置快捷入口
  • 对于B端，可以根据角色权限，只显示该角色需要的导航

问题二：同一个功能好像放在两个分类下都合理？

这个太常见了。
比如"优惠券"，放在"我的"下面合理（我的优惠券），放在购物流程里也合理（下单时选择优惠券）。
我的做法是：主入口只放一个地方，但可以在其他相关场景提供快捷入口或引导。
比如优惠券的主入口放在"我的"下面，但在下单页面提供一个"选择优惠券"的入口，点进去也能看到所有优惠券。
这样既不会让导航结构混乱，又不影响用户在各场景下的使用。

问题三：信息架构要出什么交付物？

一般来说，两个东西就够了：
1. 站点地图（Site Map）
就是我前面说的树状层级结构图。用脑图工具或者draw.io画都行。
这个图要让所有人一看就知道产品的全貌——有哪些模块，每个模块下有什么，层级关系是什么。
2. 信息架构说明文档
对一些关键的设计决策做简要说明。比如：
  • 为什么"收藏"放在"我的"下面而不是"首页"里
  • 为什么把"权限管理"从"系统设置"里拆出来作为独立入口
  • 未来新增功能的扩展预案
这些说明不需要长篇大论，简单写几句就行，主要是让团队理解你的思路。

问题四：信息架构什么时候做？

越早越好。
最理想的节奏是：
  1. 需求分析阶段，确定有哪些功能
  1. 画原型之前，先做信息架构
  1. 信息架构评审通过后，再开始画原型
如果你是在做一个全新的产品（0-1），信息架构应该是你最先做的设计工作之一。
如果你是在现有产品上加功能，也建议先看看现有的信息架构，确认新功能放在哪个位置最合适，再动手画原型。

写在最后

信息架构这个东西，说实话，很多人做了好几年产品都没怎么重视过。
因为它不像原型那样直观，不像交互那样有趣，更不像视觉那样抓眼球。
但它就像一栋楼的地基，你看不到它，但它撑起了所有东西。
地基没打好，上面装修得再漂亮，住进去也会出各种问题。
所以，下次在打开工具画原型之前，先花点时间想想你的信息架构。
你会发现后面的工作，顺滑得多。