从工程师的角度去看UI/UX设计师


除了出色的设计,设计师还需要什么

最近因为Gogobot App又被Apple和Google不约而同的Feature在主页的Best new app里,再次获得了大家不少的关注。很多用户和使用过的朋友都称赞我们的App里的细节和动画都做的很棒。做为这个App主要开发人员,必须承认这归功于我们有一个非常出色的UI/UX设计师,虽然他自己并不参与开发甚至不自己调UI,但他提供了一个非常出色的设计,更重要的是他将设计师和工程师之间的工作关系和节奏掌控的非常恰到好处。因为工程师是最直接也最经常和设计师一起工作的人,一个良好的合作关系和工作节奏是实现一个好产品最有效率的方式,也会是带来最好结果的方式。所以我想以一个完全不懂设计的工程师的立场去讨论下,除了出色的设计,UI/UX设计师还需要什么。

在多年的开发过程中,我接触过不少UI/UX设计师,大多很有才华。但是Gogobot的设计师Rodrigo Soares确实是我合作过设计师中的战斗机,两年的合作非常默契,甚至私底下很多个人的项目我都愿意和希望继续和他一起工作。先简单介绍下Rodrigo,他是一个巴西裔的设计师,大学辍学因为他觉得教授教的设计理念他都早已经理解。早先在一家和洛杉矶湖人队合作的设计公司工作,后加入当时最热火的社交网站My space做移动相关产品的设计,然后被Gogobot的CEO也是曾经的My space的高级副总裁邀请加入Gogobot做移动软件的首席设计师。我从Rodrigo身上学习总结了几点也许是很多UI/UX设计师可以借鉴,从而提高与工程师一起工作的效率和产品的质量,也能的帮助所在的团队或初创企业更好的完成计划,最关键的还能让设计师在一个团队中成为Mr. Key。


1. 开始设计前和设计中的沟通

Gogobot做了很多小细节的美化和大结构的动画,我们的设计师通常在开始真正着手设计之前会把他的想法与参与开发的Lead工程师先沟通一下,看看实现的可能性和难度。并在设计过程中和工程师简单的对接下目前的内容和将要进行的设计。我认为这个是一个事半功倍的小细节。有时候很多设计师闷头设计,只注重于自己的设计好看,酷炫。但是给工程造成了很多困扰。

通常一个非常好看的设计,再加上实力相当强劲的工程师,可以做出一个非常好看的App。但对于一个小型团队,特别是初创企业来说,设计师需要把工程的技术和能力加入他设计的考量。如果以目前合作工程师的技术无法按时完成甚至无法完成的设计,那其实就是一个“不成功”的设计。哪怕设计本身是非常出色的,但是损失了对于一个初创企业最重要的时间和金钱。例如很多Dribble上的设计都非常漂亮非常有创意,但是实现的可能性非常小或者难度很大,那最后也只能变成一个华而不实的Eye candy。有一些设计师在设计的过程中中忽略了工程的能力,和一些技术上的限制,这样必须修改甚至重新设计。这一来一回是一个效率很低,而且很消耗团队热情的过程。

不少设计师会把无法完成产品单方面的归结于工程师的能力不够,这我认为不是很客观。在一个初创企业资源有限的情况下,不考虑目前公司能力而单纯追求华丽的设计师在我看来是不专业的。当然哪怕在资源和人力充足的大型公司,也会有时间和技术上的限制。

所以一个简单的设计前的会议和设计过程中的沟通可以让设计师更了解目前技术的限制在哪里,团队的能力在什么程度。这样就可以避免Eye candy的产生,提高工作的效率和团队协作性。一个能够在技术限制和人力资源有限的情况下,依然把设计能力和创意发挥到最大的设计师才是一个团队真正不可缺少的人物。


2.设计师的Prototype

在过去的印象中,设计师只要关注设计,只要提供几张图片,接下去就让工程师去开发Prototype。而其实越来越多的公司意识到,这样的工作方法是非常低效的。因为在一个产品的设计过程中,设计师脑中早就已经有这个产品的Prototype,比如内容如何排列,一些重要信息如何出现,页面之间如何过渡,点击一个按钮之后应该出现什么,等等等等。如果等设计全部完成,再让工程师去做这样一个Prototype,会出现几个很显而易见的问题:

  • 第一,因为Prototype要用来说服PMs,做Usability测试等等,所以要尽量接近真实的产品。如果要工程师去做的话,设计师必须要解释清楚整个设计中所有的小细节。这样设计师和工程师之间的沟通就变成这个Prototype最大的成本,花在沟通的上的时间完全可以节约下来,让工程师去完成产品的初期构架。

  • 第二,Prototype在初期常常会由于各种原因面临大面积的修改,如果每次都需要设计师去修改设计,工程师去修改Prototype,这同时浪费了两个人的时间。不如让设计师修改设计的同时,修改Prototype中的内容。

所以现在市面上有越来越多的软件帮助设计师去制作Prototype,比如Gogobot设计师一直在用的Framerjs,Facebook出品的origami,invisionapp等等。大部分的软件都不需要coding或则需要一些非常简单的coding。而且最关键的是,这些Prototype都是可交互的,甚至可以在设备上模拟完整的Look and feel.

