设计师难免会有比对设计方案，自己拿不定注意，或者是跟产品对选择哪个设计方案有分歧的时候。这个时候，进行一次可用性测试，用大家的选择来说话，节约了很多纠结的内耗，和口水战。
正经的进行可用性测试需要很多准备工作，需要写脚本、安排任务、约测试用户。但是在紧凑的工作中，这种正式的方式效率比较低。所以我选择非正式的方式，脚本直接在脑海里过一下。任务直接列到测试用的原型里，最好不超过3个任务，多了会占用测试用户太多时间。测试的用户就在办公楼里找（暴露了没有明确用户画像的事实）。事实上被测试的产品面向的用户面很广，办公楼里的白领们也涵盖在我们的目标用户里，并且是主流的目标用户。最重要的一点，问本公司的员工，避免了保密的问题。还有一点，不能找开发人员来测试，他们太利益相关了。
第一次尝试：
第一次尝试我选择了一个比较简单的单个页面的设计方案对比作为开始。这种单方案的对比比较简单、我也好积累经验和勇气。本次测试找了5个测试用户。
测试中的收获：
1、如果想找测试人员完成这项工作，做好避免使用“测试”这个字眼，他们会误解直接拒绝。
2、有两个测试用户，测试后的一段时间后，直接找我询问我最终方案选择情况。如果最终方案没有使用对方提出的意见，要给出合理的解释，他们是会理解的。这里获得的经验是在测试结束的当下，就可以征求用户是否要反馈。
3、设计方案要注重画面左右均衡，有一个方案设计的左重右轻被吐槽信息乱和忽视掉空的那一块。
4、设计方案前一定要多问为什么，一定要首先问清产品经理给出的功能点的动机，不然会被测试用户质疑。其实这本来就是一个设计师应该有的设计思维啊。
第二次尝试：
第二次尝试我选择了一个完整的任务流程作为测试方案。本次测试找了5个测试用户。
这次测试的收获：
1、不能扎堆找人问。公司的工位往往是同样职能的人坐一起，扎堆问容易产生问题重复。
2、测试整个流程前自己脑海里要有一些重要节点相关的问题，当用户操作到那里的时候有针对性的提问。之前我担心我的问题会误导他们，但其实目前看来，我的担心有些多余。
3、在获得某些意料之外的收获后，可以问问后面的测试用户有没有这些问题或者顾虑等。经验就是在一个测试结束后，要停下来，整理一下自己的思路和问题，带着新的问题去访问下一个用户。一定要停下来整理一下，不然那个新出现的问题可能就被错过了。
4、测试结束后，整理了一份可用性测试报告，跟团队分享了一下。其中有些问题和想法提的挺好的，我也提出了自己的设计方案，但是毕竟设计是一门平衡的艺术，要考虑到合作方、业务、开发等等因素，只实现了其中的部分。
5、我发现大家对自家产品是寄予厚望的，但是因为种种原因产品不能表现的那么好，有些遗憾。
6、测试中一个测试用户点名了一个我在设计中忽视的问题，当时那个问题在脑海中一闪而过，没抓住就再也想不起来了。
反思
这两次测试的收获都挺大的，让我的设计方案更加接地气和接近用户，也让我在方案PK中有了底气和自信。
正巧，第二次测试结束后，我听了一本书《洞见远胜创意》中提到调查分析是主动发现问题的方式。这给我了坚持下去的信心。同时也解答了我的疑惑，我一直不确定在进行可用性测试的过程中要提带有哪些倾向性的问题，我尽量使用中立的态度、语气和测试对象进行交流。这本书告诉我要让大家抱怨他们的不满、不喜欢会有更多收获，比如下一次，我可以问测试用户你对这个设计方案有什么想吐槽的之类的问题了。
第三次尝试
这次尝试准备比较充分，制作了比较精美的原型，还打印了5张问题列表。
过程中的收获：
1、不要在制作原型上花费太多时间。平时不忙的时候更新下模板库，保证以最快的速度出原型，或者直接用旧版本进行测试。
2、找人的时候注意观察这个人是不是特别忙，忙就换个人。这次测试用户3号就找的不合适，问了关键问题后就草草结束了。
这次测试比较成功，发现了一个很关键的问题，几乎每个人都遇到了同一个困难。也发现了两种明显的行为模式.
