我不是可用性专家，我真的不想成为其中的一员。
我只需要在编写用户界面时可以遵循的一小部分经验法则，以便我的产品具有良好的可用性。
起初我认为这个问题很容易回答“使用你的常识”，但如果它在我们开发人员中如此普遍，我们作为一个群体就不会以我们糟糕的界面而闻名。
有什么建议么？
allain
问问题
2158 次
16 回答
24
于 2008-09-09T01:15:08.573 回答
12
阅读史蒂夫·克鲁格 (Steve Krug) 的《不要让我思考》。这是一个很好的起点，也是一个简单的短读。
编辑：虽然这主要是为了网络可用性，但即使你正在做富客户端，它仍然是一个很好的阅读。
于 2008-09-09T01:03:17.493 回答
7
真的只有两件事：
- “当程序的行为完全符合用户的预期时，用户界面就是精心设计的”——引自 Joel Spolsky 的《程序员用户界面设计》
- 将您的设计呈现在用户面前。真正的最终用户是最好的，但对于轻量级、快速的反馈，你无法击败走廊可用性测试，即抓住一个同事。
如果你记住 Joel 的建议，并确保你得到关于你所做的任何事情的反馈并采取行动，即迭代，你就不会走得太远。我会赞同 Steve Krug 的Don't Make Me Think的推荐——这可能是我读过的最好的与工作相关的书，没有之一，它同样适用于桌面软件和网站。
希望这可以帮助。
于 2008-09-17T17:10:58.270 回答
5
- 不要让事情以不同于用户期望的方式工作（即在 Web 表单中使用 Ajax 时打破“返回”按钮
- 跟随 KISS 校长
确实，某人发布的任何规则都将是主题的变体： 不要让您的用户思考
“Don't Make Me Think”已经发布，另见 Design of Everyday Things和Designing with Web Standards，它们也非常适合轻量级的可用性阅读。
于 2008-09-09T01:04:49.300 回答
4
Avoid modes. It's frustrating to a user when input works sometimes but not others, or does different things at different times.
于 2008-09-09T02:21:55.777 回答
4
Here are some simple rules:
- Fewer clicks are better.
- Frequently used features should be easier to find.
- Features for "advanced" users can be harder to find than the ones above.
Think about the number of mouse/keyboard clicks it takes a user to get to something.
PS - please don't tell the Microsoft Office 2008 people about this; the poor little guys would cry themselves to sleep tonight! :)
于 2008-09-17T19:55:11.433 回答
4
我要给某人的最重要的一条建议是首先在 UI 上工作。笔和纸等等。这样，您就不会下意识地将按钮与函数、输入字段与变量等耦合。
最好的 UI 可能会让人难以编写代码，如果您的后端代码大部分是编写的，它会破坏您的思维。
除此之外，我会指出Apple 的 Human Interface Guidelines。当然，如果您的平台不是 OS X，请使用带有大量盐分的 OS X 部分。在 OS X 中有效的东西可能在 Windows 上无效。你应该接受你平台的习语。
除了 OS X 的东西，该文档在基础上有一些很好的起点。
于 2008-09-09T01:07:42.490 回答
1
考虑将使用您的应用程序的用户。他们为什么使用它以及在什么情况下使用它？
- 大多数是专业用户吗？他们知道应用程序所在的领域并经常使用该应用程序吗？然后不要害怕在屏幕上添加大量数据，只要它为用户按逻辑排列（通常不是按字母顺序 :-)。想想股票经纪人或飞机驾驶舱的交易屏幕。
- 用户是临时用户吗？把事情简单化。避免上下文切换（每次在屏幕上保留所有/尽可能多的任务所需数据）。不要打破对 gui 小部件正常工作方式的期望。设计失败。
- 中间有什么？允许用户在 UI 中成长。跟踪使用情况，以便您以后确定用户似乎花费最多时间的地方，从而改进应用程序中最常用的区域。
- 在朋友和同事身上测试你的应用程序（走廊测试），看看他们是否能够有效地使用它。
这是一个开始。
于 2008-09-17T07:37:47.290 回答
0
（1） 共同的行动应该尽可能少的努力，并且应该是显而易见的；另一方面，很少需要的操作可能需要很多步骤，并且可以隐藏在菜单和对话框后面。为此，您应该始终通过列出用例来描述用户想要对应用程序执行的操作。
(2) UI应该是自记录的。该手册应集成在应用程序的对话框和菜单中，因为用户无需阅读单独的手册。例如，键盘快捷方式应显示在代表与其关联的操作的菜单项中。
于 2010-03-12T09:18:04.137 回答
0
What information does your user need, put that on the screen and nothing else. If you cannot define what the user needs - get another user.
于 2009-10-10T02:14:37.570 回答
0
请记住，您的应用程序将是用户必须处理的众多应用程序之一。不要做事只是为了与众不同或 kewl。不要想出不寻常的图形、行为、术语或交互。使用标准的操作系统控件、约定、实用程序和行为。
让您的应用与其他应用互操作；允许剪切和粘贴数据，以其他应用程序可以读取的格式保存您的数据，并允许从其他应用程序导入数据而不是使用您的 UI。
如果您正在制作桌面应用程序，请不要尝试接管用户的计算机。保留用户的 Documents 文件夹、任务栏和应用程序首选项。不要更改计算机上已安装的任何内容。允许脚本或命令行交互。
如果您正在制作 Web 应用程序，请不要尝试接管浏览器。不要试图颠覆标准的菜单栏、历史、布局或字体。允许用户使用 Javascript 更改页面。
于 2009-10-10T02:40:07.363 回答
0
除了这里的其他建议外，我还推荐Jenifer Tidwell 的 Designing Interfaces作为熟悉 UI 约定的好方法。
此外，The inmates are running the asylum By Alan Cooper非常适合提供有关如何处理交互设计的见解。
于 2010-03-12T10:32:31.333 回答
0
为高级用户提供键盘快捷键（即使它像“按回车键搜索”一样简单）
不要一次在屏幕上放太多。
如果您弹出一个消息框，您的用户通常不会阅读它。
于 2010-03-12T09:25:46.240 回答
0
- 简单胜于复杂
- 复杂胜于复杂（消除“嵌套 ifs”）
- 直观（好的元素不需要解释）
- 遵循约定（例如，下划线表示链接，红色表示错误，标签转到下一个字段等）
- 使用语义来应用逻辑（首先读取标题，然后读取段落）
- 空格很重要
于 2010-03-12T09:48:18.413 回答
0
Don't Make Me Think 的一个很好的后续是Robert Hoekman的Designing the Obvious。它更专注于 Web 应用程序，而不是像 Krug 那样的网站。
于 2010-03-12T10:38:20.480 回答