比如Gogobot最新3.5.1版本中从List到Topic page的页面过渡,因为涉及到比较多的细节和动画,Rodrigo用Framerjs做了一个简单的Prototype:List-Topic-Transition-Prototype (可能要花几秒钟读取,有时候要刷新几次。读完后可以点击图片和滚动鼠标滚轮)。还有Gogobot已经推出的Apple watch app,同样用了Framerjs制作Prototype:Gogobot-Apple-Watch-Prototype 。还有被一个没有被通过的Gogobot Apple watch app设计:Gogobot-Apple-Watch-Prototype-Not-Proved

这些Prototype提供了开发所需要了解的基本细节,比如交互的规则,界面之间的过渡,信息的排列,动画细节等等。更好的是Framerjs还提供下载源代码,如果其中有动画的话,工程师可以直接看到动画的duration, speed, spring tension等等重要的数据。比如Framerjs使用的语言是Coffee script,比较简单易懂。当设计师熟悉之后,开发整个Prototype的时间也不会很长。

一个好的Prototype让产品经理更容易理解你的设计,让工程师更清楚自己应该做什么和怎么做,让你的团队更容易接受你的设计。这些都会让一个设计师从整个团队中脱颖而出,成为不可或缺的核心人物。


3.设定明确的Design Specification

当设计完成,Prototype也通过已经通过各种测试,进入真正的开发阶段后,设计师需要定义一些整个产品里都通用的规则,比如标题字体大小,主题颜色,各种间距等等,这些规则都是可以让一个App更有整体性。其实和之前的几点类似,清晰的Specs节约了时间,节约了沟通的成本,简单的说就是别给工程师犯错的借口 :)。做一个好的Specs其实说难不难,说简单也有一些需要思考的东西。
* 通常UI规格会比较多,可以利用不一样的颜色区分不一样的内容。比如在Gogobot的Specs,橙色的标签都是字体相关的。绿色的标签都是间距。红色的都是长宽之类的尺寸。清晰的分类让复杂的UI变得不是毫无头绪。

  • 由于现在屏幕的尺寸越来越多了,为了让UI中的部件能自适应尺寸,就应该尽量少使用固定尺寸。除非这个内容在各种不同的屏幕上是一样的大小。尽量使用间距来规定一个部件,高度和宽度应当自动适应。

  • 在详细标记的基础上,如果是重复的内容,完全可以跳过。这不光可以节约一点制作的时间,也同时让Specs不会显得太杂乱以至于没有重点。

总的来说Specs需要的是内容详细但错落有序。有条不紊的把需要注意的点都标记出来。让最最没有领悟能力的工程师也能完全实现你的设计。


4.追求Pixel Perfect,但请适度

Pixel Perfect其实是一个有追求的表现。因为在一个好的设计中,每一个Pixel都应该是在设计之中的。如果能够把设计中的每一个细节都百分之百的实现,这是最完美的情况。但现实往往不如“设计师”意。

现在的设备通常都有非常高的Dpi,在开发过程中设置的数字变成屏幕上的UI时候很有可能有半个,一个Pixel的差距。有时候哪怕100%按照设计师的Specs中的数字,但是因为在图片上测量出来的数字和开完完成后屏幕上的数字也可能会有差距。

在几年的开发中,我遇到过几位非常追求完美的设计师,他们会把在实机上运行的界面截图,然后拿回Photoshop做透视比较,然后把每一个相差的Pixel都列出来要求修改。我完全理解他们的追求,我也会基本按照他们的需求进行修改。但是有一些效果往往很难百分之百做到完美,比如一些瀑布流式的UI,一些动态生成的图片式的界面等。因为很多时候这些会根据屏幕的大小和设计规格上的间距通过算法来生成,而在设计上量出的尺寸可能不包括某些边框,或者某些阴影的尺寸等等,一些不对等的测量加上开发中的算法会让Pixel Perfect的成本变得非常高。

我也和Rodrigo沟通过他对Pixel Perfect的看法,我赞同他对这个追求的看法,他认为在软件一致性规格上,他希望能够尽量Pixel Perfect,比如所有屏幕左右的间距都应该是20px,按钮的高度都应该是45px,所有分割线的高度都应该是1px,等等。而一些不是特别影响视觉效果的内容,比如文字的行间距,动画过程中的一些小细节,等等。这些都用设计师的眼睛来判断,如果看上去没有突兀感,和其他UI部件都配合,他认为就应该被通过。

Pixel Perfect是一个完美主义设计师的终极追求,但是在一个团队中,特别是初创企业中,如果过度追求,反而会得不偿失。不如学会Let it go, 让自己不会呢么累,让工程师不会浪费几天去修几个Pixel, 让产品能够更早面市,win-win-win.


前前后后写了几天,其实还有几条想加的,比如“关注最新的科技”,“自信,但别自负”,等等。但是仔细思考之后决定还是就先这些吧。其他随着时间和经验的增长应该都会理解。总而言之,就希望站在一个不是专业设计师的角度,但又是一个每天和设计师打交道的人的角度,来谈论下如何把这个合作关系变得更高效,更顺畅。希望能对一些设计师有帮助。