[!info] related notes

• 所属 MOC: ui-ux-moc
• 相关概念:
• 易混淆概念:
• 相关资源:

Product、UX、Interaction、UI 与 Frontend 的设计链路

核心结论

一个界面的质量，通常在选择颜色、圆角和阴影之前就已经决定了。

设计的真正顺序不是“先画一个好看的页面”，而是先确定用户为什么来到这里、需要完成什么，再组织信息、设计流程、定义状态与反馈，最后才进入布局和视觉表达。

[!abstract] 一句话压缩整个链路 Product — What problem? 解决什么问题？ UX — How should it work? 用户怎样才能顺利完成目标？ Interaction — How should it behave? 用户操作后，系统应该怎样变化和反馈？ UI — How should it look? 信息怎样被清晰、有效地视觉表达？ Design System — How do we make it consistent? 如何让整套产品保持一致且可扩展？ Frontend — How do we make it real? 如何把这些设计变成可靠、可访问、响应式的软件？ Usability — Does it actually work for users? 用户真的能理解并完成任务吗？

优秀 UI 的重要顺序

User Goal
   ↓
Information Architecture
   ↓
User Flow
   ↓
Interaction
   ↓
Content / Visual Hierarchy
   ↓
Layout
   ↓
Spacing
   ↓
Typography
   ↓
Color
   ↓
Decoration

这条顺序表达了一个非常重要的判断：

• 如果用户目标没有想清楚，再漂亮的界面也可能在解决错误的问题。
• 如果信息架构混乱，靠 Card、Border 和颜色无法真正补救。
• 如果 User Flow 很绕，换一套视觉主题不会让任务变简单。
• 如果状态和反馈没设计，页面截图很好看，真正操作时仍然会很差。
• 装饰应该是最后一层，而不是设计的起点。

从“页面设计”转成“任务设计”

前端开发中最容易出现的误区，是拿到一个功能后直接问：

• 这里放什么组件？
• 要不要套 Card？
• 圆角多大？
• 背景用什么颜色？

更成熟的顺序是先问：

1. 用户来到这里是为了完成什么？
2. 完成这个目标最重要的信息是什么？
3. 最重要的操作是什么？
4. 哪些信息只在特定情境才需要出现？
5. 哪些内容是重复解释、视觉噪音或设计者自己的“自言自语”？
6. 用户操作以后，系统会进入哪些状态？
7. 失败、空数据、不确定、等待和恢复应该怎样表现？
8. 最后才决定页面结构、组件和视觉风格。

因此，产品型前端真正设计的不是一张静态截图，而是：

用户目标 + 信息结构 + 行为路径 + 状态变化 + 反馈机制 + 视觉表达。

什么应该保留，什么应该删除

设计中的“删除”不是单纯追求极简，而是在保护用户注意力。

一个元素值得长期存在，通常至少满足一个条件：

• 帮助用户理解当前最重要的信息。
• 帮助用户完成当前任务。
• 表达系统当前状态。
• 防止用户犯高成本错误。
• 提供必要的安全、权限、风险或恢复信息。

其他内容可以进一步判断：

• 高频但次要：弱化视觉层级。
• 偶尔需要：折叠、Popover、Drawer 或详情页。
• 只在某个状态需要：只在那个状态出现。
• 首次使用才需要：放进 onboarding 或 empty state。
• 与其他文字重复：删除。
• 仅为了“看起来丰富”：优先删除。

[!tip] Less UI 的真正含义 不要先问“这个 Card 怎么做漂亮”，先问“这个 Card 是否必须存在”；再问“这个 Section 是否必须存在”；最后问“这段信息是否必须一直显示”。

BodySense：从功能名回到用户目标

假设正在设计 BodySense 的“身体状态地图”。

如果从组件出发，很容易得到：

标题
说明文字
当前状态
人体 SVG
人物卡片
右侧详情卡片
边框
背景层
更多解释文字

但真正的用户目标可能只是：

快速看出哪些身体区域已经有值得关注的记录，并进入对应信息继续理解或行动。

于是设计可以重新推导：

用户目标
  ↓
快速定位已有身体记录
  ↓
人体 SVG 成为主要信息载体
  ↓
有记录的区域直接标记
  ↓
点击区域才出现上下文详情
  ↓
无数据时才出现简短 Empty State
  ↓
有数据以后，解释性空态文案消失

这时，“身体状态地图”“用身体区域快速定位当前记录”“当前状态”“这些信息来自……”等文字是否保留，不应该由“页面是不是有点空”决定，而要看它们是否真的帮助用户完成当前任务。

静态页面不是设计终点

真实产品必须继续考虑：

没有数据怎么办？
数据正在加载怎么办？
只有部分数据怎么办？
AI 正在更新某个区域怎么办？
用户点错身体区域怎么办？
系统判断不确定怎么办？
请求失败怎么办？
用户能不能撤销或纠正？

因此真正的界面设计对象应当是一个状态系统，而不是单张 Figma 截图。

实战中的最短工作法

面对一个新功能，在写 JSX / CSS 之前至少写下：

User Goal:
用户为什么来到这里？

Primary Information:
最重要的信息是什么？

Primary Action:
最重要的动作是什么？

Information Architecture:
信息怎么分组，什么常驻，什么按需出现？

User Flow:
用户从进入到完成目标经过哪些步骤？

States:
idle / loading / empty / populated / error / partial / disabled ...

Interaction:
每次关键操作后系统如何反馈？

Recovery:
失败、误操作、不确定时如何恢复？

Visual Hierarchy:
第一眼、第二眼、第三眼分别应该看到什么？

Validation:
如何确认真实用户能完成任务？

只要这十项还没有想清楚，就不应该急着进入装饰层。

与前端工程的关系

前端工程师并不一定要成为品牌设计师或插画师，但非常值得掌握这一整条链路，因为最终只有前端真正面对：

• 动态状态；
• 异步请求；
• 错误与恢复；
• 响应式布局；
• 键盘与可访问性；
• Agent 流式执行；
• 工具调用和审批；
• 用户实际点击后的所有边界情况。

因此，强前端的能力不只是“把 Figma 写成 React”，而是能够判断：

这个功能应该怎样工作、什么应该删、什么应该保留、状态如何流转、Agent 怎样和人协作，以及最终如何用代码把这些约束可靠地实现出来。

继续拆解

• 面向前端工程师的 UX 设计：从用户目标、认知负担和可用性出发设计体验。
• 信息架构（Information Architecture）：决定信息如何组织和导航。
• User Flow（用户流程）：把用户目标展开成操作与系统状态路径。
• 交互设计（Interaction Design）：定义操作之后系统怎样反馈和恢复。
• Design System：从 Token 到产品界面：把一致性变成系统能力。
• AI / Agent UX 设计：处理不确定性、工具调用、人机协作与长任务。
• BodySense UI/UX 设计实战方法：把以上方法用于 BodySense 功能设计。