从 Page Design 到 System Design：我对 UI/UX 的一次认知变化

前言

做 UI 的前几年，我对"设计一个产品"的理解其实很简单。

拿到需求之后，先梳理页面，然后画原型、做视觉稿、补交互，最后整理成一套完整的页面交付给开发。

首页、列表页、详情页、登录页、个人中心......

一个个页面做完，我会自然地认为：

这个产品差不多设计完了。

但后来当我开始真正参与前端开发、WordPress 商城、后台系统和一些完整业务功能之后，我越来越发现一个问题：

页面设计完成，不代表产品设计完成。

甚至很多时候，页面只是整个产品系统里最表层的一部分。

我现在更倾向于把设计工作的单位，从 Page，逐渐切换成 System。

一、Page Design 的问题：我们天然会把产品理解成"一组页面"

这是一个很容易形成的思维惯性。

因为设计工具本身就是以 Frame 为单位工作的。

打开 Figma，我们看到的通常是：

复制代码

首页
商品列表
商品详情
购物车
结算页
订单页
个人中心

于是产品很容易在脑子里变成：

复制代码

Product = Page A + Page B + Page C + Page D

设计流程也会自然变成：

复制代码

需求
↓
页面结构
↓
页面布局
↓
视觉
↓
交付开发

这种方法当然没有错。

对于官网、活动页、内容展示型项目来说，它甚至非常高效。

但一旦进入真正的业务产品，问题就开始出现了。

因为用户实际使用的并不是"页面"。

用户使用的是：

状态
数据
权限
规则
流程
操作反馈
异常处理

页面只是这些东西最终呈现出来的一个 View。

二、一个"订单页面"，实际上并不是一个页面

以前设计订单详情的时候，我可能会先画一个标准页面：

复制代码

订单号
商品信息
价格
收货地址
订单状态
操作按钮

看起来逻辑已经很完整。

但真正进入实现阶段之后，会发现一个订单并不存在一个固定页面。

它首先存在的是状态：

复制代码

待付款
已付款
处理中
已发货
已完成
已取消
退款中
已退款

不同状态下，页面内容会发生变化。

例如待付款：

复制代码

[立即付款]
[取消订单]

已发货：

复制代码

[查看物流]
[确认收货]

已完成：

复制代码

[再次购买]
[评价商品]

退款中：

复制代码

[查看退款进度]

于是原本脑子里的：

复制代码

Order Detail Page

实际上开始变成：

复制代码

Order System
    ↓
Order Status
    ↓
Business Rules
    ↓
Available Actions
    ↓
UI

这里有一个很重要的变化：

UI 不再是业务逻辑的起点，而是业务逻辑计算之后的结果。

三、页面只是系统状态的一个"截图"

这是我现在理解 UI 的一个方式。

假设一个上传功能。

设计稿可能只有这样一个界面：

复制代码

上传文件
[选择文件]

但真正的功能至少存在：

复制代码

未选择文件
已选择文件
上传中
上传成功
上传失败
文件格式错误
文件过大
网络中断
重新上传
取消上传

甚至还可能包括：

复制代码

上传 20%
上传 70%
服务器处理中

如果只设计"上传页面"，很容易只画最正常的一种情况。

但如果设计的是"上传系统"，思考方式就会变成：

复制代码

这个功能有哪些状态？
↓

状态之间如何切换？
↓

什么事件导致状态变化？
↓

每个状态允许用户做什么？
↓

不同状态下应该显示什么？

这时候 UI 就自然产生了。

而不是先画一个页面，再不断往里面补东西。

四、真正让我改变思路的是"状态"

我现在越来越觉得，很多 UI/UX 问题本质上其实是状态设计问题。

例如一个按钮。

设计师看到：

复制代码

Button

但真实产品里的 Button 可能是：

复制代码

Default
Hover
Pressed
Disabled
Loading
Success
Error

再比如登录。

如果把登录理解成 Page：

复制代码

手机号
密码
登录按钮

设计很快就结束了。

但如果把它理解成 System：

复制代码

未登录
↓
输入账号
↓
输入密码
↓
提交
↓
验证中
↓
成功 / 失败

失败还可能继续分：

复制代码

密码错误
账号不存在
账号被冻结
验证码错误
网络异常
服务器异常

这时候才会发现：

真正复杂的从来不是登录页面，而是登录流程。

五、从页面设计转向系统设计后，我开始先问不同的问题

以前拿到一个需求，我最先想的是：

这个页面应该怎么布局？

现在我会先问：

1. 这里真正存在的对象是什么？

例如商城：

复制代码

Product
Category
User
Cart
Order
Payment
Address

而不是：

复制代码

首页
商城页
详情页
购物车页

2. 对象有哪些状态？

例如 Product：

复制代码

在售
缺货
预售
下架
隐藏

Order：

复制代码

Pending
Paid
Processing
Shipped
Completed
Cancelled
Refunded

