技术开发 频道

不懂点技术的设计师不是个好程序员

  【IT168 评论】在开发者这个圈子里,想必童鞋们一定对2014年那场血案有所耳闻,据说当时传遍各个技术、产品交流群…【事件】深圳某公司的五个程序员杀了两个产品经理,血淋淋的案发现场图片让我们倒吸了一口凉气。网上也是炸了锅,针对产品经理、开发与设计师之间的吐槽此起彼伏。刚入行的童鞋,表怕!今天小编要和大家讨论的是处在流程最下游的设计师与程序员的微妙关系…

论设计师与程序员和睦相处

  在我们ITPUB社区中,网友们已经开始讨论——【大话IT】不懂一丢丢技术的设计师你out啦!设计和技术人员都是经常加班加点、已经麻木到没休假的从业者,然而有时候这两个角色又要经常“碰撞”,小编整理了网友们的辣评和建议,希望给新人们一些帮助!

  啰嗦的小编还是把这个话题po出来,没去过坛子的网友们也大概其知道怎么回事了:小K做好一个设计方案,满心欢喜地给开发讲解方案的思路和创意时,开发突然说一句:“这个方案实现不了”,这时他整个人都不好了,心里开始嘀咕“这么简单的设计都实现不了,你是搞技术的吗?”然并卵,在产品和开发的催促下,作为设计师的小K只能加班加点地改方案。

  设计师的问题出在哪儿?

  这几张图一定会是大部分射鸡师与程序猿在工作中最真实的写照。天天为了赶进度加班加点,可是到头来还落得一身埋怨,心里的苦自然不用说,但这并不表示你的工作没有问题…

