一像素的恩怨情仇,程序猿与设计狮之间的那些破事儿
一像素的恩怨情仇,程序猿与设计狮之间的那些破事儿-移动阅读二维码

无意挑起所谓的职位之间的矛盾,直到今天看到这样一篇文章的时候,是的,这是一篇关于程序猿和设计狮之间的文章,起源是这样的,一位网友在某社区上提了一个问题:

开发人员拒绝按照 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。试着相信,每个开发者都是可爱且善良的。 如果你无法相信上一句,请不要放弃寻找。

最后, 我爱每一个工作认真敬业,懂的上进,有追求的设计师和开发工程师。

jingdesign公众号: jingdesign91

——————————————————————–

附:@alienbat 知乎回答, 原文:http://zhi.hu/8lyF

“举个例子,听同事介绍过 Frog 的工程师会为了不影响视觉设计师工作,自己开发出检查设计还原的软件进行还原检查修改。”

Frog很牛掰嘛?是业界典范嘛?
本座只知道Google至少在2012年的时候还是绝对的工程师文化,设计师没有话语权,别说1px,程序员能把界面做得像设计师的图样,设计师就感动得哭泣了。知道为啥Google的界面都那么死板不?因为程序员首要考虑的是这个界面可否运行全自动单元测试,设计成全白背景单色图标之类,UI组件容易被单元测试代码定位。当然了,Google的设计也确实不好用,Geek气息十足,而Google近年来也确实开始重视设计语言(Android L等);不同的公司有不同的侧重点,你作为设计师跑到不同的公司地位也会是不同的,这里并没有统一的标准。

好了八卦完毕,开喷。

首先请LZ摆正姿态,说个很直白很糙的道理:

对于软件开发而言,码农的工作是必需的。设计师的工作是可选的。

没人做设计,软件也可以用。实际上在扁平化的今天,许多开发比如iOS,系统默认的模版虽然不好看,但也不会是个毛胚房。但没人写代码,那就是屁也没得。

工作的重要性决定谁听谁的。就是这么简单。

===============

本座作为开发团队首席,再谈具体工作中的问题,以iOS为例。

设计师不懂编码,不懂软件工程。这里并没有“看不起”的意思,事实上设计师不可能像程序员一样对软件平台了解到代码级的细节程度,分工不同。但这一点就决定了最终产品不可能百分百还原产品原先的设计:

1. 你的设计本来就不可能照顾到所有的方面。你可以画一个iPhone 5的1:1的界面示意图,但你会把iPhone4, iPhone5, iPhone6, iPhone6+各种不同分辨率都画一遍吗?你会把每个屏幕每一种可能的情况都示意出来吗?软键盘升起的时候UI是什么表现?文字标签的动态文字在有限空间下根据长度动态缩放是什么效果?不同界面之间的动画过渡是怎么样的,动画时长是多少,等等。设计不可能面面具到,而这些细节最终都要工程师自行定夺。

2. 你的设计可能在Photoshop里就是加个滤镜的事,但软件上就是难以实现。举个例子,有个设计师要求实现全屏动态高斯模糊效果(注意不是iOS7的白色毛玻璃效果)。要做不是不可以,开个OpenGL窗口然后加上高斯模糊的pixel shader应该可以吧,然后一个app占用20%的GPU就是为了某一屏能高大上。犯得着吗?

3. 即使你的设计在技术上可行,从软件工程方面必须考虑这个设计带来的系统复杂度,性能影响,等等。比如那个动态高斯模糊,如果是个游戏那肯定要做,但你一个普通app在某一屏要用高斯模糊,我犯得着给你上OpenGL吗?很多时候要有权衡,比如动态高斯模糊不能做,但是静态的可以,这个时候让设计师有点让步不过分吧。

4. 要求px级别精准的话,设计师要在设计文件里明确标定UI元件坐标是多少,长宽多少,尺寸变化的准则是多少(是自动变大?固定大小但是缩小内容?横竖屏切换的时候拉伸至屏幕边缘?按比例拉伸?不拉伸?)。要求程序员打开你的Photoshop文件然后用定位来查找具体尺寸那基本是不可能的事,大家都很忙好不好。再说程序员的工作站上一般不会装Photoshop(License是要钱的我们不用盗版),就算装了,也没有那么多内存在开了一堆IDE窗口的情况下再开Photoshop。你要是不精确标定,程序员也就是肉眼看看然后在界面设计工具里扒拉一下,看看差不多就可以了。另外,界面设计工具可不比你的Photoshop,是看不到最终界面效果的,顶多看个大概,很多情况下(比如动态内容)连“大概”都是看不到的。某些设计师不太能理解这一点。

5. 你提供的素材要非常标准。以字体为例:要么使用系统标准字体,如果要用自带字体的话请保证你那个从网上扒拉下来的字体符合规范。我们就遇到过自带字体不符合规范的情况,直接结果就是导致使用这个字体的标签在视觉上无法跟其他UI元件对齐。再有,裁剪出来的图片请把周边透明部分trim掉啊,2x的图片的尺寸要是1x版本的两倍啊,你出个图片带透明边的,1x明明是44 x 44但2x是90 x 90的,你要程序员怎么给你精确对齐。

====

总结下:

不管是设计师还是程序员,各自的喷点都很多,但一个团队每天早晨的SCRUM meeting时候对喷一下也未尝不是好事。关键是互相理解。但回到最终的问题答案:要最终产品100%还原设计,那基本是不可能的事情,这点大家都要妥协。

—————————————————————————–

关于工作沟通,小编给大家推荐几篇文章:

写给产品经理与工程师:如何与设计师一起工作
设计师工作中的话术沟通技巧
写给设计师:如何与工程师一起工作
设计师的“通天塔”—浅谈设计沟通

 

本文链接:http://www.mobileui.cn/programmers-and-designers-that-things.html
本文标签: , , , , , ,