书名：《用户体验要素：以用户为中心的产品设计》
英文名： The Elements of User Experience
作者： Jesse James Garrett

前言

最近在继续补产品方面的知识。

前面看《人人都是产品经理》的时候，我开始对产品经理整个工作流程有了一个比较基础的认识。

包括：

用户
 ↓
需求
 ↓
产品设计
 ↓
原型
 ↓
开发
 ↓
上线
 ↓
迭代

但是继续往下学习的时候，我发现自己还有一个很明显的“开发惯性”。

就是看到一个需求以后，很容易直接开始想：

这个功能应该怎么设计？

甚至打开 Axure 以后，就开始考虑：

• 页面怎么布局？
• 按钮放在哪里？
• 弹窗怎么设计？
• 点击以后跳转到哪里？

但是《用户体验要素》让我开始意识到：

页面其实已经是产品设计非常靠后的一个环节了。

在开始画页面之前，还有很多问题需要先想清楚。

一、产品设计并不是从页面开始

以前作为开发接需求的时候，我们看到的产品通常已经比较完整了。

产品经理可能已经提供：

• PRD
• 原型图
• 流程图
• 交互说明

所以开发天然会认为：

需求
 ↓
原型
 ↓
开发

但是如果自己开始做产品，就会发现：

原型不是需求的起点，而是前面很多思考的结果。

《用户体验要素》把整个产品体验拆成了五个层次：

        ┌──────────────┐
        │   表现层      │
        │   Surface    │
        ├──────────────┤
        │   框架层      │
        │   Skeleton   │
        ├──────────────┤
        │   结构层      │
        │   Structure  │
        ├──────────────┤
        │   范围层      │
        │   Scope      │
        ├──────────────┤
        │   战略层      │
        │   Strategy   │
        └──────────────┘

从下往上分别是：

战略层 → 范围层 → 结构层 → 框架层 → 表现层

这个模型看起来并不复杂。

但对我这种开发背景的人来说，它最大的意义是让我开始改变一个习惯：

不要一拿到需求就开始画页面。

二、第一层：战略层——为什么要做？

战略层其实是在回答最基础的问题：

为什么要做这个产品？

主要涉及两个方面：

用户需要什么？
      +
我们希望得到什么？

也就是：

用户目标 + 产品目标

比如交易所准备增加一个：

模拟交易功能

如果直接进入功能设计，很容易马上想到：

虚拟资产
模拟下单
模拟持仓
模拟盈亏
排行榜

但是在战略层，首先应该问：

为什么要做模拟交易？

可能是因为：

新用户注册
   ↓
不会交易合约
   ↓
担心真实资金亏损
   ↓
不敢完成第一次交易
   ↓
新用户转化率低

那么产品目标可能是：

降低新用户学习合约交易的门槛。

用户目标则是：

在不承担真实资金风险的情况下学习交易。

这样一来，后面的产品设计才有一个明确方向。

否则很容易变成：

别人有模拟交易，所以我们也做一个。

三、第二层：范围层——到底应该做哪些功能？

确定为什么做以后，下一步才是：

需要做什么？

这一层我觉得非常像开发里面经常讨论的：

Scope。

例如模拟交易，可以做的功能非常多：

模拟资产
现货交易
合约交易
杠杆
止盈止损
跟单
排行榜
任务
奖励
历史订单
收益曲线

如果什么都做，开发周期可能直接变成几个月。

所以产品经理需要做取舍。

假设我们的目标只是：

帮助新用户完成第一次合约交易。

那么第一版可能只需要：

模拟 USDT
    ↓
选择 BTC/USDT
    ↓
选择杠杆
    ↓
开多 / 开空
    ↓
查看持仓
    ↓
平仓
    ↓
查看盈亏

其他功能暂时都可以不做。

这让我开始理解：

功能越多，并不意味着产品越完整。

真正重要的是：

这些功能是否服务于最开始确定的产品目标。

四、第三层：结构层——用户应该怎么完成任务？

确定功能以后，还不能马上开始画 UI。

接下来需要考虑：

这些功能之间是什么关系？

例如一个新用户第一次进行合约交易：

进入模拟交易
      ↓
领取模拟资产
      ↓
选择交易对
      ↓
选择杠杆
      ↓
输入数量
      ↓
开多 / 开空
      ↓
查看持仓
      ↓
平仓
      ↓
查看收益

这其实就是用户完成任务的路径。

如果这个路径设计得很复杂：

首页
 ↓
合约
 ↓
更多
 ↓
模拟交易
 ↓
创建模拟账户
 ↓
选择账户
 ↓
划转模拟资产
 ↓
进入交易页面

即使每一个页面都设计得很好看，用户体验依然可能很差。

所以我现在越来越觉得：

用户体验并不是 UI 漂不漂亮。

很多体验问题其实发生在 UI 之前。

五、第四层：框架层——页面上的东西应该放在哪里？

到了这一层，才开始越来越接近我们平时看到的“原型”。

比如交易页面可能包括：

┌─────────────────────────────────────┐
│ BTC/USDT        最新价      涨跌幅    │
├─────────────────────────────────────┤
│                                     │
│              K 线区域                │
│                                     │
├──────────────────┬──────────────────┤
│                  │                  │
│      深度         │      下单区域     │
│                  │                  │
├──────────────────┴──────────────────┤
│           当前持仓 / 当前委托         │
└─────────────────────────────────────┘

