0

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

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

但是，用例有许多缺陷，其中大部分与它们包含技术细节（如 UI 等）这一事实有关，如这里所示。但是，由于我们不能使用用户故事和完全交互的设计，我决定妥协：我将使用基本用例来隐藏这些细节。

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

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

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

2 回答 2

2

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

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

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

于 2010-04-16T22:29:31.330 回答
1

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

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

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

请参阅http://www.cs.helsinki.fi/u/salaakso/papers/GUIDe.pdf上的较长过程描述

于 2010-04-16T23:13:49.483 回答