一个列表

菜单
吃东西是一种非常个人的体验,当然会被笨重的餐具毁掉。特别是当它们以包含许多您可能需要或不需要的其他特性而闻名的时候。

插图的Dougal麦克弗森

打破用户体验和开发人员体验之间的僵局

2013年初,小于14%所有的网络流量来自移动设备;今天,这个数字还在增长到53%。在世界其他地方,这种差异甚至更惊人:在非洲国家,超过64%的网络流量来自移动设备;在印度,近78%交通是流动的。这是件大事,因为所有 新增互联网用户2.48亿2017活过在美国以外

文章如下

当互联网连接越来越快时,目前仍有几十个国家的互联网接入低于2 Mbps的速度。即使在发达国家,人们在移动设备上看到参差不齐的覆盖,脆弱的WiFi连接,以及覆盖中断(如火车隧道或乡村道路)。

这意味着我们不能再谈论用户体验(UX)而不将性能作为首要需求。谷歌的一项研究发现53%的手机用户会在页面加载时间超过三秒后放弃该页面-没有人愿意失去一半的流量,正确的?

用户体验和性能在理论上是一致的

用户体验设计师和研究人员为构建现代Web应用奠定了坚实的基础。通过思考用户是谁,他们想要完成的,以及他们在使用我们的应用程序时可能处于的环境,我们已经发现了几个性能必需品:通勤者,例如,将从他们的手机或覆盖不均匀的低速公共WiFi连接访问应用程序。

对于这类用户,我们知道要关注快速加载时间,三秒钟或更长时间,我们将失去一半的访问者——除了一种有效的体验,即使是在不稳定的连接上。由于下载大量文件对这个用户来说也需要很长时间,减少我们发布的代码量也是必要的。

用户体验和性能在实践中存在问题

我的妹妹狗。有一次,作为一个孩子,她猛地抱住了我们的狗,非常爱它,以至于它惊慌失措,咬了它。

web社区与UX的关系就像我姐姐与狗的关系:我们正在尝试那么辛苦为了爱我们的用户,我们让他们痛苦。

我们在衡量和改进用户体验方面所做的努力充满了悲剧的、讽刺的、试图去爱我们的用户的尝试:我们试图通过用分析方法来增加用户体验来改善我们的应用程序体验,分裂测试行为分析,和净启动子得分弹窗。我们把插件放在第三方库之上,放在框架之上,以使网站“更好”的名义——不管它是否被误导了,就像添加一个旋转木马为了安抚某些高管的强烈愿望,让一切都“超支”,或者做一些真正想帮助别人的事情,像一个支持聊天覆盖。通常最终的结果是页面加载变慢,一个令人沮丧的经历,和/或(通常是“和”)大量额外的代码和资产转移到浏览器。

我们发送的信息是,“我们非常关心你作为用户的体验,所以我们愿意把它停下来,这样我们就可以问你关于它的问题,追踪你如何使用我们建造的东西!”

让事情变得更糟

我们不添加这种膨胀,因为我们是在故意破坏用户的体验;我们添加它是因为它由解决开发难题的工具组成,所以我们不需要重新发明轮子。

当我们添加这些工具时,我们仍在努力改善体验,但我们现在已经将注意力转移到了另一个用户:开发人员。有一个庞大的产品和工具生态系统,旨在使开发人员的生活更容易,将这些面向开发人员的工具放在术语下面是很常见的开发人员的经验,或DX

工具叠加可以解决我们的问题,但是这给我们的用户带来了很多问题。我们为帮助用户而采取的措施无意中使用户体验变差,这一悖论导致了Nicole Sullivan所说的“开发人员体验和用户体验之间的僵局”。

来自nicole sullivan(@stubornella)的tweet读到“更严重,我们需要后退一步,打破开发人员体验和用户体验之间的僵局。为什么他们之间有分歧?Perf:传输的文件大小和内存占用。好吧,那么我们怎么才能让它不存在呢?”
这个 Nicole Sullivan推特这篇文章的启发。

开发人员体验超出了技术堆栈

