前言

“这个做不了、很难做的啊、我没时间啊、改这个有什么意义吗？不是上次刚改过么怎么又让我改？”

“我都没见过哪个设计师像你这样，不就几个像素而已？有必要扣这么细吗，能用就行了啊。还改？！我觉得这已经很好看了啊，这么搞很麻烦的啊……”

各位设计师是不是已经开始按耐不住摩拳擦掌了，以上场景在跟开发提需求和设计走查的时候经常碰到，或是无奈或是生气，但开发就是有无数种理由拒绝你。

毫不客气的说，这个问题一般都会在你职业生涯的中的某个阶段碰到，或早或晚，虽迟但到一般不缺席。

想必很多设计师都踩过下面这个坑…

上线后还原不到位被领导职责“你这设计怎么做的，为什么这里设计成这样?”

一对设计稿，一把辛酸泪…你正想极力辩解，不好意思，领导说

“我 只 看 结 果”

就问你气不气？气不气？

开发到底为什么拒绝你？

收起大刀，咱先分析一波。这个问题不会随着技术的变化而改变，也不像是方法论拥有固定的解题策略，但是在面试中又经常碰到，比如“开发不配合、还原度不高时怎么办”。这足以说明很多公司都会有这个问题，骑士说到底还是人的问题，那我们就来看看“当事人”是怎么说的。

由于某些原因对接过很多开发，也咨询了几个前端朋友。不管开发口头拒绝的原因有多么千奇百怪，一般情况下，开发反感或者不愿意配合设计还原都可以归纳为以下几个原因：

1.业务紧，任务重

也许是项目赶着上线，也许是一堆需求还未交付，当开发手头有更重要的事情要处理时，他没办法分心或者用额外的劳动力去做设计优化的内容。

很多时候给定的工时就那些，若是跟绩效挂钩就更别提了。老子做需求改bug已经要加班了，还要我配合你调来调去的，是你还会有这个心情吗？

因此设计师也要关注项目的整个排期，尝试着去宏观把握项目进度，做到理解或评估开发的工时。多站在对方的角度考虑现状。

再者就是要判断走查结果的优先级，开发侧的用户体验因素如性能、bug数等要优先于界面还原。毕竟用户体验并不等于界面的开发实现。

当连bug都没修完的情况下，还死盯着几个像素去抠显然是不妥的。完全可以先把低优先级的问题记录下来，留着某个版本再一起更新优化。

2.有背职业方向

前端的方向一类偏视觉展示的（动效视觉还原组件搭建等），一类偏数据层面的(算法之类)。共性都需要比较强的数据处理和逻辑能力。

有些开发会十分明确自己的方向，比如往算法类的会认为专注视觉还原侧是在浪费时间，因此在面对该类需求时内心会产生一定的排斥心理。他们经常不关注体验这种东西。

其实像还原这种的都算开发底层的基础能力。就像UI有的偏交互有的偏视觉，但一个偏交互的UI说不愿意画图标这说不过去把。说到底本职工作还是设计。

3.水平不够

设计圈里都流传着这样一句话“没有实现不了的效果，只有不想做的开发”。

不想做更倾向于是态度问题，不会做是能力问题。但所有技术不都是由不会到会么，况且大部分的还原问题借助搜索引擎是可以解决的，只是要权衡学习成本与收益的问题。若是实在基础的问题都不愿意去做，必要的时候可以让设计领导同开发领导反馈。

4.价值观不一致

有部分开发会不认可设计，你跟他谈对齐亲密性，他跟你说听不懂要下班；他不想也不愿意去接受或了解设计的作用，沉浸在自己的认知体系里，自然也就不会认同你。这种是很少数了，只能说是公司招人不慎，可以尝试多次沟通，依然无果后，与领导反馈。

以上就是常见的开发不愿意配合的原因了，有些情况会由于客观条件确实难以解决，有时候可能睁一只眼闭一只眼就过去了。

那么有什么其他的办法呢？

设计师该怎么做？

