界面 UI 与交互 UX
5.5 UX 设计原则
Tip
理解UX设计原则,学会设计即时反馈和防错机制,避免灾难性的用户体验。
1. 为什么要学这个?
你做了一个删除按钮。为了美观,你只放了一个垃圾桶图标🗑️,没有文字。
用户想清理缓存,误以为这个图标是"清理垃圾",结果点了一下。没有任何提示,没有任何弹窗,数据瞬间消失了。
用户炸毛了:"我就手滑了一下,我的毕业论文就没了?"
这就是典型的UI满分(好看的图标),UX零分(灾难的体验)。
2. 核心概念
2.1 UI vs UX
- UI(用户界面):长得怎么样。按钮的颜色、圆角、字体
- UX(用户体验):用起来爽不爽。按钮好不好找、报错看不看懂、操作是不是顺手
好UX的标准:别让我思考(Don't Make Me Think)。
2.2 关键原则
- 反馈(Feedback):用户做了任何操作,系统必须在0.1秒内给反应(按钮变色、转圈圈)
- 防错(Safety):对于危险操作(删除、支付),必须有"保险栓"(确认弹窗)
- 空状态(Empty State):当没有数据时,不要留白,要告诉用户"现在没数据,你可以去点这里创建"
3. 两种删除体验对比
sequenceDiagram
participant User as 用户
participant BadApp as 差劲的App
participant GoodApp as 优秀的App
Note over BadApp: ❌ 糟糕的体验
User->>BadApp: 点击删除图标
BadApp-->>User: (毫无反应,数据直接消失)
User-->>User: 惊慌失措
Note over GoodApp: ✅ 优秀的体验
User->>GoodApp: 点击删除图标
GoodApp-->>User: 弹出警告框: "确定要永久删除吗?"
User->>GoodApp: 点击"确认"
GoodApp-->>User: 显示Loading转圈(反馈)
GoodApp-->>User: 提示Toast: "删除成功"(结果)
4. 适用场景
| 🎯 场景 | UX优化方案 | Prompt话术 |
|---|---|---|
| 数据加载慢 | 不要白屏,显示骨架屏(Skeleton) | "在数据fetch期间,请显示shadcn的Skeleton组件" |
| 表单校验 | 别等提交了才报错,要在输入时实时校验 | "使用zod实现即时验证,密码过短时输入框变红并提示" |
| 危险操作 | 二次确认 | "删除前弹出AlertDialog,要求用户再次确认" |
5. 避坑指南
| ✅ 推荐做法 | ❌ 禁忌 |
|---|---|
| Loading状态(按钮变灰禁用) | 点击按钮后没反应,用户以为没点上,疯狂连点10次 |
| 明确的报错("密码必须含数字") | 模糊的报错("发生错误","Error 500") |
| 破坏性按钮标红 | 确认和取消按钮长得一模一样 |
6. 真实案例
Story
2018年,夏威夷导弹误报危机
2018年1月13日,夏威夷全境的每个人手机收到紧急警报:"弹道导弹进袭夏威夷。立刻寻找避难所。这不是演习。"全岛恐慌,人们把孩子塞进下水道,游客在酒店大堂痛哭。直到38分钟后,官方才发出第二条消息:"没有导弹。刚才那条是误发。"真相:这不是黑客攻击,也不是系统故障,仅仅是一个UX设计错误。操作员面对的是一个密密麻麻的文字列表,一行写着PACOM (CDW) - STATE ONLY(演习模式),紧挨着一行写着PACOM (CDW) - STATE ONLY(真实警报模式,看不出区别)。没有任何颜色区分,没有任何图标,点击后甚至没有明显的"你确定要向全岛发送核弹警报吗?"的红色阻断弹窗。
Vibe心法:人手总会滑,系统必须挡——防错设计(如二次确认)和即时反馈是区分别致UI与工业级产品的生死线。
7. 本章小结
- 🎨 体验至上:漂亮的UI如果很难用(UX),就是灾难
- ⚡ 即时反馈:任何操作都必须有回应(Loading、Toast)
- 🛡️ 安全屏障:对于危险操作,必须设计足以阻断手滑的二次确认机制
- 📝 明确报错:告诉用户具体哪里错了,而不是"发生错误"