前端开发人员如何赋能设计师的工作

已发表: 2022-03-10
快速总结↬作为一名前端开发人员,我想为过去发生的所有误解向那里的设计师道歉。 我认为现在是我们开发人员提高我们对设计师角色的认识并向他们展示我们可以而且应该超越我们自己的屏幕的时候了。

亲爱的前端开发人员,这篇文章主要针对您,他们喜欢实现用户界面,但在与您合作的设计师保持期望方面遇到困难。 也许您被称为“UI 开发人员”或“UX 工程师”。 不管你的头衔是什么,你的工作(以及我的工作)不仅仅是为设计文件注入活力。 我们还负责填补设计和开发工作流程之间的空白。 然而,在跨过那座桥时,我们面临着多重挑战。

今天,我想和大家分享一些实用技巧,这些技巧帮助我在过去几年中更有效地与设计师合作。

我相信,作为 UI 开发人员,我们的工作不仅是帮助设计师了解 Web 的工作原理,而且还要了解他们的现实并学习他们的语言。

了解 UX 设计师的背景

大多数用户体验设计师(也称为网页设计师或产品设计师)通过 Photoshop 和 Illustrator 等工具在设计界迈出了第一步。 也许他们是平面设计师:他们的主要目标是创建徽标和品牌标识,并为杂志设计版面。 他们也可能是营销设计师:打印广告牌、设计横幅和创建信息图表。

这意味着大多数 UX 设计师在早期都在为印刷设计,这与他们当前的媒介——屏幕完全不同。 那是他们的第一个大挑战。 在处理打印时,设计师关心像素对齐,但在固定区域(纸张)上。 他们不必与动态布局(屏幕)抗衡。 考虑文本中断或交互状态也根本不是他们工作的一部分。 设计师在颜色、图像和排版方面也有完全的自由,没有性能限制。

幸运的是,自学成才的 UX 设计师社区做出了许多努力,教授开发基础知识,讨论设计师是否应该学习编码以及了解如何最好地向开发人员移交。 开发方面也是如此(稍后会详细介绍)。 然而,这两个领域之间仍然存在摩擦。

一方面,每次实现与他们的设计不匹配时,设计人员都会抱怨,或者当开发人员在没有明确解释的情况下拒绝这些实现时,他们会感到被误解。 另一方面,开发人员可能会理所当然地认为设计师知道一些技术知识,而这可能不是真的。 我相信我们都可以做得更好。

跳跃后更多! 继续往下看↓

拥抱新的思维方式

我们正在构建的网站和应用程序将显示在各种屏幕尺寸上。 每个人都会在多个设备上使用它们。 我们的共同目标是在他们的旅程中创造一种熟悉的体验。

当我们作为开发人员认为设计师对像素对齐很挑剔时,我们需要了解为什么会这样。 我们需要认识到它超出了保真度和一致性。 这是关于所有部分一起工作的总和。 是凝聚力。 我们必须接受它并尽最大努力实现它。 学习设计原则的基础是一个很好的起点。 了解选择正确颜色的重要性、层次结构的工作原理以及留白的重要性。

注意有一个名为“面向开发人员的设计”的在线课程和一本名为“重构 UI”的书——两者都非常适合帮助您入门。 有了这些,您将能够以敏锐的眼光来实现用户界面,并在与设计师交流时获得显着的优势。

放大设计师的意识

您可能想当然地认为设计师和您一样了解网络。 好吧,他们可能不会。 其实,他们不必! 作为开发人员,我们有责任让他们了解网络的当前状态。

我曾与这个范围的两个方面合作过:认为可以构建任何东西(例如复杂的过滤器、新的滚动行为或自定义表单输入)而不考虑浏览器兼容性的设计师。 然后,有些设计师假设“网络的低限制”,只是自己假设某些东西是不可能实现的。 我们需要向他们展示网页设计的真正可能性,而不是让限制阻碍他们的技能。

教他们编码,而不是如何编码

这似乎是矛盾的,但请容忍我:知道如何编码是开发人员工作的核心。 我们在一个快节奏的行业工作,每天都会出现新的东西。 如果我们要求设计师学习如何编码,那将是一个虚伪的要求。 但是,我们可以帮助他们理解代码。

坐在与你一起工作的设计师旁边15 分钟,教他们如何自己查看元素的规格是否正确以及如何更改它们。 我发现 Firefox Page Inspector 对此非常友好。

如今,可视化布局、调试 CSS 动画和调整排版是一种乐趣。 向他们展示一个像 Codepen 这样的即用型代码游乐场供他们探索。 他们不需要知道所有的 CSS 规范来理解布局范式是如何工作的。 但是,他们需要知道元素是如何创建和表现的,以便为他们的日常工作提供支持。

在开发过程中包括设计师

邀请设计师加入您的站立会议,成为 QA 流程的一部分,并在您完善实施中的视觉细节时与您坐下来。 这将使他们了解网络的限制,并且很快他们就会认识到为什么一个功能需要时间来实现。

