前端项目怎么做，才能少返工

做前端，最容易看到的进展是页面：

• 导航搭好了；
• 列表出来了；
• 按钮也能点了。

但真正开始使用后，问题才会陆续冒出来：

• 用户不知道下一步该做什么；
• 从详情返回后，找不到刚才的位置；
• 提交失败后，得重新填写；
• 真实标题一长，整个布局就乱了。

这些问题往往在写代码之前就埋下了。

要减少返工，得先把页面背后的使用过程想清楚，再逐步确定结构、样式和实现。

一、先把一件事走通 #

接到需求后，可以先挑一件用户最常做的事，从头走一遍。

比如审批系统，用户打开页面是为了处理待办。那就要先看清楚：

1. 待办从哪里进入？
2. 哪些信息能帮助判断优先级？
3. 点进去之后需要读什么？
4. 材料不足时怎么办？
5. 处理完成以后回到哪里？

把这条路径画出来之后，很多页面设计问题就有了依据：

• 页面应该怎么拆；
• 信息应该放在哪里；
• 哪些操作应该突出；
• 侧边栏是否真的需要那么多入口；
• 详情是否值得单独开一个页面。

第一轮就用真实业务内容 #

第一轮最好用真实业务内容走通这条路径。

几条有代表性的数据，往往比几十条整齐的占位内容更有帮助。

尤其应该早点放进这些情况：

• 长标题；
• 缺失字段；
• 复杂备注；
• 异常状态；
• 内容长度差异明显的数据。

这些内容能够更早暴露页面真正要解决的问题。

先把一个真实任务完整走通，比先把很多页面“画出来”更重要。

二、排信息之前，先想用户会问什么 #

页面内容多的时候，可以按照用户的阅读过程来安排。

用户刚进入页面，通常会依次关心：

1. 我现在在看什么？
2. 当前是什么情况？
3. 重点在哪里？
4. 还有哪些细节？
5. 我现在能做什么？
6. 执行操作有什么条件或限制？

页面顺着这个过程展开，理解起来会省力很多。

以订单详情为例 #

订单详情中：

• 订单状态、商品和金额应该容易找到；
• 需要用户处理的事项，应放在显眼位置；
• 操作记录、物流明细等内容，可以继续往下查看；
• 如果退款限制会影响当前操作，就应该出现在操作附近。

页面布局不只是“把字段摆进去”，而是要配合用户判断和行动的顺序。

三、该折叠的信息可以折叠，但别把关键条件藏起来 #

折叠区域适合收纳低频查看的信息。

但有些内容必须直接露出来，比如：

• 价格；
• 权限；
• 有效期；
• 当前状态；
• 关键限制；
• 会影响操作结果的条件。

这些信息可能直接改变用户的决定。

如果把它们都放进“更多详情”，页面看起来确实更简洁，但理解成本被转移给了用户。

视觉上的简洁，不等于使用上的简单。

这一阶段先用简单线框就够了。

重点是先确定：

• 阅读顺序；
• 信息层级；
• 操作位置；
• 关键条件是否可见。

颜色、阴影、圆角和装饰，可以稍后处理。

四、用一组页面确定风格，而不是只看一个首页 #

开始做视觉时，最好同时看几个相邻场景，例如：

• 列表页；
• 详情页；
• 编辑页；
• 确认页；
• 完成结果页。

这样才能判断一套视觉风格是否真的适合整个工作过程。

不同页面需要不同的信息密度 #

首页上的大卡片可能很好看，但到了需要比较二十条记录的页面，就未必合适。

不同页面承担的任务不同：

它们可以共享：

• 字体；
• 颜色；
• 基础组件；
• 圆角；
• 间距规则。

但不必强行保持完全相同的信息密度。

五、设计稿里的每个内容，都要问一句“它从哪里来” #

设计稿里的内容也要经得起推敲。

每一个：

• 数字；
• 状态；
• 趋势；
• 筛选条件；
• 标签；
• 按钮；

都应该有明确来源或行为。

使用生成工具做设计稿时尤其要注意。

生成工具可能会顺手加入：

• 评分；
• 趋势图；
• 推荐标签；
• 筛选条件；
• 排名；
• 统计数字。

这些东西看起来很完整，但不一定属于真实需求。

落地前要逐项核对：

这个信息真的存在吗？数据从哪里来？用户真的需要吗？点击之后会发生什么？

否则，示意内容很容易在不知不觉中变成新的产品需求。

