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