页面需求怎么写

在前面的章节中，我们聊了产品需求文档的整体框架、用户故事、信息架构等内容。到了具体落地的时候，设计师和开发者最常翻看的，其实是「页面需求」这一部分。它不像是愿景层面的东西，而是非常具体的——这个页面长什么样、有哪些元素、用户怎么操作、操作之后会怎样。写得好，设计师可以直接出图，开发者可以估算工时；写得差，就会出现「我以为你要的是这个」的反复沟通。

页面需求之所以重要，是因为它是 PRD 中最接近「执行」的部分。用户故事回答了「为什么要做」，页面需求回答了「具体做成什么样」。对于出海产品来说，页面需求还需要考虑多语言适配、不同市场的用户习惯差异，这些内容我们也会在后面提到。

本章会详细讲解页面需求包含哪些内容、怎么写、用什么工具、以及常见的坑。

页面需求到底包含什么

一份完整的页面需求通常包含四个部分：页面列表、页面结构描述、交互说明和状态说明。这四部分对应了设计师和开发者最关心的四个问题：要做哪些页面、页面里有什么、用户怎么操作、各种情况下怎么表现。

页面列表

页面列表是整个页面需求的索引。它需要回答：这个功能涉及哪些页面，页面之间的层级关系是什么。

页面列表不需要写得特别复杂，一张表格就够用：

页面列表的价值在于「不遗漏」。当你把所有页面列出来之后，哪些页面需要做、哪些可以推迟、哪些可以复用已有页面，就一目了然了。

页面结构描述

页面结构描述是页面需求的核心部分。它描述每个页面内部的内容组织方式，包括区块划分、内容元素和布局说明。这部分内容我们后面会详细展开。

交互说明

交互说明描述用户在页面上的操作行为以及系统的响应。比如点击按钮后发生什么、表单提交后跳转到哪里、输入错误时怎么提示。好的交互说明可以让开发者不用猜「这种情况该怎么处理」。

状态说明

状态说明覆盖页面可能出现的各种情况。一个页面不只有「正常显示」这一种状态——数据为空的时候怎么显示、加载中怎么显示、出错了怎么显示、权限不足怎么显示，这些都需要在需求中写清楚。

怎么描述页面结构

页面结构描述需要回答三个问题：页面分成几个区块、每个区块里有什么内容元素、这些元素怎么排列。

区块划分

每个页面都可以拆分成若干区块（Section）。区块是页面结构的一级划分，通常对应视觉上的独立区域。

以一个典型的「脚本列表页」为例，可以拆成以下区块：

• 顶部导航栏：包含 Logo、导航菜单、用户头像
• 筛选工具栏：包含搜索框、状态筛选下拉菜单、排序方式选择
• 列表主体：展示脚本卡片列表，每张卡片包含脚本标题、摘要、状态标签、创建时间、操作按钮
• 分页器：位于列表底部
• 空状态提示：当没有数据时替代列表主体显示

内容元素

每个区块内部由具体的内容元素组成。描述内容元素时，需要说明元素的类型和必要属性。

以「脚本卡片」为例：

布局说明

布局说明描述元素之间的排列方式。不需要写得像 CSS 代码一样精确，但需要让设计师和开发者理解你的意图。

常见的布局描述方式：

• 水平排列：「搜索框和筛选按钮在同一行，搜索框占主要宽度」
• 垂直排列：「卡片列表纵向排列，卡片之间间距 16px」
• 网格布局：「卡片以网格形式排列，每行最多 3 张，响应式适配」
• 层级关系：「状态标签显示在卡片右上角，作为角标」

对于出海产品，布局说明中还需要注意：多语言文本长度差异较大，德语、俄语等语言的文本长度可能是英语的 1.5-2 倍。布局设计需要预留足够的弹性空间，避免文本截断或溢出。

怎么描述交互

交互说明是页面需求中容易被忽视、但极其重要的部分。写交互说明的基本原则是：每个可操作的元素，都要说明「操作方式」和「操作结果」。

交互说明的基本格式

一条完整的交互说明应该包含：触发条件、操作方式、系统响应、反馈形式。

常见交互类型

在实际写需求时，交互大致可以分为以下几类：

导航跳转：点击某个元素后跳转到另一个页面或锚点。需要说明跳转方式（当前页跳转还是新标签页打开）、跳转目标、是否携带参数。

表单操作：输入、选择、提交等。需要说明校验规则、提交后的行为、失败时的处理。

数据操作：增删改查。需要说明操作的确认机制、成功和失败的反馈、对列表或关联数据的影响。

