上篇文章《可用性测试真的赞，但你用过几次？》中，我们探讨了“1天小成本敏捷可用性测试”的可能性，本篇我将分享整个设计推导过程以及测试的详细流程。
前情提要
一个卡片，既有选中，又有查看(教师)详情，有以下3个方案，该如何选择呐？
方案A：选中态在右侧，更方便操作；卡片左侧对齐，页面更规整；
方案B：点击热区互不相干，但是左侧对齐方式不舒服； 方案C：选中样式更突出，且与时间选择更统一；
读者投票

上篇的投票中，方案C占了绝对优势。

*以上比例四舍五入向上取整 但实际上，我们最终选了方案B。
为什么？下面详细论证。

01

最初的假设

▼ 设计本身，就是一场假设。
设计的过程，本质上，就是假设→验证→调整→假设→验证→调整… 不断迭代和打磨的过程。
想要在短期内拿到最优方案，就要加速整个迭代过程，包括假设、验证、调整速度。因此在敏捷可用性测试里，不用过多追求极致方案，有了大概假设就开始试错，对结论快速归因和方案调整，才是提升效率的上策。

实际上，开篇看到的三个方案，也并非一开始就都想到的，而是在测试过程中不断诞生的。
最初的假设很简单，因为选中优先级＞详情，所以大的点击热区优先给到选中，详情入口用小热区，于是得到以下两个方案。

方案1

方案2

02

敏捷可用性测试

▼ 1、目标分析

可用性测试的目的有两个： 1、探索性目的，即寻找和发现方案的体验问题。如从0-1的产品上线前的测试。 2、评估性目的，即多方案的体验对比。如线上vs新版优化、线上自家vs竞品、0-1多方案的对比。

因为整个热区给到了选中，我们并不担心选中问题。更多比较在意用户是否能够get到如何进入教师详情页。
测试目标：针对“进入教师详情页”，评估哪个方案更容易理解和操作效率更高。
衡量指标：任务完成时间、错误操作次数，时间越短错误次数越少，方案为优。
测试原理：控制变量法，很重要！！！整个测试流程都要遵循的原则。 一方面控制测试和真实场景的变量，另一方面控制测试方案之间的变量。 测试人群：App内七日内活跃用户→目标用户，即小学生的妈妈。这里我选择直接从公司里非设计，非产研的同事里找，上班时间直接工位偶遇。每个方案各5人。 2、测试脚本&场景化任务设定
任务其实很简单，就是找到肖雄老师，然后查看他更多信息。 我们可以 通过场景构建和心理暗示，激发用户需求，从而带入真实场景。从而达成「控制变量」的目的。 具体测试脚本如下： ① 了解用户基础信息 我：hello，你好，我是咱们直播课的设计同学，想找你做一个简单的测试，大概5分钟时间，现在有时间不？ 用户1：有的。（继续） 用户2：抱歉在忙（打扰了。结束） 我：为了测试的准确性，我想先了解一些基础信息哈，主要还是购课相关的，不会涉及隐私。 用户：恩，好的 我：咱们家里有孩子么？ 用户1：有 用户2：没有。（哦哦，打扰了，我们想找一些有孩子的用户。结束）
我：几年级了呀？ 用户1：三年级了。 用户2：还没上学（哦哦，打扰了，我们想找一些小学孩子的家长。结束）
我：方便问下，孩子数学成绩怎么样？ 用户：不行/一般/挺好的
我：感觉现在小学的题都还挺难的，咱们在家会辅导孩子么？ 用户1：哈哈是的，有些题我们还得到网上搜 用户2：会辅导啊，实在太头疼了 用户3：辅导不多，孩子自己学 …
② 心理暗示，激发真实需求 我：那我觉得你可以考虑给孩子报个咱们公司的直播课，清北名师，优惠还挺多的。
③ 带入前置场景 我：咱们这次测试就是假设你要给孩子报个数学课，然后选好了时间，就差选个老师了。
④ 引入任务场景 我：咱们的任务就是（手机展示任务界面）你想了解「肖雄老师」的详细信息，点这个开始按钮（展示）就可以操作了。操作没有对错，就按你的理解完成任务就行了。 你可以再看一眼任务，觉得没问题了，就可以点这个按钮开始了。
⑤ 测试过程观察 注意观察卡点，超过两分钟仍没操作成功，可以提示放弃。
⑥ 测后访谈 针对卡点提问，挖掘背后原因。如 我刚看你一直在点那个地方，最后才点了这里，是什么原因呐？
3、可交互原型&Maze搭建

