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

Question

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

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

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

Answer 1

我用评论

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

当我与客户谈论需求时，就像咒语一样。

采取两管齐下的方法，一个高层次的，Powerpoint 或白板演示，如果你可以让用户在 POC 或模型上放松。

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

如果你在高水平集之前做详细的需求，用户永远不会掌握设计中的任何概念，并陷入最细微的细节规范中。没有任何框架或概念，用户将围绕大头针头上的天使数量旋转。

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

Answer 2

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

Answer 3

尽量消除用户和最终实施者之间的中间步骤。每一个这样的步骤都会掩盖和丢失信息。你团队中最有价值的成员可能是可以穿两套衣服的人——与用户的“界面”，并实际实施。

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

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

Answer 4

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

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

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

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

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