极客的可用性/来自客户的反馈
< 极客的可用性
让我们回到 这个例子，一位不幸的男子在数据库中删除了列而不是行，从而丢失了 5000 个地址。
导致此错误的一些因素包括
- 该用户以前在这个数据库中删除过数百条记录，每次程序都会将默认选项设置为删除记录。该用户习惯于只点击确定。
- 由于工作的例行性质，以及他周五下午加班的事实，该用户的警觉性低于平时。
- 数据量太大，超出了程序的撤消缓冲区，因此无法撤消致命操作。
这些因素中没有一个可能出现在可用性测试中，甚至可能不会出现在 beta 测试中。因此，这个错误不太可能在可用性测试中被发现。即使发现了，你可能也意识不到它的严重性，因为用户不会感受到失去 5000 个地址的恐惧。找到这种错误的唯一方法是倾听你从产品用户那里获得的反馈。
事实上，用户反馈是一个极好的信息来源，对改进产品非常有用。不幸的是，大多数生产商未能利用此资源。他们只是认为用户查询是一种麻烦，并没有以任何系统的方式使用它们来改进产品。近年来，这种情况实际上已经恶化，将用户支持外包到遥远的国家已成为一种普遍现象。有关用户问题的信息永远不会到达开发人员手中。
实施一个处理客户查询的程序非常重要。所有用户问题、建议、投诉和支持请求都应该被记录下来并进行统计分析。如果几个用户遇到了相同的问题，那么很可能是一个可用性问题。应该奖励用户报告问题，例如，发一封信说你正在解决这个问题，并在实施解决方案后提供免费补丁或更新。
这应该成为任何技术设备生产商的质量控制组织的一部分。如果用户设备无法立即修复和更新，那么你可以创建一个网页，向所有用户提供如何处理已知问题的相关信息。对于软件产品，你可以制作一个可下载的补丁。