让我们谈谈烹饪经验(CX)。当我在家的时候,我喜欢烹饪。(坚持我;我有道理。)我有一个铸铁平底锅,煤气灶,还有一个我喜欢的准备区。如果你足够幸运,能在我的桌子旁吃一顿周末早午餐,这是你一生中最美味的早餐三明治之一。

然而,当我旅行时,我讨厌烹饪。airbnb的厨具通常是便宜的宜家(IKEA)平底锅、钝刀和加热不均匀的灶台,我不知道任何东西在哪里。每当我在这些环境中烹饪时,食物出来是可食用的,但肯定不是很好。

如果我需要自己的厨房来做一顿可食用的饭,这可能很有诱惑力。我只是不太会做饭。但实际上,高质量的工具和精心设计的环境在我的厨房在家里创造了一个更好的CX,这反过来导致我花更多的时间在食物上,更少的时间与我的工具斗争。

在劣质的厨房里,糟糕的CX意味着我无法专注于烹饪,因为我花了太多的时间来处理锅里的热点问题,或者在抽屉和柜子里找餐具。

优秀的开发人员体验就是有忘记的自由

像在做饭,如果我们的开发工具非常适合当前的任务,我们可以做得很好,而不必担心潜在的细节。

当我写HTML和CSS的第一行时,我用的是普通的旧记事本。没有语法高亮,自动更正,或任何其他可用的协助。只有我,参考书,还有一个游戏沃尔多在哪里?为了找到我忘记关上的标签。经验很慢,沮丧,和痛苦的。

今天,我使用的编辑器不仅提供语法高亮显示,还自动完成我的变量名,格式化我的代码,识别潜在的问题,帮助我调试我输入的代码,甚至让我分享我当前的编辑会话与同事一起帮助调试问题。现在存在着大量的增量改进,它们让我们忘记了微小的细节,相反,让我们专注于手头的任务。这些工具旨在把正确的事情简单化,引导开发人员在默认情况下遵循最佳实践,因为我们的工具是为我们的利益而设计的。

现代开发环境对我的生产力的影响再怎么强调也不为过。

这就是我的编辑器。

UX和DX是不一致的

没有一款适合所有人的应用程序,但是大多数开发人员工具都是用一种通用的方法构建的。为了使这项工作顺利进行,大多数工具都是为解决这个问题而构建的有一件事一般来说,例如日期管理或密码学。这个,当然,为了实现我们的目标,需要将多个工具叠加在一起。从DX的角度来看,这是惊人的:我们几乎总是可以找到一个开源的解决方案来解决那些不是特别针对我们所从事的项目的问题。

然而,为了改善我们的DX而堆砌了6个工具,这损害了我们应用程序的用户体验。为这个工具添加几千字节,对于这个工具,在我们意识到这一点之前,我们已经交付了大量的代码。在今天的前端环境中,看到应用程序发送数兆字节的javascript并不少见——只需打开浏览器开发工具的Network选项卡,当你注意到你最喜欢的网站向你的浏览器里倾倒大量的javascript时,轻轻地哭泣。

为福布斯网站开放的Chrome开发工具截图,显示在页面空闲30分钟的情况下,共下载了超过762个请求的10 mib javascript。
我离开福布斯网站开了三十分钟。它发送了3273个请求并加载了10mb的JavaScript。

除了使页面下载速度变慢之外,脚本对用户的设备造成了压力。对于使用低功耗手机的人(例如,一个廉价的智能手机,或者旧的iPhone)。下载时间只是查看应用程序的第一个障碍;下载后,设备必须解析所有的javascript。作为一个例子,大约需要1mb的JavaScript解析时间为6秒在三星Galaxy Note II上。

在3G连接上,添加1mb的JavaScript意味着在应用程序的下载和解析时间上增加10秒或更长时间。那是用户体验。

修补用户体验中的漏洞是有代价的

当然,我们可以解决其中一些问题。我们可以手动优化我们的应用程序,只加载我们实际使用的部分。我们可以找到库的轻量级副本来减少总体的包大小。我们可以增加绩效预算,测试中,如果代码库开始变得太大,其他检查会提醒我们。

