虽然有人可能会合理地认为销售是任何组织的命脉 (特别是如果你负责报告损益)，但客户参与度至少是一个主要的促成因素。当企业有兴趣创造或提高客户与他们自己之间的互动水平时，应该怎么做？
传统问题
当主要 “产品” 由服务组成时，企业会创建他们认为可以满足用户需求的应用程序。带着最好的意图，召开会议，做出决定，收集需求，编写代码。令内部大张旗鼓的是，该应用程序已发布，并且自信的产品所有者焦急地等待，希望大规模参与。为了确保客户知道应用程序的存在，营销人才被带到承担-发送邮件，发布新闻稿，参加会议，并赠送t恤。
传统结果
接下来发生的事情太普遍了。该应用程序满足了业务需求，似乎应该满足客户的需求，但没有。由于某种原因，用户不感兴趣，下载下降到报告他们变得尴尬的程度，最终，应用程序停止支持并消失了。为什么会这样？
用户体验解决方案
与看似显而易见的解决方案相反，推动大规模参与的关键不是创造一种方法，让用户告诉企业他们想要什么。虽然这可能足以推动增量改进，但用户只能表达他们的明显需求: “我想访问我的服务”，“我想能够支付我的账单”，“让我很容易看到我的覆盖细节。” 这些都是很好的和明显的功能，用户认为他们想要的，但还有另一组需求-潜在需求-定义特性和功能，将改善用户的生活方式，他们无法描述或要求。
用户体验研究
下一个问题是，既然用户无法表达他们潜在的需求，我们怎么知道它们存在呢？假设它们存在，我们如何希望定义它们？这两个问题的答案都是用户体验研究。通过采用现场观察 (一种称为阴影的技术) 和智能访谈 (一种称为上下文查询的技术)，经验丰富的UX团队能够识别关键用户组，定义现有的工作流程，任务频率，重大瓶颈和问题区域，设备使用情况等。本质上推断用户的潜在需求。基于这种理解，他们可以将这些信息协调成一组统一的陈述需求和潜在需求，完全定义用户专业环境中的问题区域。这组协调的需求定义了用户愿意参与业务的空间。因此，参与度仅限于解决方案解决用户问题的程度。
用户体验流程和可交付成果
我做了一些粗略的假设，以显示这样的研究项目对于B:B应用程序可能是什么样子，例如为医疗专业人员设计的保险应用程序。请记住，任何或所有这些都可以修改，并且不需要按顺序发生，这取决于情况和业务需求。
小型办公室研究人员 (3人)
- UX团队上门服务2天
- 有一天协调调查结果
中型办公室研究人员 (10人)
- UX团队上门4天
- 两天协调调查结果
大型办公室研究人员 (10人)
- UX团队现场8天
- 三天协调调查结果
可交付成果
- 用户配置文件/角色
- 工作流/旅程地图
- 信息需求 (按用户类型
- 频率使用指标
- 推荐的应用程序格式 (web、移动web、本机web)
- 应用程序线框
- 全美学设计
- 前端开发
)
UX过程几乎是无限可塑的。最终，它归结为了解与您如何花费研究资金相关的风险，您的UX团队的经验以及时间，金钱和代表性样本量之间的关系。客户参与是关于主动了解客户需要什么，以及如何在正确的时间以最有用的格式提供它，而不是被动地处理功能请求列表。
设计在Infragistics
在Infragistics Consulting这里，我们为提供周到和有用的设计而感到自豪。完成工作并不等同于把工作做好，我们为小事流汗，因为这很重要。让我们向您展示我们如何通过services@infragistics.com与我们联系来提供帮助。
</p