对第一次产品易用性（Usability）体验活动的总结

前言

在产品的整个实现过程中，有两种情况可以请（或者说需要）一些用户参与进来：

概念形成或叫需求确定阶段：此时的大方向通常已经定了，但会有些“想不清楚”的细节问题。那么可以使用“焦点小组”或“特约用户”的方法对用户进行概念测试，从而达到在产品设计阶段验证团队想法的目的。方法就是在项目的开始阶段邀请至少六位目标用户（目标用户指的是对核心概念认可或者说他刚好就有核心概念所提及的需求，他不能是对核心概念一无所知的）来针对一些问题进行讨论，明白他们的真实意愿。比如我们产品（全携通）的核心概念（目前）是：团队用户的文件存储分享和协作。这是大方向，但具体要怎样来进行分享和协作需要在搞清楚了目标用户的真实使用场景后才能来设计具体的功能，以帮他们达成所愿。『焦点小组』即是帮忙确定真实的用户场景的一个很好的方法。

易用性测试阶段：同样要邀请至少六位的目标用户（同样不能对核心概念一无所知）来对核心功能中的交互设计进行测试，以帮助改善易用性。显而易见，我们此次的测试或体验属于（“接近于”更恰当）『易用性体验』，其实它应该有一个很重要的前提是：受试者有这方面的需求，或者至少要在测试之前对核心概念能有足够的了解，这样才能保证测试中所安排的任务是尽可能接近测试者经常遇到的问题或者说其真实意愿（严格来做的话，必须要邀请到目标用户才有意义，而且要越早越好，有的甚至在 UI 设计阶段就会邀请他们参与进来）。

分析与总结

这次产品易用性体验会老实说全程都被吐槽，但很多槽也非常准确地吐到点上，我们从中收集到了不少有价值的信息用以提高我们产品的『易用性』（换一个词就叫『体验』）。但我们必须认识到的是这样的体验或测试并不是用来获得这些易用性测试者的需求（事实上也获取不到，倒是平常就在使用这类产品的陆同学当场表示以后会使用全携通，他才是里面最明显的目标用户，所以他也给出了颇多的正面反馈），而是在我们已经提供了这些功能的前提下，请他们来测试它们的易用性而已，看看对一个完全的新手来说是不是能够非常容易上手。基于这个前提，我对所搜集到的信息做了些分析和总结，并提出一点个人的浅陋看法：

排除操作任务指导中的限制性预设产生的问题

比如在生成链接并分享的任务中，我们限制了体验者必须将访问权限设置为『只能预览』（当然我们的初衷可能是希望他们能感受到我们的权限控制功能），而这跟我们的默认设置（允许下载，无需访问密码，不会自动失效）不一致所以体验者需要重新更改权限再分享，所以其中便有人觉得麻烦希望能先设置好权限再生成链接。但其实这样的预设并不能算作真正的使用场景，行业内领先的竞品们的做法都是按照最常用的权限（『允许下载，无需访问密码，不会自动失效』）作为默认值直接生成链接，只有在特别需要有安全方面的顾虑的时候才会需要去更改权限，竞品们这么做除了有数据的支撑外，更重要的是这里可以作为一个诱导免费用户付费升级的一个重要转化点，当免费用户在分享文件时需要安全方面的考虑的时候，比如他希望设定一个自动失效的时间，设置一个密码，甚至可能不希望被访问者下载，于是他进入到『链接设置』界面，此时他才发现原来免费用户的这些功能全都是无法使用的，而他又急需它们，这样他便有更大的概率会进行付费。这个『付费转化点』找的可谓是相当准确，反过来允许先设置权限再生成链接的话这个『付费转化点』便无法成立了。所以我仍旧坚持现在的做法（之后也会把提高付费转化率作为一个重要的项目来实施，它的关键就是要找到这样一个个让人不得不付费的地方）。所以诸如此类因为预设条件所得到的使用反馈是我们要坚决排除掉的，不加分辨地采纳任何意见是相当危险的做法。

谨慎对待个人观点

比如关于讨论这样的及时通讯模块，其中的一个体验者说这个功能完全不需要，用 QQ 就可以了，如果我们就这样下结论说立马砍掉它的话，那这种通过个案来论证结论的过程是相当不严谨的，如果这种论证成立的话，我这边刚好可以举出截然相反的例证：有道云协作的产品团队在他们的产品上创建了一个产品吐槽建议群（就类似于全携通的协作文件夹），旨在搜集用户反馈，我就常常看见有人留言说有道云协作这样的讨论功能好好用，他们团队基本上就用它来沟通工作，甚至还有人希望增加讨论的显示面积与重要性，他们认为文件反而应该放在更次要一点的位置……那我是不是就能因此证明说讨论功能非常有用？

其实这种时候任何的主观判断都是没有意义的，我们应该通过最理性的东西——数据作为最高的指导标准，一个功能只要它的场景是合理的就可以大胆地实现它（其实我们每天都在践行着这个场景，它会跟独立的 IM 会有不同，我们上传或更新了文件，全携通便自动推送一个相应的动态，我们也可以顺便留个言，描述一下相关情况，比起打开 QQ 再去沟通，这一切难道不是更加自然而便捷吗？这个过程可以完全省去啰嗦麻烦地描述『全携通的什么文件夹下的子文件夹的某个子文件夹下的一个什么文件怎样怎样了』），紧接着要做的事情是对它的数据进行监控，一段时间（比如一个自然月）后如果数据显示用户频繁使用了文件管理与分享功能，而讨论这一块却几乎不用，这个时候我们才可以得出结论用户不需要它所以应该果断将其砍掉；而如果数据还不错的话，我们应该继续优化它。

举这个例子是希望随着用户数的增加，我们能逐步提高对数据的关注度，对一个互联网产品来说，数据就好像是导航系统，是能够帮助产品找到正确方向的定位工具。

共性问题非常具有价值

虽然这次的体验者可能有的并不是我们的目标用户（其中一部分的体验者没有使用过这类产品的经验），但他们反映出来的一些共性问题还是能很好地说明我们全携通目前的易用性问题的（根据人机交互博士 Jakob Nielsen 提出的可用性问题发现率曲线，6到9个即能反应出90%左右的问题）。我们会认真总结并据此在将来一一优化我们的产品（全携通）。