3. 状态如何发生变化？

例如：

复制代码

Pending
  ↓ 支付成功
Paid
  ↓ 商家处理
Processing
  ↓ 发货
Shipped
  ↓ 用户确认
Completed

4. 谁可以执行什么操作？

例如后台订单：

复制代码

管理员
客服
仓库
用户

可能拥有完全不同的操作权限。

5. 数据异常的时候怎么办？

比如：

复制代码

没有数据怎么办？
请求失败怎么办？
部分数据加载失败怎么办？
权限不足怎么办？
用户重复操作怎么办？
网络断开怎么办？

这些东西最终都会变成 UI。

六、System Design 并不是"画更多页面"

这里很容易产生一个误区。

从 Page Design 转向 System Design，并不是要求设计师把所有状态都画成几十张 Figma 页面。

那只是增加设计稿数量，并没有真正改变思维。

真正的区别在于设计顺序。

Page Design 更像：

复制代码

先画页面
↓
再补交互
↓
发现问题
↓
再补状态

System Design 更像：

复制代码

先理解业务对象
↓
梳理规则
↓
梳理状态
↓
梳理状态变化
↓
定义用户操作
↓
最后映射成 UI

一个是：

从界面进入系统。

另一个是：

从系统推导界面。

这是两个完全不同的方向。

七、这也改变了我对"设计系统"的理解

以前提到 Design System，我首先想到的是：

复制代码

Color
Typography
Grid
Button
Input
Modal
Card

这些当然是设计系统的一部分。

但它们主要解决的是：

UI 如何保持一致。

真正做业务之后，我发现还有另一层东西：

复制代码

商品如何展示
订单状态如何表达
权限如何反馈
错误如何反馈
价格如何展示
数据为空如何处理
危险操作如何确认

这些规则并不一定存在于传统 UI Kit 里。

但它们对产品一致性的影响可能更大。

所以现在我会把系统理解成两层：

复制代码

Visual System
+
Product Behavior System

视觉系统解决：

复制代码

长什么样

行为系统解决：

复制代码

怎么运行

一个成熟产品真正需要的是两者同时稳定。

八、为什么设计师理解一点开发后，很容易出现这种变化

我以前也见过一种观点：

UI/UX 设计师应该学代码。

但我现在觉得，"会不会写代码"其实不是最重要的。

真正有价值的是，开发过程会迫使你面对设计稿里可以被隐藏的问题。

比如一个筛选器。

设计稿里可能只是：

复制代码

品牌
价格
分类
颜色

但真正开发时必须回答：

复制代码

数据从哪里来？
多个条件能不能同时选择？
条件之间是什么关系？
刷新页面后状态是否保留？
URL 是否需要同步？
筛选结果为空怎么办？
分页之后怎么办？
接口失败怎么办？
移动端怎么显示？

代码不能接受"差不多"。

系统必须有确定的规则。

这也是我觉得设计和开发思维最大的区别之一：

设计工具允许模糊，运行中的系统不允许模糊。

只要真正参与几次实现，这种思维会自然反过来影响设计。

九、我现在更愿意把一个产品拆成"系统"，而不是页面

比如一个电商网站。

以前我可能会拆：

复制代码

首页
商城
商品详情
购物车
结算
订单
个人中心

现在我更喜欢拆成：

复制代码

Navigation System
Product System
Search & Filter System
Cart System
Checkout System
Payment System
Order System
Account System

然后每个 System 再继续拆：

复制代码

对象
状态
规则
操作
异常
界面

最后这些系统才组合成用户真正看到的页面。

页面依然重要。

但 Page 已经不再是最基础的设计单位。

十、从 Page 到 System，本质上是一次视角变化

现在回头看，我觉得很多所谓的"UI 做得不够深入"，其实并不是视觉能力的问题。

而是设计对象理解错了。

如果设计对象是：

一个页面

那么工作自然集中在：

排版
信息层级
视觉样式
页面交互

但如果设计对象变成：

一个可以持续运行的产品系统

那么你就不得不开始考虑：

数据
状态
业务规则
用户权限
异常
流程
前后端约束
内容结构
可维护性

视觉没有变得不重要。

恰恰相反。

只有先理解系统，视觉设计才能准确表达这个系统。

最后

我现在依然会设计 Page。

Figma 里的工作方式也没有发生本质变化。

真正变化的是，在开始画页面之前，我会多做一步：

先试着把页面背后的系统想明白。

一个页面真正应该长什么样，很多时候并不是设计师凭感觉决定的。

它是由：

复制代码

业务规则
+
数据结构
+
用户状态
+
当前任务
+
系统能力

共同推导出来的结果。

所以相比以前，我现在越来越少问：

"这个页面应该怎么设计？"

而更愿意先问：

"这个系统到底是怎么运行的？"

可能这就是我目前从 Page Design 走向 System Design，最明显的一次认知变化。