Tips：用真实数据搭建，方便用户更好带入场景；

① 用figma/sketch(正版)搭建一个可交互原型。点击热区用透明度0%的矩形即可； ② 复制链接。注意要调整为“任何拥有链接的任-可编辑”，不然后面Maze无法解析；
③ 打开Maze，登录后新建项目；
④ 新建测试项，这里选“Prototype Test原形测试”； ⑤ 填好任务，点击“Add Prototype添加原型”；
⑥把步骤②里的链接复制进去，点击按钮； ⑦ 等待加载完成， 在图中点击设定好的操作热区。（用户只有按着我们设定好的路径操作，才算完成任务） ⑧ 点击开始测试，发布完成后，就可以复制测试链接开始测试了； ⑨方案2的搭建，figma和Maze都要新建个文件，重复以上流程即可。 4、预测试与调整

这块主要是check一遍流程，预测试的用户范围不用过多要求， 按照既定脚本，测身边1-2人即可。一旦出现有不理解甚至卡点的地方，记录并迭代，直到0问题0卡点。
测试完记得删除数据，方法如下：

5、正式测试
重复预测试的流程，因为有1、2两个方案，先聊完用户基本信息，再根据实际情况给到1或2的测试链接，尽可能保证方案1的5个用户和方案2的5个用户特征一致，如果不够可以适当加测1-2人。 测试时候记得带上业务方，上下游合作方，说服力、影响力max。 6、数据及结论 方案2略优于方案1

方案1和2测试过程中，用户都经过很多次尝试，直到试了所有方法，才看到了解TA的入口。 相比之下方案2的miss数略微少一点，但整体还是有miss，体验不达标，需要进一步探索。

03

方案调整

▼ 调整1：点击热区调整 进入详情问题挺大的，尝试把大热区（橙色区域）给到详情页，小热区（红色区域）给到选中，于是有了方案3（投票方案C）。

①测试数据如下
方案3的两个任务中，用户都会有所迟疑，而在选中任务中，几乎所有的用户都误点进了详情； ② 结论及分析 1）大热区给到详情有效，可以继续延用； 2）因为选中状态 框定的是整个卡片，会让用户误认为整个大卡都是选中区域； 3）选中还有优化空间，需要继续尝试； 调整2：更明确的热区分隔
根据测试结论，保留详情页的大热区，考虑去掉选中态的大框，或可以更明确的区分两个热区。

方案4（投票方案A）

方案5（投票方案B）

因为保持了详情的大热区，前面已经论证可行，所以这次只测试选中任务，数据如下： 方案3的两个任务中，用户都会有所迟疑，而在选中任务中，几乎所有的用户都误点进了详情； 方案B基本上达到了理想状态。虽然对齐方式很奇怪，但是业务&UI同事一起参与了测试和整个方案的演进过程，也并没有argue的声音。

04

复盘归因&策略延伸

▼

为什么方案B可用性最优呐？

1、越分隔越明确 从用户miss数可以看出来，没有用户会先谨慎思考再操作的，说明用户在点击行为上不会有过多思考，因此界面热区语义越明确越好，分隔越明确可用性越好。

2、被忽略的已有心智
直到验证到最后，才恍然大悟，最优方案我们其实很熟悉，几乎每天都能看到：

淘宝购物车卡片

京东购物车卡片

仔细观察，因为图片是天然的分隔，所以对京东和淘宝而言，选中和详情的界限很明显，因此不会有可用性问题。
但是对于sku的选择，新版淘宝选择去掉了表示区域的色块，这一点是否会影响可用性呐？欢迎评论区讨论~

- END -

---

推荐阅读

设计大招系列

‍《【理论篇】「可用性测试」真的赞，但你用过几次？》

‍‍

---

你「在看」是最好的肯定与鼓励

​​