要求设计师将您包括在他们的设计过程中

你会意识到他们做的不仅仅是“让事情变得漂亮”。 您将了解有关研究过程以及如何完成用户测试的更多信息。 您会发现,对于他们向您展示的每个设计建议,之前都放弃了其他几项研究。 当设计师要求更改时,请询问其背后的原因,这样您就可以了解更多有关所做决定的信息。 最终,您将开始理解为什么他们对空白和对齐方式很挑剔,希望很快您也会如此!

我发现将前端开发视为设计过程的核心部分,并将设计视为开发过程的核心部分至关重要。 提倡每个人都有机会参与设计和开发周期的思维方式,这将有助于我们所有人更好地了解彼此的挑战并创造出色的体验。

我们可能使用不同的工具,但我们必须说同一种语言

现在我们开始更好地了解彼此的工作流程,是时候进行下一步了:说同一种语言。

超越代码编辑器

一旦你开始关注周围的环境,你就会更有能力解决问题。 更好地了解业务并愿意倾听设计师的意见。 这将使您成为对项目有更丰富贡献的团队成员。 在我们专业之外的领域进行合作是建立有意义的对话和相互信任的关键。

使用 UI 系统作为合同

要求设计师与您分享他们的设计系统(如果他们不使用,那么开始永远不会太晚)。 这将使您免去挑选所用颜色、计算边距或猜测文本样式的麻烦。 确保您与他们一样熟悉 UI 系统。

您可能已经熟悉基于组件的概念。 然而,一些设计师可能不会像你那样看待它。 向他们展示组件如何帮助您更有效地构建用户界面。 传播这种心态,并与相似但不相等的名称说再见:标题与英雄,定价信息与价格选择器。 当构建用户界面的一部分(又名“组件”)时,请大步使用相同的名称,以便它们可以反映在设计和代码文件中。 然后,当有人说“我们需要调整提案邀请小部件”时,每个人都清楚地知道在谈论什么。

承认真相的真正来源

尽管用户界面首先是在设计文件中创建的,但真正的事实来源是在开发方面。 归根结底,这是人们实际看到的,对吧? 更新设计时,最好在旁注一下其开发状态,尤其是在涉及大量人员的项目中。 这个技巧有助于保持沟通顺畅,所以没有人(包括你)想知道:“这与现场版本不同。 它是一个错误还是尚未实现某某?

控制债务

所以,你对技术债务了如指掌——它发生在实施新事物的成本很高时,因为我们过去为了赶上最后期限而采取的捷径。 同样的情况也可能发生在设计方面,我们称之为设计债务

你可以这样想:UX 和 UI 不一致的程度越高,债务(技术和设计)就越高。 最常见的不一致之一是使用不同的元素来表示相同的动作。 这就是为什么糟糕的设计通常会反映在糟糕的代码中。 作为设计师和开发人员,我们所有人都应该认真对待我们的设计债务。

易于访问并不意味着它必须是丑陋的

我非常高兴地看到,作为开发人员和设计师,我们终于开始将可访问性引入我们的工作。 然而,我们中的很多人仍然认为设计无障碍产品很难或限制了我们的技能和创造力。

让我提醒您,我们并不是只为自己创造产品。 我们正在创造一种供所有人使用的产品,包括那些以与您不同的方式使用该产品的人。 考虑如何在保持当前用户流清晰和连贯的同时更容易访问各个元素。

例如,如果设计师真的认为创建增强的选择输入是必要的,那么站在他们的一边,共同努力,以一种可访问的方式设计和实现它,以供具有不同能力的广泛人群使用。

向设计师提供有价值的反馈

在进行设计时不可避免地会出现问题。 然而,这并不是你开始抱怨设计师的错误或他们雄心勃勃的想法的理由。 设计师不是为了让你动脑筋,他们只是并不总是直觉地知道你需要什么来完成你的工作。 事实是,在过去,你也不知道这些东西,所以要有耐心,把协作作为一种学习方式。

反馈越早越好

反馈的时机至关重要。 反馈工作流程很大程度上取决于项目结构,因此没有一种万能的解决方案。 但是,如果可能的话,我相信我们应该以定期反馈的工作流程为目标——从早期阶段开始。 拥有这种开放式协作的心态是减少以后出现意外大重复的可能性的方法。 请记住,您向设计师提供第一个反馈的时间越晚,他们在需要时探索新方法的成本就越高。

用简单的术语解释抽象的想法

还记得我说过性能与设计师以前的工作无关吗? 当他们不知道如何为 Web 创建优化的 SVG 时,不要惊慌。 当面对需要加载大量不同字体的设计时,向他们解释为什么我们应该尽量减少请求的数量,甚至可以利用可变字体。 除了加载速度更快之外,它还提供了更一致的用户体验。 除非设计师热衷于学习,否则在解释某事时避免使用过多的技术术语。 您可以将此视为提高您的沟通技巧和澄清您的想法的机会。

不要让假设变成决定