开发本身的问题很多时候我们作为设计师没办法介入，作为设计师，更应该从自身出发去解决问题。

掐指一算对接过的开发也不在少数，软磨硬泡，用尽毕生所学与其斗智斗勇，在耗尽气力之前终习得了一点心法同大家探讨，文末也一同附上了所有用到的工具和宝典配合使用，希望对大家有帮助。

1.良好的沟通是前提

所有的合作都是基于沟通进行下去的，好的沟通方式会直接决定结果。别一听开发不愿意做上来就急眼干架，友谊的小船说翻就翻，都是同事，不出意外以后还要天天见面的。这样只会显得自己更不专业，冷静冷静...

首先要保持客观，聚焦问题。作为设计师要明确方案解决的问题是什么，为什么要做这个方案，尽可能地深入剖析问题根源，试着对着一个问题连续问自己5个为什么。

这样在对接需求时，既能做到证明自己的方案是对的，同时也可以游刃有余的回复对方的疑问。

另一方面，在沟通或设计评审时，可以广泛的听取他人的建议，每个人的出发点和认知是不同的，这就意味着看待问题的角度会不一样，多记录并思考别人的视角会更加拓宽自己的思维，这也有利于设计交接。

说了这么多，举几个最常见的可直接落地的实际方案：

1.条件允许的话，搬个凳子直接坐在开发旁边磨（前期最好也可以带点小零食慰问品，收了礼总得给个面子改改吧，这招通常都很管用），面对面沟通细节是最高效的。

有一些开发压根不懂设计，基本的对齐都看不出来，不是不愿意做，是真的看不出来。不要笑，一大把。这种方式虽然前期比较耗时间，但既可以培养感情，同时比聊天式的沟通更清晰高效。

因为面对面的沟通能够感受到你的情绪和状态，有句话怎么说来着“线上聊千遍，不如线下见一面”。

2.尽量跟开发混好点。比如有球局就一起去打打、有机会就一起吃吃饭、平时有聚会就多玩玩唠唠嗑。混熟了调个样式什么的那还不是分分钟的事情。什么？你说你是女的，那简单，撒个娇卖个萌开发顶不住的。

3.在解释自己的方案时，可以用“我有解释清楚吗”而不是“我这么说你听得懂吧？”多站在听者的角度去阐述。

4…...

2.有一定的前端基础常识

想必很多从事设计师的朋友一部分原因是被代码劝退了，二选一选了设计。

设计师没有要求一定要会写代码，但做到看懂一些常规的内容其实不会很难，一方面提高我们走查还原的效率，一方面也是自己“专业”的体现，提高开发信任感，同时沟通也能更顺畅。

2.1 熟悉主流UI框架

当前市面上最主要的就3个：移动端H5的 Vant，PC端的 Element 和 Ant。官网都有组件库的源文件，导入sketch就可以直接调用了。

这里顺带提一嘴，element 是基于vue开发的，而ant主流是react，但也有vue版（https://2x.antdv.com/docs/vue/introduce-cn）

因此动手前一定要提前跟前端确认用哪套框架再进行设计。尤其是B端，非大团队是没有足够的人力和资源去搞源生的。大部分公司前期的开发都是基于ant或Element，可直接用官方组件做设计稿。

考虑到开发效率与成本，基本上样式都是基于框架调整的，所以碰到差距非常大的样式最好是提前跟前端确认。

2.2 走查工具的应用

再提工具之前，建议大家学习一下“盒模型”的概念，它是前端设计布局还原设计稿的基础，下面要讲的工具也会用到，偏幅有限，关于盒模型的内容就不展开了，有兴趣的可以自行搜索。

不知道大家有没有遇到过以下这种场景：

开发上线后发现实际效果跟预期的有点差距，可能想微调字体大小或者间距或者某个颜色，要么屁颠屁颠求开发大爷调整一下，要么就自己再用软件做调整试错，这些方法也不是不行，但是有种更快捷的方式。下面提到的两个工具就可以帮到你。

2.2.1 浏览器审查定位，快速试错

