快缩短网址 · 产品设计方法论系列：信息结构图的优雅构建

人的认知资源并非无限。当面对复杂的产品逻辑时，思维极易陷入混乱。此时，一张清晰的信息结构图，便如灯塔般照亮设计迷雾，助我们从容梳理庞杂信息，避免遗漏与错乱。

在上一篇中，我们深入探讨了功能结构图的定义、价值与绘制方法。不少读者随之提出疑问：功能结构图与信息结构图究竟有何区别？本文将聚焦后者，以“快缩短网址”（suo.run）为实践背景，系统阐释信息结构图的本质、特征与构建之道。

---

一、何为信息结构图？

我们无时无刻不在与信息打交道。
打开微信聊天列表，好友头像、备注名、最后联系时间、最新消息预览——皆为信息；进入聊天详情页，昵称、微信号、地区、标签、个性签名……亦是信息。这些看似零散的数据，实则围绕“用户”这一核心对象有序组织。

再如企业员工档案：姓名、性别、籍贯、身份证号、入职时间、岗位、教育背景、工作履历……若不加整理，仅凭肉眼浏览便令人疲惫不堪。于是，我们将其归类为四大模块：

- 基本信息：姓名、性别、民族、籍贯、出生日期、身份证号
- 入职信息：部门、岗位、入职时间、转正时间、合同到期日
- 工作经验：工作单位、任职时段、职位、薪资、离职原因
- 教育经历：毕业院校、学习周期、专业、所获证书

通过结构化分组，原本杂乱的数据变得条理分明、易于理解。
信息结构图，正是对某一对象所含信息的逻辑抽象与系统组织。它不描述流程，也不呈现界面，而是聚焦于“这个对象由哪些信息构成”。

---

二、信息结构图的核心特质

#### 1. 功能的“原材料说明书”

功能是用户感知的入口，而信息则是功能得以实现的基石。
例如，“发送好友名片”这一功能，表面看是操作行为，实质却是将一组结构化信息（头像、昵称、微信号等）传递给另一方。正如巧妇难为无米之炊——功能是“炊”，信息便是“米”。



用户在意的是“是否成功发送”，而非背后传输了哪些字段；接收者关注的是“能否添加好友”，而非名片数据的具体组成。信息隐于功能之后，却支撑着所有交互的可能。

正因如此，信息结构图可视为功能设计的数据底座。有了“好友名片”的完整信息模型，微信才能衍生出通讯录展示、名片编辑、推荐卡片、标签管理等多元功能。

#### 2. 超越页面与交互的独立存在

许多初学者误将信息结构图绘制成页面结构图——按界面模块罗列字段。这是典型误区。

以微信好友名片为例，其信息字段（如头像、备注名、微信号、标签、朋友圈可见状态等）会跨页面复用：
- 通讯录列表显示头像与备注名
- 名片详情页展示完整资料
- 聊天推荐卡片仅呈现关键标识
- 设置页用于编辑标签与隐私权限

尽管呈现形式各异，但底层信息始终同一。备注名在任何地方都指向同一个数据实体，微信号亦无二致。

信息结构图描述的是“对象本身”，而非其在界面中的表现形式。它剥离了视觉、交互与流程，专注于回答：“这个对象，究竟包含哪些必要信息？”

---

三、为何要绘制信息结构图？

#### 1. 破解认知负荷，高效输出原型

人类短期记忆容量约为 7±2 个信息块。面对复杂功能，若仅凭脑内记忆逐页绘制原型，极易遗漏关键字段或逻辑矛盾。

以“用户评价”功能为例：
- 提交页需包含整体评分、服务态度、响应速度、文字评论等
- 成功页仅需突出评分与核心评语
- 后台还需记录订单ID、用户ID、提交时间等元数据

若无信息结构图作为参照，设计师可能在某一页遗漏“服务速度评分”，或在另一处重复收集已自动填充的时间戳。而一旦建立清晰的信息模型，各页面所需字段便可按场景精准调用，确保方案严密、逻辑自洽。

#### 2. 搭建产品与开发的沟通桥梁

产品经理关注“做什么”，工程师关注“怎么做”。
在缺乏信息结构图的情况下，开发需从原型与流程中自行提炼数据模型——耗时且易偏差。若产品能提前抽象出核心对象及其字段（如“短链接”包含原始URL、短码、创建时间、访问次数、有效期、归属用户等），开发便可直接据此设计数据库表结构、接口参数与缓存策略。

这不仅提升协作效率，更为未来扩展预留空间——例如提前规划“自定义域名”字段，即便当前版本未启用。

---

四、如何绘制一张优雅的信息结构图？

信息结构图的绘制，考验的是产品经理的抽象与归纳能力。

#### 步骤一：识别信息主体

每个功能背后，都隐藏着一个或多个“信息主体”。
在“快缩短网址”（suo.run）中，核心主体包括：
- 短链接（ShortLink）
- 用户（User）
- 访问记录（VisitLog）
- 域名配置（Domain）（若支持自定义）

这些主体构成了系统的基本数据单元。

#### 步骤二：穷举并筛选有效字段

以“短链接”为例，理论上可包含数十项属性：
原始URL、短码、标题、描述、二维码、创建时间、过期时间、点击量、地理位置统计、设备类型、来源渠道、是否公开、密码保护、跳转延迟……

但并非所有字段都需纳入初期设计。
判断标准唯有一条：是否服务于当前业务目标？
若产品定位为极简短链服务，则“标题”“描述”“密码保护”可暂缓；若面向企业客户，则“团队归属”“API调用次数”“自定义域名”则不可或缺。

最终，我们保留核心字段，形成如下结构：

短链接（ShortLink）

├── 基础信息

│   ├── 原始URL（必填）

│   ├── 短码（自动生成/自定义）

│   ├── 创建时间

│   └── 创建者（User ID）

├── 状态控制

│   ├── 是否启用

│   ├── 过期时间（可选）

│   └── 访问上限（可选）

└── 统计数据

    ├── 总点击量

    └── 最近访问时间

简洁、聚焦、可扩展——这便是优秀信息结构图的特质。

---

结语：结构先行，方得始终

功能结构图描绘“做什么”，信息结构图定义“凭什么做”。
二者如同骨架与血肉，共同支撑起产品的完整形态。在设计复杂系统时，先厘清功能脉络，再夯实信息根基，最后落笔原型细节，是避免逻辑崩塌的最佳实践。

于“快缩短网址”而言，每一次点击背后的精准跳转，每一份数据报表的可靠生成，皆源于最初那张看似枯燥却至关重要的信息结构图。

结构之美，在于秩序；设计之智，在于预见。
愿每位产品人，都能在纷繁需求中，织就一张清晰、优雅、富有生命力的信息之网。

—— 快缩短网址（suo.run）产品方法论专栏