程序猿与设计狮之间的那些事儿

   很久没聊过设计师职场了,今天说回那个千古难题:工程师与设计师的1像素之争。设计师认为一像素至关重要,非改不可,工程师认为小题大做,精力没花在刀刃上,有的设计师也容易因此沮丧,如果你是其中之一,推荐来看会代码的设计师如何解决这件事。

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

  开发人员拒绝按照 UI 标注还原设计,如何让他理解精确还原的重要性,从而去修改代码?

  当一个开发工程师屡次发问「这里让我移1px有什么意义,我为什么要浪费时间这么做」且拒绝修改时,如何让这位开发理解、认识到修改的重要性?

  为什么国内很多视觉设计师得为了那些虽然看起来很细碎、甚至可谓之鸡毛蒜皮,但对于设计师还是很重要的细节追着工程师去修改,一项项列出问题,却得不 到工程师正面的回应?举个例子,听同事介绍过 Frog 的工程师会为了不影响视觉设计师工作,自己开发出检查设计还原的软件进行还原检查修改。

  是什么背后的原因另产品的设计实现这么困难?是因为设计师不懂代码?部分技术人员的审美意识?还是大厂心态或者其他什么原因?这种状况怎么解决?到什么时代或是契机才能够被解决?

  嗯,不出所料,顶到最高的回答是这样的。

  限于篇幅,全文可右戳查看:http://zhi.hu.com

  通篇文章中,作者不遗余力的对设计师进行污蔑和调侃,甚至将话题转移, 文中写到:

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

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

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

  嗯,静电看完后,唯一感觉是 这是黑社会还是自我感觉太良好了呢?如果说用户群决定了回答的质量的话,我一点都不怀疑,除了对这个社区表达一点点微弱的反感情绪外,静电还想对现实中设计师和开发的关系写一点自己的心得和体会。

  首先表明立场,静电是位设计师,懂一点代码以及产品。


  缘起 1 像素,改与不改?

  作为一个负责任的设计师来说,一像素对他们来说,重不重要,如果说不重要,那静电认为这不是一个合格的设计师,因为这是设计师的本职工作;

  如果说重要,有的人会说,这个世界上没有完美的事物,安啦安啦,不改也没什么大不了,别折腾啦!

  当他们去求助开发想改掉这个问题的时候,开发可能会说,改这个工作量很大,需要很多时间,况且只是一个像素的问题,没什么大影响,不要改了。

  产品经理说:我们最终的目标是保证产品快速迭代,保证核心功能没问题即可。1像素不用调了,浪费时间。

  别折腾啦,别折腾啦,别折腾啦!

  这个时候想的开的设计师估计会放弃这样的执着,虽然心有不甘,但也无可奈何,心想:不改就不改吧,所有事物都是不完美的。

  随着时间的推移,一像素问题就这么越来越多。最终,当有成百上千的一像素问题积累到一起的时候,突然有一天,用户说:“这个软件(网页)怎么这么丑?你们的设计怎么做的?能力不行吧?”

  设计师周围的所有人:“这个是你设计的问题,你就不能好好设计吗?你的水平有问题!态度有问题!”

  设计师:“。。。”

  我想这是发生在我们所有人身边的事情,最终一款乱糟糟的软件(网页)就这么上线了。至于市场反响,你懂的。。。

  我想这个时候设计师心里肯定有一万头草泥马在奔腾。

  一个烂产品就是在无数的妥协和一像素的错位中产生的。在当今产品同质化严重的情况下,用户自然会选择界面美观易用的产品。

  没人做设计,软件也可以用?

  是的,可以用,没人做设计,软件绝对可以用,就是用着很纠结就是了。举个栗子,当人类还在远古时代的时候,大家伙都是吃生肉的,没人觉得不妥。后来呢,有个爱折腾的人对大家说:“那啥,其实用火烤的肉更好吃哟~” ,我估计当时有很多对他说:“你瞎搞毛线啊,生肉就是好吃,吃生肉就够了,吃烤的多麻烦!”。但最终熟肉还是战胜了生肉,结果就是后来大家没人吃生肉了。静电想说的就是,凑合不是不可以,但凑合已经无法满足当今人们日益提高的审美需求了。人们不仅要吃饭,而且要吃饱饭,然后还要吃的美味。

  设计存在的价值亦然。至于知X上某人的言论,程序是必选的,设计是可选的。静电除了呵呵,还想附带释放嘲讽技能:“其实程序也不是可选的,因为吃饭才是可选的,活着才是可选的,其他神马的,都特么见鬼去吧!这位仁兄,你说对吗?”

  当设计师开始写代码,程序员开始尝试设计的时候,你在做什么?

  其实一像素的问题压根不是问题,在设计师完成设计稿,设计缜密,标注明确的情况下,开发人员在遵从设计稿的情况下,还原的程度是非常高的,基本可以到达80%到90%,这个时候的一些小细节,静电建议作为设计师的大家积极与开发沟通协调来解决问题,相信大部分的开发者都是非常愿意帮助我们解决问题的。 另一方面,在沟通过程中,设计师也需要从与开发者的合作过程中理解开发者是如何进行设计稿的复现的,代码如何写,布局如何合理,哪些地方是可以避免发生问题的,哪些是可以与开发者一起思考想办法解决的。

  静电从事APP开发过程中,电脑上是安装于开发者一样的运行环境的(xcode),并使用git保持代码与开发人员的代码同步. 这样有助于我们了解软件的产生过程,必要的时候,我们可以顺带学习一些样式调整的小技巧,对于设计师来说,这学到了更多东西有助设计稿的实现,对于开发者,他们一定是非常欢迎你这么做的,因为身边有一个同样会写一些代码,帮他们解决问题而不是提出问题扔给他们不管的人。 于是好基友就这么诞生了。

  在这个过程中,一个非常好的现象正在发生,由于你们关系的进展,作为设计师的你,在程序员遇到取色或者某些简单的图片问题的时候,你可以非常方便的来帮他,甚至可以帮他装个photoshop慢慢教他做一些简单的图形处理。

  这样,相互协作和融洽的沟通就产生了。这个时候,你在做什么呢?是在写一篇酸溜溜的檄文,还是无休止的抱怨对方?

  

  优秀的设计师和开发者:沟通与相互理解

  其实我们一直在强调沟通,什么是沟通呢,双方的交流才叫沟通,单方面的讲解,另一方面却无动于衷,不叫沟通。我们之前假设,设计师和开发者都是通情达理,气场不那么相悖的。 但万一遇到气场不合的呢?或者对方就是不愿意去改着1px呢?原因可能是:

  1,设计稿不够谨慎,频繁的改动,设计师请想象一下给客户做东西改到吐血时的情景。

  2,如果设计稿谨慎,标注完整,但始终还原度较低,低到你无法忍受。 那么除了沟通,还有一个能力和态度的问题摆在你面前。 如果说初次磨合,我们可以尝试来进行沟通,在双方态度都不错的情况下,对方一般都愿意帮忙;还有一种情况,这个是大家最关注的问题,就是对方极度不配合,这个时候我们需要求助PM或者你的领导作为中间人来协调,成功将矛盾化解,记住,在这种情形下,设计师就不要过于较真儿了,否则针尖对麦芒,结果是两败俱伤。

  3,当设计师做到第二节描述的做到了体谅和理解的情况下,但对方依旧极度不配合,最终导致产品出问题,这个时候就不是设计师能解决的了,相信你的上级或者领导会对整个情况有更深入的了解和判断。 你所要做的,就是做好本职工作完美到没有纰漏即可。因为最终产品的质量已经不是你能把控的了的了,顺其自然。通过其他形式寻找自身成就感。

  4,没有完善的bug反馈和质量控制机制,将问题归于个体认知所带来的差异而不是流程的标准化。

  5,沟通不善.我知道设计师您在说要改改改.但开发可能是”….(都不爱理你)”

  致我们亲爱的开发者

  我们知道您很忙,每天面对无数的代码看花了双眼,无数bug需要修改,但我很想学一点代码来分担你的痛苦。

  我们知道您并不是low爆的没品位的代码狂人,您的内心一定有对完美的追求。

  请你理解沟通是双向的,很多时候,我们需要你来告诉对代码一窍不通的设计师,怎么做更好。

  我们知道简洁优雅执行效率超高的代码是您毕生追求,但与设计师一起合作修改一个像素的问题,说不定也很好玩呢?

  我们的最终目的是一样的,作出一款让人满意的产品。 请相信设计师的专业程度,尽管你可能比他更有才。

  设计师很乐意帮你在电脑上安装一些更方便你进行界面开发的小工具。

  请不要再说:”程序要会ps,要美术干嘛?”这样伤人心的话。

  致自己——为1像素努力的设计师

  严格要求自己,一定没错。请认真对待自己的每一个设计稿和每一个1px。

  如果你被甲方的变态客户蹂躏过,请考虑一下,你现在作为甲方是如何对待”乙方”的。

  如果一个像素可以调一次,那就不要调两次,如果反复调节多次,最好跟开发道个歉,然后学习如何自己调。

  学习简单的代码,其实他们没那么难,甚至还挺好玩,试着求助工程师,让他们在你电脑上装一个开发环境,相信他们很乐意帮你。

  我们的最终目的是一样的,作出一款让人满意的产品。 请相信开发者的专业程度,尽管你可能比他更有才。

  请相信,未来职业之间的区分会越来越模糊。 你就是这样一个会写代码的牛逼设计师,也许是一个懂设计的产品经理,让他们羡慕去吧。

  试着相信,每个开发者都是可爱且善良的。 如果你无法相信上一句,请不要放弃寻找。

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

  作者公众号:jingdesign91


 

