← [ BACK_TO_NOTES ]

面向前端工程师的 UX 设计

从用户目标、心智模型、认知负担、信息架构、流程、错误预防与可用性出发,整理前端工程师在真实功能开发中应如何做 UX 判断。

#synthesis #growing #design #frontend

[!info] related notes

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

面向前端工程师的 UX 设计

一句话理解 UX

UX(User Experience)关注的不是一个页面“长什么样”,而是:

用户为了完成一个目标,从进入产品到得到结果的整个过程是否清楚、顺畅、可控、可信,并且在出错时能够恢复。

对前端工程师而言,UX 最有价值的地方,是把“做页面”升级成“设计任务完成过程”。

UX 不是装饰层

一个页面可能视觉很好,但仍然有差的 UX:

  • 用户不知道从哪里开始;
  • 功能很多,却找不到真正需要的那个;
  • 点击以后没有反馈;
  • AI 一直在运行,但不知道运行到了哪里;
  • 失败以后只有一个 toast,没有恢复动作;
  • 页面解释很多,却没有告诉用户下一步应该做什么。

所以 UX 经常要比 UI 更早发生。

Problem
  ↓
User Goal
  ↓
Context / Mental Model
  ↓
Information Architecture
  ↓
User Flow
  ↓
Interaction & States
  ↓
UI
  ↓
Usability Validation

UX 在实战中到底要想哪些问题

1. User Goal:用户真正要完成什么

不要用功能名代替用户目标。

例如:

功能名:身体状态地图

这不是用户目标。

更接近用户目标的是:

我想快速知道最近哪些身体区域有值得关注的记录,并找到对应的信息。

开发前可以写:

User Goal:
用户想在几秒内理解当前最值得关注的身体区域,并能继续查看详情或回到对话补充信息。

自检问题

  • 用户为什么会打开这个功能?
  • 用户完成什么以后才会觉得“这次操作结束了”?
  • 这个功能是在帮助用户理解、选择、输入、比较,还是执行动作?
  • 当前页面有没有在服务另一个并不重要的目标?

2. Context:用户现在处于什么情境

同一个信息,在不同情境下优先级完全不同。

BodySense 中至少可能有:

  • 第一次进入,还没有身体记录;
  • 刚完成一轮咨询;
  • AI 正在流式分析;
  • 已经积累多次记录;
  • 用户只想回看某个区域;
  • 系统发现需要优先关注的安全信号。

UX 不能只设计“数据完整、接口成功、用户知道怎么用”的理想状态。

开发时可以补一句:

Primary Context:
用户刚结束或正在进行一次咨询,希望理解当前记录,而不是阅读一份产品说明书。

3. Mental Model:用户以为这个东西怎样工作

心智模型是用户根据现实经验形成的“我觉得它应该这样工作”。

例如身体地图上一个明显的区域标记,用户自然会期待:

  • 可以点击;
  • 点击后看到这个区域的相关记录;
  • 当前选中的区域会有明显反馈;
  • 再点击其他区域时详情会跟着切换。

如果视觉上像可点击元素,实际却不可操作,就违背心智模型。

实战要写什么

Expected Mental Model:
身体区域标记 = 可探索的入口;点击区域 = 聚焦并查看该区域的当前记录。

4. Information Architecture:信息怎么组织

UX 不等于“所有信息都展示出来”。

要区分:

  • Primary:当前任务必须看见;
  • Secondary:有帮助,但不是当前核心;
  • Contextual:只有特定选择或状态下才需要;
  • Utility:设置、历史、帮助等辅助能力。

BodySense 的身体地图中,人体 SVG 和有记录区域可能是 Primary;某一区域的详细时间线是 Contextual;方法说明、数据来源解释更适合按需查看,而不是一直占据主界面。

详细拆解见 信息架构(Information Architecture)。

5. User Flow:用户怎样走完任务

不要只设计页面,要设计路径。

例如:

进入身体地图
  ↓
看见有记录的区域
  ↓
选择左肩
  ↓
看到左肩相关观察
  ↓
发现信息不完整
  ↓
继续对话补充
  ↓
AI 更新记录
  ↓
返回地图看到状态变化

这里已经不仅是一个页面,而是多个操作和系统状态组成的任务过程。

详细拆解见 User Flow(用户流程)。

6. Cognitive Load:不要让用户同时处理太多东西

认知负荷很高时,用户会出现:

  • 不知道先看哪里;
  • 不知道哪个按钮最重要;
  • 阅读很多说明仍不理解;
  • 因为害怕点错而不操作。

减少认知负荷常用的方法不是“把字体做小”,而是:

  • 减少同时出现的选择;
  • 建立明确层级;
  • 把高级信息按需展开;
  • 删除重复文案;
  • 用自然的分组代替大量边框;
  • 只在当前状态展示当前需要的信息。

7. Recognition over Recall:让用户看见,而不是要求记住

用户能直接识别一个选项,通常比要求用户记住名称、命令或格式更容易。

例如 AI Provider:

请输入 Provider:________

需要用户记忆名称。

更自然的是:

OpenAI
Anthropic
Gemini
Custom

BodySense 中也一样:如果用户可以直接在人体图上看到对应区域,就不要要求他记住某个内部分类名称再去搜索。

