文章 on UE.CN - 中国用户体验从业者社区

可用性测试执行完全指南

Sun, 25 Jan 2026 00:00:00 +0000

一、测试前准备

✓ 明确测试目标 — 这次测试要回答什么问题
✓ 准备任务脚本 — 用户要完成什么任务
✓ 预约用户 — 5 个用户是最低要求
✓ 设备与场地 — 屏幕录制、软件测试

二、测试执行流程

开场（5分钟） — 介绍测试目的，签订知情同意书
warm up（5分钟） — 聊聊天，让用户放松
任务执行（30分钟） — 用户完成任务，主播记录问题
访谈（10分钟） — 问体验感受与建议
结束（5分钟） — 感谢用户，支付报酬

三、测试中的注意事项

不要提示用户 — 让用户自己探索，不要说「你应该点这里」
记录原话 — 用户的原话比你的解读更重要
关注失败 — 任务失败的地方往往是设计问题
保持中立 — 不要对用户的操作做评价

四、测试后分析

5 个用户能发现 85% 的问题。分析方法：

问题归类 — 把相似问题合并
严重度评级 — P0 必须改，P1 下版改，P2 优化
输出报告 — 问题描述 + 截图 + 建议

可用性测试的价值不在于发现多少问题，而在于让设计决策有据可依。

设计系统从 0 到 1 实战

Sat, 24 Jan 2026 00:00:00 +0000

一、为什么要建设计系统？

设计系统的价值不在于「有一份设计规范」，而在于：

效率提升 — 设计师不用每次重新画按钮
一致性 — 全站体验一致
协作语言 — 设计师与开发有共同语言

二、落地 4 步法

1梳理现有组件

先把当前产品里常用的组件整理出来

2定义设计 token

颜色、间距、字体的变量

3制作组件文档

每个组件要有「什么时候用、怎么用」

4推广与迭代

让人用起来，并根据反馈迭代

三、我们的避坑经验

不要追求完美 — 先用起来，80% 的组件够用了
必须有专人维护 — 没人维护的设计系统 = 死文档
推广要接地气 — 靠行政命令没用，得让人看到价值

四、衡量设计系统的价值

我们用这几个指标衡量：

组件使用率 — 新页面中有多少组件来自设计系统
设计师工作量 — 同样需求，交付时间缩短多少
用户投诉 — 与 UI 相关的客诉是否减少

设计系统不是一次性工程，而是「产品」。把它当成团队的工具类产品来运营。

B端 vs C端，设计差异到底在哪？

Fri, 23 Jan 2026 00:00:00 +0000

一、核心差异

ToB（企业产品）

用户用产品是「工作」
效率 > 美观
决策者与使用者分离
功能多，流程复杂

ToC（消费者产品）

用户用产品是「娱乐/生活」
好看 > 高效
决策者就是使用者
功能少，交互简单

二、具体场景差异

场景	ToB	ToC
新手引导	需要，但用户没时间看	用户愿意探索
界面风格	信息密度高	留白充足
权限设计	必须有	一般没有
数据展示	越多越好	关键指标即可

三、设计师的常见误区

把 ToC 的视觉标准搬到 ToB — 老板会骂「这么空旷，能干活吗？」
把 ToB 的功能堆叠带到 ToC — 用户直接卸载
忽视决策链条 — ToB 做好用的功能，不代表有人买单

没有最好的设计，只有最适合产品形态的设计。理解你的用户是谁，是一切的前提。

Design Sprint 设计冲刺实战

Thu, 22 Jan 2026 00:00:00 +0000

一、什么是 Design Sprint？

Design Sprint（设计冲刺）源自 Google Ventures，5 天完成「问题定义→原型测试」的极速工作坊方法。适合：

验证一个新想法是否可行
解决团队争议性问题
在正式开发前发现核心风险

二、5 天工作流程

Day 1 定义问题 — 明确要解决什么问题，设定目标

Day 2 发散方案 — 每人至少出 3 个方案，不批评

Day 3 决策方案 — 选择一个方案，画详细草图

Day 4 制作原型 — 做出可交互的高保真原型