六、方向确定后，再统一基础视觉规则 #

当页面方向基本稳定后，就可以统一当前项目中反复出现的视觉规则。

例如：

字体
间距
颜色
圆角
边框
按钮尺寸
表单高度
标题层级
状态颜色

规则不需要一开始就非常完整。

先覆盖当前页面中已经重复出现的部分即可。

这样既能保持一致性，又不会因为过早建设一套庞大的设计系统，反而拖慢实际开发。

七、组件从实际重复里提取 #

公共组件做得好，后面的页面会越写越顺。

但项目刚开始就设计一个包罗万象的组件库，通常会花掉很多时间，最后实际页面还得反过来迁就组件。

更合适的方式是：

先完成有代表性的页面，再从真实重复中提取组件。

基础组件通常较早稳定 #

例如：

• 按钮；
• 输入框；
• 弹层；
• 状态提示；
• 标签；
• 分页；
• 空状态。

这些组件通常很快就会出现重复，可以较早统一。

业务组件要从用途出发 #

像这些业务结构：

• 商品摘要；
• 审批意见；
• 执行记录；
• 订单信息；
• 操作日志；

则应该结合真实使用方式来划分。

不要因为“长得像”就强行做成一个组件。

八、除了外观，行为也应该复用 #

组件复用不只是统一样式。

很多真正影响体验的东西，其实是行为约定，例如：

• 提交时按钮怎么显示；
• 是否禁止重复点击；
• 错误出现在哪里；
• 成功之后怎么反馈；
• 弹层关闭后焦点回到哪里；
• 表单校验在什么时候出现；
• 加载时页面是否还能操作。

这些规则统一之后，用户在不同页面之间的操作预期才会稳定。

页面本身主要负责：

• 组织数据；
• 组织流程；
• 组合组件。

组件边界清楚之后，后续修改一处业务时，也更容易判断影响会落在哪里。

九、把“出错之后的路”一起做出来 #

一个页面能够正确显示正常数据，只完成了部分工作。

开发时还要提前准备这些情况：

• 没有数据；
• 加载中；
• 加载失败；
• 提交失败；
• 内容过期；
• 权限不足；
• 部分成功；
• 重复提交；
• 请求超时。

空状态要告诉用户下一步 #

例如：

• 空列表：告诉用户如何开始；
• 筛选无结果：方便清除或调整条件；
• 没有权限：说明原因和可采取的下一步。

提交失败后，不要让用户重来 #

提交失败后：

• 已经填写的内容应尽量保留；
• 用户需要知道操作到底有没有成功；
• 系统应明确告诉他现在还能做什么。

相比：

“发生错误，请稍后再试。”

更有帮助的信息是：

“提交失败，已填写内容仍然保留。请检查网络后重新提交。”

错误提示真正需要回答的是三个问题：

1. 刚才发生了什么？
2. 我之前输入的东西还在吗？
3. 现在可以怎么继续？

十、部分成功也要成为正式状态 #

批量任务尤其容易出现部分成功。

例如一次处理 20 条记录：

• 15 条成功；
• 3 条失败；
• 2 条仍在处理中。

这时不能只显示一个模糊的：

“操作失败”

也不应该简单显示：

“操作成功”

应该明确列出：

• 已成功项；
• 待处理项；
• 失败项；
• 每个失败项的原因；
• 是否可以重新执行。

只有这样，用户才能继续完成工作，而不是重新猜测系统状态。

十一、异常状态需要前后端一起设计 #

有些体验问题，靠前端提示无法真正解决。

例如：

• 重复提交怎么处理；
• 一个任务当前到底是什么状态；
• 提交成功但前端没收到响应怎么办；
• 已经生成的结果能否再次查询；
• 长任务能否继续查看进度；
• 同一个操作是否具有幂等性。

这些问题都需要接口能力支持。

因此，可以在开发早期就准备一份状态清单：

- 初始状态
- 加载中
- 加载成功
- 空数据
- 加载失败
- 提交中
- 提交成功
- 提交失败
- 部分成功
- 内容过期
- 权限不足
- 重复操作

提前把这些状态列出来，通常比上线前到处补提示更省事。

十二、页面之间的往返，也属于功能的一部分 #

用户很少只使用一个孤立页面。

更多时候，他们会反复：

列表
  ↓
详情
  ↓
处理
  ↓
返回列表
  ↓
继续下一条

因此，页面之间的状态恢复非常重要。

