前端开发人员如何帮助弥合设计师和开发人员之间的鸿沟

在过去的九年里，几乎每一个与我共事过的设计师都对我表达了他们的沮丧，因为他们经常不得不花费数天时间向开发人员提供反馈，以纠正根本没有正确实现的间距、字体大小、视觉以及布局方面. 这往往会导致设计师和开发人员之间的信任减弱，并导致设计师没有积极性以及两个学科之间的不良氛围。

很多时候，在考虑设计团队提出的细节时，开发人员似乎仍然有过度技术化和无知的坏名声。 根据 Andy Budd 的一篇文章，“[...] 许多开发人员在设计方面处于相同的位置——他们只是没有意识到这一点。” 但实际上（正如 Paul Boag 指出的那样），“开发人员 [需要] 始终做出设计决策。”

在本文中，我将为前端开发人员提供实用的建议，以避免他们在与创意同行合作时感到沮丧并提高生产力。

透过设计师的眼睛看

让我们暂时假设您是一名设计师，并花了最后几周（如果不是几个月的话）为网站制定设计。 您和您的团队成员经历了多次内部修订以及客户演示，并投入大量精力来微调视觉细节，例如空白、字体样式和大小。 （在响应式时代——当然是针对多种屏幕尺寸的。）设计已经得到客户的批准，并交给了开发人员。 你感到如释重负和快乐。

几周后，您会收到一封来自开发者的电子邮件，内容是：

“暂存站点已设置完毕。 这是链接。 可以请QA吗？”

在期待的激动中，您打开该临时链接，并在滚动浏览某些页面后，您注意到该站点看起来有点不对劲。 间距甚至不接近您的设计建议，并且您注意到布局中的一些问题：错误的字体和颜色以及不正确的交互和悬停状态。 你的兴奋开始慢慢消退，变成一种沮丧的感觉。 你不禁问自己，“怎么会这样？”

寻找原因

也许只是设计师和开发者之间的沟通中出现了很多不幸的误解。 然而，你继续问自己：

• 设计的交接是什么样的？ 是否只是通过电子邮件共享了一些 PDF、Photoshop 或 Sketch 文件并附有评论，或者是否有实际的交接会议讨论了可能的设计系统、排版、响应行为、交互和动画等各个方面？
• 是否存在有助于可视化某些交互的交互或运动原型？
• 是否创建了具有明确优先级的重要方面列表？
• 进行了多少次对话——设计师和开发人员在同一个房间里？

由于通信和切换是两个非常重要的关键点，让我们仔细看看它们。

沟通是关键

设计师和开发人员，请互相交谈。 多说话。 项目越早进行，越频繁越好。 如果可能，请在项目早期（并定期）一起审查正在进行的设计工作，以便不断评估可行性并获得跨学科的意见。 设计师和开发人员自然会关注同一部分的不同方面，因此从不同的角度和角度看待事物。

尽早签入可以让开发人员熟悉项目，以便他们可以开始研究和提前计划技术术语，并提出他们关于如何优化功能的想法。 经常签到也可以在个人和社交层面上将团队凝聚在一起，并且您将学习如何接近彼此以进行有效沟通。

从设计到开发的交接

除非组织遵循真正敏捷的工作流程，否则设计组合和资产（从设计团队到开发人员）的初始移交可能会在项目的某个时刻发生。 这种移交——如果彻底完成——可以成为双方之间知识和协议的坚实基础。 因此，重要的是不要急于完成它并计划一些额外的时间。

问很多问题，讨论每一个需求、页面、组件、功能、交互、动画，任何东西——并做笔记。 如果事情不清楚，请要求澄清。 例如，在与外部或基于合同的团队合作时，设计人员和开发人员都可以签署作为共同协议文件的笔记，以供将来参考。

平面和静态设计组合非常适合显示网站的图形和布局方面，但显然缺乏交互和动画的正确表示。 索要复杂动画的原型或工作演示，将更清楚地了解需要为所有相关人员构建的内容。

如今，有各种各样的原型工具可供设计人员用来模拟不同保真度级别的流程和交互。 Javier Cuello 在他的一篇综合文章中解释了如何为您的项目选择正确的原型设计工具。

每个项目都是独一无二的，其要求也是如此。 由于这些要求，并非所有概念化特征都可以始终构建。 通常，构建某些东西的可用时间和资源可能是一个限制因素。 此外，限制可能来自技术要求，例如可行性、可访问性、性能、可用​​性和跨浏览器支持，经济要求（例如预算和许可费）或个人限制（例如开发人员的技能水平和可用性）。