论设计师与程序员和睦相处

  网友佚名是译名说到:设计过程中,没有参考开发的意见,其实在设计过程中需要开发的参与,这样可以避免设计出来的东西完全实现不了;“设计师如果不懂技术,那就该加强学习,补齐自己的短板。”来自网友jieforest简单又麻辣的评论,看来他认为设计师还应再提高,建议去充电;另一种心理学分析观点是网友wilde4587提到的“问题出现的原因是多方面的。如果单从这个案例来看,设计与开发人员在ROI的考量上的分歧比沟通要大些。”

  以下点评来自为设计师小K鸣不平的网友xkf01“都在说小K的问题,没有人说开发的问题?实际上有些时候小K说的并不是他想要的, 开发理解的需求也不是小K要的。多沟通,并且开发不能直接说做不了就完事了,好歹要有些替代方案供人选择直接一句做不了,谁也接受不了”

  小编总结:这其实是由于设计师对App技术框架的知识匮乏所导致的,虽然设计师不必做到会写代码,但掌握必要的App技术框架原理,能更有效地帮助预判哪些方案可行和实现效果较好。

  设计与技术应该如何相处(权衡)

  相信大部分的公司都遵循着这样的工作流程,在没有pm的时代,流程短一些,矛盾相对较少,但由于产品经理的介入,流程变长,产品经理整理与推动需求并由设计师与程序员执行。想想自己在工作中是否很晚才知道上边的决策,产品与其他部门讨论完成了,扔给你照着做就可以的方案,后知后觉…

  流程固然要走,那设计与技术更应多交流沟通,少走弯路。网友佚名是译名说到:“多多交流,一般设计是女的,开发是男的,多多交流是多好的事,男女搭配,干活不累,还可能擦出爱情的火花。”

  网友ilovecranberrie的“暖心”点评:

  首先,要明确一点,那就是无论什么程度的分歧和争论,其出发点都是为了把事情做得更好。我们自己首先要怀有这样的端正态度,不能有夹带私人利益在其中,并且相信对方也是一样的。因为大家是为了共同的产品或项目而组合到一起的,大前提我们是队友而不是对手。所以,在分歧的初始阶段,要尽最大可能地心平气和的沟通。笼统地说,设计师会比较偏艺术气质,表现为个性很强,技术人员更偏程序逻辑,表现为单纯而执拗。这些或许是沟通障碍的因素,但是更应该看到,大家都是同一个文化环境下的个体,有着相同教育经历和相似成长轨迹,世界观基本大同小异,沟通起来能有多难呢,多一点耐心。当然啦要尽可能去换位思考,体谅彼此的难处。

  网友wilde4587依然从ROI角度进行点评:在项目化的团队中,各种角色交流的机会要比传统的那种“瀑布”模型驱动下的人际关系密切多了,所以沟通交流的因素在两者中的比重已经较以往下降很多。那么为何在工作中两者还时常出现互相压制的情况呢?个人觉得是对同一个产品的ROI,两者是有着不同的换算方式的,自然得到的结果就会不同。与其说是权衡,不如让两者互相尝试着从事一下对方的工作内容,从同一的业务需求角度去协调相互的工作。

  小编总结:1、提前与开发沟通设计想法的可行性。分析完产品需求后,可以先简单地在纸上画出粗犷的交互原型,然后,跟开发沟通想法的可行性及实现难度,做到心中有数。2、明确设计方案的主流程。在对应的App技术框架下,设计师在考虑设计方案时,要明确设计方案的主流程和支流程,凡是会影响到方案核心的主流程的方案,即使开发的实现难度和成本较高,同时也要持续推动技术的突破,来为用户提供更好的使用体验,而对于方案的支流程,就可以跟开发协商不同的解决方案,明确哪些地方可以调整技术实现方式或换一种设计方案,哪些方案存在风险,需备选方案。

  来自星星(ITPUB)的你(网友xdsnet)分享经验、教训

  一个软件开发和发布的不完全例子:

  记得刚开始工作15-6年前,网络还很不发达,工作需要把大量视频类资源(不定期的)传递到用户端(个性化用户,且中间传递过程只能是成本价),这样一个系统当时只能走光盘介质,这样一个人获得所有需要光盘的价格大致在100-200元,而如果走自己下载,按当时的价格要1000元。虽然当时通过网络确实已经可以进行传递啦,但当时的网络速度、带宽、普及性.......等等还不足以支撑这个应用,所以当时设计的非常好的方案就是光盘介质寄送(虽然现在看来低端,当时也不是技术先进性的代表)。所以,适用的设计才是好的设计!(给满分,你懂得!!!)

  总结:

  “世上没有完美的设计,因为你最终能做的就是在各种关系之间取得平衡”

  ——Paul Rand(美国著名设计师)

  在项目中,设计师往往需要权衡商业目标、用户体验和技术实现三者之间的关系来做设计方案,由于技术日新月异,每天都在进步中,所以在实践中需要根据项目的不同阶段与开发工程师保持紧密的沟通,来让设计方案更靠谱。

  与其抱怨或者付诸暴力,不如思考如何通过改进流程与提升自身来改善现有的状况。

  1. 停止抱怨,主动沟通,由被动执行变为主动参与项目中,了解项目进行的最终目的及计划,只有站的更高,才能看的更远。不愿沟通,不想沟通,不屑沟通,过于自我的观念存在于很多程序员与设计师的固有意识中,这其实是大部分技术人员的短板所在,也是禁锢很多人发展的一大障碍。

  2. 自我增值:不管是程序员还是设计师,都应该留出自己思考与整理思维的时间,通过一系列的自身努力提升自己。

  3. 扩宽眼界:程序猿如果还只是埋头于代码,两耳不闻窗外事,那就是真out了,优秀的程序员会非常有兴趣了解并尊重其他同事的工作,比如问问产品经理为什么要进行这个需求,玩一玩用户体验较好的网页或app,提升自己的审美,你会发现这一定很有趣。

  4. 心理疏导:如今看来,加上这么一条还是很有必要的。如此紧密配合的职位之间必然会发生各种的小矛盾,没关系,大家坐下来一起聊聊,相互沟通与理解,相信没有什么解决不了的问题。

0
相关文章