前阵子在本版看到有人询问关于网页测试的问题：
除了工程师测试，会让全公司的其他人测试吗？
文章代码：#1TaBYoiN
之前我有写过一篇文章分享跟QA合作的经验：http://user449.psee.ly/LVQ93
里面提到一开始我们没有QA，因此的确有点类似全公司乱测，
工程师、PM、客服或相关部门都会帮忙测试，
有专职QA加入后就由QA来带领我们把关产品的稳定与安全。
最近新写了一篇文章关于“易用性测试 Usability Testing”，
比较偏向产品团队有点资源又没那么多资源，想要开始使用者测试的试水温方法！
Medium 好读版：http://pesc.pw/KGYAZ
【没有资源做产品的使用者研究？让我们从内部易用性测试开始！】
大家都知道使用者研究、易用性测试（Usability Testing）很重要，但不是每个团队都机会或资源进行。
最常见的状况是老板认为这不是必要的，因此不想花时间跟资源下去，其他状况如小公司或新团队没相关经验、之前的阶段不需要（先照抄竞品、或工程师快速建一个版本去冲流量和销量）、羞于将半成品呈现给他人、或觉得产品新功能是公司机密不能外流等等理由，而迟迟没有开始尝试。
在这边分享一个较为轻量级的作法 — — 找内部的团队成员来做易用性测试与访谈。
▍什么是易用性测试
易用性是一种以使用者为中心的设计概念，易用性设计的重点在于让产品的设计能够符合使用者的习惯与需求。以互联网网站的设计为例，希望让使用者在浏览的过程中不会产生压力或感到挫折，并能让使用者在使用网站功能时，能用最少的努力发挥最大的效能。（以上取自维基百科）
易用性测试则是透过直接让使用者与产品互动，了解他们实际如何使用、遇到什么困难、是否有解决他们的问题，来验证产品的易用性，并以之为基础来优化产品。
PM、设计师虽然是产品设计、UIUX 的专家，但毕竟不是真正的使用者，无法非常直觉又透彻的了解使用者的问题与需求；就算本身是使用者，也可能因为对产品、软件设计太过熟悉而会有盲点，看不出产品难以操作的地方。在这种时候，使用者才是真正能够帮助产品团队的专家。
易用性测试进行的阶段通常在改动实际进入开发之前，由 PM、设计师针对现阶段设计出来的产品解法做出可互动的 prototype，初步验证解法的方向是否正确，蒐集回馈来修正；有时也会在功能开发完成后、上线前进行易用性测试作为上线前的最后确认，避免好的点子与功能因为难用而无法发挥效果。
易用性测试有它的限制，它可以告诉你好不好用、容不容易用，但无法完全告诉你使用者会不会想用这个功能、数据会不会增长，对于一些较小的改动，直接上线、做实验、看数据可能会有更好的效果。除了产品本身的 UIUX 外，有时候文案、FAQ 的易读性等产品辅助也会对易用性造成影响。
▍什么是内部易用性测试
内部易用性测试，说穿了就是不找外面真实的使用者，而找内部团队成员来做易用性测试。如果平常本来就会将 PRD、mockup 丢给大家给意见，不如就当成另一种搜集资料的方法，也作为未来若有机会找真实使用者测试前的内部练习。
在某些团队中，本来就会找内部同事进行 Pilot Testing 来作为正式测试前的 rehearsal，确保真正找外部受测者时流程可以顺利进行。
▍内部易用性测试的作法
1. 规划与设计
内部易用性测试的使用情境跟一般易用性测试没有不同，包含 Prototype 测试、不同解法的测试、上线前的测试等。
一开始先设定好研究与测试目标、预期达成的结果，规划测试流程（主要使用情境、需要使用者完成的任务），并撰写流程稿与访谈大纲。
最重要的是招募受测对象！
内部易用性测试容易遭人诟病的原因，很多都与同事这个“人”有关，找到合适的受测对象对于这次是否能搜集到有用的回馈非常重要。
- 不要找产品团队的人，包含其他 PM、设计师、工程师、QA，因为他们本身就是软件/产品专家
- 不要找你的利益关系人（stakeholder），包含你的直属主管或老板，这些人给的回馈不一定会中立
- 不要找真实使用者的利益关系人（stakeholder），因为他们可能会建立假设并从使用者角度思考，而不是从自己角度思考（这个阶段应该是要接收受测者本人最真实的回馈）
以上这些人可以直接帮你看 PRD 给意见，但不见得是最适合当成受测者的对象。找受测者、受访者的重点是挖他们脑中的想法出来，而不是塞东西进去他们的脑海，但对于同个公司甚至同个部门的人来说，他们脑袋已经有各种挥之不去的产品细节了。若他们想要参与测试与访谈过程，作为不介入流程的“观察者”会较适合。
排除以上选择之后，通常在招募外部测试的受测者时，会先释出问卷（Screeners）来筛选出合适的对象，但在公司内部，我认为第一次练习时可以先省略这一步。毕竟如果团队很小，其实也没什么好筛选的；如果团队很大，的确可以试试使用问卷筛选，但随着时间成本增加，算是有点失去内部易用性测试的弹性与优点，同时可能也会降低同事愿意受测的意愿（懒的填问卷）。
找错人的风险就是浪费时间、蒐集到无用回馈，如果真的遇到测试到一半，你跟设计师突然发现对方不是你们想要的受测者，提早结束也不会太失礼，同事大不了回去座位上工作。将“找到不合适的受测者”这个资讯记录下来，也可以当成未来正式招募受测者时的参考。
那可以找哪些人呢？
- 较不相关的部门同事，例如财务、人资、行政，他们甚至可能还没认真用过自家产品。
- 其他产品线的同事，例如其他产品线的业务、BD、客服、行销等等。
- 刚加入公司没多久的人、实习生，他们脑袋里还没太多产品想法，是很好的测试对象。
接下来就是寄送测试邀请和注意事项，包含时间地点、所需时间长度、是否需要自备器材（带自己熟悉的电脑、手机）等等，静待测试日的到来。
二、进行流程
测试当下的流程大致如下：
1. 说明今日的流程与 PM 团队的期待
2. 说明测试情境与背景资讯
3. 让受测者开始进行测试、完成指定的任务
4. 测后访谈
5. 让受测者提问、针对整个流程做回馈
第一点即先帮受测者做心理建设、说明你希望得到的回馈，例如：一遇到不懂或有问题的地方就提出，看到每个页面、进行每个步骤的时候简单说出看到什么、想做什么等等。这篇文章《First-Time Usability: The Test and Script》提供了满好的范例。
第二点简单说明完情境后，在第三点测试进行中，跟受测者互动时最好都使用问句，让他来说明他的想法，而不是由产品团队推销与解释自己的点子。就算是受测者主动提问，也可以继续反问他“你觉得呢？”，持续引导他说出内心的想法。他说愈多，你赚愈多！
举例来说：
- 受测者：“这边我应该要按 XXX 对吗？”
- 主持人：“你觉得呢？”
- 受测者：“我觉得我好像应该要按，但是页面上的 OOO 看起来也可以让我（达成某任务），所以我第一眼是比较想去 OOO 的。”
- 主持人：“了解，就依照你认为合理的方式去做吧！”
这时可以持续追问他为什么会这样认为，或者也可以先记录下来，让受测者继续操作并完成整个任务，待会后的测候访谈一并做更深入的讨论 — — “你刚才在操作的时候，第一次是先去 OOO，可以多跟我说明一下原因吗？”也许是接口设计的轻重与明显程度、文案内容、产品操作流程的一致性等等各种原因，问下去才会知道受测者实际的使用逻辑。
第四点的测后访谈，除了针对在测试时没有跟受测者讨论的议题进行追问，也可以更加了解受测者的背景、动机，补问我们没有在问卷（Screeners）问到的基础问题。
3. 后续分析与追踪
上述的测试流程，最好有至少两位产品团队的人参与，一个主问、一个主纪录，每位受测者离开后负责测试的团队可以先简单的整理记录与做总结，并且调整测试流程和访问内容。待所有的测试都完成后，就可以跟整个团队一起整理、分享测试结果，并依照观察到的问题来优化产品。
根据研究表示，找到五个受测者来做易用性测试，就足以发现大部分的问题了。每次规划易用性测试不用测试太多人，但是可以在优化解法与流程并产生新的 prototype 后再进行第二次的易用性测试，找回第一次测试中合适的受测者再次参加，同时邀请之前没来参加过的受测者。
除此之外，一定要将这次的经验、结果记录下来，作为未来要求公司做外部真实用户测试的筹码！
▍内部易用性测试的优缺点
不做易用性测试和使用者研究的风险在于，花了资源做出使用者不满意、难用、没意愿使用的产品/功能/变动，直到推出上线后才发现一切都是白工。请注意，尽管做了内部易用性测试，如果找错人（毕竟他不是真的使用者），或是没有正确的期待与认知，这个风险还是会存在的。
内部易用性测试的优点
1. 在公司内部推动对 UX 的重视
老板请给我一次机会！我认为最大的优点在于，对过去没有机会做使用者访谈或易用性测试的团队，要老板一步到位花钱跟时间做他不确定价值如何的易用性测试也许不容易，但若是小规模的先从内部开始试验，让老板看到易用性测试可以达到的效果，也许未来就有机会去找真实的使用者来测试。
另一方面，被招募来受测的同事可以更了解产品团队的工作流程，一起参与产品设计过程，透过提供真实的意见来推动产品优化。
2. 金钱/时间成本较低
在一般的易用性测试中，金钱成本包含给受测者的车马费，时间成本包含来来回回筛选跟招募受测者的时间；在内部易用性测试中，可以用零食打发同事，招募跟敲定时间较容易外，也比较不会轻易被放鸟（办公室走来走去就可以碰面，跨国团队就用线上视讯）。
如果想做多次的易用性测试，修改 prototype 之后，可以轻易找到同一个人再次搜集回馈，而不用屈就于只有部分的受测者有空、有意愿再次受访。
3. 给自己练习的机会
一方面如同前面提到过的 Pilot Testing — — 先在内部测试“测试的流程”再进行外部测试总是比较保险。
另一方面是练习和优化自己团队易用性测试、访谈的方法，在内部测试的试错空间较大，例如时间与流程掌控不顺、PM 与设计师访谈默契不足、原本设计的流程测不出东西等等都可以发现，如果测试与访谈当下忘了追问某个问题（你为什么觉得XXX？多问一个为什么！）也有机会事后再找那位同事追问。
内部易用性测试的缺点
1. 很难从同事口中得到真实的回馈
同事的回馈有时候不可信！这些不真实回馈的来源可能是：
- 同事太爱公司，所以不想提产品缺点
- 同事跟你是朋友，所以怕指出产品设计很烂会伤了你的心
- 同事怕不会用产品显得自己很笨、很丢脸，因此假装一切都没问题
- 同事在公司是老鸟，一直以来都有某些强烈的产品建议，顺势提出来
- 同事因为自己本身的工作内容、KPI，而倾向某种设计方向或是优先级
2. 同事是专家（或觉得自己是专家）
假设同事原本就很常在使用类似功能的产品，或常常在做竞品研究的人，可能会因此非常熟悉如何设定与操作。这不能代表这个产品的易用性很高，只能代表同事真的满强的。大家都懂行话可以说是优点，也可以是缺点，在测试过程中看似很顺利，不代表真实使用者使用时也会很顺利。
有些同事则是本身也懂点技术，会自主帮产品团队想很多 — — 这个技术上要花比较多资源跟时间、这个跟其他功能会有相依性、甚至开始想要讨论设计或技术的实作细节。
另一个状况是同事觉得自己是专家，看到 prototype 后没有先融入情境试用，而是直接提出了修改的建议与解法。在修改 prototype 的第二次易用性测试、或是产品上线后，当他发现产品团队没有采取它的意见，可能会有些失落、或再次强烈表达意见。
如何处理？
这些“人”的问题会造成团队搜集到的可能不是真实的“使用者”回馈！里头参杂了额外的拉扯与小剧场，要避免这些状况，只能从受测者招募与测试前的心理建设下手。
第一是在筛选受测者的时候先排除掉不适合的对象；第二是自己要先认知到可能会遇到上述问题，当下要设定正确的期待，事后也要适度筛选回馈；第三是也要给受测者正确的认知与期待，测试前先建立好规则，希望他们在听了我们的肺腑之言后，可以用平常心来试用产品。
“嗨，我的好同事！这个测试的目标是为了让产品更好，我们在测试的是产品本身好不好用，不是你用的好不好。所以如果你不会使用、遇到任何问题，通常是产品设计的问题。当下直接回馈给我们，不会伤到 PM、设计师的心，反而能让我们搜集到更多真实的回馈来优化产品！你给的回馈愈真实，对公司与团队的帮助愈大唷～”
这些难以避免的“同事”的问题，在内部团队进行易用性测试时，风险是可以适度被降低的；但若是“使用者访谈”则就非常非常不适合找内部的人来进行，因为解读搜集到的访谈内容、挖掘洞见的时候很容易跟真实使用者有大大的出入。
特别不适合进行内部访谈的情境
1. 产品本身还在早期发展阶段
这时最重要的是找到真实的使用者、重度使用者会是谁，他们面临的问题是什么，我们如何帮他们解决。优化产品流程、UIUX 并不能回答这些问题，那个阶段最重要的是发展产品核心价值。
2. 前期的使用者访谈
就算产品本身已经较为成熟，但要挖掘特定使用者遇到的问题、行为背后的动机，还是要找到真实的用户才能找出值得解决的问题。
3. 产品 TA 属性特别
如果产品很明显是做给特定族群，尤其是特定行业的 B2B 产品，业内人士的使用方式与痛点会是同事无法提供的资讯。
▍长远目标：真实用户的易用性测试
内部易用性测试不应该是团队内使用者测试与研究的全貌，而是一个过渡期 — — 先在内部测试没有问题，长远目标应该是说服公司能够找真实用户来做易用性测试，再推动真实用户的前期访谈与使用者研究。

推

使用者测试法

推

推