我可以使用哪些 UI 设计原则(如 "separation of concerns")来说服开发人员 UI 需要修复?



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

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

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

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

我和设计团队争论了很多,认为把不同的东西放在一起是个坏主意,在我们的例子中,软件测试工具功能和版本控制脚本功能。我解释说,通过这样做会产生重复的UI,而且更多的情况是为了解决同样的问题,也是维护的大问题。我更喜欢将两者从UI中分离出来,一个UI(对话框或向导)应该只关注两种不同事物中的一种。

我总结了一个UI设计原则,"一个UI不应该包含两个完全不同的东西"。虽然他们认为,他们希望付出这样的努力和所有的努力(比如更多的UI,更多的UI需要解决的情况,与将两种不同的东西分开的UI设计相比,更多的开发/测试/维护工作),让用户获得一个易于使用和良好可用性的软件。当然,我完全不同意这种说法,一个其他方面都不好的软件怎么可能对用户有好处?并没有什么可以衡量的,因为设计团队还并没有完整的设计。

最后我无法说服球队。一切似乎还是客观的。

这让我思考,是否有任何好的UI设计指南/最佳实践/原则涵盖了我们的情况(通过不将它们放在一个特殊的UI、对话框或向导等中,来区分不同的关注点,详细地调试/运行脚本需求和版本控制脚本需求。)

如果有任何与整个问题有关的意见和建议,我将不胜感激。我也会回答任何我在这里表达不好的问题。

请不要关闭这个:)作为一名开发经理,这对我来说真的是个大问题。

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

有效的是可用性测试看着一些用户在尝试使用该软件时陷入困境,会让开发人员感到不安,并希望修复UI。另一方面,如果你看到真正的用户可以很好地使用新软件,那么就没有问题,设计原则也无关紧要。

可用性测试可以是一个正式的过程,你把客户带到实验室,让他们用你的软件完成特定的任务,并录制用户和屏幕的视频。

重要信息:请确保告诉测试用户您没有测试他们;你要求他们帮你测试软件。解释一下,如果他们不喜欢这个软件,你不会被冒犯。你需要诚实的反应。定期让他们说出自己的想法,即在他们想好该做什么时"大声思考"。除非他们完全陷入困境,否则不要回答他们的操作问题。

可用性测试也可以是一个非正式的过程,你可以让一些随机的同事来尝试。我在自助餐厅做过这件事,只是向一些同事展示了一个新的UI,并询问他们认为一些新图标的意思(代表)是什么。

在每次测试期间或测试后立即记下笔记。您可以让开发人员在之后观看录制的视频(编辑掉等待的部分,以便开发人员可以观看全部视频),或者在测试期间在另一个房间观看视频。或者在没有视频的情况下,你可以一次带一个开发者到房间里观看,但要求他们坐在自己的手上。开发人员在回答用户的问题时必须首先说"对不起,我构建了一个糟糕的用户界面。">

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

有一整个领域致力于可用性测试。这里有训练有素的专家。你可以聘请经验丰富的顾问来做这件事,或者了解并自己尝试。

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

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

可用性测试是一种用于以用户为中心的交互的技术通过在用户身上测试来评估产品的设计。这一点可以看出作为一种不可替代的可用性实践,因为它在真实用户如何使用该系统。这与可用性形成对比检查方法,专家使用不同的方法来评估用户界面,而不涉及用户。

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

您在这个问题中谈到了几个不同的方面;我将专注于用户体验的管理。

我没有争论"关注点分离"之类的笼统问题,而是从用户体验的角度以及更抽象或一般的概念来审查特定UI设计的具体问题。要做到这一点,您需要一个UI模型。在进行UI实体模型之前,您需要一组基本的UI意图描述,这些描述将驱动UI实体模型。一旦你完成了UI模型,你就可以讨论UI的用例,并强调为什么用户体验问题是值得关注的,因为关注点的分离或其他特定原则。

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

如果你关心构建UI模型所需的资源,你可以考虑将精力集中在时间上,例如,"花3个小时把UI模型放在纸上,让我们复习一下。">

最新更新