程序员与设计师和谐相处的7个建议

程序员| 2017-08-14

文章译自：Medium

原文标题：Here’s the reverse: 7 things I wished developers did more of when working with designers

原文作者：Valinda Chan

文章翻译：村长道哥

为了创造出伟大的产品，开发者和设计师之间的协作是至关重要的。虽然程序员和设计师可能会关注的是产品的不同方面，但是与大多数人的固有印象不同的是程序员和设计师有着很多共识。设计师和程序员都是善于分析和创造性地解决问题的人。程序员和设计师的组织结构可能在每个公司中都是不一样的，甚至在开发团队中也可能存在子团队。对于一个成功的项目，无论组织结构是怎样的，程序员和设计师都需要紧密合作。

这两个角色我都做过，所有我想花些时间整理出一些想法，希望一些人能从中有所收获。从设计的角度来看，我参与过用户调研，提出过一些想法并将落实到具体的设计中。从开发的角度来看，我尽我所能地实现设计团队所做的设计。有些时候，我身兼两职，既提出概念也实现这些概念。我希望我的这个背景能让你明白我并不会冒犯到某一种角色（为什么我要花这么多时间来做这件事？）我希望看到所有人在一起工作时所带来的价值，并且希望看到双方都能高效地协作。

1 主动给出反馈，并坦率指出问题

a. 就像设计师一样，开发人员也可以提供有价值的反馈

许多曾与我共事的开发人员都有着丰富的经验和见解，特别是当他们在某个行业或某个特定产品上工作了一段时间后。现在很多程序员都会参与线框图设计、原型设计和视觉设计，因此他们对设计师也能提出帮助性的反馈。设计是共同创造，开发人员和其他人一样是不可或缺的。

在整个设计过程中我经常与设计师进行互动。如果你还没有准备好那就参加一些会议吧。尽管你可能不需要参与到每一次讨论中，但要与你的团队或项目经理一起商议，确保你参与了决定产品功能的一些重要的讨论。这样你就有机会在为时太晚之前把问题提出来。管理设计师、客户、产品经理和其他相关人员的期望也是很重要的一项工作。

b. 及时提供反馈

忙于当前的 sprint 工作，同时又要为下一个 sprint 的设计提供反馈并不是件容易的事情。由于紧急交付的压力，你可能最终会把重点放在第一个 sprint 上。但这常常会导致在以后的工作中出现一些问题。如果你的团队还没有这样做的话，我建议你（或你的项目经理）在做计划时提供对设计的反馈。我多么希望我在之前的一些项目中能做得更多一些，因为当你在做一个复杂的产品时，提供反馈就可以变成一份兼职工作。在定义产品时，开发团队需要做一个相关的陈述，这是非常重要的，一定要有人来做。

c. 为什么定期反馈很重要

回顾并提供设计的反馈，这和进行实际的设计一样重要。你可能会问为什么。

从各个角度来看这个问题，设计师花了大量的时间来决定一个东西应该长成什么样或者怎么工作，客户几个月前就签定了一个，项目经理或产品经理管理各方的预期，高级经理进行关于交付的沟通等等。

下面是我在主持关于 UX 的研讨会时使用的一张图，以此说明为什么设计过程很重要。随着项目的深入，设计变更的数量会越来越少，但是改变主意的成本会显著增加。

当你开始做项目的时候，有很多设计方案可供选择，而且改变主意的成本也很低。这时候在这个项目上投入的资金还不是太多。随着项目时间的推移，团队在项目上投入了更多的资金，设计方案的数量也在不断减少。与此同时，改变想法的成本越来越高。千万不要等到这张图的后半部分才把问题说出来。

图0：程序员与设计师和谐相处的7个建议

如果你对设计方案的可行性感到担忧，那就诚实一点吧。表现出脆弱的一面并承认有一些想法是你无法做到，这的确很难。请求更多的时间来提供反馈完全没问题。当团队成员能够花些时间进行研究和评估时，我就很感激他们，我也希望他们能在我做这些工作的时候同样感激我。“能做”的态度是很好，但不要觉得在当场达成一致感到有压力。

说出技术限制并不会使你的程序员显得能力不足，事实上，当你清楚地说出技术难点并帮助团队找到另一种方法时，这会让你获得更多的尊重。

记住，在受限的环境中产生的创新才更能带来更多价值。愿意接受限制并创造性地解决问题可以让你与众不同。

2 无死角检查注释、规范和原型