反馈提示：Toast、对话框、内联错误提示、 loading 状态。需要说明触发时机、显示位置、持续时间、消失方式。

交互描述要避免的问题

不要只写「点击后跳转」——跳转到哪里？带什么参数？新标签页还是当前页？

不要忽略异常流程——网络超时怎么办？接口返回错误怎么办？用户快速重复点击怎么办？

不要假设「大家都知道」——你觉得很明显的交互，开发者可能理解不同。写清楚比不写要好，多写比少写要好。

线框图 / Wireframe 的作用和基本画法

线框图（Wireframe）是页面需求的可视化补充。它不需要好看，只需要清晰地展示页面结构和元素布局。在产品设计流程中，Wireframe 介于信息架构和视觉设计之间，起到「把抽象需求变成具象布局」的桥梁作用。

Wireframe 的价值

对齐理解：文字描述容易被不同人理解成不同样子。一张简单的线框图可以让所有人看到同一个东西，减少沟通偏差。

快速验证：Wireframe 的绘制成本很低，可以在几分钟内画出多个方案进行对比。不需要等到设计师出高保真图才发现问题。

辅助开发估算：开发者看到线框图后，可以更准确地评估前端工作量。哪些是标准组件、哪些需要定制开发，一眼就能看出来。

作为需求附件：在 PRD 中附上 Wireframe，比纯文字描述更有说服力。即使后续设计稿有调整，Wireframe 仍然是理解需求意图的重要参考。

Wireframe 的基本画法

Wireframe 不需要任何设计功底。它的核心原则是：只关注结构和布局，不关注视觉细节。

绘制 Wireframe 时的基本约定：

• 矩形框表示区块或内容容器
• 横线表示文本内容（单行横线代表一行文字）
• 十字叉框表示图片占位
• 实心矩形表示按钮
• 箭头表示跳转或交互方向

常用的 Wireframe 工具：

Wireframe 和 Mockup 的区别

这里需要区分两个容易混淆的概念。Wireframe 是低保真的结构示意，关注「放什么、放哪里」；Mockup 是高保真的视觉设计稿，关注「长什么样、什么颜色、什么字体」。在页面需求阶段，我们只需要 Wireframe 级别的图示。视觉设计是后续设计阶段的工作。

状态说明：不要只写「正常情况」

很多页面需求只描述了「数据正常加载完成」时的页面样子，然后开发者在实际开发中遇到了一堆没考虑到的情况。状态说明的目的，就是把页面可能出现的各种情况都列出来。

常见的页面状态

一个页面通常需要覆盖以下状态：

状态说明的写法

状态说明可以以清单形式列出，每个状态描述三要素：触发条件、页面表现、用户下一步操作。

以「脚本列表页」为例：

页面需求的完整模板

以下是一个可以直接使用的页面需求模板。每个页面的需求文档可以按照这个结构来写：

# [页面名称] 页面需求
 
## 基本信息
- 页面路径：/xxx
- 所属模块：xxx
- 优先级：P0 / P1 / P2
 
## 页面目标
> 一句话说明这个页面要帮用户完成什么
 
## 页面列表（如果是模块级别）
| 序号 | 页面名称 | 路径 | 说明 |
|------|----------|------|------|
 
## 页面结构
 
### 区块 1：[区块名称]
- 布局：[水平/垂直/网格]
- 内容元素：
  | 元素 | 类型 | 说明 |
  |------|------|------|
  |      |      |      |
 
### 区块 2：[区块名称]
...
 
## 交互说明
| 触发条件 | 操作方式 | 系统响应 | 反馈形式 |
|----------|----------|----------|----------|
|          |          |          |          |
 
## 状态说明
| 状态 | 触发条件 | 页面表现 | 用户下一步 |
|------|----------|----------|------------|
| 加载中 |        |          |            |
| 空数据 |        |          |            |
| 正常   |        |          |            |
| 错误   |        |          |            |
 
## 线框图
> 附图或链接
 
## 多语言 / 国际化备注
> 出海产品需要额外考虑的内容

好页面需求 vs 差页面需求

交互说明格式对比

不同团队对交互说明的粒度要求不同。以下是三种常见的格式，从简到繁：

对于出海产品的早期团队，建议使用「标准版」，在关键流程（支付、注册、数据删除）上使用「详细版」。

案例分析

案例一：AI 脚本生成工具的「生成结果页」

这个页面展示 AI 生成的脚本内容，用户可以在页面上查看、编辑、重新生成。

页面结构：

区块划分：

