无意挑起所谓的职位之间的矛盾，直到今天看到这样一篇文章的时候，是的，这是一篇关于程序猿和设计狮之间的文章，起源是这样的，一位网友在某社区上提了一个问题：
开发人员拒绝按照 UI 标注还原设计，如何让他理解精确还原的重要性，从而去修改代码？
当一个开发工程师屡次发问「这里让我移1px有什么意义，我为什么要浪费时间这么做」且拒绝修改时，如何让这位开发理解、认识到修改的重要性？
为什么国内很多视觉设计师得为了那些虽然看起来很细碎、甚至可谓之鸡毛蒜皮——但对于设计师还是很重要——的细节追着工程师去修改，一项项列出问题，却得不到工程师正面的回应？举个例子，听同事介绍过 Frog 的工程师会为了不影响视觉设计师工作，自己开发出检查设计还原的软件进行还原检查修改。
是什么背后的原因令产品的设计实现这么困难？是因为设计师不懂代码？部分技术人员的审美意识？还是大厂心态或者其他什么原因？这种状况怎么解决？到什么时代或是契机才能够被解决？
嗯，不出所料，顶到最高的回答是这样的。
限于篇幅，全文请大家复制链接到浏览器查看，链接为：http://zhi.hu/8lyF
通篇文章中，作者不遗余力地对设计师进行污蔑和调侃，甚至将话题转移，文中写到：
对于软件开发而言，码农的工作是必需的。设计师的工作是可选的。
没人做设计，软件也可以用。实际上在扁平化的今天，许多开发比如 iOS，系统默认的模版虽然不好看，但也不会是个毛胚房。但没人写代码，那就是屁也没得。
工作的重要性决定谁听谁的。就是这么简单。
嗯，静电看完后，唯一感觉是：这是黑社会还是自我感觉太良好了呢？如果说用户群决定了回答的质量的话，我一点都不怀疑，除了对这个社区表达一点点微弱的反感情绪外，静电还想对现实中设计师和开发的关系写一点自己的心得和体会。
首先表明立场，静电是位设计师，懂一点代码以及产品。
缘起1像素，改与不改？
作为一个负责任的设计师，一像素对他们来说，重不重要，如果说不重要，那静电认为这不是一个合格的设计师，因为这是设计师的本职工作。
如果说重要，有的人会说，这个世界上没有完美的事物，安啦安啦，不改也没什么大不了，别折腾啦！
当他们去求助开发想改掉这个问题的时候，开发可能会说，改这个工作量很大，需要很多时间，况且只是一个像素的问题，没什么大影响，不要改了。
产品经理说：我们最终的目标是保证产品快速迭代，保证核心功能没问题即可。1像素不用调了，浪费时间~
别折腾啦，别折腾啦，别折腾啦！
这个时候想的开的设计师估计会放弃这样的执着，虽然心有不甘，但也无可奈何，心想：不改就不改吧，所有事物都是不完美的。
随着时间的推移，一像素问题就这么越来越多。最终，当有成百上千的一像素问题积累到一起的时候，突然有一天，用户说：“这个软件（网页）怎么这么丑？你们的设计怎么做的？能力不行吧？”
设计师周围的所有人：“这个是你设计的问题，你就不能好好设计吗？你的水平有问题！态度有问题！”
设计师：“…”
我想这是发生在我们所有人身边的事情，最终一款乱糟糟的软件（网页）就这么上线了。至于市场反响，你懂的…
我想这个时候设计师心里肯定有一万头草泥马在奔腾。
一个烂产品就是在无数的妥协和一像素的错位中产生的。在当今产品同质化严重的情况下，用户自然会选择界面美观易用的产品。
没人做设计，软件也可以用？
是的，可以用，没人做设计，软件绝对可以用，就是用着很纠结就是了。举个例子，当人类还在远古时代的时候，大家伙都是吃生肉的，没人觉得不妥。后来呢，有个爱折腾的SB（不好意思用这样的词，大家抱歉）对大家说：“那啥，其实用火烤的肉更好吃哟”，我估计当时有很多对他说：“你瞎搞毛线啊，生肉就是好吃，吃生肉就够了，吃烤的多麻烦！”。但最终熟肉还是战胜了生肉，结果就是后来大家没人吃生肉了。静电想说的就是，凑合不是不可以，但凑合已经无法满足当今人们日益提高的审美需求了。人们不仅要吃饭，而且要吃饱饭，然后还要吃得美味。
设计存在的价值亦然。至于知X上某人的言论，程序是必选的，设计是可选的。静电除了呵呵，还想附带释放嘲讽技能：“其实程序也不是可选的，因为吃饭才是可选的，活着才是可选的，其他神马的，都特么见鬼去吧！这位仁兄，你说对吗？”
当设计师开始写代码，程序员开始尝试设计的时候，你在做什么？
其实一像素的问题压根不是问题，在设计师完成设计稿，设计缜密，标注明确的情况下，开发人员在遵从设计稿的情况下，还原的程度是非常高的，基本可以到达80%到90%，这个时候的一些小细节，静电建议作为设计师的大家积极与开发沟通协调来解决问题，相信大部分的开发者都是非常愿意帮助我们解决问题的。另一方面，在沟通过程中，设计师也需要从与开发者的合作过程中理解开发者是如何进行设计稿的复现的，代码如何写，布局如何合理，哪些地方是可以避免发生问题的，哪些是可以与开发者一起思考想办法解决的。
静电从事APP开发过程中，电脑上是安装与开发者一样的运行环境的(Xcode)，并使用git保持代码与开发人员的代码同步。这样有助于我们了解软件的产生过程，必要的时候，我们可以顺带学习一些样式调整的小技巧，对于设计师来说，这学到了更多东西有助设计稿的实现，对于开发者，他们一定是非常欢迎你这么做的，因为身边有一个同样会写一些代码，帮他们解决问题而不是提出问题扔给他们不管的人。于是好基友就这么诞生了。
在这个过程中，一个非常好的现象正在发生，由于你们关系的进展，作为设计师的你，在程序员遇到取色或者某些简单的图片问题的时候，你可以非常方便的来帮他，甚至可以帮他装个photoshop慢慢教他做一些简单的图形处理。
这样，相互协作和融洽的沟通就产生了。这个时候，你在做什么呢？是在知X上写一篇酸溜溜的檄文，还是无休止地抱怨对方？
优秀的设计师和开发者——沟通与相互理解
其实我们一直在强调沟通，什么是沟通呢，双方的交流才叫沟通，单方面的讲解，另一方面却无动于衷，不叫沟通。我们之前假设，设计师和开发者都是通情达理，气场不那么相悖的。但万一遇到气场不合的呢？或者对方就是不愿意去改这1px呢？原因可能是：
- 1.设计稿不够谨慎，频繁的改动，设计师请想象一下给客户做东西改到吐血时的情景。
- 2.如果设计稿谨慎，标注完整，但始终还原度较低，低到你无法忍受。那么除了沟通，还有一个能力和态度的问题摆在你面前。如果说初次磨合，我们可以尝试来进行沟通，在双方态度都不错的情况下，对方一般都愿意帮忙；还有一种情况，这个是大家最关注的问题，就是对方极度不配合，这个时候我们需要求助PM或者你的领导作为中间人来协调，成功将矛盾化解，记住，在这种情形下，设计师就不要过于较真儿了，否则针尖对麦芒，结果是两败俱伤。
- 3.当设计师做到第二节描述的做到了体谅和理解的情况下，但对方依旧极度不配合，最终导致产品出问题，这个时候就不是设计师能解决的了，相信你的上级或者领导会对整个情况有更深入的了解和判断。你所要做的，就是做好本职工作完美到没有纰漏即可。因为最终产品的质量已经不是你能把控得了的了，顺其自然。通过其他形式寻找自身成就感。
- 4.没有完善的bug反馈和质量控制机制，将问题归于个体认知所带来的差异而不是流程的标准化。
- 5.沟通不善。我知道设计师您在说要改改改.但开发可能是“…(都不爱理你)”
致我们亲爱的开发者
- 1.我们知道您很忙，每天面对无数的代码看花了双眼，无数bug需要修改，但我很想学一点代码来分担你的痛苦。
- 2.我们知道您并不是low爆的没品位的代码狂人，您的内心一定有对完美的追求。
- 3.请您理解沟通是双向的，很多时候，我们需要您来告诉对代码一窍不通的设计师，怎么做更好。
- 4.我们知道简洁优雅执行效率超高的代码是您毕生追求，但与设计师一起合作修改一个像素的问题，说不定也很好玩呢？
- 5.我们的最终目的是一样的，作出一款让人满意的产品。请相信设计师的专业程度，尽管您可能比他更有才。
- 6.设计师很乐意帮您在电脑上安装一些更方便您进行界面开发的小工具。
- 7.请不要再说：“程序要是会ps，要美术干嘛？”这样伤人心的话。
致自己——为1像素努力的设计师
- 1.严格要求自己，一定没错。请认真对待自己的每一个设计稿和每一个1px。
- 2.如果你被甲方的变态客户蹂躏过，请考虑一下，你现在作为甲方是如何对待“乙方”的。
- 3.如果一个像素可以调一次，那就不要调两次，如果反复调节多次，最好跟开发道个歉，然后学习如何自己调。
- 4.学习简单的代码，其实它们没那么难，甚至还挺好玩，试着求助工程师，让他们在你电脑上装一个开发环境，相信他们很乐意帮你。
- 5.我们的最终目的是一样的，作出一款让人满意的产品。请相信开发者的专业程度，尽管你可能比他更有才。
- 6.请相信，未来职业之间的区分会越来越模糊。你就是这样一个会写代码的牛逼设计师，也许是一个懂设计的产品经理，让他们羡慕去吧。
- 7.试着相信，每个开发者都是可爱且善良的。如果你无法相信上一句，请不要放弃寻找。
最后，我爱每一个工作认真敬业，懂的上进，有追求的设计师和开发工程师。