使用基本用例设计以 UI 为中心的应用程序 [关闭]答案

【问题标题】：Using Essential Use Cases to design a UI-centric Application [closed]使用基本用例设计以 UI 为中心的应用程序 [关闭]
【发布时间】：2010-04-16 22:08:15
【问题描述】：

我正在乞求一个新项目（哦，我多么喜欢新项目的新鲜味道！）我们才刚刚开始设计它。简而言之：应用程序是一个 UI，它使用户能够对执行流程进行建模（类似于 Visio 的拖放界面）。因此，我们最关心的是可用性和功能，它们将帮助用户快速清晰地建模执行流程。

我们建立的方法广泛使用用例，以便在程序员和用户之间创建和谐的应用程序视图。这确实是一个商业问题：我更喜欢使用带有用户故事而不是用户案例的敏捷方法，但我们需要定义一个明确的范围来向我们的客户销售产品。

然而，用例have a number of flaws，其中大部分与它们包含技术细节（如 UI 等）这一事实有关，就像here 一样。但是，由于我们不能使用用户故事和完全交互的设计，我决定妥协：我将使用基本用例来隐藏这些细节。

现在我有另一个问题：对 UI 交互有一个清晰的描述是必不可少的（不是双关语），那么，我应该如何记录它？换句话说，我如何通过使用 UI 交互对其至关重要的基本用例来指定应用程序？

我可以看到一些替代方案：

放弃使用用例，因为它们不能正确代表问题
不要在用例中包含接口描述，而是创建另一个文档（故事板）并链接到基本用例
在基本用例中包含 UI 交互描述，因为从用户和应用程序本身的角度来看，它们是业务规则的一部分

【问题讨论】：

标签： agile methodology use-case rational-unified-process

【解决方案1】：

通过 UI 原型获得用户反馈对于创建用户社区能够理解并高效使用的用户界面至关重要。执行此 IMO 的最佳方法是使用 paper prototyping。您的用例可以推动这些原型的初始创建，并且与您的客户的用户交互会话可以改进 UI 设计。

如果您更喜欢电子原型，您可以使用PowerPoint 之类的东西快速制作原型。

另见http://www.codinghorror.com/blog/2008/04/ui-first-software-development.html和http://www.codinghorror.com/blog/2007/01/low-fi-usability-testing.html

【讨论】：

@Harvey：很酷的原型制作技术。一个问题：您认为这些用例是否应该包含 UI 细节？
@Bruno：用例不应包含任何 UI 细节。它们应该只包含用户的目标。如何使用 UI 的细节是我们想要设计的。如果用例已经修复了其中的一些细节（如“UML 用例”通常有），我们将无法发明更好的方法来实现相同的目标。我使用的过程在cs.helsinki.fi/u/salaakso/papers/GUIDe.pdf 进行了描述

【解决方案2】：

首先收集有关用户工作流程和目标的信息。这最好通过亲自去看看用户今天的工作情况来完成（例如使用contextual inquiry）。将这些目标记录为基于目标的用例（请参阅下面的链接），其中仅包含目标 - 它们不应包含有关如何使用系统的任何细节，因为这些细节是我们刚刚开始根据用例。

根据用例，创建一个 UI 的快速纸质原型，并逐步尝试了解用户如何使用原型系统实现目标。如果 UI 原型不能很好地执行用例，请继续改进它，直到支持所有用例。向用户展示原型并使用可用性测试和其他技术来找出 UI 的问题。

当 UI 设计足够好（约 85% 准备就绪 - 一些精细的细节最好在实施后进行调整）时，您可以记录它，例如通过拍摄原型的图片序列，展示如何执行用例系统。但是与程序员交流 UI 设计最好是面对面进行，通过手动展示原型的工作原理并回答他们的问题。不要只是“把文档扔到墙上”，而是要坚持到底是如何实现的，并测试实现是否与设计相符。

在http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe.pdf查看更长的流程描述

【讨论】：