时间: 2024-08-31 15:25:46

程序猿与设计狮之间的那些事儿的相关文章

iOS APP体验设计:从程序猿和设计湿说起

iOS APP体验设计不像互联网的体验设计那样,有一堆的方法论和可以"借鉴"的案例. 目前除了苹果的<Human Interface Guidelines>和前Palm的<Zen of Palm>外,没有找到更好的设计哲学和方法论. 事实上,即便认真地研读了HIG和Zen of Palm,甚至是Oolon Colluphid的哲学巨作你也无法严格按照Guideline设计出一款出色的APP.其原因,得从程序猿和设计湿说起. 程序猿 vs 设计湿 最被思想处于上世

程序猿的新博客开通啦!

以前在新浪博客发表代码,由于新浪博客对代码的发表不太支持,所以现在搬家到CSDN,感觉这才是为 程序猿专门设计的博客,很喜欢这里的代码发表格式!赞一个! 原博客地址是:  http://blog.sina.com.cn/iecoder

程序猿日记S01E03

"Wake me up when it's done." 礼物文化 有一次给组员分享程序猿该如何去尽力帮助到其他人,如何赢得声誉.在日常开发过程中,我们在实现业务需求的同时,抽象出可复用的模块,提供API供业务层调用.不同的程序猿会设计出不一样的API,好的设计往往是遵循一定原则的.网上比较经典的是Google API Design指南,可以作为一个模板来Review我们日常的API设计.以前看过一本书,<以用户为中心的软件设计>,一个很重要的思想就是如何让设计的软件更易于