8. Progressive Disclosure:需要时再展开复杂度

渐进式披露的核心不是隐藏功能,而是:

当前任务只展示当前需要理解的复杂度。

BodySense 例如:

  • 默认只展示身体区域和简要状态;
  • 点击区域后出现摘要;
  • 再展开才看历史、证据或更多细节;
  • 高级设置不应该占据主要任务空间。

9. Visibility of System Status:用户必须知道系统发生了什么

只要操作不是瞬间完成,就要考虑状态可见性。

例如:

用户发送消息
→ 已发送
→ AI 正在响应
→ 正在检索相关信息
→ 等待用户确认
→ 已更新身体记录

这里不需要展示模型内部私有推理,但要展示对用户有意义的执行状态和结果变化。

10. Error Prevention:能预防的错误不要等发生后再提示

最好的错误体验通常不是写一条更漂亮的报错,而是减少错误发生概率。

例如:

  • 不确定身体区域时,不要静默写入错误区域,先让用户确认;
  • 高风险动作执行前明确结果和范围;
  • 表单不完整时即时提示;
  • 网络正在提交时防止重复提交。

11. Recovery:错误以后怎么回来

所有重要操作都应该问:

用户点错了、系统失败了、AI 判断错了以后怎么办?

BodySense 中尤其应该允许:

  • 更正身体区域;
  • 补充遗漏信息;
  • 重试请求;
  • 中断长时间生成;
  • 回到上一个稳定状态;
  • 对 AI 结果继续追问,而不是只能接受。

12. User Control and Freedom:用户始终应该有控制权

特别是在 AI 产品里,不要让界面变成“AI 已经决定好了,你只能看”。

应该让用户知道:

  • 可以停止;
  • 可以修改;
  • 可以拒绝;
  • 可以重新生成;
  • 可以补充上下文;
  • 可以纠正事实;
  • 某些动作为什么需要确认。

13. Usability:最终看用户能不能完成任务

设计不是因为“看起来合理”就结束。

可以从几个问题验证:

  • 用户是否能发现入口?
  • 是否知道下一步做什么?
  • 完成任务需要多少无意义步骤?
  • 用户会在哪一步犹豫?
  • 错误率高不高?
  • 第一次使用是否需要别人解释?
  • 失败后能否自己恢复?

BodySense:完整 UX 推导示例

以“身体状态地图”为例。

先写目标

User Goal:
快速理解当前有哪些身体区域已经形成记录,并进入最相关的区域继续查看或补充。

再写优先级

Primary Information:
人体区域 + 有意义的记录标记

Primary Action:
选择区域查看相关记录

Secondary Information:
区域的简要状态

Contextual Information:
历史记录、证据、来源、进一步解释

再写 Flow

进入页面
 ├─ 无记录 → Empty State → 引导完成咨询
 ├─ 有记录 → 显示区域标记
 │             ↓
 │           选择区域
 │             ↓
 │           查看摘要
 │             ├─ 信息足够 → 阅读结束
 │             └─ 信息不足 → 继续咨询
 │                             ↓
 │                           AI 更新记录
 │                             ↓
 │                           地图同步更新
 └─ 加载失败 → 保留页面结构 + Retry

最后才讨论 UI

到这时才值得讨论:

  • 人体图占多大;
  • 详情放右侧还是 Drawer;
  • 标记用什么视觉方式;
  • 哪里需要 Border;
  • 标题是否必要;
  • Empty State 文案怎样写。

而不是反过来先画三个 Card,再想每个 Card 填什么。

每次开发 UX 功能时可以直接写的模板

1. User Goal
用户要完成什么?

2. Context
用户通常在什么情况下来到这里?

3. Primary Information
第一眼必须知道什么?

4. Primary Action
最主要的动作是什么?

5. IA
哪些常驻,哪些次要,哪些按需出现?

6. User Flow
正常路径、决策分支、失败路径是什么?

7. States
loading / empty / populated / partial / error / disabled / offline ...

8. Feedback
每次关键操作后,用户怎么知道发生了什么?

9. Prevention & Recovery
怎样预防错误?发生错误怎样恢复?

10. Cognitive Load
能不能删、合并、折叠或延后信息?

11. Accessibility
键盘、Focus、语义、对比度是否成立?

12. Validation
怎样证明用户真的能完成任务?

与 UI 的边界

UX 不是“不关心视觉”。视觉层级、间距、排版都会影响体验;但 UX 更早问的是:

用户为什么在这里、现在应该理解什么、下一步做什么,以及系统如何帮助他顺利完成。

UI 则进一步把这些优先级变成可见的大小、位置、颜色、字体、留白和组件形态。

相关知识

创建于 2026/8/27 更新于 2026/8/27
Digital Biome
Access

键盘导航

j / k / ↑ / ↓
选择对象
Enter / o
打开选择
/ 或 Ctrl+K
全站搜索
i / f / 1–4
筛选当前列表
g → h / l / p / t / a
首页 / 笔记 / 项目 / 工具 / About
r → 1–9
打开所选对象的关联
u
返回上一页
Esc
关闭浮层 / 取消命令;输入框内清空文本