那么，如果这些约束导致设计人员和开发人员之间发生冲突怎么办？

寻找妥协并建立共享知识

为了按时成功交付项目并满足所有定义的要求，在这两个学科之间寻求妥协几乎是不可避免的。 开发人员在解释为什么需要更改或无法在特定情况下构建的原因时，需要学会用非技术术语与设计师交谈。

开发人员不应仅仅说“抱歉，我们无法构建这个”，而应尝试给出设计人员可以理解的解释，并且——在最好的情况下——为在已知约束范围内工作的替代解决方案准备建议。 用统计数据、研究或文章支持你的观点，有助于强调你的论点。 此外，如果时间是一个问题，是否可以将一些耗时的部分的实施移到项目的后期阶段？

尽管并非总是可行，但让设计人员和开发人员坐在一起可以缩短反馈循环并更容易制定妥协的解决方案。 可以通过打开 DevTools 的编码和优化直接进行适配和原型设计。

向您的设计人员展示如何在浏览器中使用 DevTools，以便他们可以在浏览器中更改基本信息并预览微小的变化（例如填充、边距、字体大小、类名）。

如果项目和团队结构允许，尽快在浏览器中构建和原型设计可以让参与的每个人更好地了解响应行为，并有助于消除项目早期的错误和错误。

设计师和开发人员一起工作的时间越长，更好的设计师就越能理解开发人员构建什么更容易，什么更难。 随着时间的推移，他们最终可以参考过去对双方都有效的解决方案：

“我们已经使用该解决方案在项目 A 中找到折衷方案。我们也可以将它用于这个项目吗？”

这也有助于开发人员更好地了解设计师非常具体的细节以及哪些视觉方面对他们很重要。

设计师期望前端看起来（和功能）像他们的设计

设计文件与。 浏览器比较

防止设计人员受挫的一个有用技术是在您收到的设计文件和您当前的开发状态之间进行简单的左右比较。 这听起来可能微不足道，但作为开发人员，您必须处理许多需要在后台运行的事情，以至于您可能错过了一些视觉细节。 如果您发现一些明显的差异，只需更正它们。

可以这样想：实现中的每一个细节都与设计完全一致，可以为您和设计人员节省宝贵的时间和麻烦，并鼓励信任。 不是每个人都可能对细节有同等程度的关注，但为了训练您的眼睛注意视觉差异，快速一轮 Can't Unsee 可能会有所帮助。

这让我想起了很久以前我们玩过的一个游戏，叫做“找到它”。 您必须通过比较两个看似相似的图像来找到差异才能得分。

不过，你可能会想：

“如果设计中根本没有明显的字体大小和间距系统怎么办？”

好，好点！ 经验告诉我，通过要求澄清而不是从根本上开始自己改变事物并在以后为设计师制造不必要的惊喜，这有助于开始与设计师的对话。

学习基本的排版和设计规则

正如 Oliver Reichenstein 在他的一篇文章中所说，网络上 95% 的信息都是书面语言。 因此，排版不仅在网页设计中而且在开发中都起着至关重要的作用。 了解排版的基本术语和概念可以帮助您更有效地与设计师沟通，也将使您作为开发人员更加灵活。 我建议阅读 Oliver 的文章，因为他详细阐述了网络排版的重要性，并解释了诸如微观和宏观排版之类的术语。

在“移动网页设计中的排版参考指南”中，Suzanne Scacca 彻底涵盖了排版术语，如字体、字体、大小、粗细、字距、前导和跟踪，以及排版在现代网页设计中的作用。

如果您想进一步扩展您的排版视野，Matthew Butterick 的书“Butterick 的实用排版”可能值得一读。 它还提供了排版关键规则的摘要。

我发现在响应式网页设计中特别有用的一件事是，应该以45 到 90 个字符的平均行长（每行字符）为目标，因为较短的行比较长的行更易于阅读。

开发人员应该设计吗？

设计师是否应该学习编码已经有很多讨论，你可能会反过来问自己同样的问题。 我相信一个人很难在这两个学科中都出类拔萃，这完全没问题。

Rachel Andrew 在她的文章“一起工作：设计师和开发人员如何沟通以创建更好的项目”中很好地概述了为了更有效地协作，我们都需要学习团队成员的语言、技能和优先事项，以便我们可以创建共享语言和重叠的专业领域。

在设计领域变得更有知识的一种方法是由 Sarah Drasner 提供的名为“为开发人员设计”的在线课程，她在其中谈到了基本的布局原则和色彩理论——网页设计的两个基本领域。

