0

我最近与团队就我们最近的软件项目的 UI 设计进行了一次大讨论。

我们需要将一个特殊的版本控制系统集成到我们现有的产品中，这是一个软件测试工具，用于通过编写和回放测试脚本进行测试。

设计团队提出了一个我不能同意的设计，并认为它违反了基本的设计规则。

从我的角度来看，设计的最大问题是他们在我们现有的 UI 中添加了版本控制特殊的东西（比如创建视图、签入/签出脚本）（实际上是复制现有的 UI 并将其更改为另一个并添加一些东西） ）。例如，在我们的 Open Project 对话框中，复制 UI 然后添加两个按钮来触发特殊的版本控制（就像在打开脚本之前一样。必须有一个包含项目源代码的版本控制视图）。

我与设计团队争论了很多，认为将不同的东西放在一起是一个坏主意，在我们的示例中，软件测试工具功能和版本控制脚本功能。我解释说这样做会出现重复的用户界面，同样要解决更多的情况，维护也是大问题。而且我更喜欢将两者与 UI 分开，一个 UI（对话框或向导）应该只关注两个不同事物中的一个。

我总结为一个 UI 设计原则，“一个 UI 不应该包含两个完全不同的东西”。虽然他们认为，他们想要付出这样的努力和所有的努力（比如更多的用户界面，更多的用户界面需要解决的情况，与分离两个不同事物的用户界面设计相比，更多的开发/测试/维护工作），为用户获得一个易于使用和良好的可用性软件。当然，我完全不同意这样的说法，一个其他方面都不好的软件怎么可能对用户好呢？由于设计团队还没有完整的设计，因此没有什么可衡量的。

最终我无法说服团队。一切似乎仍然是客观的。

这让我想到，是否有任何好的 UI 设计指南/最佳实践/原则涵盖我们的情况（区分不同的关注点，详细调试/运行脚本需要和需要版本控制脚本，而不是将它们放在一起一个特殊的 UI、对话框或向导等。）

我将不胜感激任何与整个问题相关的评论和建议，而不是针对上述问题。我也将回答我在这里没有很好地表达的任何内容。

请不要关闭这个:) 作为开发经理，这对我来说确实是个大问题。

4

2 回答 2

1

我同意@JanNeilson 的观点，即设计原则不会帮助您说服开发人员更改 UI 设计。

有效的是可用性测试。看着一些用户在尝试使用该软件时遇到困难，这会让开发人员感到不安并想要修复 UI。另一方面，如果您看到真正的用户可以很好地使用新软件，那么没有问题，设计原则也无所谓。

可用性测试可以是一个正式的过程，您可以将客户带入实验室，要求他们使用您的软件执行特定任务，并记录用户和屏幕的视频。

重要：一定要告诉测试用户你不是在测试他们；您要求他们帮助您测试软件。说明如果他们不喜欢该软件，您不会被冒犯。你想要诚实的反应。定期要求他们说出他们的想法，即在他们弄清楚要做什么时“大声思考”。除非他们完全陷入困境，否则不要回答他们的操作方法问题。

可用性测试也可以是一个非正式的过程，您可以在其中随机邀请一些同事进行尝试。我在自助餐厅做过这个，只是向一些同事展示了一个新的 UI，并询问他们认为一些新图标的含义（代表）。

在每次测试期间或之后做笔记。您可以让开发人员在之后观看录制的视频（编辑掉等待的部分，以便开发人员将其全部观看），或者在测试期间从另一个房间观看视频。或者如果没有视频，您可以一次将一名开发人员带入房间观看，但请他们坐在他们的手上。开发人员在回答用户问题之前必须先说“对不起，我构建了如此糟糕的用户界面”。

如果您的软件还没有准备好进行此测试，您可以使用纸质模型进行可用性测试。

有一个专门用于可用性测试的领域。有训练有素的专家。您可以请有经验的顾问来做，也可以自己学习并尝试。

网络搜索会出现许多文章和书籍。这是一篇非常好的文章开头： http ://alistapart.com/article/usability-testing-demystified

维基百科关于可用性测试的第一段说：

可用性测试是一种在以用户为中心的交互设计中使用的技术，通过对用户进行测试来评估产品。这可以被视为一种不可替代的可用性实践，因为它可以直接输入真实用户如何使用系统。这与可用性检查方法形成对比，其中专家使用不同的方法来评估用户界面而不涉及用户。

我添加了斜体。换句话说，没有可用性测试就无法获得良好的可用性。相比之下，让专家使用原则和经验来评估 UI 会有所帮助，但不是必需的。

于 2014-03-09T17:21:09.587 回答
0

您在这个问题中涉及了几个不同的方面；我将专注于UX的管理。

我没有争论“关注点分离”之类的一般性，而是从用户体验的角度以及更抽象或一般的概念来回顾特定 UI 设计的具体问题。为此，您需要一个 UI 模型。在 UI 模型之前，您将需要一组基本的 UI 意图描述，这些描述将驱动 UI 模型。一旦你有了 UI 模型，你就可以讨论 UI 的用例，并强调为什么由于关注点分离或其他特定原则而关注 UX 问题。

根据我的经验，争论一般性是无效的，因为理解它的人不需要听到它，而那些不理解它的人需要模型有足够的上下文来理解。

如果您担心构建 UI 模型所需的资源，您可能会考虑对工作进行时间限制，例如，“花 3 个小时将 UI 模型放在纸上，让我们回顾一下”。

于 2014-03-09T05:18:00.357 回答