但现在我们增加审计,编写定制代码来管理我们应用程序的基础,进入未知世界,不支持将不相关的工具连接在一起的领域,这意味着我们很难在网上找到帮助。一旦我们跳出已知的抽象用例,我们只能靠自己了。

一旦我们发现自己为我们的问题建立和管理定制的解决方案,我们以前享受的DX的许多好处现在都失去了。

好的用户体验往往需要不好的DX

有许多框架可以帮助开发人员在几乎没有开销的情况下启动和运行。我们可以开始构建应用程序,而不需要首先学习设置开发环境所需的所有样板和配置工作。这是一种流行的前端开发方法,通常被称为“零配置”,以表示启动和运行是多么容易,因为它消除了从头开始的需要。我们不需要花时间建立项目之间基本的代码,我们可以立即开始处理功能。

这是真的,一开始,直到我们的应用程序超出定义的用例,很可能会。然后我们就进入了配置优化的世界,transpilers代码,浏览器polyfills,和开发服务人员,即使是经验丰富的开发人员,这可能是非常压倒性的。

这些工具本身都是相对简单的,而是尝试学习如何配置六个新工具这样你就可以开始工作了是疲劳和沮丧的真正来源。作为一个例子,下面是在2018年从头开始一个JavaScript项目的感觉:

  • 安装节点和NPM;
  • 使用npm安装纱线;
  • 用纱线装胶,回来的,Babel(以及1-5个Babel插件和预设),开玩笑,ESLint,webpack,和PostCSS(加上插件);
  • 为Babel编写配置文件,开玩笑,ESLint,webpack,PostCSS;
  • 编写几十行样板代码来设置Redux;
  • 最后开始做与项目需求实际相关的事情。

这可以加上在项目之间设置几乎相同的样板代码所花费的全部时间。从零配置选项开始让我们启动并运行许多的更快,但是如果我们需要做一些不是标准用例的事情,它也会立即把我们扔进深渊。

尽管维护这些抽象的开源开发人员尽力满足每个人的需求,如果我们开始改善我们个人应用的用户体验,我们很有可能会发现自己偏离了常规,埋头于错综复杂的配置文件中,诅咒我们选择web开发作为职业的那一天。

总有人付钱

在表面上,可能看起来这只是工作:Web开发人员获得报酬来提供一个好的用户体验,所以我们应该吸取教训,忍受发展的艰辛。这在实践中是行不通的。

开发人员很紧张,而且大多数公司都负担不起聘请无障碍专家,的性能,以及其他可能影响用户体验的领域。即使是经验丰富、对自己的堆栈有深刻理解的开发人员,也可能难以对一个普通web应用程序的每个部分都进行完整的UX审计。有太多的事情要做,却没有足够的时间去做。这是麻烦的秘诀,它会导致物体从裂缝中掉下来。

在时间压力下,这变得更糟。开发人员通过交付有bug的代码来节省时间//修好我哦,上帝,我很抱歉附呈。他们取消了用户体验关注点的优先级——例如,确保屏幕阅读器用户可以,你知道的,把事情理解为“稍后再回顾”,他们以达到最后期限和预算的名义做出决定,最终,强迫我们的用户支付DX的费用。

开发人员在可用的时间和工具上做到最好,但由于缺乏时间和资源,当需要在UX和DX之间进行权衡时,通常情况下,成本都是由用户承担的。

我们如何打破DX和UX之间的僵局?

虽然有人总是要付出代价,有一些方法可以同时使用UX和DX,从而降低成本,或者在最佳情况下,允许开发人员一次性支付成本,并且可以无限期地获得DX的好处,而不必在最终的用户体验中进行任何权衡。

了解卓越用户体验的成本

在任何给定的项目中,我们应该以理想的用户体验为出发点。这种理想的用户体验应该建立在用户研究的基础上,低保真的测试,和一个迭代的设计过程,这样我们就可以确定这是我们的用户真正想要的。

一旦我们知道理想的用户体验是什么,我们应该开始将用户体验考虑因素映射到技术任务。这是一个将抽象概念(如“感觉快”)分解为具体度量的过程:我们如何度量用户体验目标是否已经实现?

