通常的做法是使用案例研究，构建工作和数据流等。但这并不一定会在用户/赞助者与分析师-设计者之间创建一个共享的词汇表：通常，一个或者另一个都必须获取术语并对其他专业领域的"内部人员"的看法，这通常会导致误会和澄清的会议(输入RAD技术，例如"进化原型")等。

用户/赞助者专注于他/她的需求/环境，并且不希望也不应被迫获取与他们无关的"编程术语"。分析人员/设计人员(/程序员)负责学习新的环境。

我们如何克服学习曲线？当我们遇到需要软件解决方案的用户时，什么对我们有效？

解决方案

一个好的交互设计师应该能够以通俗易懂的方式描述软件的工作原理。如果没有，他不应该做前端，恕我直言。

尝试消除用户和最终实施者之间的尽可能多的中间步骤。每一个这样的步骤都会使信息模糊不清并丢失信息。我们团队中最有价值的成员可能是既可以与用户穿着两套西装的"界面"，又可以实际实施的人。

如果没有，请确保我们有快速迭代并迭代地实现。容易将其与增量混淆。不同之处在于，通过迭代方法，我们可以以较小但统一的程度实现广泛的功能。在增量方法中，我们一个接一个地实现了大量功能。

在迭代方法中，我们具有敏捷性的优势。用户改变了主意，还是有些误解？没问题，仍有改变的空间。即使希望，也不会花费太多的精力。

这需要多种技术，并且双方都需要学习在某种程度上理解对方的业务：即分析师必须了解用户的领域，并且用户必须熟悉分析师的某些技术。

我发现流程流是一个很好的开始方式，可以在高层达成业务运作的共识。一些用户擅长数据模型(例如ERD)，但我通常会说它们不是：当规则以文本形式(例如

• 订单可以包含一个或者多个订单行
• 每个订单都有一个唯一的10位数参考编号

与对ERD进行质量检查相比，他们可以更轻松地阅读，打勾或者交叉这些内容。

接下来，没有什么能比输入屏幕和报告的草图更好地吸引用户关注他们想要的细节了。

我用评论

"如果我们无法向女服务员解释物理学，那不是很好的物理学"和"除非我们能向祖母解释，否则我们将无法真正理解某些东西"(归因于卢瑟福和爱因斯坦)

当我与客户讨论需求时，这是口头禅。

采用两种方法，一种高级的Powerpoint或者白板演示，如果可以让用户在POC或者模型上放松一下。

然后按行做详细的需求。细节决定成败。让他们签署这些详细信息。给它们加上标签并编号，以便他们可以逐行进行分析。

如果我们在进行高级设置之前执行了详细的要求，则用户将永远不会掌握设计中的任何概念，也不会陷入最微小的详细规格中。没有任何框架或者概念，用户将绕着针头上的多个天使旋转。

只要客户和开发团队可以使用相似的语言，敏捷性和迭代性就很好。确保设定并满足期望。