“你在自己的学科之外学到的越多，实际上对你 [...] 作为一名开发人员来说就更好了。”

— 莎拉·德拉斯纳

视觉中心

通过与设计师合作，我了解了数学中心和视觉中心之间的区别。 当我们想将读者的注意力吸引到某个元素上时，我们眼睛的自然焦点就位于页面的数学中心略上方。

例如，我们可以应用这个概念来定位模态或任何类型的叠加层。 这种技术可以帮助我们自然地吸引用户的注意力，并使设计看起来更加平衡：

我们谁都跑不了

在快节奏且不那么灵活且截止日期紧迫的代理环境中，开发人员经常被要求实施基于移动和桌面模型的全功能响应式前端。 这不可避免地迫使开发人员在整个过程中做出设计决策。 诸如“我们将在多大程度上减小标题的字体大小？”之类的问题。 或者“我们什么时候应该将我们的三列布局切换到单列？” 可能出现。

此外，在当下的热潮中，可能会发生诸如错误状态、通知、加载状态、模式或 404 页面样式之类的细节完全漏掉的情况。 在这种情况下，很容易开始指责和指责那些早该想到这一点的人。 理想情况下，开发人员不应该被置于这种情况下，但如果是这样的话怎么办？

当我听上野的创始人兼首席执行官 Haraldur Thorleifsson 在 2018 年旧金山的一次会议上发言时，他提出了他们的两个核心价值观：

“这里没有什么是别人的问题。”

“我们捡起没有放下的垃圾。”

如果更多的开发人员主动开始尽可能好地模拟上述缺失的部分，然后与坐在他们旁边的设计师一起完善呢？ 网站存在于浏览器中，那么为什么不利用它来构建和改进呢？

虽然缺少或遗忘的部分可能并不总是理想的，但我从过去的经验中了解到，它总是帮助我们更快地前进并在飞行中消除错误——作为一个团队。

当然，这并不意味着设计师应该在这个过程中被否决。 这意味着开发人员应该通过表现出解决问题的主动性来尝试恭敬地与设计师会面。 除此之外，我作为一名开发人员，仅仅因为关心和承担责任而受到团队的重视。

在设计师和开发人员之间建立信任

在创意团队和技术团队之间建立信任和积极的关系可以极大地提高生产力和工作成果。 那么，作为开发人员，我们可以做些什么来增加这两个学科之间的信任呢？ 这里有一些建议：

1. 关注细节。
   完全按照设计的方式建造东西会向设计师展示你的关心，并让他们脸上露出灿烂的笑容。
2. 尊重沟通。
   我们都是在专业环境中努力争取最好结果的人。 尊重彼此的纪律应该是所有沟通的基础。
3. 尽早并定期检查。
   从一开始就让开发人员参与进来有助于尽早消除错误。 通过频繁的沟通，团队成员可以形成共同语言，更好地了解彼此的立场。
4. 让自己可用。
   每天至少有一个可选的 30 分钟窗口，设计师可以与开发人员讨论想法，这可以给设计师一种被支持的感觉。 这也让开发人员有机会用不太懂技术的人可以更好地理解的语言来解释复杂的技术事物。

结果：双赢局面

通过有效的沟通和适当的设计移交，必须在 QA 上花费更少的时间，这让创意和开发团队有更多的时间专注于构建实际的东西，减少头痛。 它最终创造了一种更好的氛围，并在设计师和开发人员之间建立了信任。 在一些设计相关领域表现出兴趣和知识的前端开发人员的声音将在设计会议中被更多地听到。

积极主动地帮助在设计师和开发人员之间找到折衷方案并作为开发人员解决问题可以让您对整个项目有更广泛的所有权和参与感。 即使在当今蓬勃发展的创意产业中，要找到除了技术技能之外还关心并关注视觉细节的开发人员也并非易事。 这可能是您帮助弥合团队差距的机会。

相关资源

• “如何选择正确的原型设计工具，”哈维尔·库洛
• “移动网页设计中的排版参考指南”，Suzanne Scacca
• “巴特里克的实用印刷术，”马修·巴特里克
• “一起工作：设计师和开发人员如何沟通以创建更好的项目，”Rachel Andrew
• “为开发人员设计”，前端大师 Sarah Drasner
• “网页设计是 95% 的排版，”Oliver Reichenstein
• “Can't Unsee”，一个浏览器测验，用于训练您识别视觉细节的感觉。