这个时候需要考虑：

• 哪些信息最重要？
• 用户第一眼应该看到什么？
• 高频操作放在哪里？
• 哪些信息可以隐藏？
• 哪些操作需要二次确认？
• 哪些状态必须明确展示？

这时候 Axure、Figma 这些工具才真正开始发挥作用。

但工具解决的是：

如何把你的方案表达出来。

而不是：

帮你决定应该做什么产品。

六、第五层：表现层——好看当然也很重要

最后才是表现层。

包括：

• 颜色
• 字体
• 间距
• 图标
• 对齐
• 状态
• 视觉层级

以前作为开发，有时候会觉得：

“功能能用不就行了吗？”

但是站在用户角度以后，会发现视觉其实也会影响使用效率。

尤其是交易产品。

例如：

普通文字

重要数据

风险提示

错误状态

成功状态

可点击元素

如果视觉层级完全一样，用户就需要花更多时间寻找信息。

所以好的视觉设计并不仅仅是：

让产品看起来更漂亮。

更重要的是：

帮助用户快速理解页面。

七、五个层次之间不能反着来

这本书对我最大的启发，其实就是这五层之间的关系。

正确的思考过程应该更接近：

战略层
为什么做？
   ↓
范围层
做什么？
   ↓
结构层
怎么组织？
   ↓
框架层
怎么交互？
   ↓
表现层
怎么呈现？

但现实工作中很容易反过来：

老板：这里加个按钮
       ↓
产品：按钮放右上角
       ↓
设计：按钮用蓝色
       ↓
开发：接口怎么定义？
       ↓
上线
       ↓
没人使用

然后大家才开始讨论：

这个功能到底是解决什么问题的？

这其实就是把最应该首先讨论的问题，放到了最后。

八、拿交易所产品举个例子

比如现在收到一个需求：

“增加合约计算器。”

以前可能马上开始分析：

入口放在哪里？
 ↓
需要几个 Tab？
 ↓
收益怎么计算？
 ↓
强平价怎么计算？

但按照五层模型，可以换一个思路。

1. 战略层

为什么做？

用户可能在开仓前无法快速判断：

• 保证金
• 收益
• 强平价格

目标：

降低用户进行合约交易时的计算成本。

2. 范围层

需要支持什么？

第一版可能只支持：

收益计算
强平价计算
目标价格计算

而不是一开始把所有计算功能全部做进去。

3. 结构层

用户使用路径：

交易页面
   ↓
打开计算器
   ↓
选择计算类型
   ↓
输入参数
   ↓
查看结果
   ↓
返回交易

4. 框架层

考虑：

• 输入项如何排列
• 结果放在哪里
• 是否保留用户输入
• 是否允许直接带入当前交易对
• 是否自动读取当前杠杆

5. 表现层

最后才考虑：

• 字体
• 间距
• 颜色
• 输入框样式
• 盈亏数据显示方式

这样整个需求的思考路径就清楚很多。

九、这本书对开发转产品最大的帮助

我觉得技术人员学习产品，很容易出现一个问题：

太喜欢解决问题。

看到一个问题以后，马上开始想方案。

比如：

这里增加一个接口

这里加 Redis

这里异步处理

这里增加一个按钮

解决问题当然没有错。

但产品经理可能需要强迫自己稍微慢一点。

先问：

为什么？
 ↓
谁的问题？
 ↓
什么场景？
 ↓
问题有多严重？
 ↓
解决以后有什么价值？
 ↓
然后才是怎么解决

《用户体验要素》其实给了我一个比较简单的检查方式。

以后准备画原型之前，可以先问自己五个问题：

如果连前两个问题都回答不了，就不应该急着打开 Axure。

十、我开始理解为什么有些需求“看起来没问题，用起来却很难用”

以前遇到一些产品，会有一种感觉：

每个功能单独看都没问题，但是整个产品就是不好用。

现在回头看，问题可能并不出在某一个按钮。

而可能出现在：

战略层：目标用户没想清楚

范围层：功能越来越多

结构层：信息组织混乱

框架层：操作路径复杂

表现层：信息没有层级

最后所有问题都会集中反映到：

“用户体验不好。”

但真正修改的时候，如果只是：

换颜色
改按钮
调整间距

可能根本解决不了问题。

因为问题可能发生在更下面的层级。

写在最后

读完《用户体验要素》，我最大的收获并不是学到了某种具体的 UI 设计方法。

而是建立了一个比较简单的产品设计框架：

Why
 ↓
What
 ↓
Structure
 ↓
Interaction
 ↓
Visual

以前做开发的时候，我们更多是在产品流程的后半段参与。

所以习惯拿到一个已经确定的需求，然后考虑：

怎么把它实现好。

开始学习产品以后，我发现自己需要逐渐把思考位置往前移动。

不只是：

这个页面怎么画？

而是先考虑：

为什么需要这个页面？

也不只是：

这个功能怎么实现？

而是：

用户到底需要解决什么问题？

对我来说，从研发转产品可能并不是突然换一个岗位。

更像是在原来的技术思维上，逐渐增加：

用户、需求、场景、体验和商业目标。

这也是目前我觉得学习产品最有意思的地方。