沟通差距：用户与分析师-设计者

Question

通常的做法是使用案例研究、构建工作流和数据流等。但这并不一定会在用户/发起者和分析师-设计者之间创建共享词汇表：通常，一方或另一方都必须获得对方专业领域“内部”的术语和观点，这通常会导致误解和澄清会议（进入 RAD 技术，如进化原型）等。

用户/发起人专注于他/她的需求/环境，并且从他们的角度来看，不想也不应该被迫获取不相关的“编程术语”。学习新环境的责任在于分析师/设计师（/程序员）。

你如何克服学习曲线？当您面对需要软件解决方案的用户时，什么对您有用？

Answer 1

尝试消除尽可能多的 中间步骤 尽可能在用户和最终实施者之间进行。每一个这样的步骤都会掩盖并丢失信息。你的团队中最有价值的成员可能是那些能穿的人 两套西装 - 与用户“接口”，并实际执行该操作。

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

在迭代方法中，您具有以下优势 敏捷。 用户改变主意了，还是有什么误会？没问题，还有改变的空间。甚至希望没有花费太多努力。

Answer 2

我用的是评论

“如果你不能向酒吧女招待解释你的物理学，那么它就不是很好的物理学”和“除非你能向你的祖母解释它，否则你并没有真正理解某些东西”（出自卢瑟福和爱因斯坦）

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

采取双管齐下的方法，高级的 Powerpoint 或白板演示，以及是否可以让用户放松地使用 POC 或模型。

然后逐行做详细的要求。细节决定成败。让他们签署这些细节。对它们进行标记和编号，以便他们可以进行逐行分析。

如果您在高级设置之前完成详细的需求，那么用户将永远无法掌握设计中的任何概念，并陷入最微小的细节规范中。在没有任何框架或概念的情况下，用户将围绕大头针头上的天使数量旋转。

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

Answer 3

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

Answer 4

这需要一系列技巧，双方都需要学会在某种程度上了解对方的业务：IE。分析师必须了解用户的领域，而用户必须熟悉分析师的一些技术。

我发现流程是一个很好的起点，可以在高层就业务运作方式达成一致。有些用户擅长数据模型（例如 ERD），但一般来说我会说他们不擅长：当规则以文本形式阐明时，他们通常会做出更好的反应，例如

• 一个订单可以由一个或多个订单行组成
• 每个订单都有一个唯一的 10 位数参考号

他们可以比检查 ERD 的质量更容易地通读、勾选或交叉这些内容。

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