一些关于设计规范的问题只有在我们弄脏代码时才会出现。 为了加快速度,我们可能会很想根据我们的假设做出决定。 请不要。 每次将假设转化为决定时,您都在冒着设计团队对您实施 UI 的信任的风险。 如有疑问,请联系并澄清您的疑虑。 这将向他们表明您和他们一样关心最终结果。

不要自己做变通方法

当你被要求实现一个太难的设计时,不要说“这不可能”或开始自己实现一个廉价的替代版本。 当设计团队发现他们的设计没有按预期实施时,这会立即引起与设计团队的摩擦。 他们可能会做出愤怒的反应,或者什么都不说,但感到挫败或沮丧。 如果我们用简单的术语向他们解释为什么某些事情是不可能的并提出替代方法,那么这一切都可以避免。 避免教条主义的行为,并愿意就新的解决方案进行合作

让他们了解 Graceful Degradation 和 Progressive Enhancement 技术,并一起构建一个理想的解决方案和一个备用解决方案。 例如,我们可以将布局从 flexbox 增强为 CSS Grid。 这使我们能够尊重功能的核心目的,同时充分利用 Web 技术。

谈到动画,让我们变得真实:在内心深处,您对实现下一个令人惊叹的动画就像设计师要创造它一样激动。 我们和他们的区别在于我们更清楚网络的限制。 但是,不要让这限制了你自己的技能! 网络发展迅速,因此我们必须利用它对我们有利。

下次您被要求将原型变为现实时,请尽量不要提前拒绝它或自己做所有事情。 将其视为推动自己的机会。 动画是 Web 开发中最挑剔的部分之一,因此请确保与您的设计师亲自或通过共享私人同步链接来优化每个关键帧。

超越理想状态思考 — 齐心协力

事情是这样的:这不是关于你的全部。 设计师面临的挑战之一是真正了解他们的用户,并以最有吸引力的方式向产品经理展示设计。 有时他们忘记了超出理想状态的内容,开发人员也忘记了它。

为了帮助避免这些差距的发生,请与设计人员保持一致的场景要求:

  • 最坏的情况
    最坏的可能性正在发生的场景。 这有助于设计师对固定内容说不,让它变得流畅。 如果标题超过 60 个字符或列表太长会怎样? 这同样适用于相反的空场景。 当列表为空时,用户应该怎么做?
  • 交互状态
    浏览器不仅仅是悬停和点击。 有很多状态:默认、悬停、焦点、活动、禁用、错误……其中一些可以同时发生。 让我们给予他们适当的关注。
  • 加载状态
    在本地构建东西时,我们可能会使用模拟并忘记加载实际上需要时间。 让设计师也了解这种可能性,并向他们展示让人们感知到加载时间不会那么长的方法。

考虑到所有这些场景将在开发阶段为您节省大量时间。

注意Scott Hurff 有一篇很棒的文章,介绍了如何修复不良的用户界面,这将使我们更接近可访问的产品。

接受变更请求

众所周知,开发人员不会因为有人在他们的代码中发现错误而感到高兴——尤其是当它是由设计师报告的设计错误时。 它周围有很多模因,但你有没有想过,当这些设计错误被随意忽略时,这些错误如何复合地破坏体验质量以及你们的关系? 它发生得很慢,就像睡着了一样。 一点一点,然后一次。 设计师可能会开始说,“这只是一个很小的细节”,直到冷漠和怨恨积聚起来,什么也没说。 损害已经造成。

这种情况是双重的:对你的同龄人和你的工作。 不要让这种情况发生。 研究影响你反应的因素。 设计师“挑剔”可能会带来不便,但也可能是工程师对专注和热情的肤浅诠释。 当有人告诉你你的实现并不完美时(还),把你的自尊放在一边,向他们展示你如何认识到他们在完善最终结果方面的辛勤工作。

偶尔去记录一次

我们都有要交付的任务和要完成的路线图。 然而,一些最好的工作是在记录之外发生的。 它不会登录到TO DO板,这没关系。 如果你找到了与你有默契的设计师,就潜入他们的工作区,一起探索新的实验。 你永远不知道那里会发生什么!

结论

当你愿意向设计团队学习时,你也在学习不同的思维方式。 您将从您的经验中发展您与其他领域合作的心态,同时完善您创造新体验的眼光。 随时提供帮助并乐于学习,因为分享让我们变得更好。



没有很多伟人的反馈,这篇文章是不可能完成的。 我要感谢设计师 Jasmine Meijer 和 Margarida Botelho 帮助我就设计师和开发人员之间的误解分享了一个平衡的观点。

SmashingMag 的相关阅读

  • Mason Gentry的“为开发者设计”
  • “一起工作:设计师和开发人员如何沟通以创建更好的项目”,作者: Rachel Andrew
  • “前端开发人员如何帮助弥合设计师和开发人员之间的差距”,作者Stefan Kaltenegger
  • “网页设计师和开发人员应该听哪些播客?” 通过瑞奇昂斯曼