第一步：键盘F12或鼠标右键点击“检查”调出如图所示的代码界面。

第二步：点击右上角的小箭头，再移动到左侧页面寻找你想查看的任何元素，比如“UI设计_百度百科”，鼠标移上去时就可以看到基础的元素属性了。

第三步：单击刚刚要选择的元素“UI设计_百度百科”，在右侧就会自动定位到对应的代码，双击可以自己随便打字，按enter立即生效，有时候测试文本极限值的时候用这个方法就不用再打开sketch敲文本了。

第四步：定位元素，设计试错。重头戏来了，还是选中刚刚的“UI设计_百度百科”为例，点击代码块右上角的“Computed”，很好，现在引入眼帘的这个大色块就是传说中的盒模型了。简单理解就是前端在实现时，每个元素都用类似于盒子的这种模式一层套一层实现的，没错，你也可以理解为套娃。

鼠标移动到对应的某一层，就可以看到每一层对应在界面的哪个位置。比如这里的padding就是对应左侧界面的绿色条高度：10px。

那快速试错又怎么理解呢？比如我们现在想调整“UI设计_百度百科”上面的间距，点击下方的“Filter”，输入padding就可以看到这个数值了。

点击箭头直达修改路径，双击修改直接生效。

要改其他的属性同理。这样就避免了请开发大爷帮忙，也省去了用软件去调整试错设计效果了。

为了方便大家理解，我录了个小视频，大家可以直接配合食用。

可以点击原链接去公众号查看。

以上的方法技巧比较投机，适合实在害怕或者没有时间学习代码的同学，用这个方法可以帮助你省下很多时间。

当然这只是很小的一个例子，应用在各种场景后会有很多新发现的，就比如某些在线设计的网址可以用这种方式拿到原始图片，大家可以自己多去尝试。

2.2.2 走查神器：CSS Peeper

CSS Peeper 是一款Chrome浏览器插件。主要用来辅助走查，如果你是得了看到代码就头疼的病，F12审查也帮不了你，那这款绝对是你的最佳良药了。嗯，坐稳了，我要开始装逼了。

1.快速查看元素属性以及间距。字号、行高、色值、字重、元素间距，哪里不懂点哪里，验收原来还可以如此轻松。

2.预览网页所有色值。只要有不按规范的基本无所遁形，全站色值给你扒过来，查颜阅色，我是专业的。

3.一键下载网站图片素材。下载图片什么的那是信手拈来，图标banner任意素材，只要你是图，我就下的来。盗图20年，从来不知道什么叫禁止下载。

这，就叫专业，就问你香不香吧。

以上两款都可以帮助我们快速的验收，回归主题，这一节主要提到的是了解前端基础常识，其实主要还是为了更好的交接，说到这就顺带提一下设计交付的小技巧：

1.除了交付静态图外，还要带上交互说明。比如基础的字段极限值、图标的hover、禁用状态、适配方案等等，这些是产品不一定考虑的到的，在设计执行过程中可以另起一个画板一并写下来，避免开发时的频繁沟通。

另外涉及微交互/难实现或难描述的样式，都可以拿现成已上线的成品给到开发去做参考，直接调用代码、学习或改动都可以增加他们的效率或者提高他们去做的意愿。毕竟说再多不如见一面，动态效果总比文案描述要容易理解，不是所有开发都能够看一眼静态图就知道怎么实现。

2.设计稿完成后在交付开发时要有一次正式的交接。也可以带上测试，大概阐述一下设计稿的一些还原、交互难点以及注意点，毕竟还未正式介入开发，若有问题可以及时处理。小的问题一般在开发执行时才会碰到，到时再给到设计支持就行了。

3.注意标注平台的设计稿布局和分组。先给大家感受一下普遍的在线平台设计图，包括但不限于蓝湖、慕客、Codesign等。

很多时候画布一多，设计稿全堆一起，就算是设置好顶对齐，隔开间距，但还是遭不住一多就难以定位的问题。

