最近团队正在设计一个全新的产品，大家都对这个产品抱着很高的期待。从定位上看，它确实填补上了现有业务的一大空缺，满足了大家的期待和想象。于是乎团队摩拳擦掌倾力而为，产品经理和设计师也花了很长时间讨论和修改方案。
但是我们问过用户的意思吗？
正是因为这个产品很重要，团队也打算投入较大资源去做，才最是不能闭门造车。去问问用户，看看用户怎么操作，如果产品概念或者设计上存在什么问题，就可以尽早纠正，在节约开发资源的同时，也可以在上线时交出一份更令人满意的答卷。
当我意识到这个问题的时候，其实已经有点晚了，交互方案已经迭代过几个版本。但无论如何，“现在”仍然是最早的时候，如果需要做些什么，那就尽快做吧！
于是我问设计师拿来了最新一版的设计稿，用墨刀贴贴补补了大半天，终于做出来一个设置了简单页面跳转的Demo。接下来的计划是：用最敏捷的方式，寻找用户、做可用性测试，发现问题后，快速修改调整（之后再继续用新方案重复这种敏捷测试）。
结果是：我们用了2个小时，测试了4个用户，发现了3个比较严重的设计问题以及其他的小问题（已经需要设计师花时间好好考虑一下了）。
我认为这个过程的ROI是很高的。如果你对墨刀这类工具以及要测试的设计稿够熟悉的话，一个早上就能做出来Demo，下午就可以开始做测试了。用2-3个小时的时间就可以做完测试，简单地整理一下结果，甚至初步讨论一下可行方案。如果执行力够高的话，当天做出新的设计稿，第二天继续同样的步骤——经过3-4个迭代之后，最终形成的方案一定会比最初的方案好很多。
不需要特意花费时间去寻找用户。我们是直接到公司附近的咖啡厅、便利店等人流较多的地方，带上一些小礼品，问一下身边那些可爱的陌生人是否愿意参与这个简短的小调查。虽然也会遭遇冷脸，但是找到4、5个愿意参与的人并不难。
也许设计师们很容易觉得自己的方案已经很好了，问用户能问出来什么？确实，当我拿到那份设计稿的时候（即使不是我自己做的），我也觉得用户是挑不出来什么刺的——流程清晰，布局合理，页面精美。但是，我仍然抱着试一试的态度，如果真的发现用户很喜欢这个设计，也算是对设计师的一种肯定。事实也证明了这种尝试是有价值的，甚至是有必要的。在很多我们认为很自然的地方，用户就是不会操作。他不理解这些概念，不知道元素之间的关系，不知道操作带来的结果——这些问题，即使团队内部讨论过很多次，十有八九也是发现不了的。
如果用户做出了一些很出乎我们意料的反应，最好记下这个问题，问一下后面测试的那些用户。这个很有必要，否则我们可能无法意识到这些问题的重要性。比如说，我在测试第一个用户的时候，就发现他不理解任务列表前面的勾选框，以为是多选（实际上是完成任务的意思）。但是测试的第二个用户却能正确理解。设计师是后来才参与测试的，所以只看到了第二个用户的测试过程。当我告诉设计师第一个用户不理解时，设计师的态度是拒绝的：“像这种没有用过GTD的用户啊，我是不管的”（用勾选表示完成任务是GTD软件非常通用的做法）。但是我坚持在第三个、第四个用户测试中了解这个问题，发现他们也不理解勾选框的真正含义。这个时候设计师才接受了这件事：我们的用户群跟GTD的用户群是不同的，不能只考虑用过GTD的用户啊。
这次简易的可用性测试是我拉着交互设计师一起做的。但是用研毕竟很难渗入到产品设计的方方面面（毕竟产品线也很多），无法及时了解到什么时候需要让用户参与。所以交互设计师如果自己能有一些用研的思维，不要闭门造车，而是可以常常使用这种敏捷的可用性测试方法（如上所述，成本并不高），快速验证和迭代自己的设计方案，就更有可能创造出优质的用户体验。毕竟我们平常口口声声说的是User-Centered Design啊，不要让它沦为一句口号。