通过将用户体验目标转化为可测量的结果,我们可以开始了解它的影响,从UX和DX的角度来看。

一个Y轴为“用户值”的二维图,X轴表示“组织的努力”这个图被分成四个象限,面积按顺时针顺序表示“可能”,“是的! ! !”“也许”,还有“不”。
确定某项任务的收益是否大于成本的优先级矩阵。来源: 尼尔森诺曼集团

从规划的角度来看,我们可以知道哪些任务对用户体验的影响最大,这需要开发人员付出最高的努力。这有助于我们理解成本和相关的权衡:也许让用户支付这些费用是可以的。但是如果某些东西对用户体验有很大影响,跳过它而选择好的dx可能不是个好主意。

选择解决方案时考虑成本

一旦我们能够理解给定任务的相对成本和权衡,我们可以开始详细分析它。我们已经知道这个问题有多难解决,所以我们可以开始研究如何解决这个问题。一般来说,解决问题有三大类:

  • 从头开始发明自己的解决方案。
  • 研究社区里最聪明的人在做什么,并将他们的发现应用于定制解决方案。
  • 通过使用现成的解决方案来利用开源社区的集体努力。

每一类都有权衡,要知道成本是否大于任何给定问题的收益,就需要通过项目的需求来工作。如果没有一张清晰的地图来说明正在构建的内容和构建它的成本,那么任何关于工具的决策都只能是有根据的猜测。

什么时候发明自己的解决方案

在我担任IBM前端架构师的早期,我领导了一个项目展开一个GraphQL层让前端团队在基于微服务的架构中快速构建应用程序。我们从开源工具开始,但在当时,没有任何东西能够解决我们面临的特殊挑战。我们最终建立了爷爷,我们在2017年底开源,抓挠我们的痒。

在这种情况下,定制是我们成本最低的选择:我们知道GraphQL将为我们解决一个关键问题,但是在微服务体系结构中没有运行graphql的工具。从微服务转移出去的成本太高了,长期来看,保持现状的成本是无法控制的。花时间创建我们需要的工具,通过提高生产力和改进团队的DX,我们获得了回报。

这个故事的警告是,不过,IBM是少有的拥有雄厚财力和庞大团队的公司。让一组开发人员全职工作来创建只需开始在实际目标上工作是很少可行的。

虽然DX针对使用我们实施的改进数据层的团队进行了改进,我们团队在构建工具时使用的DX相当粗糙。

有时候额外的努力和风险是值得的,但正如埃里克·李所说,你写的每一行代码都是a责任,不是一个资产。在选择推出自定义解决方案之前,认真考虑一下你是否有足够的资源来管理这些负债。

何时应用该领域专家的研究和经验教训

在工具阶梯上更进一步,我们能够利用和实施行业专家的研究。我们不是发明解决了;我们是实现由某一特定领域的顶尖专家设计的解决方案。

通过一些研究,感谢像这样的专家,我们可以获得行业最佳实践的可访问性莱奥尼瓦森马西萨顿;对于Web标准,通过杰弗里泽尔德曼埃斯特尔韦尔;通过蒂姆Kadlec阿迪他

通过利用网络领先专家的集体知识,我们不仅可以了解当前的最佳实践是什么,还可以通过实现这些最佳实践而成为专家。

但是网络发展很快,对于每一个我们有时间研究和实施的解决方案,十几个国家将会看到重大的改善。跟上最佳实践成为一场吃力不讨好的恶作剧,即使是最优秀的开发人员也无法跟上整个行业的发展。这意味着,当我们在应用程序的某个领域实现最新技术时,其他领域将变得陈旧,技术债务将开始累积。

虽然学习所有这些新的最佳实践感觉非常棒,实现这些解决方案的DX可能相当粗糙——在许多情况下,这使得成本高于给定团队的承受能力。

