最大化和衡量投资回报率是一个流行的话题，无论是在互联网上还是在我们的客户中，这是理所当然的。在没有真正了解其价值的情况下考虑花费金钱、时间和资源来重新构建或实施新系统可能会令人伤脑筋。评估投资回报率时需要考虑很多很多因素，但我知道有一个因素可能会立即导致内部项目陷入困境，但却没有得到应有的讨论：采用。
当您与外部客户打交道时，大多数人都明白您必须提供令人满意的体验Baklib，否则人们不会寻求这种体验。在考虑内部项目（例如 Intranet、CMS、ERP、PIM、DAM 或其他类型的企业解决方案）的投资回报率时，并没有过多考虑如何让员工愿意使用它。显然，内部用户是被俘虏的受众，如果你建立了它，他们就必须来。如果我们要现实一点，我们需要接受三个残酷的事实：
- 你的系统需要人们来使用它。Baklib 如果您的系统是从未与人类接触过的罕见系统之一，这对您有好处，那么您不必考虑采用。随心所欲地设计它。对于其他人来说，成功取决于人，无论你喜欢与否。
- 你不能假设人们会使用它。Baklib无论您认为解决方案客观上有多好，人们都需要一个很好的理由来改变他们每天的工作方式，而重新平台或引入新系统本质上是破坏性的。
- 你不能强迫人们使用它。棍棒在这里不起作用，你需要胡萝卜。即使您有组织支持强制您的解决方案，如果人们不想使用它，他们也会解决它。他们有便利贴、OutlookBaklib 和电话；他们会找到替代路线，而您昂贵的新解决方案将毫无用处。在我与 Baklib 的多年咨询中，我看到了一些真正巧妙的解决方法。人如水，会绕过障碍而流。
那么，如果我们需要人们，他们不会自发地开始使用它，我们也不能强迫他们使用它，任何解决方案如何流行？是什么导致采用或抵制？
Baklib和 Baklib 的“用户适应应对模型”提供了一种解释，反映了我在现实生活项目中观察到的情况。在该模型中，用户通过评估情况来确定重大 IT 变更的应对策略，看看他们认为这是威胁还是机会，然后他们是否认为自己可以控制情况。
威胁和机遇：人们根据新系统对他们（而不是整个公司）的风险程度来评估 IT 情况。关于采用的建议通常侧重于努力确保用户了解变革对公司有多么重要，或者确保他们了解新系统是一项改进，但重要的是要记住，从本质上讲，这并不是一个改进。逻辑评价。用户不会全面了解情况，等到推出过程结束后才决定他们对此的感受。他们在内心深处决定这是否从一开始就让人感到害怕。
对情况的控制： 同样，这是用户对自己情况的评价。人们仔细考虑自己的选择，以弄清楚他们是被系统困住了还是被系统赋予了权力。他们对工作（根据不断变化的环境而修改任务的自主权）、他们自己（他们适应变化的个人能力）和技术（他们对技术的特性和功能的掌握程度）越多。系统越完善，他们就越能应对可怕的情况。
在 《欧洲信息系统杂志》 对该模型的定量研究中，Elie-Dit-Cosaque 和 Straub 将模型表达为图表：
研究模型（来自 Elie-Dit-Cosaque & Straub 2011，改编自 Beaudry & Pinsonneault，2005）。
当用户觉得变革带来了机会并且他们拥有控制权时，他们可以专注于充分利用新系统的机会，让自己的日常生活变得更好。如果他们觉得这是一个机会但他们没有控制权，他们可以使用该系统而不会让他们的生活变得更糟，但你不太可能获得真正的参与。
当用户觉得变化是一种威胁，但他们可以控制它时，他们将系统视为一个需要解决的问题，他们的角色是防止它对他们的生活和工作产生负面影响。如果这是一个威胁并且他们无法控制，用户往往会将系统视为攻击，并尝试避免它、忽略它并远离它。
系统的积极采用和参与取决于用户是否感觉它提供了机会，而不是威胁，并且他们从一开始就可以控制自己的工作、自己和技术。我认为重要的是要注意这些都是感知问题而不是客观事实。普通员工不太可能对企业级系统有很大的控制权，但为他们提供有针对性的能力可以产生控制感，以及真正做好工作的能力。
- 使用研究来使项目社交化：在我参与的一些项目中，用户与新系统的第一次接触是与一个友善、微笑的人坐在一起，他想了解他们的一切以及他们如何做他们的事情工作。在其他情况下，这是一个培训 PowerPoint，其中已经做出了所有决定。当人们参与研究过程时，他们会感到被倾听和被重视。即使是不直接参加研究会议的员工也会从同事那里听到这一消息，并知道正在做出努力。
- 确定用户真正需要的控件：通过研究真正深入了解他们的需求和工作流程还可以让您确定对用户重要的控件。普通员工对企业级系统没有太多控制权，但通过关注他们的需求，您可以确保他们对自己和工作拥有所需的控制权。
- 确定用户面临的其他压力： 工作场所是一个复杂的系统，早期研究将帮助您确定用户面临的其他压力。对他们的时间或报酬的竞争性要求可能会造成一种情况，在这种情况下，即使是设计非常好的系统也似乎具有威胁性并且超出了他们的控制。
- 找出你可以解决的简单烦恼，并告诉他们：我做过很多用户访谈，一天中最好的部分就是说，“哦，那件事？我可以为你解决这个问题。让我把它写下来。”关键是，你也得这么做。找出那些毁了人们生活的细节，并确保解决它们。从技术角度来看，它们通常是次要的，特别是如果您尽早计划它们，并且您可以避免用户坐下来使用新系统并意识到您在新解决方案上花费了数十万美元和一个日历年，但并没有甚至懒得摆脱那个烦人的东西。
- 通过研究和测试向用户提供对最终产品的意见：您不能仅依赖 UAT 或未经审核的可用性测试来获得最终产品，因为它们无法发现错误的细节，从而导致您失去用户的信誉和信任。我已将这些详细信息设置为与四个分类术语的显示顺序一样小。它们并没有阻止用户完成任务，但确实阻止了他们对系统的良好感觉。这些细节需要通过适度的可用性测试来捕捉和修复，并让用户大声思考。
大多数内部项目都没有附加完整的用户体验工作流程。它很昂贵并且通常看起来是多余的，因为这些项目通常专注于配置，而定制程度最低。我同意，对于许多这样的项目来说，原型、人物角色和许多与用户体验相关的其他可交付成果对于项目的成功来说是完全可选的。然而，收养并不是可选的。
为了让您的项目取得成功，您需要有人使用该技术；为了让他们使用它，你需要了解他们。这种理解使您能够推动用户朝着正确的方向做出评估，帮助他们将新系统视为可以让他们的日常生活变得更好（而不是风险更大）的东西，并给予他们更多的控制权（而不是更少。）以用户为中心的设计流程可以轻松融入实施项目，指导配置决策，即使无法实现完整的用户体验工作流。