开发一点进来，我是谁？我在哪？我要点哪里？图一多就乱难免会引起一定的不适感。

那么有什么解决办法吗？

这个时候可以把设计稿按类别/模块整理清楚，一个模块的设计稿尽量不要超过10张，多了就考虑建一个子类别，另外要多建一个画板做好分组。

同时平台自带的分组功能也要应用上，设计稿的命名也要准确便于利用搜索去定位。

最后就是按版本建立大的文件夹存放设计稿。切忌所有的稿都放在一个画布里，多了不方便找是其次的，卡到想你锤烂屏幕的心才是最难受的。

既然一直谈体验，那么看稿的开发就是我们的核心用户了，好的阅览体验说不定能带来更高的代码效率呢。千万不要小看这些细节，都是一些小事情，无外乎命个名以及拖动拖动画板，耐心一点也就几分钟的事。这些都是个人能力与专业的体现。

3.建立走查机制

前面讲的都是基于个人角度出发，而建立走查机制有点偏团队侧了。将走查纳入整个产品设计流程的一部分，提测后就可以进入走查阶段了，过程中需要记录并与开发沟通修改还原问题。

一来可追溯防背锅（你懂的），二来让还原的问题有沉淀，方便我们去记录和复盘。

类似这样的表格模板，因为各个团队大小和工作模式都不一样，所以字段会有所差异，有的也有产、设、测共同维护的表。这个可以按实际情况参考这个模板适当增加删减，另外走查时除了视觉类的，也可以通过交互自查表去做一些验证，查缺补漏。

其中特别注意的一点就是走查反馈尽量写的细致一些。比如截图后在图片上带上箭头指向，同时配合文字填写在“问题描述”那一列里，是间距差了还是不对齐等等，有色值给错的就把正确的色值也标注上。

最后，就算存在赶时间赶项目的情况，也要有基础的设计底线，有些原则性的内容不能随意更改，比如通用的设计准则、一致性等，设计师需要根据实际情况把握好这个平衡点，对走查内容做筛选沉淀。

4.提升设计在团队的影响力

这里的“设计”不仅是指设计师本人，还可以引申到具体的设计输出、设计团队等一切跟设计相关的人和事务。

比如做一些设计知识分享、设计团队（或个人）项目的复盘总结，让结果呈现更加的专业化，期间还可以引入用户的声音、用户研究结论、数据分析等。这些都是建立信任、提高影响力的方式，长期执行下来会带来很大价值的。

5.培养开发的用户体验意识

开发的设计意识越高，设计落地自然就越顺畅。一方面通过上面提到的技术分享耳濡目染，不断提高开发侧的设计认知。

另一方面相关考核可以把开发侧的用户体验因素权重提高。比如，稳定性、性能、系统资源占用与消耗、bug数、bug解决率等，同时在招聘时也适当做一些筛选。再者就是常说的界面还原度了，视觉、交互动效与优化等，可以通过验收次数等来做一定的量化。

不过要达到这一点比较难，尤其是刚建立的小团队。过程涉及多方协作，还要具体看开发侧的认知和配合情况，需要基于人和现有的工作流去建立起设计共识，因此还是得细水长流，逐个攻破。

结尾

以上提到的种种是对开发不配合，设计难还原等相关问题的思考，经验有限，不一定能解决所有情况，具体的落地也会因人而异。如果实在接受不了也改变不了现状，在实力允许的情况下大不了就换咯，大团队在流程上肯定要更规范和成熟的。

我也遇到过很贴心的开发小哥，他甚至可以与你一起探讨解决方案，视觉还原什么的都是基操，压根不用你担忧。这种的开发只能说是可遇不可求了，碰到了一定抓住好好珍惜~

资源获取

关注公众号“Andy聊设计”，回复“设计前端一家人”即可领取文中提到的交互自查表、走查插件等源文件资源。

还在为开发还原而烦恼吗？抱走本指南

对所有的烦恼说拜拜~

对所有的开发说嗨嗨~

我是设计师Andy，拜了个拜~