有很多同学面试都遇到过这样一个问题（包括我）：如果你做的设计开发说实现不了，你会怎么办？这是一个直接反映设计师在自己领域业务水平的问题，也是 UI 设计工作中最常遇到的阻力之一，是 设计师 和前端程序员的主要矛盾来源。
开发沟通指南
6000 字干货！写给设计师的开发沟通指南 前言 “这个做不了、很难做的啊、我没时间啊、改这个有什么意义吗？
阅读文章 >
这一篇，我就要从几个维度来讲讲，在真实项目环境中，开发说设计不出来的话，我们应该怎么办。
想要解决开发做不了的问题首先要了解他们做不了的原因。
在正常的团队协作中，正式进入前端开发阶段前，有需求评审、交互评审和视觉评审。需求评审即产品经理的工作产出评审，告知团队这个阶段要实现的功能有哪些。而交互和视觉评审，则是设计师交付给团队，产品怎么操作，界面长什么样的过程。这个过程不一定是要在会议室中一群人看设计师演示交互原型或 PPT，只要是设计没有完全定稿针对它的讨论都可以算是评审过程。
开发会告诉你设计稿实现不了，就是在这个阶段中发生的，那为什么他们会在这个阶段说实现不了呢？
主要原因有四个：
技术上有难度，实现不了 时间不够充裕，来不及做 单纯看你不爽，对人不对事 看破职场沉浮，一心躺平 针对第一点，稍微有点经验的程序员都不会在看到设计稿后判断不了自己能不能实现，不会把设计稿拿回去代码写到一半，再跑回来和你说实现不了。
这里的不能实现包含三种情况，第一种是技术上真没办法实现，比如使用了一些非常复杂的 3D 着色器、渲染效果。
第二种是开发的能力有限，以他目前的水平做不出来。尤其是小公司中的初级前端群体，因为经验和技术能力不足，往往复杂点的效果就不知道怎么下手，所以自然实现不出来。
第三种，就是为了实现这个效果的代价过大，觉得完全没有必要，这是最常见的情况。比如团队已经使用某开源框架做前端了，结果你设计稿效果和官方组件南辕北辙，为了和你的设计效果保持一致，得花费几倍的时间精力。
可能设计新人会觉得奇怪，程序员还原设计稿效果不是天经地义的嘛？
但程序员的思考方式是不一样的，程序写代码的第一目标必然是 “功能实现”。所以他们分配给界面样式的时间和精力是不多的，如果视觉稿需要让他们投入过多的精力，影响到功能的实现，那么他们肯定优先选择功能而不是视觉效果。
多数 B 端项目中程序员的时间都是不够用的，所以也导致复杂的视觉效果基本都会被他们驳回。这就关联到第二点，时间不够充裕的问题。因为时间紧迫，一些开发成本过高的视觉效果，即使程序员认可你的设计方案，也想这么输出，但是根本没有充裕时间完成，所以只能拒绝。
再到第三点，程序员就是对你有意见，只要设计稿稍微复杂，就算做的了也有时间但就是不想和你配合，也会想方设法找理由给借口说做不了。同事发展到这个地步并不少见，根据我多年的经验和观察，除了少数心理健康有待商榷的程序员以外，这种情况多数由设计师的不专业行为长期积累而引发的，被对接程序员嫌弃……
最后一点，就是和你对接的前端看破滚滚红尘，参透职场的真理，认清剥削的真相，选择躺平了……躺平了……平了……了……这和上一点类似都是消极对待工作，只是这次他没针对你了，而是针对项目团队在座的各位。这种程序员高频出现在国企或其它大型企业中，有比较长的工作年限，得过且过没有任何的工作热情了。或者是已经打定主意要离职，已经抱着你们爱咋咋滴和我已经没关系的心态了。
以上就是程序员会讲开发实现不出来的主要原因。
想要解决实现不了的问题，肯定要先定位出实现不了的原因属于上面哪一类，然后才能对症下药。
第 1：技术实现不了的解决方案
如果是技术上的困难导致无法实现，那么设计师修改方案是必须的。但改动前，要尽量和程序员询问技术实现不了的原理，再针对性的做出调整。比如我们之前做过的一个筛选面板优化，增加了右下角 “查询” 按钮，需要每次筛选完成后点 “查询” 才能刷新筛选结果，而不是像京东这些网站的筛选项一样点击后立刻刷新。
这是因为开发做不到结果秒出，一般项目的后端数据库搭建非常简陋，检索效率极低，每次查询请求到输出结果需要数秒到数十秒不等。所以，增加查询按钮多一个操作步骤反而是效率更高的做法。
还有特别常见的情况，就是设计师自己辛辛苦苦画了花里胡哨的图表、可视内容，还加上各种酷炫的动画和特效，但是开发做出来和设计稿完全不一致。
这就是因为一般开发掌握的图形技术往往非常有限，或者使用的引擎本身也不具备实现相关模型、效果的渲染。这需要设计师和程序员进一步确认可以实现的效果特征有哪些，支持什么程度的模型，可以应用哪种着色器、光源，再根据这些特性重新优化设计方案。
解决技术实现上的难度，就是找出问题在交互的步骤上还是视觉上（动画也算），然后围绕这个方向和开发进一步商议出可以实现的方案，再动手去修改。
第 2：时间不够充裕，来不及做
时间来不及也是非常常见的情况，尤其在设计师设计出非常多全新的样式和细节时。多数项目都会使用类似 Ant、Element、Tdesign 之类的开源前端框架，如果你制定了大量新组建或修改了原有组件的样式或细节，那么调整起来是非常耗时的，即使是一些看似简单的微小改动。
因为成熟的大型开源项目，每一个元素的样式、逻辑都作用了大量的代码，这些代码又分布在不同的样式表或者脚本中。往往做一点小改动，就会发生莫名其妙的 BUG，这种情况就要倒逼程序员去检查和理解与它关联的所有代码信息。即使成功把这个细节改好了，保不准其它关联到的元素会出现问题，引发一连串的连锁反应……
所以通常在前端时间不足的情况下，最简单的解决办法就是减少新样式的使用，尽可能使用框架自带样式或者过去开发的原有样式。这不是说每次迭代时间紧迫设计师永远不思进取，对所有设计 Ctrl+C/V 就结束了，而是要做权重评估，哪些样式的改动不仅重要性不高而且花费的时间特别多，哪些是非常必要且无法忽视的更新。
之后，就是要和开发进行讨价还价的时候，放弃一部分次要的样式，集中精力来处理一些重要的内容。要有目的性的把整体视觉样式迭代拆分成多个版本来完成，每个版本见缝插针，而不是一口吃成胖子指望前端工程师进行 007 强行军。
第 3：单纯和你有矛盾，不想做你的需求
产品、设计、程序员之间如果有矛盾，一般不会是一天两天产生的，而是长期积累下来的。如果关系已经恶化到不能调和，那么需求的执行只能依靠公司规章，或者同对方上级沟通强行推进（也可能推不动）。
如果关系还有挽回的余地，你又想顺利推进设计落地，那只有主动低头示好一条路能走了。因为设计和开发是没有从属关系的，只能晓之以情动之以礼，强势的压迫只会获得相反的结果。提升自己的专业能力，沟通能力，全局观，站在别人角度思考做出有效的让步，才能长期维护协作关系的紧密性。
第 4：看破职场沉浮，一心躺平
这种情况接近无解，当一个员工选择彻底躺平，就已经放弃追求和责任感。除非你们的私交非常好可以站在基友、朋友的角度上做感化，否则只能全部改成最简单的方案。
如果和你对接的前端都已经躺了，而你又是个有追求的设计，那给你们唯一的建议：
跳槽……
上面的建议，与其说是解决方案，不如说是如何 “妥协” 的方案。
这是一种无奈的客观要求，任何行业的设计，都是一个针对理想方案和现实情况进行妥协的过程。强如苹果，也在极度追求轻薄后重新增加了笔记本的厚度和散热模块尺寸（变成砖头）。
固然我们可以用圆滑的处事方法和职场生存技巧处理样式实现不了的问题，但一个真正有职业精神和追求的设计师，会在项目初期就做好开发可行性的研究判断，而不是等到设计都输出完了再做调整。
让可以遇见的问题扼杀在摇篮中，项目的推进效率才会更高，留给视觉交互的开发时间才会更多。
想要尽量避免开发做不了的问题，就要满足下面的条件：
掌握基础的前端技术逻辑 前期进行开发可行性评估 培养和开发团队的协作默契 掌握前端技术逻辑这个观点以往的分享已经讲烂了，但还是不能不提，没有任何前端技术认识是绝对没办法判断设计的可行性的。
拓展阅读
设计师学前端有用吗？来看腾讯设计师的分析！ 凡事编程类课程广告找上门来，我都会立马拒绝，以为我真心不鼓励设计师盲目学习代码，包括前端。
阅读文章 >
掌握 HTML + CSS 认识静态页面的布局，是唯一要涉及到需要自己上手做练习的地方，这个我们过去录制过对应的教学，顶多一周就能掌握。其它的部分，就是理解 JS 或 React、VUE 是什么，前端语言的基本认识和功能实现逻辑，还有诸如响应式、API、封装、异步等术语的意思。
除了 JS 建议花一周时间看一些入门教程，其它的专业术语学习，就是在工作中碰到什么百度什么，全都有非常基础的科普扫盲。
第二，就是在每次项目前期，将你认为可能会遇到的技术问题提前和开发商议。比如特殊的业务组件的复杂交互方法，界面框架响应式的变更，特殊动效的动画形式，图表的自定样式等等。
掌握越多的前端知识，可以发现的问题就越精准。在构思设计方案的阶段觉得有开发难度，又拿捏不准的地方就一定要提前和开发通气，排除掉不合理的，确定出具体的实现方向。
这可以避免很多没必要的问题，以及建立开发在界面实现方向工作量的预期，这点非常重要。因为设计稿没拿出来之前，对前端开发来说就是盲盒，很可能会收到一份意想不到的 “大礼”。只要预期可以建立，项目进度又不是非常迫切的话，专业的前端都是愿意尽量配合设计师实现一些更优或者更有挑战的效果。
在过去，我和不同团队的前端工程师都会预留一部分的时间，进行特殊的效果尝试，尝试不同的技术方案和可能性，即使他们最终不一定能落地，但这可以非常好的提升各自的专业水平和眼界。
有效的前期沟通也是专业性和获得话语权的关键操作，因为沟通意味着协商，协商意味着尊重，对技术人员尊重的缺失就是后面会被针对的主要问题之一（另一个是菜）。试想一下，你们的老板还是运营、市场人员，不咨询你的意见也不管你的能力范围，指定要下面这些效果的 Banner 还是 H5，你会怎么想？
能满足前面两点，就能追求第三点，培养和开发团队的默契了。优秀的产品团队产品、设计、开发都要有一定的协作默契，这样可以减少很多不必要的沟通成本。默契是多方面的，包括了解双方的工作流程，每个阶段要做什么，怎么配合。另一方面，是了解对方的技术水平，擅长哪个方面，做出正确的评估，交付对应的成果。
这是在半年到一年以内可以实现的目标，当你了解对接的前端工程师主要熟悉哪些技术栈、框架，技术水平、工作投入程度，你就会对怎么沟通，提供给对方什么样的设计内容有更深入的见解。
虽然我们不能确保每次项目中所有界面技术问题全能在前期完美解决，但我们的目标就是尽可能减少到项目后期开发说 “做不出来”，再浪费时间在争吵谁听谁的问题上。
理解完前面的内容，就可以进入最后的重点。针对面试中开发说 “实现不了” 的回复框架：
找出原因：开发说实现不了，我首先要和对方确认并判断实现不了的原因是什么，是技术上的难点还是时间不够，而不是无理由强行推进自己的设计方案。
解决方案：如果是技术上的问题，我会和程序员商量解决方案再做调整，来适应落地需要。如果是时间不够，那么我就会评估相关内容的优先级，放弃一些低优先级的设计需求留到后面版本再实现，集中精力在核心需求的开发上。
提前避免：当然，除此之外我会尽力避免在设计完以后才知道实现不了。第一是我会积极掌握前端的相关技术内容，具备技术难度的初级评估能力。第二是我会在每次动手设计前，通过一些基础原型和程序员做更具体的开发可行性评估，提前调整不合理的方案。第三，我会在长期的研发过程中培养和前端团队的默契，尽可能提升设计落地的效率，从而预留出更多时间来实现更好的用户体验或视觉效果。
这类问题主要考察的就是设计师针对项目实施的态度，是只在意你自己的想法，还是把团队产出放到个人喜好之上。以及你的团队协作潜力，一个缺乏协作精神的设计师，越有优秀的设计能力或者吹毛求疵的态度，越是项目研发中的负资产。
所以，上面的回复框架大家可以根据自己的理解修改，或加入过去实际经历过的案例做说明，让它更有说服力！
本次的分享就到这里，如果还有一些遇到不知道如何回答的面试问题，也可以发到下方留言中。
我们下篇再贱～
欢迎关注作者的微信公众号：「超人的电话亭」