1. 顶部操作栏：返回按钮、脚本标题（可编辑）、保存状态指示、操作按钮组（重新生成、导出、发布）
2. 脚本内容区：富文本展示区，支持行内编辑
3. 侧边面板：AI 建议、角色列表、场景时间线（可折叠）

交互说明（关键交互）：

状态说明：

线框图（文字示意）：

┌──────────────────────────────────────────────────┐
│ [←返回]  脚本标题(可编辑)  ●已保存  [重新生成] [导出] [发布] │
├─────────────────────────────┬────────────────────┤
│                             │ AI 建议            │
│ 脚本内容区                  │ ┌──────────────┐   │
│ （富文本，支持行内编辑）     │ │ 角色列表      │   │
│                             │ │ · 角色A       │   │
│                             │ │ · 角色B       │   │
│                             │ ├──────────────┤   │
│                             │ │ 场景时间线    │   │
│                             │ └──────────────┘   │
└─────────────────────────────┴────────────────────┘

这个案例的关键点在于：自动保存的防抖处理、生成中的实时反馈、以及侧边面板和内容区的联动交互。这些都是只靠文字描述容易产生歧义的地方，配合线框图就清晰很多。

案例二：出海 SaaS 产品的「定价页」

定价页（Pricing Page）是出海产品中最常见的公开页面之一，也是转化漏斗中的关键节点。

页面结构：

区块划分：

1. 页头：标题、副标题、计费周期切换（月付/年付）
2. 套餐卡片区：3-4 列并排的套餐卡片，每张卡片包含套餐名称、价格、功能列表、CTA 按钮
3. 功能对比表：详细的功能对比矩阵
4. FAQ 区：常见问题折叠面板
5. 底部 CTA：引导联系销售或开始试用

交互说明（关键交互）：

状态说明：

国际化备注：

• 价格需要支持多币种显示（USD、EUR、GBP、JPY 等）
• 功能对比表的表头在移动端需要特殊处理（横向滚动或折叠）
• 不同语言的价格文案格式不同（如 ¥1,000 vs $1,000 vs 1.000 €）

写页面需求的流程图

以下是编写页面需求的推荐流程：

这个流程的核心思路是：先整体后局部，先结构后细节。先列出页面清单建立全局视角，再逐个页面深入描述。线框图放在结构描述之前，是因为图形化的沟通效率更高，先对齐布局再补充细节可以节省大量返工。

页面需求检查清单

在完成一份页面需求文档后，可以用以下清单逐项检查：

• 是否列出了所有相关页面，没有遗漏
• 每个页面是否有一句话的目标说明
• 页面结构是否拆分为清晰的区块
• 每个区块的内容元素是否列出了类型和说明
• 布局方式是否有明确描述（水平、垂直、网格、响应式规则）
• 每个可交互元素是否都有交互说明
• 交互说明是否包含触发条件、操作方式、系统响应、反馈形式
• 是否覆盖了异常流程（网络错误、接口失败、校验不通过）
• 状态说明是否覆盖了加载中、空数据、错误、无权限等常见状态
• 是否附有线框图或结构草图
• 多语言/国际化相关的文本是否已标注
• 不同语言文本长度差异是否已考虑（布局弹性）
• 页面路径和跳转关系是否清晰
• 是否标注了优先级（P0/P1/P2）
• 是否与设计师和开发者做过评审

本章小结

页面需求是 PRD 中最接近执行的部分。它需要回答四个核心问题：要做哪些页面、页面里有什么、用户怎么操作、各种情况下怎么表现。

写好页面需求的关键在于：

1. 结构化描述——用区块划分、元素列表、布局说明来组织页面结构
2. 交互要写完整——每个交互都要包含触发条件、系统响应和反馈形式
3. 状态要写全面——不要只写正常情况，异常状态才是容易出 bug 的地方
4. 用线框图辅助——一张简单的草图胜过千言万语
5. 考虑国际化——出海产品的页面需求必须考虑多语言和地区差异

下一章我们会继续讲解原型设计和视觉设计阶段的需求文档写法。

参考资料

• How to Write a PRD in 7 Simple Steps — Notion
• What is a Product Requirements Document? — Atlassian
• How to Write a PRD That Actually Helps You Build Products — Reforge
• What is Wireframing? The Complete Guide — Figma
• What is a wireframe? A guide for non-designers — Balsamiq
• A Practical Guide to UX Specifications — Chris Kiess
• Design Specifications Template — UX Collective
• Documenting Functional Requirements with Wireframes — PowerMockup