发展的 2022 年,现代企业应用如果想一直蓬勃发展下去就需要关心终端用户的感受。现在,许多企业级应用程序公司都在使用曾经为消费者保留的 UX(消费级用户体验)概念,这是有原因的。实现这一概念的公司,在终端用户采用率、终端用户支持、工作流效率、市场份额和收入方面,一直优于那些乏味的竞争对手。
在很早的时候(即 2000 年代早期),人们并不认为企业应用 UX 是重要的销售驱动力。经理们查看功能表,比较不同服务的成本,仔细权衡利弊,最后看哪个销售员动作快就买谁的。用户会接受,因为这是他们老板的决定,过程基本就是这样。
但 2010 年前后事情发生了变化。Slack 推出后,很快就在 2014 了超过了当时占据颇大市场份额的 Atlassian 的 Hipchat(这伙人还做了 Jira)。许多其他公司(Dropbox、Asana 和谷歌等)也开始学 Slack:将为消费者提供更好用户体验的原则运用到企业应用开发中。
用户成为决策制定者。公司用加油站般的用户体验换取人们的依赖,其高明之处体现在两个方面。首先,用户在使用设计良好的系统时效率更高;其次,终端用户成为拥护者,会在其公司内部推荐采用他们喜欢的解决方案,尤其是当他们以前用过这些解决方案时。这些因素结合在一起,使这些品牌成为家喻户晓的专业品牌。以 Slack 为例,他们的产品名变成了动词。
通常,在以下两种情况下需要开展 UX 改造项目。首先是那些希望更好地服务客户的老牌企业,要么是新晋领导层带来了新理念,要么是更现代、更灵活的替代方案正在蚕食他们的市场份额。其次是那些快速增长的初创公司,他们一开始优化了实现速度,以证明他们的产品符合市场需求,随着他们越过早期采用阶段,设计债务越来越多,用户越来越不宽容。
在现有产品中实现消费级用户体验是一项资源密集型的、非常耗时的工作,并且存在相当大的风险(“为什么要改变一支冠军队伍?”)。决策者可能认为这样的投资纯属浪费,因为它们占用了开发新特性、提高软件质量和修复 Bug 的时间。
借助广泛的重新设计及多团队的长期规划,是有可能自上而下对用户体验进行改造的。然而,这需要强烈的组织意愿、高管层支持、前期投资及其他非必须的东西。我们的关注点不在这里。
我们关注的是任何团队今天就可以开始的事情:启动一场 UX 变革,一次一个迭代。实现这一目标主要有四个阶段:
了解现状。
设计一个可行的解决方案,并获得认可。
进行小规模试验。
迭代并乘势而上。
第一步是在开始之前了解业务、应用程序、当前的局限性和最终用户。你需要回答,客户是谁,你的最终用户,你卖给他们什么,他们的主要目标和关键任务,他们付给你多少钱,以及什么有助于降低成本。
许多优秀的消费级 UX 改造项目未能越过最初的概念阶段。尽管这可能是个悲剧,但决策者不一定是错的。我曾见过许多工程师、产品经理和设计师提出了理想的方案,但很快就加入了“可能”的行列,然后被遗忘了。这些提案主要有两个问题,它们要么不能解决实际问题,要么没有说商业语言。
合格的决策者总是想着更好地服务于客户,并在这个过程中从客户那里获得更多的价值。如果你想要吸引他们的注意并获得认可,就需要了解现状,并就 OKR、KPI、ROI、路线图等方面的变化展开讨论。
从了解业务、产品、客户、最终用户以及他们的痛点入手。一种方法是与产品经理、高级工程师、客户支持经理以及初创公司的创始人交流。问他们这样一些问题:你卖的是什么?谁会买?他们为什么要买?价格结构是什么样的?你提供这些服务的成本是多少?用户是谁?他们需要完成的主要任务是什么?
另一个有价值的信息源是数据。你需要分析两类关键绩效指标(KPI):落后或输出 KPI 以及领先或输入 KPI。第一类指标告诉你用户是否得到了他们需要的东西,第二类指标告诉你他们在这个过程中是否遇到了困难。
输出 KPI 的例子有净推荐值(NPS)、系统可用性评分(SUS)、给定时间内完成的关键任务数,以及每个关键任务的成本。领先 KPI 的一个例子是用户完成关键任务所需的时间(以及错误 / 拒绝率)。这两种类型的 KPI 你都需要。如果少了其中的一部分(或全部),那就从与团队合作入手开始跟踪。
建议:多花心思去获取与用户多么喜欢使用应用程序相关的 KPI。不要低估快乐的力量。Slack 早期与 Hipchat 的一个核心区别在于,用户找到并发送动画 GIF 的难易程度。
举一个真实的例子:我曾在美国一家快速发展的 AdTech 公司领导工程团队。该公司运营着一个 DSP(需求端平台)。客户是营销机构和拥有内部广告团队的大品牌。最终用户是他们的广告运营商和活动经理,他们使用我们的产品来创建数字化营销活动,跟踪活动进展,适时做出调整,并生成结果报告。主要的 KPI 包括创建活动的时间、分析新鲜度、生成报告的时间以及目标交付率。
推动项目前端工作的员工做得非常出色,并且特别注重提供卓越的用户体验,使我们赢得了 2015 年度用户体验人民选择奖。
下一步是设计一个可行的解决方案,并获得必要的决策者支持。首先,利用你的业务知识来确定最有可能产生巨大作用的最大挑战。通常,这些都跟滞后和领先 KPI 有关,并与最终用户必须执行的主要任务相一致。
选择你准备克服的最高 ROI 挑战并持续关注。成果定义了投资回报率(ROI),实现成本定义了投资。选择一个有意义的问题以便解决,选择一些可处理的问题以便交付,这至关重要。如果第一次迭代失败,整个过程就会失败。选择一个具体的问题,从现在开始,而不是经过漫长的计划和评审过程之后再开始。最后,确保这是一个双向决定——也就是说,如果事情出错,可以在不影响业务的情况下逆转。
选择了一项挑战后,便需要明确其最终用户,他们的痛点,以及需要改进的 KPI,并在此基础上设计一个讨人喜欢的最小解决方案。快速前进并适时调整的关键是构建 - 度量 - 学习迭代周期——构建一些东西,看看它在现实世界中的效果,汲取经验教训,重复以上过程。与此同时,因为你目的很明确,是要处理用户体验问题,所以方案不仅要可行还要讨人喜欢。
此时,应该基于对底层业务逻辑和最终用户需求出具可行设计。还应该针对有意义的 KPI 制定一个可衡量的目标。最后一步是获得涉众的认可。
为了将项目推销给需要他们提供支持的人(产品经理、工程经理、队友等)就需要讲一个好听的故事。从为什么开始:展示你正在解决的问题,以及为什么它们对于业务和当前目标来说很重要。然后跟进预期成果,解决方案将是什么样子,以及最终需要多少时间 / 金钱 / 人员来实现它。许多推销新业务的规则在这里同样适用。
建议:考虑变革的时机。在错误的时间提出以 UX 为中心的变革(例如,当团队正在处理一个重大的技术问题或正在进行安全审计时)可能会给人留下“低情商”的印象,并且可能无法引起所需人员的充分注意。充分发挥你的判断力,不过,最好的时机是在产品成功发布后,在季度计划期间,或在与产品经理一起喝咖啡时(永远不要低估 1 杯咖啡的力量),仅举几例。
在之前的例子中,我们发现,通过运营商投放广告的方法非常繁琐、单调且容易出错。运营商必须在短时间内投放几十个、或数百个广告,在此期间,即使一个小错误也会浪费大量的时间和金钱。我很确定,洛杉矶的餐厅不会想在澳大利亚做广告。
我们改进了表单的用户体验,增加了许多自动化操作,彻底改变了这个过程。我们将一些部分做成可选项,实现了多步骤过程,并添加了一些功能,如根据选中的国家限制搜索的城市,以及支持直接从客户那里批量导入广告配置。这些修改大幅缩短了广告及广告活动的投放时间,减少了投放错误和营销预算浪费,减轻了广告运营商的压力,提升了他们的幸福感。
至此,你已经了解了业务,设计了一个令人惊叹的解决方案,并获得了所需的支持。下一步就是执行了。
将第一次消费级 UX 修改看成一个试点项目。确保自己已经准备好跟踪所有必要的信息,尤其是试图改进的核心指标。使用类似 Google Analytics、Hotjar、Kissmetrics、Data Dog 等工具,尽可能自动化追踪过程。如果无法实现自动化,也不要让这个成为你前进的阻碍——找到手动跟踪所需数值的方法即可,重拾 Excel 也没关系,谨防瞎忙。
建议:定期从乐于相助的终端用户那里获取反馈,了解他们的定性观点。数值只能让你了解故事的一部分。你需要同时掌握定量和定性信息,才能了解正在发生的事。
推荐以旧版本为基准运行 A/B 测试。这样就可以与新旧版本进行比较,确保新设计有改进,或者是发现新设计的问题。
随着数据和终端用户的反馈开始进入,做好快速迭代的准备,不要让偏见影响自己的分析。理解数据的含义,并相应计划新一轮的修改。这些修改可大可小,视结果而定。或者,可以根据时间预算来计划,保证利益相关者了解情况,快速行动,维护变更日志,写明你正在做的事情以及那样做的原因。
在我举的例子中,我们一开始并没有这么早就引入批量广告导入功能的计划。在改造项目开展过程中,我们从运营商的反馈中了解到,改进输入流程非常好,但还不够,所以我们不得不将这一功能的进度提前。运营商在一些重要时刻(如第一次发起大型活动),之后他们就有了用于描述广告的半标准化格式。
试点完成后要总结经验教训。与客户和最终用户面谈,了解对你所实现的东西的总体看法。整理变更日志的信息,了解什么有效(什么无效),为什么有效以及为什么失败。掌握全貌才能确定这次变革是否成功,前进方向是否正确。
不管试点是否成功,也不管你是否达到了目标,都要向团队以及利益相关者介绍成果、经验,并做个总结。这可以帮助你积累信誉,为后续工作打下坚实的知识共享基础。
放眼全局,考虑更为系统性的变革。你从试点项目获得的知识,不只是如何在下一次迭代中做得更好,还包括可以扩展到整个应用程序的模式。着手创建一个总体愿景和工具集,将所有东西联系在一起,保证后续迭代的一致性。这可以包括通用的设计语言、一致的表单元素、快捷方式的使用、何时同步等待或运行后台作业,等等。
试点项目不是终点——它是变革的第一步。借助第一次迭代的势头,综合考虑本次迭代的经验教训,选择一个或多个高 ROI 挑战作为下一步的工作。这次推销起来会简单些,因为未知的东西少了。不要就此停住!
今天就可以启动一场公司范围的消费级 UX 变革。不要小题大做,也不要让“分析瘫痪症“束缚你的团队。从了解业务入手,针对一个影响大但可交付的场景设计一个解决方案,推销解决方案并获得所需的支持,开展一个数据驱动的试点项目,最后,借势创建一个愿景,解决下一个挑战。
当开始第一次 UX 改造迭代时,我们需求端平台(DSP)正处于一个非常关注技术的时期。每秒需要处理 100K 以上的事务,在几毫秒内运行复杂的规划和 ML 算法,创建每天可以处理数 TB 数据的分析管道——所有这些都要在启动预算范围内,而且是由一个小而勇敢的团队完成的。UX 不是我们的关注点,在这方面,跟上竞争对手的步伐就很满足了。我们的第一次试点测试改变了工程师和高管们的看法。
毫不夸张地说,这是点燃一场变革的火花。
作者简介:
Marcelo Wiermann 由一名软件开发人员转型为管理人员。他在该领域有超过 10 年的经验。他曾服务于拉丁美洲、欧洲和美国的公司,并帮助早期创业公司和上市公司建立组织、培养人才及开发软件。他帮助 AdTech 创建了每天处理数 TB 数据的高可用性 API 和数据管道,屡获大奖的区块链解决方案,以及每天服务于数百万用户的电子商务平台。在业余时间(几乎没有),Marcelo 热衷于在 The Mentoring Club 上为工程师、工程经理和企业家提供指导。目前,他担任 Delivery Hero(德国最大的科技公司之一)的高级工程经理,领导全球建议部门。
原文链接:
https://www.infoq.com/articles/spark-ux-revolution/
点击底部阅读原文访问 InfoQ 官网,获取更多精彩内容!
“华为 30 岁以下员工仅占 28%”上热搜;腾讯二季度净利润腰斩,员工减少超 5500 人;百度网盘回应人工审核用户照片|Q 资讯