每一个外省进城务工的设计师(们) 曾经都一直信奉这句箴言:

只要我切的图够快,寂寞就追不上我。

可是摆京不相信眼泪,不管你切@2x、@3x图的手速有多快,如果核心产品逻辑没理清,后期创意执行不到位,收尾细节考虑不周全,一样在比稿(自查)时被K掉重做,到最后只能默默啜泣把妆哭花,浪费宝贵时间。

做设计的时间越久,就越意识一个好的、可执行性高的标准工作流真的能帮你节省非常多的时间,从繁琐的日常设计中解放出来,才能成为真♂REAL 设计师。大熊自己总结了一套行之有效的方法,这里无保留分享给你:

三大步骤,绝大部分日常的设计需求,都可以用这套流程过一遍;至于无命题式的自由创造,则无需拘束在这几个步骤里面。工作流是拿来提高效率的,而不是限制想象力。

一、灵感和原型

除非是天赋迥异,否则谁也不能保证拿到创作命题就来灵感。因此,在工作生活中积累一个「灵感库」非常重要。

人们在那里高谈阔论着天气和灵感之类的东西,而我却象首饰匠打金锁链那样精心的劳动着,把一个个小环非常合适地连接起来。 ——海涅

这里安利一款叫Inboard的应用,你可以很方便的用它管理图片素材,更棒的是只要在上面登陆你自己的Dribbble帐号,它会自动将你Like过的设计作品都同步下来,在本地也能轻松查看。

如果你早先用过Pixa或者Ember这样的素材管理工具,上手是分分钟的事情。

「图为 Inboard 2」

有经验的设计师不会临阵磨枪,那是刚入门的新手才犯的错误。然而「太阳底下无新事」,让我们看看2006年 NASA 再版的设计指南

「图为 NASA 2006年上线的设计指南」

从字体规范到各个场景的应用(封面、网页、小册子、运输工具的外观、航天飞机的喷涂)全部囊括在内,且大部分内容都遵循2005年就已发布的版本做追加和修改。

10多年前的规范到如今都没有什么大的变化,这意味着按照现有的人机交互范式,最常用的组件永远都是那么几样(不论 Mobile App还是 Web App)。

  • Navs
  • ButtonGroups
  • Pagination
  • Media
  • Form
  • ListGroups
  • ContentWrapper

这对你意味着什么?

意味着你并不需要一切「从头来过」。

你所要设计的「新」东西, 其实前人在10多年前就设计过各种风格和交互样式,并且还出过「规范」。所以,投入设计工作前,请务必做好这三件事:

  1. 前人是否做过类似的设计(不论风格有没有过时),检查你的「灵感库」并罗列出来;
  2. 删去所有修饰元素,将内容重组,并且使其贴合你现有产品的设计风格,作为备选方案(是的没有打错,就是备选方案);
  3. 再想想其他的实现方案,可能只是一个微小的点,也足以让你打破原有的设计思路。论证其可行性并完善,作为主方案。

大熊在今日头条工作时,勇哥(前财新产品设计主管)常提起他和胡舒立共事的细节,印象很深的一点是他说,当你想到一个绝妙的设计点子时,不要急着出方案,而是将它小心翼翼的放在心里,作为备选方案,然后再想下一个。

这是因为,设计永远有更精妙的,而你要确保你每一次的设计,从视觉风格到交互体验,都在你的水准线以上。所以无论何时,都要留个备选方案,哪怕出不了彩,也能保证设计质量。(虽然备选方案最后经常被弃用)

此外,Pinterest,Pttrns,Reeoo等都是灵感扎堆的地方,特别是跨界设计往往容易把思路打开,做GUI设计不一定只看界面设计,有时候一副摄影作品(Unsplash有多好用我就不多说了)都能给你带来无限灵感,比如:

「图为 haobtc landingpage 头图的灵感来源」

最方便的原型工具依然是你身边的纸笔。

大熊在用的是Moleskine和Evernote的合作款,偶尔产生的新想法、草图都可以记录在内,并且同步到 Evernote,非常方便。

「图为 haobtc 开发中的公告系统界面手稿」

提到原型工具,去年是它们爆发的一年,今年目测依然会继续。

Origami、Pixate、、Form、Invision、Principle、Marvel各有各的侧重点(Pixate 与 Form 都已被 Google 收购),如果你是JavaScript好手,毫无疑问是最合适的工具,代码级细粒度的调试能保证最后的效果和设计原型别无二致。

而如果产品中使用了 Pop Animation(Facebook 开源) 这样的动画框架,那么 Origami 当之无愧是最佳选择。

然而除却上面这些,不得不提的却是 Keynote,因为诞生之初 Keynote 就使用了OS X 内置的 Quartz 图形技术,拿它做动态交互居然出人意料的流畅,这也难怪有这么多设计师偶尔也拿它做原型动画,Apple WWDC 2014 甚至专门演示了内部团队用 Keynote 制作 App 原型的过程。

