我可以使用哪些 UI 设计原则（例如“关注点分离”）来说服开发人员 UI 需要修复？[关闭]

Question

关闭. 。这个问题需要多问 专注的. 。目前不接受答案。

---

想要改进这个问题吗？ 更新问题，使其仅关注一个问题 编辑这篇文章.

关闭 5年前.

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

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

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

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

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

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

最终我无法说服团队。一切看起来还是客观的。

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

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

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

Answer 1

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

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

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

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

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

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

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

有一个完整的领域致力于可用性测试。有训练有素的专家。你可以请有经验的顾问去做或者自己了解并尝试。

网络搜索可以找到许多文章和书籍。这是一篇非常好的文章：http://alistapart.com/article/usability-testing-demystified

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

可用性测试 是一种以用户为中心的交互作用设计的技术，可以通过对用户进行测试来评估产品。这可以看作 不可替代的可用性实践， 由于它给出了真实用户如何使用该系统的直接输入。这与可用性检查方法相反，专家使用不同的方法评估用户界面而无需用户。

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

Answer 2

您涉及这个问题的几个不同方面；我将把重点放在管理上 用户体验.

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

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

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