该保留的内容应该保留，例如：

• 筛选条件；
• 分页位置；
• 滚动位置；
• 排序条件；
• 当前选中的对象；
• 标签页状态。

关闭详情后还能回到刚才那一条，看起来只是细节，但对于一天需要重复几十次操作的用户来说，影响非常直接。

返回之后还能接着工作，本身就是一种重要的产品能力。

十三、验收时，照着用户真正的方式用一遍 #

最后检查时，要从用户入口开始完整操作，而不能只确认每个页面是否都能打开。

例如完整走一次：

找到一条内容
    ↓
进入详情
    ↓
修改或提交
    ↓
查看结果
    ↓
返回
    ↓
继续处理下一条

然后主动制造一些不理想的情况：

• 慢请求；
• 错误输入；
• 连续点击；
• 页面刷新；
• 浏览器后退；
• 网络中断；
• 重复提交。

很多问题只有在连续操作时才会出现。

十四、视觉验收要换掉“完美数据” #

视觉检查时，不要一直使用整齐的示例内容。

应该主动放入：

• 很长的标题；
• 很长的段落；
• 空字段；
• 极短内容；
• 大量记录；
• 特殊字符；
• 大数字；
• 多行标签；
• 较窄窗口。

然后检查：

• 是否有内容溢出；
• 按钮是否被挤走；
• 信息层级是否失效；
• 重点是否被淹没；
• 表格是否还能阅读；
• 移动或窄屏状态是否合理。

真实数据通常不会像设计稿一样整齐。

越早面对真实数据，后面的返工越少。

十五、别忘了键盘和焦点 #

验收时还应该检查：

• 键盘能否到达主要操作；
• 当前焦点是否清楚可见；
• Tab 顺序是否合理；
• 弹窗打开后焦点是否进入弹窗；
• 弹窗关闭后焦点是否回到原来的位置；
• 表单错误是否能被快速定位。

这些内容对依赖键盘操作的用户尤其重要，同时也常常能暴露页面结构本身的问题。

十六、截图看布局，交互测试看行为 #

不同验证方式解决的问题不同。

截图适合确认 #

• 页面布局；
• 对齐关系；
• 间距；
• 字体；
• 视觉层级；
• 内容溢出。

交互测试适合确认 #

• 页面跳转；
• 表单提交；
• 状态恢复；
• 错误处理；
• 重复点击；
• 返回行为；
• 关键流程是否仍然可用。

关键流程有了稳定的检查方式以后，后续修改样式、组件或业务逻辑时，就更容易发现意外影响。

十七、用户说“不好用”时，要找到具体发生在哪一步 #

用户反馈回来后，尽量不要停留在抽象评价上。

“不好用”可能意味着：

• 入口难找；
• 信息不够；
• 信息太多；
• 操作步骤太多；
• 关键条件出现得太晚；
• 点击后没有明确反馈；
• 返回以后状态丢失；
• 错误后不知道怎么继续。

应该继续追到一个具体动作：

用户是在什么任务、哪一步、遇到了什么阻碍？

找到发生问题的那一步，改动才会有方向。

十八、项目结束时，要留下能够继续复用的东西 #

一个前端项目做完，除了交付页面，还应该留下一些后续可以继续使用的积累。

至少包括：

1. 清楚的任务流程 #

知道用户如何进入、操作、完成，以及异常情况下如何继续。

2. 统一的视觉规则 #

字体、颜色、间距、状态和常见模式已经形成基本约定。

3. 边界合理的组件 #

真正重复的结构和行为已经沉淀，而不是为了抽象而抽象。

4. 关键状态的验证记录 #

知道正常、空数据、错误、部分成功、返回恢复等场景是否已经检查。

结语 #

减少前端返工，不只是让代码写得更规范，也不是一开始就建立最完整的设计系统。

更重要的是，在开发过程中始终围绕真实使用过程推进：

先走通任务，再安排信息；先验证真实内容，再确定视觉；从实际重复中提取组件；把失败和返回路径一起设计；最后按照用户真正的操作方式验收。

这样做的结果，不只是页面更稳定。

随着项目推进，团队还会逐渐留下：

• 更清楚的任务流程；
• 更一致的视觉语言；
• 更可靠的组件边界；
• 更完整的异常状态；
• 更可重复的验收方式。

下一次增加功能时，就能更快进入真正需要解决的问题。

而用户，也不用每次都重新学习一次产品。