「图为大熊早期练习 keynote 时制作的动效,学习门槛非常低」

不过,最让大熊期待的还是 Silver Flows (已被 Invision 收购,并入Craft 2.0套件),直接在 Sketch中完成页面之间的链接跳转,原生的转场动画,可实时编辑的输入框,还有嵌入 Webview,这些都在手机上实时预览,简直亦可赛艇。

希望早日推出正式版本,比Adobe XD用起来效率高应该是肯定的。

二、设计与改进

有了原型(不管是画在纸上的还是用Axure这样的工具输出)后就进入真正的设计阶段,这时就要细细考量:

  • 字体
  • 字符间距
  • 用色规范
  • 组件的摆放对比
  • 多屏的适配
  • 动效

至于 GUI 界面设计的利器,当然要提 Sketch。它几乎成了现在设计师的标配,一方面门槛很低、体积轻巧,相比Adobe家族的一票设计软件,上手要容易的多;另一方面软件的种种特性都为Web和App设计量身定做,输出CSS、模块化的设计组件、都让设计和后期开发减去许多沟通成本。

然而,设计并不能拘泥于工具。绝没有「用 Sketch 就比用 PS 的技高一筹」的说法,说出这种话的设计师,其自身能力往往也很一般。

工具没有最完美,只有最合适。

Sketch 在互联网设计圈流行开以后,经历了很长时间的停滞期(3.X 版本),由于迟迟没有新的 feature 跟进,受到很多人的抱怨,大熊也是其中一员。后来发现一家叫 Serif 的英国工作室推出了 Affinity Photo 和 Affinity Designer 两款设计套件,极快的响应速度和高兼容性马上就吸引了很多设计师的目光。大家迅速转移阵地,这两款设计软件也流行开来,还斩获了Apple Design Award 和 2015 年度 Mac App。

在这之后 Sketch 也随即开始了一系列的版本更新,修复了许多旧 Bug,看的出 Bohemian 团队充满危机意识。

设计工具的选择已经上升到党派战争,完全可以另起一篇好好讨论,这里篇幅有限,不再展开。

接着要说说初步设计完成后,如何改进的问题。

一稿过就跟 One take 一样,偶尔会发生,从未寻常过。

–大熊

设计几乎一定是要改的,既然做了设计师,就要做好心理准备。大熊以前很抗拒改稿,辛辛苦苦做的设计说改就改,那么多晚都白熬了,心里肯定不爽。

但是后来却意识到,改才是常态,好设计真的(几乎)都是改出来的。比如今日头条内部创业做了一款产品叫时光相册,非常好的产品,初期设定界面时,大熊单单就相册的展示页做了16种不同的版式,最终和产品负责人从中挑选了最合适的展示方式:

「图为部分时光相册早期界面样式探索。 」

只有比较的过程中,你才更容易发现原来设计中不合理的地方,逐一剔除删改,最后留下来的一定是经过多层考虑最合适的设计。

这款产品现在早已和我没有关系,但当时沈振宇提到的一个观点,我一直都非常认同:设计师们对美的东西有天然的偏好,所以你看他们的设计稿,一张张都无比美幻。而实际上, 产品的内容是用户创造的,用户不是艺术家,他们的相册里放的都是日常的琐碎,试想拿这样的照片替换设计稿中的占位图,设计还有原先那么美吗?

回过头去看 dribbble 上的首推设计作品,无一不讲究氛围,基调的拿捏。放在那个场景里是无可挑剔的,但落到实际的产品上,却不太经得起推敲。

有一位叫 Tobias 的设计师在 Medium发表了类似的文章,观点之一就是 dribbble 上的作品从未真正的「解决」过问题,值得一读。

译文版本:《设计追波风!值得每个设计师阅读思考的深度剖析文》

此外,改进要尽可能面面俱到,不起眼的小改动,却往往能让整个界面变得不一样。

比如一个创业朋友正在开发他们的 App,心急火燎的找大熊改进界面的设计,其中一个界面改版是这样的:

「左侧为改版前,右侧为大熊改版后」

看起来变化很大,实际上只作几处改动:

  • 调整了字重、大小和间距;
  • 强化原来的卡片设计的层级;
  • 强化了主色和辅助色;
  • 调整了组件的摆放位置;

自己做的设计也一样,多次改动后可能面目全非,跟初版差距很大。有心里落差很正常,但只要最后的结果是变好的,那么这样的改动就很值得。(不过也要记得做好备份,改完10版最后用回第一版是高频事件)

另外顺便提一下 Luke Wroblewski,这哥们从2001年开始十多年笔耕不辍,职业生涯一直都游走在用研和人机交互间,产出了很多高质量的文章。国内许多设计团队在做设计决策时,都直接或间接参考过他提供的数据和结论,在交互设计界影响力可见一斑。

