信息架构与任务流：让用户不迷路的设计底层
信息架构这个词，听起来挺唬人的。说白了，就是帮用户回答三个问题：我在哪？这里有什么？我要怎么去？
我做了这么多年多屏项目，发现一个规律：凡是上线后被吐槽"找不到功能"的产品，十有八九是信息架构没想清楚。今天我们就来拆解这个环节的核心工具和方法。
卡片分类法：让用户帮你搭结构
很多设计师喜欢自己闷头画菜单。我个人习惯是——先做一轮卡片分类。
卡片分类分两种：
| 类型 | 做法 | 适用场景 |
|---|---|---|
| 开放式 | 用户自己分组、自己命名 | 新产品、全新领域 |
| 封闭式 | 给定分类名，用户往里放 | 改版、已有结构优化 |
具体操作步骤：
- 准备卡片——把核心功能点写成一张张卡片，每张一个功能名+简短描述
- 找5-8个用户——覆盖不同角色，别只找产品经理
- 让用户分类——线上用 OptimalSort，线下用便签纸
- 分析结果——用相似度矩阵看哪些卡片总被放在一起
我的经验：线下卡片分类效果往往比线上好。用户边贴边念叨"这个应该和支付放一起"，这些吐槽比数据更有价值。
信息架构图绘制：从散点到系统
卡片分类做完，你会得到一堆"用户觉得该放一起"的功能组。接下来就是画信息架构图。
我习惯用三层结构来组织：
- 一级导航：4-7个主入口，再多用户就记不住了
- 二级页面：每个一级下的子功能，控制在5-8个
- 三级详情：具体操作页、表单、详情页
举个例子，一个电商App的信息架构可能是这样：
首页
├── 推荐流
├── 搜索入口
└── 快捷入口（订单、收藏、购物车）
分类
├── 商品类目树
└── 品牌筛选
购物车
├── 商品列表
├── 数量编辑
└── 结算入口
我的
├── 个人资料
├── 订单中心
├── 收货地址
└── 设置
注意：信息架构图不是菜单树。它要体现页面间的关系——是父子关系？跳转关系？还是平级切换？我见过太多人把架构图画成简单的树形结构，结果开发时才发现页面间缺少连接路径。
下面这张SVG图展示了信息架构的核心逻辑：
核心任务流与分支任务流
信息架构解决了"页面怎么组织"，但用户真正关心的是"事情能不能办成"。这就需要梳理任务流。
我通常把任务流分成两类：
- 核心任务流：用户使用产品的主要目的，比如"下单购买""发布内容"
- 分支任务流：核心流程中的异常处理、辅助操作，比如"修改地址""取消订单"
举个例子，电商App的"下单"核心任务流：
浏览商品 → 加入购物车 → 确认订单 → 选择支付方式 → 支付 → 下单成功
分支任务流可能包括：
┌─ 修改商品数量
├─ 删除商品
├─ 使用优惠券
├─ 修改收货地址
├─ 支付失败重试
└─ 取消订单
一个常见的坑：很多设计师只画了"happy path"（顺利流程），忽略了分支流程。结果开发时才发现"用户支付失败怎么办""网络中断怎么处理"。我曾经在一个项目中，核心流程只占了30%的代码量，剩下70%都在处理分支和异常。
导航模式设计：三种主流方案
信息架构和任务流确定后，最后一步是选择导航模式。多屏场景下，我主要用这三种：
| 导航模式 | 特点 | 适用场景 | 注意事项 |
|---|---|---|---|
| 标签式 | 底部/顶部固定，切换快 | 核心功能平级，如微信底部4个Tab | 不超过5个标签，文字+图标 |
| 抽屉式 | 侧边滑出，内容集中 | 功能多但使用频率低，如设置、个人中心 | 避免嵌套太深，3层以内 |
| 列表式 | 纵向列表，可分组 | 设置页、分类页、内容列表 | 注意分组间距，避免视觉疲劳 |
实际项目中，我经常混合使用。比如：
- 底部标签式放4个核心入口
- 其中一个标签内用列表式展示子功能
- 个人中心用抽屉式收纳低频操作
我的建议：导航模式的选择要结合用户使用频率和功能重要性。高频且重要的放标签式，低频但必要的放抽屉式，结构化的内容用列表式。别为了设计感牺牲可用性。
多屏场景下的特殊考量
如果你做的是手机+手表+电视的多屏项目，信息架构还要考虑跨屏一致性：
- 核心功能在所有设备上保持相同的命名和位置
- 次要功能根据屏幕尺寸做取舍，但入口路径要一致
- 导航模式可以不同（手机用标签式，手表用列表式），但信息层级要对齐
举个例子，一个健身App：
- 手机端：底部标签式（首页、训练、记录、我的）
- 手表端：列表式（开始训练、查看记录、设置）
- 电视端：卡片式（推荐训练、我的计划、历史记录）
虽然导航模式不同，但用户知道"训练"功能在哪个层级、怎么找到。
避坑提醒：我曾经做过一个项目，手机端和手表端的信息架构完全独立设计。结果用户反馈"手表上找不到刚在手机上收藏的训练计划"。后来我们统一了数据模型和分类逻辑，才解决这个问题。所以，多屏项目的信息架构一定要先统一底层分类，再适配不同屏幕。
好了，信息架构和任务流这部分就聊到这儿。记住一句话：好的信息架构让用户感觉"理所当然"，差的信息架构让用户觉得"这产品真难用"。花时间把底层结构想清楚，后面的设计会顺畅很多。