作为一名web开发人员,持续学习是绝对必要的一部分——我们应该一直努力学习和改进——但是如果它是我们的,那么它就无法扩展只有提供优秀用户体验的方法。套用杰姆杨,我们必须权衡利弊,我们应该做出提高球队dx的决定。我们的目标是让团队更高效,我们需要知道,在理解应用程序的每个细节和在合理的时间内为用户提供高质量的体验之间,该如何划清界限。

换言之:跟上行业最佳实践是衡量构建内部解决方案或使用现有工具之间权衡的最佳工具,但我们需要和这样一个事实和平共处,那就是我们根本无法跟上这个行业发生的一切。

何时使用现成的解决方案

虽然它是压倒性的尝试,并跟上快速变化的前端景观,不断发展的开源工具生态系统也是预付费dx的一个难以置信的来源。

有几十种不可思议的聪明,为解决网络问题而工作的充满激情的人们,其中许多解决方案都是开源的。这为像你我这样的开发者提供了前所未有的预付费解决方案:社区已经支付了费用,所以你和我可以在不放弃DX的情况下提供一个很棒的用户体验。

这类工具的设计考虑到了用户体验和DX。随着最佳实践的发展,每个项目都有数百个贡献者一起工作,以确保这些工具总是使用最好的方法。每个都产生了一个教程生态系统,的例子,betway体育注册的文章,让DX变得更好。

通过利用web社区的集体专业知识,我们能够避开所有的心痛和沮丧去弄明白这些事情;开源社区已经为我们预付了费用。我们可以享受到一个显著改进的DX,相信创建良好用户体验的许多最困难的部分已经解决了。

权衡是因为总是至少有一个是我们需要接受并在这些框架的假设和约束下工作,以获得伟大的dx。因为,一旦我们走出快乐的道路,我们又一次独立自主了。之前采用任何解决方案无论它是开源的,SaaS,或者说,有必要对我们正在努力实现的目标有一个透彻的了解,并将这种了解与提议的工具的目标和局限性进行比较和对比。否则,我们将面临一个重大风险:今天的DX改进将成为明天的技术债务。

如果我们愿意接受这种交换,我们发现自己处于一个很好的位置:我们可以自信地发布应用程序,知道UX在我们的堆栈的每一层都是头等重要的考虑因素,我们将在一个优化的环境中工作,为我们的团队提供一个不可思议的DX。

死锁是一个(可解决的)设计问题

在一个零和游戏中,把UX和DX定义为对立的力量是很有诱惑力的:为了一个人更好,另一个需要恶化。在很多应用中,这显然是事实。

以用户体验为代价的DX是一个设计问题。如果软件的设计是为了让开发人员的生活更轻松不考虑用户,难怪后来会出现问题。如果用户的需求不是每个决策的核心,我们看到问题悄然而至:我们没有意识到,如果用户加载时间超过3秒,他们就会放弃我们的移动网站,我们的项目最终变得臃肿不堪在4G上加载需要两倍的时间-在3G上更久。我们发送数百千字节的bloat,因为优化图像或删除未使用的代码是乏味的。简而言之:我们变得懒惰,我们的用户为此而受苦。

同样地,如果一个团队忽略了它的工具,只专注于提供优秀的用户体验,开发商将蒙受损失。严格的质量保证清单,全是手工流程,确保我们项目的用户体验是一流的。但这是一个艰难的过程,对于编写代码的团队来说,这是一个让人麻木的DX。在一个充满热爱创新和创造的开发者的行业里,繁琐的清单往往会扼杀员工的敬业度,这最终对用户不利,开发人员,以及整个公司。

但如果我们在项目开始时花点时间来考虑一下双方,我们能够找到平衡点,在问题出现之前做出明智的设计决策。我们可以把UX和DX都当作头等大事,防止他们之间产生矛盾,至少,当冲突发生时,我们可以最小化权衡。我们可以为用户提供良好的体验,同时还可以创建一套健壮的工具和框架,使开发在整个项目生命周期中都是愉快且可维护的。

我们是否通过选择现有的工具来完成工作,通过花费适当的时间适当地规划自定义解决方案,或其组合,我们可以有意识地做出明智的设计决策,这样我们才能留住用户开发人员高兴。

关于作者

5读者评论

加载评论