如果说 LittleBigDetails 是收集「让人会心一笑的设计细节」,那么 Luke 对于设计的观察就是回归理性,一切用数据说话。

「图为Apple Watch 推出时,Luke发表的一篇关于用户使用电子设备习惯的一篇文章」

三、交付与实现

任何事都没有表面看起来那么简单。 ——墨菲定律

如果是你没有接触过的开发领域,比如 iOS 应用的开发,必须要学习 Obj-C 或 Swift 语言,那么通常来说,将标注的清清楚楚,完完整整的设计指南(Design Guide)、素材(Assets)和交互流程 交付给研发工程师,任务到这里就可以告一段落了。

在没有神器 Zeplin 之前,大熊通过 Sketch Measure 这款插件来标注设计图。

每张视觉稿都对应3张页面,两张页面分别解释横向布局和纵向布局,一张页面解释视觉样式,包括字体、字号、行高,字间距等等。即便有插件的帮助,可标注依然只能手动。

所以设计师最痛苦的事情就是设计过稿了以后,桌面放上一壶水,眼睛眯成一条缝,连续标上两三天(如果有几十个页面,这是再正常不过了)。

「图为 haobtc 内部项目原设计」

重复的劳动应该让机器来做,所以我们有了 Zeplin,由以色列 Startupbootcamp 和 YC 孵化出来的一个项目,彻底解放了设计师的双手。不光解决了所有标注的问题,真正做到WYSIWYG,还生成了Guidline,自动整理了设计中所用到的字体(Fontbook)和颜色(Color Palette)。

美中不足的是,在我们实际使用过程中,发现Zeplin 不能准确的识别元素的边距,经常有0.1-0.5pt 的误差,值得庆幸的是 Zeplin正在努力解决这个问题,相信后续的版本会得到修正。总的来说,使用 Zeplin能节约团队的开发时间,没有理由不推荐。

「图为 Zeplin 操作面板」

「图为 Zeplin 设计指南」

对于你不甚了解的领域,比如从未写过一行 Obj-C 的代码。能尽可能做到保证设计组件结构清晰,同时站在工程师和产品经理的角度思考问题,那么作为一个设计师,到这里交付给研发工程师是可以理解的。

但如果你同时也略为熟悉这个领域,比如 Web 端的开发,HTML 和 CSS 都写的简炼干脆,那么最好将完整的页面(以合理的 Dom 结构和语言标签)一并写好并交付给研发工程师。为什么设计师最好要写代码?原因非常简单:

  1. 让研发工程师调试界面是非常痛苦的事情,他们对这件事并没有好感;
  2. 人力资源有限的情况下,研发工程师(通常)会将绝大部分精力花在业务逻辑代码等事情上,以实现资源的最优配置,界面按照设计还原的优先级是滞后的,除非强制要求。
  3. 大部分人对设计的感知停留在「感觉这个比那个看起来舒服,但说不出来为什么」,也只有设计师把情愿把时间花在无穷无尽的像素级对比和排版上,并以此为乐。

这样一来双方都开心,效率也提高了。

但是,大熊并不鼓吹现在流行的 Full Stack Designer (这里特指在设计的同时,分配很多精力在业务逻辑的代码上)这种说法,这样往往两者都做不好。早期之所以有 Web Master(包括建站、数据库、后台、前端界面、设计,都一手包办的人),是因为在当时的环境下,Web 开发远没有像今天这么复杂:

「图为Apple 20年前的官网。 」

在那个时期,许多网站都像是简单的(以及符合当时审美)图文编排的 Blog,附上一堆超链接,并没有如今这么复杂的后台业务逻辑和网络环境。

但如今再去言必提及 Full Stack,实在是有点不客观。比起前者,Multi Stack 这个词更符合现在的实际情况。

设计领域已经非常细分了:界面设计、人机交互、三维骨骼、原画、场景、粒子特效、HUD设计、动作镜头(有兴趣可以去看@光学核心 个人制作的动作镜头,顶级的分镜水准,无可挑剔的节奏感和打击感,中间花了多少时间反复揣摩和练习恐怕无人能知。)

每一项都必须花上可怕的时间才能达到单个领域里专家的水准,所以当有设计师遑论样样精通时,实际上是样样稀松,单个拎出,都上不了台面。

正因如此,对自己不熟知的专业领域要尊重,才能有好的心态去学习和进步,先有一技之长,才能多处开花。

最后再安利 Hammer 这款工具来提高你的效率,这简直又是一枚神器。

Auto Reload(类似Hot-Reload)、Html Includes、Clever path,支持SCSS/SASS…毫不夸张的说,它帮助大熊节约了至少20%写页面花费的工作时间。当然,也有一些其他的工具,比如 Codekit 也能做类似的事情,最好根据自身的需求去选择。

「图为 Hammer 的界面。 」

最后,希望大家都能找到设计的乐趣,做出好玩有意义的东西出来,保持学习的激情。