【发布时间】：2008-09-09 01:00:38
【问题描述】：
我不是可用性专家，我真的不想成为一名专家。
我只想在编写用户界面时遵循一些经验法则，以便我的产品具有良好的可用性。
起初我认为这个问题很容易回答“使用你的常识”，但如果它在我们开发人员中如此普遍，我们作为一个群体就不会以我们糟糕的界面而闻名。
有什么建议吗？
【问题讨论】：
【发布时间】：2008-09-09 01:00:38
【问题描述】：
【讨论】：
-
这实际上并不能回答问题。
-
是的，对不起。但是你可以从中得到一些教训：试着让它变得简单——或者像其他人所说的那样，让它成为禅宗。就像史蒂夫克鲁格在他的书中所说：不要让我思考！
-
现在我感到内疚，它在顶部。哈哈:)
-
我认为这是一个很好的答案。使其尽可能简单和直观，特别是对于用户每天将与之交互数十次的界面部分。为管理员保存可怕的表格和“千载难逢”的功能。
-
其实这很好回答了这个问题。图片的重点是说“看看 Apple 和 Google，他们的产品非常成功。现在看看他们的用户界面的简单性，并将其与您自己的业务应用程序进行比较。”仅仅因为它是一个业务线应用程序并不意味着它应该有一个简单、干净、易于使用的界面。不，除了“保持简单”之外，这个答案并没有给出一套遵循的规则，但它仍然是一个很好的答案。
阅读Don't Make Me Think by Steve Krug。这是一个很好的起点，而且很容易阅读。
编辑：虽然这主要是为了网络可用性，但即使您正在做富客户端，它仍然是一本好书。
【讨论】：
真的只有两件事：
- “当程序的行为完全符合用户的预期时，用户界面设计得很好” - quoted 来自 Joel Spolsky 的 User Interface Design For Programmers
- 将您的设计呈现在用户面前。真正的最终用户是最好的，但要获得轻量级、快速的反馈，您无法击败走廊可用性测试，即找一位同事。
如果您记住 Joel 的建议，并确保您得到关于您所做的任何事情的反馈并采取行动，即迭代，那么您就不会出错。我会赞同 Steve Krug 的 Don't Make Me Think 的推荐——这可能是我读过的最好的与工作相关的书，没有之一，它同样适用于桌面软件和网站。
希望这会有所帮助。
【讨论】：
- 不要让事情以不同于用户期望的方式工作（即在 Web 表单中使用 Ajax 时打破“返回”按钮
- 遵循 K.I.S.S 原则
真的，有人发布的任何规则都是主题的变体： 不要让用户思考
“别让我思考”已经发布，另请参阅 Design of Everyday Things 和 Designing with Web Standards 也非常适合轻度可用性阅读。
【讨论】：
避免modes。当输入有时有效但有时无效，或者在不同时间做不同的事情时，用户会感到沮丧。
【讨论】：
我要给别人的最重要的一条建议是首先处理 UI。笔和纸等等。这样一来，您就不会下意识地将按钮与函数、输入字段与变量等耦合。
最好的 UI 可能会让人难以编写代码，如果您的后端代码大部分是编写的，那么它会破坏您的思维。
除此之外，我会指向Apple's Human Interface Guidelines。当然，如果您的平台不是 OS X，请使用带有大量盐分的 OS X 部分。适用于 OS X 的功能可能不适用于 Windows。您应该接受您平台的惯用语。
除了 OS X 的东西，该文档在基础方面有一些很好的起点。
【讨论】：
这里有一些简单的规则：
- 点击次数越少越好。
- 应该更容易找到常用功能。
- “高级”用户的功能可能比上述功能更难找到。
想想用户点击鼠标/键盘的次数。
PS - 请不要告诉 Microsoft Office 2008 人员这件事；可怜的小家伙今晚会哭着入睡！ :)
【讨论】：
想想将使用您的应用的用户。他们为什么使用它以及在什么情况下使用它？
- 大多数是专业用户吗？他们知道应用程序所在的领域并经常使用该应用程序吗？然后不要害怕向屏幕添加大量数据，只要它为用户按逻辑排列（通常不是按字母顺序 :-)。想想股票经纪人或飞机驾驶舱的交易屏幕。
- 用户是临时用户吗？把事情简单化。避免上下文切换（每次都在屏幕上保留所有/尽可能多的必要数据）。不要打破对 gui 小部件正常工作方式的期望。为失败而设计。
- 介于两者之间吗？允许用户在 UI 中成长。跟踪使用情况，以便您以后确定用户似乎花费最多时间的地方，从而改进应用中最常用的区域。
- 在朋友和同事身上测试您的应用（走廊测试），看看他们是否能够有效地使用它。
这是一个开始。
【讨论】：
我建议从Enso 创建者那里阅读这些blog posts。
当然，他们会重复诸如
The Design of Everyday Things 和 About Face 等书籍中的指南/想法/建议，但尽管如此，这些帖子包含了很多见解，并且 (IMO) 值得一读。
【讨论】：
您的用户需要什么信息，将其显示在屏幕上，仅此而已。如果您无法定义用户的需求 - 获取另一个用户。
【讨论】：
请记住，您的应用程序将是用户必须处理的众多应用程序之一。不要做事只是为了与众不同或 kewl。不要想出不寻常的图形、行为、术语或交互。使用标准的操作系统控件、约定、实用程序和行为。
让您的应用与其他应用互操作；允许剪切和粘贴数据，以其他应用可以读取的格式保存您的数据，并允许从其他应用导入数据而不是使用您的 UI。
如果您正在制作桌面应用程序，请不要试图接管用户的计算机。保留用户的 Documents 文件夹、任务栏和应用程序首选项。不要更改计算机上已安装的任何内容。允许脚本或命令行交互。
如果您正在制作网络应用程序，请不要尝试接管浏览器。不要试图颠覆标准的菜单栏、历史、布局或字体。允许用户使用 Javascript 更改页面。
【讨论】：
(1) 共同的行动应该尽可能少的努力并且应该是显而易见的；另一方面，很少需要的操作可能需要很多步骤，并且可以隐藏在菜单和对话框后面。为此，您应该始终通过列出用例来描述用户希望对应用程序执行的操作。
(2) UI应该是自记录的。该手册应集成在应用程序的对话框和菜单中，因为用户无需阅读单独的手册。例如，键盘快捷方式应显示在代表与其关联的操作的菜单项中。
【讨论】：
为高级用户提供键盘快捷键（即使它像“按回车键搜索”一样简单）
不要一次在屏幕上放太多。
如果您弹出一个消息框，您的用户通常不会阅读它。
【讨论】：
除了此处的其他建议外，我还推荐 Designing Interfaces by Jenifer Tidwell 作为熟悉 UI 约定的好方法。
此外，The inmates are running the asylum By Alan Cooper 非常适合深入了解如何进行交互设计。
【讨论】：
Don't Make Me Think 的一个很好的后续是 Robert Hoekman 的 Designing the Obvious。它更侧重于 Web 应用程序，而不是像 Krug 那样的网站。
【讨论】：
- 简单胜于复杂
- 复杂胜于复杂（消除“嵌套 if”）
- 直观（好的元素无需解释）
- 遵守约定（例如，下划线表示链接，红色表示错误，标签转到下一个字段等）
- 使用语义来应用逻辑（首先读取标题，然后读取段落）
- 空白很重要
【讨论】：