细节决定成败。视觉设计师通常会把所有的规范都设计出来。当我的团队被要求改变边距、颜色和间距时，他们总是难受得要死要死的，因为他们认为这看起来并不重要。一点不骗你，我曾经被设计师要求把文本调高 2px。在花了120个小时调试某个功能之后，再听到这种反馈确实会令人沮丧。但是，我知道这些在用户界面中都很重要。即使你认为标签距离一段字多出5px一点也不重要，但这确实可能会影响到用户体验。因为用户很可能因为一个标签比较靠近错误的一段字而产生混乱的感觉。例如，邻近性是设计的一个重要原则，所以这个标签放置在那里是有其原因的。颜色同样也很重要。大多数产品必须遵循公司制定的特定品牌指导方针。不要认为某些东西是“装饰用的”或“那么小”就忽视其作用。优秀的设计是有其意图的。

图1：程序员与设计师和谐相处的7个建议

我们可能会认为标签的左对齐并不是什么大不了的事情。但是，设计者指定标签是右对齐的，这样标签就可以更接近于它们制定的内容。

新想法的出现总是件好事。你的反馈是有价值的，所以尽量早点去做（参考第一条建议）。如果您想要在样式或功能上作出与已批准的设计不同的改动，请务必提前沟通，并在花大量时间做这些之前与团队进行核对。如果你在晚些时候才提出改变，先和你的团队一起核对，然后准备好解释这些改动背后的原因。根据团队的情况，以及你所处的不同阶段，所谓的惊喜可能需要一个合理的理由才能被称之为惊喜。

3 如果不确定就去问

在工作场合中不必要的误解经常发生，而这居然似乎是显而易见的事情。如果有什么不清楚或者你对任何设计决策有疑问的话，那就去问问设计师吧。对于开发人员来说，这是一个非常好的机会来填补那些可能被团队忽略的部分。不要等着团队去发现一些漏洞。提出好的问题可以帮助减少最后阶段才出现的设计请求。

“唯一比编写软件更昂贵的是编写糟糕的软件。”

—— Alan Cooper（好汉两个半）

下面是当我拿到一个关于搜索结果列表的设计时脑中出现的一些问题：

* 我们是否会在当前结果列表下面动态加载相同数量的搜索结果？

* 在加载结果时，我们是否使用动画？

* 只剩最后一个搜索结果应该会发生什么？我可以去掉这个“加载更多”的按钮吗？

* 当加载结果时，使用spinner吗?

4 邀请设计师进行非正式的评审

即使有 QA 评审，也要主动提前和定期地进行评审，这样你就可以做出相应的调整。如果在你的团队中还没有这么做的话，那就去寻找与设计师一同评审的机会。这也有助于程序员和设计师理解彼此对项目的贡献，从而建立更牢固的关系，并对彼此的工作更加尊重。

5 阐明你的工作流程

有些设计师可能对开发的整个流程都不太了解，比如测试、bug修复和文档编写。跟上面提到的类似，和别人分享你的工作流可以帮助管理其他人的期望值，并为改动的程度设置界限。当我告诉设计师我的工作流程后，他们知道改动是需要时间的，而我可能无法在一夜之间就实现出来。

“接受竞争约束的意愿甚至热情是设计思维的基础。”

——Tim Brown，《设计改变一切》的作者

6 了解用户是如何与你做的东西进行交互的

我建议一个产品的团队中的每个人都在某种程度上参与到调研过程中。你可以听一些电话录音，看一段录像，或者查看一些有重大发现的幻灯片。虽然这可能会让我们的注意力从主要关注点转移，但参与一些研究过程有助于从用户的角度去思考问题。即使作为一个开发人员，我也认为与用户建立共鸣是非常重要的。当一个程序员发现她的用户因为一个被忽视的性能问题而在屏幕上沮丧地花费几分钟的时间等待加载时，她就会意识到共鸣的重要性了。

图2：程序员与设计师和谐相处的7个建议

知道用户抓狂是一回事，但看着用户因为你的产品而抓狂是另一回事。

从用户研究中获得的见解也让我对需要先做什么以及为什么要做的理由有了一个全面的理解，进而产生出一种更强烈的参与感和创造感。

7 了解设计变更的原因

设计师和你都是同一条船上的人。试着对设计变化进行换位思考。对最后才发生的设计变更感到崩溃这是可以理解的。这种情况却是很糟糕。然而，改变不是并不是为了某个人。应该让人们相信，改变是为了获得最好的产品，或者是为了适应商业目标。有的时候开发团队应该延迟发布，因为有些更改对最终的交付至关重要。

如果你需要花额外的时间在设计的改动上，这意味着设计师也同样会花一些时间在这些改动上面——尽管我承认，两者的时间并不是相等的。也许一个设计的改变需要一个设计师很少的工夫，但是却需要开发人员大量的努力才能完成。但是，让我们来考虑一下相反的场景，当有一个改变需要设计师付出更多的努力时，也许他或她必须进行许多次的可用性测试，反复修改他们的设计，然后进行更多的可用性测试，还要从不同的角色那里获得认同，重新修改直到设计定稿。应该多问一些问题来了解改动背后的原因，然后坚信这些改变是为了做一个更好的产品。