iOS程序猿如何快速掌握 PHP,化身&amp;quot;全栈攻城狮&amp;quot;?

这是一篇以 iOS 开发人员的视角写给广大iOS 程序猿的 PHP 入门指南.在这篇文章里我努力去发掘 objectiv-c 与 php 之间的共性,来帮助有一定 iOS 开发经验的攻城狮来快速上手一门后台开发语言.后台开发语言,就是以"数据接口"的形式出现在我们的开发文档的那个东西!掌握PHP,无论对自己目前的iOS开发工作还是以后个人职场生涯的长久发展,都会大有裨益!最重要的是,PHP本身不是一个玩具语言,而是目前相当一部分公司仍然在用的后台开发语言,甚至包括你目前的公司;这篇文章

iOS程序猿如何快速掌握 PHP,化身&quot;全栈攻城狮&quot;?

这是一篇以 iOS 开发人员的视角写给广大iOS 程序猿的 PHP 入门指南.在这篇文章里我努力去发掘 objectiv-c 与 php 之间的共性,来帮助有一定 iOS 开发经验的攻城狮来快速上手一门后台开发语言.后台开发语言,就是以"数据接口"的形式出现在我们的开发文档的那个东西!掌握PHP,无论对自己目前的iOS开发工作还是以后个人职场生涯的长久发展,都会大有裨益!最重要的是,PHP本身不是一个玩具语言,而是目前相当一部分公司仍然在用的后台开发语言,甚至包括你目前的公司;这篇文章

