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 回答