二、设计与改进

有了原型(不管是画在纸上的还是用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 结构和语言标签)一并写好并交付给研发工程师。为什么设计师最好要写代码?原因非常简单：

让研发工程师调试界面是非常痛苦的事情，他们对这件事并没有好感;

人力资源有限的情况下，研发工程师(通常)会将绝大部分精力花在业务逻辑代码等事情上，以实现资源的最优配置，界面按照设计还原的优先级是滞后的，除非强制要求。

大部分人对设计的感知停留在「感觉这个比那个看起来舒服，但说不出来为什么」，也只有设计师把情愿把时间花在无穷无尽的像素级对比和排版上，并以此为乐。

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

但是，大熊并不鼓吹现在流行的 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 的界面。 」

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

大熊的 dribbble：Raymond Wong Github：rayston92 (rayston92) · GitHub

欢迎关注大熊的微信公众号：大熊拨清波。