写给程序猿们的交互设计

编者按:看到此文时恍惚回到自己学习网页的时候,那时候只知有编程,不知有设计.各个论坛大部分时候讨论的也是如何用 Frame 实现页面的分区,如何做出圆角,以及写一大段 javascript 代码或者做个 flash 只为让页面看起来更眩一点.后来 css1.0, 2.0 陆续出现,html 4.0 4.1 以及如今的 html 5 也逐渐淘汰掉了表现样式的标签.视觉传达思想开始陆续进入程序猿与产品经理的视线,从网页到现在的 APP,经历过野蛮生长阶段后,只有那些功能与视觉传达同样优秀的产品才能笑

文艺范儿的程序猿和攻城狮们

文艺范儿的程序猿和攻城狮们 太阳火神的美丽人生 (http://blog.csdn.net/opengl_es) 本文遵循"署名-非商业用途-保持一致"创作公用协议 转载请保留此句:太阳火神的美丽人生 -  本博客专注于 敏捷开发及移动和物联设备研究:iOS.Android.Html5.Arduino.pcDuino,否则,出自本博客的文章拒绝转载或再转载,谢谢合作. 1. 2. 我该如何责备你,我的程序猿 --- 老帅          你的逻辑是云深不知处,自己都找不到归路:你的代

程序猿转型AI必须知道的几件事!

更多深度文章,请关注云计算频道:https://yq.aliyun.com/cloud 历史上AI火过两次,但是最终都已销声匿迹作为结束.这次AI大火的原因:AlphaGo 4比1战胜李世石,相对于一些外行人的恐慌和恐惧,其实很多业内人员在这场世纪之战结束后,都为人类点上了一个大大的赞.因为对于了解AlphaGo背后技术的那些人来说,人类有如此的计算能力和宏观把握能力已经很了不起了.但是,就在前不久AlphaGo2.0在乌镇完胜了柯洁.事实还是证明了人类在某些方面还是有一定的缺陷,毕竟万事万物都

程序猿怎样选择机械键盘

给苹果电脑选机械键盘 机械键盘的轴体选择是见痛苦的事,不知道哪款轴体是最适合自己的,我的第一部机械键盘是 IKBC C87 青轴.青轴使用了一年多,对机械键盘越来越了解,期间跟同事交换使用,体验机械键盘其他轴体茶轴和红轴,最终发现真正适合自己的是红轴. 由于工作主要使用 Mac 电脑,于是便关注起了能兼容苹果按键红轴机械键盘,最早关注的是 Cherry MX 8.0 始终不清楚他对 Mac 的兼容性,官方也没有资料.偶然发现 IKBC G87 升级了,升级版支持 Win跟Mac 双系统,另外得知