我觉得应该各司其职吧。前端就是负责实现设计的页面。可是老被前端质疑。说我的页面做得不合理。


估计是因为你不懂技术

同样身为设计师,我待过的每个团队的程序员都很愿意跟我合作。我接收到最多的来自程序员的评价也是:「她不会给我们做不出来的设计稿」。

IT行业的设计师很难成为理想主义者,因为我们需要在很多限制内尽量做出最好的设计来帮助用户解决问题。而项目上最大的限制往往有三个:人不够,钱不够,技术上实现起来太困难。

见过很多设计师,出的图乍一看很漂亮,再多看两眼立马会发现很难实现。很多不懂技术的设计师经常在图上多画几个线,多加几个效果,可能程序员就要多花很多个小时去编程来实现效果图。这些细节多了,不单单是要花前期编程实现的时间,更会增添以后长期维护起来的精力。

而IT行业的好的设计师应该是一个优秀的平衡者,如何用设计真正解决客户的问题,并且让程序员少写一些「无用」的代码。

并不是说不能在设计图上追求完美,追求更好的用户体验精益求精估计是每个设计师的本能。但我是想说,在效果图上加上的每一个小点都应该慎重。每次画图我都会不断思考这些问题,我这里需要加多一个点,那这个点有没有用,是有真实的用途,还是仅仅只是为了符合我自己的审美,它能给客户带来多大的好处,可不可以删掉,删掉有多大影响,加上这个点之后编程会不会很难实现,实现起来需要花多长时间,会给今后长期维护带来多少的工作量,等等。对我来说可能只是在设计图上一个灵光乍现而加上的点,可能就需要程序员多花很多时间来实现,可能会让公司/客户最终多花一些不必要的钱,所以我要对我做的设计负责,对我参与的项目负责。

我做设计的过程中很喜欢跟程序员配对(pairing),问问他们的意见,听听他们的想法,调整设计难度,解释设计背后的想法。而这也是一个很重要的沟通过程,设计与创意不单单需要让客户理解它的重要性,也要让创意的真正实现者去了解这个设计的原因。很多时候在不断沟通的过程中,程序员了解到了这样做设计背后真正的目的,了解到了这个设计能带来的好处,也会愿意花加倍的时间来实现这些可能有些复杂的创意,因为他们理解到「这个时间他们花的值得」。

我也经常会在画设计图的时候,顺便把相关的code在网上搜出来看看,看看难不难实现,评估一下是否有其他的设计方式可以替代。最后把设计图和相关的code一并转交给程序员。大家都省时间,最终项目也能更高效的完成。

设计师和程序员应该是相辅相成,相互理解的好伙伴/好战友的关系,毕竟我们的目标是一致的,都想项目/产品最终做好。

「各司其职」在当今成熟的IT团队里来看真的是不太现实,好的前端必然懂用户体验设计,而优秀的设计师也应该懂技术,才能在最短的时间里让优秀的设计真正投入应用得以实现。


作为一个前端,在考虑问题时和设计肯定有角度上的差异的。

美感: 这方面,不是所有的前端都有发言权。尽管很多前端同学美感很好,但是设计师毕竟是吃这口饭的。

功能性: 这一点,作为前端是很想吐槽的。很多设计师为了布局和颜色的好看,对于功能的合理性思考不足的现象非常普遍。比如说用户在实际场景中会不会使用这个功能,这个按钮会不会不好点击,使用体验会不会跳脱,数据交互上会不会因为太复杂而造成难以优化的卡顿。很多设计师甚至对布局的可伸缩性都不考虑,这方面前端技术的同学在评估的时候肯定要说的。不然做出来之后这个锅算谁的?

可实现性:想说飞机稿真是见的多了。随著能力和经验的增长,虽然有一些飞机稿都想方设法的搞出来了,但是实现的成本是相当高的。产品的同学要求这个迭代两周上线,设计师为了一个动效搞的研发同学要增加好几个工作日来做。这种设计,前端同学能不说么?

理想的情况是,设计同学能稍微对技术多了解一点,这样对自己的设计也能有所帮助。技术同学也要多从设计师的角度上考虑。任务是个人的,成功是团队的。最重要的不是设计要怎么样,也不是技术要怎么样,甚至不是说用户要怎么样。最重要的是如何找到产品价值和商业的平衡点。Everything is about trade-off


很正常,高级前端(以及高级测试)的核心技能之一就是精通用户体验。所以,前端挑战你的设计再正常不过了。有话好好说,共同打磨出好产品就是了。


我是个前端程序员。

工作上遇到的设计人员给出的设计稿,通常有这三个问题:

1.有些是只给个设计稿的png图片(对界面要求不高)。

2.有些给的设计稿PSD文件结构混乱,使用pxcook等代码生成工具艰难。

3.设计稿没能完全符合需求,可能有遗漏。

4.设计要求的交互动效模糊

如果前端说的是这几个问题,那么就需要设计修正自己的问题了。否则如果是前端实现设计困难,就需要前端找找自己的原因了。

另外如果矛盾很大,找一下上级,这个时候需要团队进行沟通


应该鼓励技术提意见,团队的意义就是不同职能的同事为同个目标协作达成。不同职能的人所涉及的领域不同,互相协作能避免工作上出现未考虑到的盲点。

技术质疑前期的需求和设计,能有效避免在限期内出现不可行性或高成本方案。

有一点需要注意,设计输出阶段,技术提的建议分为需求层和感知层。需求层会导致设计方案返工,需要提醒技术这类问题应在需求评审时尽早暴露。感知层问题需要设计评估建议是否合理决定是否接受。

不要认为技术只是实现层的执行者不能提意见,这是偏见。团队所有成员都为需求方案的稳定和可行性负责,对事不对人。


推荐阅读:
相关文章