Day 5 用户测试 — 找 5 个用户测试，收集反馈

三、关键成功因素

决策者必须在场 — 没有拍板权的人在场，效果为零
时间严格控制 — 每个环节超时，整体就会拖延
原型足够真实 — 用户会当真，体验才真实

四、我们的经验

第一次做 Design Sprint 时，我们踩了这些坑：

Day 2 讨论太久，导致后面三天都在赶
原型做得太粗糙，用户不愿意操作
没有提前预约用户，Day 5 人没到齐

Design Sprint 不是灵丹妙药，但在需要快速对齐团队认知时，它是目前最有效的方法之一。

体验度量指标怎么建立？

Wed, 21 Jan 2026 00:00:00 +0000

一、为什么需要体验度量？

老板说「体验很重要」，但发版前才想起做测试。没有度量指标的团队，往往陷入两种极端：

拍脑袋决策 — 「我觉得这个体验不好」
只关注转化率 — 「其他不重要」

二、三层指标体系

层级	指标类型	示例
行为层	用户做了什么	任务完成率、错误率、操作时长
态度层	用户怎么想的	SUS、NPS、满意度评分
业务层	对业务的影响	留存、转化、客服工单

三、指标选择的原则

可测量 — 必须能量化，而不是「用户体验好」
可归因 — 设计改版必须能影响这个指标
可行动 — 指标异常时，知道下一步做什么

四、我们的实践

我们选择了 5 个核心指标：

任务完成率 — 核心任务能否完成
首次成功率 — 用户第一次使用能否成功
错误恢复时长 — 出错后多久能恢复正常
SUS 评分 — 整体可用性感知
客服工单量 — 与体验相关的客诉

指标不在多，在于持续跟踪。建议从 3 个指标开始，每两周看一次趋势。

交互设计评审会怎么开才有效？

Tue, 20 Jan 2026 00:00:00 +0000

一、评审会的常见问题

每次评审会开了 2 小时，结果设计师疯狂改稿，问题却越改越多。这种场景在很多团队都很常见：

评审时大家各抒己见，但缺乏判断标准
每个人都有想法，但没人愿意做最终决策
讨论发散严重，2 小时后回到起点
方案改了 8 版，但没人记得第一版的问题解决了没有

二、用「决策树」组织评审会

我们团队经过一年迭代，总结出「决策树」评审法：

第一步：问题聚焦（10分钟） — 先说清楚这次评审要解决什么问题，而不是展示方案
第二步：决策标准（5分钟） — 明确这次评审的通过标准是什么
第三步：方案展示（15分钟） — 设计师展示方案，不接受直接否定，改为「建议」
第四步：决策投票（10分钟） — 每人用脚投票，少数服从多数
第五步：会议纪要（5分钟） — 当场确认下轮修改项与负责人

三、一个关键原则

评审会上不解决新问题，只解决已识别的问题。

如果在评审过程中发现新问题，记录下来，作为下次评审的输入，而不是在现场展开讨论。

好的评审会不是让所有人满意，而是让所有人都清楚地知道：这次要解决什么问题，以及这个版本要达成什么目标。

如何在 ToB 系统中做可用性测试？

Sun, 18 Jan 2026 00:00:00 +0000

一、背景

在 ToB 产品中，用户角色复杂、业务流程长，很多体验问题并不会在测试阶段暴露。与 ToC 产品不同，ToB 产品的用户使用产品是「工作」而非「娱乐」，他们更在意效率而非体验。

二、常见误区

只测试功能，不测试任务路径
只找"熟练用户"参与
测试过程缺乏记录
没有设定量化指标

三、实践方法

我们将测试拆成三个阶段：

关键任务梳理 — 找出用户最常用的 5 个核心任务
真实场景模拟 — 在真实环境中测试，而非测试环境
问题严重度评级 — P0 必须改，P1 下版改，P2 优化

四、核心指标

我们通常关注这几个指标：

任务完成率 — 用户能否完成任务
错误次数 — 操作过程中出错的次数
完成时间 — 完成任务需要的时间
主观满意度 — 用户对流程的评价

可用性测试的价值，不在发现多少问题，而在避免多少错误决策。