如果你是在开发消费级软件(Consumer Software)，那你必须清楚，在对计算机的理解上，你跟你的大多数客户处在完全不同的等级。当你开始对你的软件进行技术支持的时候，你可能会对这种差距的巨大感到非常震惊。这并非说明你的用户都是傻瓜，只是因为他们没有像你一样在电脑上花了无数时间。下面我总结了一些通过回答我的排座软件成千上万个技术问题得到的经验：

1. 拷贝和粘贴

从我收到的大量技术支持邮件中可以很清楚的看出用户经常重新输入我用邮件发给他们的序列号，其似乎原因是他们并不知道如何（或者说他们能够）拷贝和粘贴文本。千真万确！你可以通过在软件手册中在关于序列号的地方说明如何拷贝和粘贴来缓解这种问题（这样不仅快捷，而且可以避免一些易混淆的字符，比如“0”和“o”）。

2. 网页和本地应用程序的差异

许多使用web应用的用户并不理解他们需要下载并且安装桌面软件的新版本才能使用一些新的功能。你可以通过自动更新的程序来避免这一问题，不过一点你出错了那结果会相当悲剧。

3. 数据存储

许多用户不理解他们的数据是如何存储的，也不知道存在哪里，甚至不知道数据居然是和应用程序分离的。他们无法理解一些数据是存在他们的本地硬盘中，而另外一些居然是存在“云”中的。他们不能理解文件、数据库和注册表的差别。那么当他们在一台新机器上安装桌面应用程序的时候，他们可能会对对无法访问在以前那台机器上创建的文档感到惊奇。因此在你的FAQ中加上关于如何从一台机器迁移到另外一台的说明还是有价值的。

4. 你用到的术语

使用你的用户不能理解的术语常常会让用户非常恼火。比如说，非技术人员完全无法理解什么是“对话框（dialog）”，跟别说“模态对话框（modal dialog）“了。你可以称之为”窗口（window）“。

5. 右键

有些用户没有发现（或许没有想过去尝试）点击鼠标右键。因此你不要把任何功能仅仅放在邮件菜单中或者其他不容易被发现的地方。

6. 并行（Concurrency）

一些应用程序能够处理并行访问（比如客户端-服务器应用程序和web应用程序），而另外一些则不能（比如大多数桌面应用程序）。但是许多用户以为所有的软件在被多个用户同时使用的时候都是安全的。如果你的软件不能实现这一点，可能你需要在你的宣传册上说明这一点从而避免用户产生错误的预期。

7. 什么样的修改可以恢复

技术人员可以非常开心地使用一些软件并观察发生哪些事情。他们通常不会担心“尝试”一些东西，因为他们能够通过“撤销（undo）”、版本控制或者备份来恢复大部分呢的修改，通常他们也能判断一个操作是否不可恢复。非技术人员不会如此自信，因此不会用同样的方式来尝试一些事情。实际上有些人看上去可能会觉得一个错误的移动操作可能导致电脑炸的火光四射。因此通常尽量只做他们理解的传统操作（比如在Windows上他们用Microsoft Office和Outlook），对于复杂的任务需要提供详细的教程。

8. 什么时候需要备份

每隔几天我就会从某人那里收到邮件说由于一个大的硬件故障他所有的数据都丢失了，而且没有在独立的设备上进行备份。有时候这是因为他们甚至没有意识到数据是存储在他们自己的计算机上。你可以在你的文档或者软件中提醒他们需要备份，不过这样没什么区别。历史证明这是绝大多数人不得不学习的教训（包括技术人员）。提醒备份并不会伤害任何人，而且如果你在事情发生之后指出这一点的话还有助于化解用户的愤怒。

9. 他们应该读文档

人们使用你的软件是因为他们有事情要做。不管你是否喜欢，你心爱的软件只是到达终点的手段而已。虽然有些用户可能会读文档，但是大多数人都认为这是在浪费他们宝贵的时间。实际上，从我收到的客户邮件来中可以看到一个不容置疑的事实：有的用户甚至没有看一句解释问题的错误消息提示。这表明你需要写一份清晰和精确的文档，但是你同时需要带着一个假设来开发你的软件：大多数用户不会去读它。这就是为什么我们需要可用性测试（Usability Testing）。

10. 键盘和椅子中间的问题

译注：键盘和椅子中间？你可能会问，这是翻译的啥啊？请看这里延伸阅读：PAEBK，Problem exists between keyboard and chair

缺乏技能的用户常常并没有认识到他们有多么地缺乏技能。这样他们可能会因为他们自己所犯的错误来指责你的软件。在这种问题上只能尽可能地礼貌。如果显而易见客户并没有足够的技能来使用软件，那么你应当礼貌地建议“显然他们的需求并非理想的”，同时向他们提供无条件退款。然而如果你个人提出了相同的问题，那么你需要修改你的产品来更贴切你的用户（改变用户来适应你的软件当然是好的，但是不幸的是对于大多数人来说并不可行）。