作为前端开发，这些年跟设计师的斗智斗勇

我无意中在知乎上看到这样一个话题, 让我不得不有感而发。

因为曾经的我也是被设计师给虐惨了。

我是工作了 8 年的老前端了， 如果算上实习那就有 9 年了。

我做过 C 端应用， 做过 B 端应用， 做过 SaaS 应用， 我经历的所有设计师， 都不接受 0.5px 的像素偏差。 可以说是对像素偏差 0 容忍。

所以想作为前端工程师， 来来给大家聊聊我的日常工作中是怎么跟设计师斗智斗勇的。

1. 给设计师设置门槛

这个设置门槛意思很简单， 你不能拿着电脑， 指着我屏幕就说， 这这这不行， 那那那不行的。

你得走系统工单， 一个样式一个工单。 得注明， 哪儿样式不对齐， 差多少像素， 预期重新验收的时间， 走查报告， 样式走查进度等等。如果没有系统工单的流程， 搞一个复杂的文档丢给设计同学也行， 让设计师同学把每一个问题都尽可能的详细记录下来。

还要明确设计走查验收时间， 定稿的设计稿件， 非特殊原因不允许修改等方式， 增加设计师自身的成本。

和设计师合作完成一个项目， 完成之后大家都分蛋糕， 自己改样式是有成本投入， 设计师别人是零成本投入， 哪儿那行？ 所以这个就是门槛的来源。

2. 告诉设计师我修改某一些样式的成本， 这个成本超过了预期， 需要设计师额外承担成本付出

举一个简单的例子哈。 设计是要求做 移动端 和 PC 端兼容， 我预估做移动端和PC 端兼容， 需要 5 天时间。 已经拍板定下来了。 做到了一半， 设计说， 我的移动端， 要适配 小屏幕手机和大屏幕手机以及 平板 拥有独立的样式展现。 这个成本是预估之外的额外成本， 可能需要多加 5 天时间。 那么这个 5 天时间， 是需要设计师去向项目经理申请的， 项目经理如果同意， 多给我加五天我就做。（其实相当于转移矛盾）

3. 给出设计师无法拒绝的理由

就说到了静态和动态的问题了。 比如设计师给了一个版本的设计， 是没有数据情况下的设计， 但是前端数据加载出来了， 渲染出来的结果， 跟设计师预期的不一样。 而且设计师自己也没有给设计稿。 这个就直接专业碾压就行了， 黑话直接就来，比如：我的架构能力已经做好了， 实在是改不了了， 否则的推翻了重新做； 你这个 1 PX 的像素偏差， 真的有必要吗，你如何论证你这部分必要性；它是一个共性问题，以前的需求都是这样子的， 如果你这次改了，那之前的那些样式也都改吗，否则是不一致的；..........

这个方向， 就是主要针对一些可有可无的样式调整。如果修改成本较大， 而且设计稿本身就模棱两可的， 就可以使用专业知识碾压。

4. 设计稿变动要周知

其实很多时候在开发过程中是， 会出现一个情况， 设计师改了设计稿（在没有跟前端同学商量的情况下改了设计稿）。这个我相信是很多前端同学最头疼的事情之一。

我之前合作过一个设计师， 很喜欢临时改设计稿，但是改了又不周知，让我跟着后面反复改， 最后项目导致了一定时间的延期。 最后项目复盘的时候， 我就直接跳出来喷这个情况，有理有据，让 leader 们去核算这部分成本了。

其实一定要达成一个一致意见， 甚至可以在做项目之前就商量好， 如果遇到设计稿变更， 导致开发工作要返工的情况， 总计返工超过 0.5 日的情况， 要提出需求变更，不通过需求变更的设计稿变更， 一律不接受。

5. 提升自己专业能力

最后这个没啥好说的， 吃这个饭， 就的接受这个设定；尽量想办法还原设计师的设计稿即可。

曾经我也常被设计师折磨得体无完肤， 甚至想过要转行算了。 想想， 后端同学还不是一样被数据、稳定性、服务器运维等问题折磨得体无完肤。 各行都有各行的难处， 吃这个饭就得接受这个设定。

提升自己专业能力， 只会有利无害， 就比如我现在也能算是半个像素眼。