产品

在实际项目中使用Figma进行设计

. 7 min read . Written by seki
在实际项目中使用Figma进行设计

国庆假期前一天,我将Figma上的设计稿重构至Sketch中,这也意味着,自六月选择Figma作为设计工具开始,团队与Figma的关系告一段落了,此后,项目的工作将在Sketch为核心的软件生态下继续。我打算写一些东西记录这段实战过程中的感受,因此,这大概算是一篇讨论Figma的随笔。

网上已有不少Sketch vs Figma的文章,我想不需要再对这些软件进行太多介绍,本文不打算讨论Sketch这一“对标软件”。首先,设计的工作并不只是“P个图”——绘制静态界面只占设计工作中很小的一部分。Figma像一把工兵铲,让它与名为Sketch的斧头比谁砍树快,并不公平。此外,比如说Sketch的Libraries与Figma的Component,本质上都是设计资产管理方案,两者各有千秋,都很好用,但也都不完美,完美的方案也从不存在。

综上,大部分Sketch vs Figma意义并不大,在Sketch早已路人皆知的当下,我们不如来聊聊Figma的Aha moments。

为什么使用Figma

项目中需要频繁将设计稿展示给开发同学,甚至预期让开发用组件自己拼界面玩玩(可惜并没有出现这一场景 ),但非每个人都使用Mac系统,因此一开始就不打算使用Sketch。将“沟通”作为工作计划的首要诉求,自然就选择了Figma。

最大的Aha moment

作为一款主打协作的软件,Figma最大的Aha moment莫过于当用户第一次将文件分享给团队,看着同伴们进入当前画板的一瞬间——“不同用户可以在同一个画板上同步进行设计”,这无疑是Figma特性中最吸引人的一项。大部分设计师在了解到这一功能时,脑海里一定会浮现出团队成员们“拿着Figma稿进行电话会议、五颜六色的鼠标指针在画板上挥舞、时不时还来一下同步设计”的画面。可惜,这是一项伪需求。

在实际工作中,大项目会被拆分成不同的模块,进行开发、设计,最终由老大统一设计稿和代码,制定规范。而产品与交互、交互与UI之间的协作中,会使用需求文档和低保真原型进行沟通。如果设计师允许别人直接在自己的设计稿上进行修改,一定会导致“代码腐烂”的状况发生,因此,在画板上同步绘图并不符合现实的工作方式,通过批注完成交流才是真正的协作,目前,Sketch和PS只能用蓝湖和Zeplin这样的第三方工具来完成批注任务,可以说,Figma最大的Aha moment是免除了对批注工具的依赖。

被忽视的Aha moment

假如你想在静态的UI稿中描述动效,你会——

首先,当然可以用纯文字进行标注。比如当一个按钮被hover时,样式会发生变化,此时我们可以给出hover前后的样式,再标注好:“使用ease-in的模式进行缓动、时间为100毫秒。”——但是,这种方式在较复杂的组件中难以使用,并且非常不直观,只适用于落地开发的场景中。

是否可以使用Flinto、Protopie、Principle甚至AE这样专门做动效的软件?诚然,这几项工具非常强大,可以做出几乎以假乱真的原型,但它们的输出方式并不理想——团队成员必须也安装同一款软件,否则只能浏览导出的视频。此外,为了方便动画制作,往往还需要对图层进行调整、再导出。这些繁琐的工作有悖于“小步快跑”的原则,因此,实际工作中几乎没有它们的用武之地。

也有团队使用PPT和keynote制作原型,这个方法是可行的,因为软件基本大家都有。但设计师依然需要调整图层、重构UI至PPT中。

Figma的“原型”功能与PPT类似——毫不留情的说,制作功能并不强大。但Figma基于web端这一特点,决定了它可以直接“甩一个链接过去,完成方案输出的工作”,目前为止,我认为Figma的原型功能是实战中动效交付的最佳方案。

为什么放弃Figma

SaaS软件有两个问题:

  1. 如果服务器在国外,可能会卡。更可怕的是,如果软件因不可抗力不再提供服务,后果不堪设想
  2. 文件保存在别人的服务器上,如果公司重视安全性问题,Figma作为工具将受到挑战。后者导致我们决定迁出Figma,转向Sketch。

实际上,国内使用Figma还算流畅,也不需要科学上网帮忙。对于安全性要求不高的小团队而言,完全可以考虑使用Figma进行设计工作,更何况它还免费。

还会使用Figma吗

目前团队不会,但个人会,并且会在之后工作中继续进行。

把control point拖拽到end point上自动合为一体 神一般的用户体验

首先必须夸一夸Figma的矢量绘制逻辑,简而言之,几乎不再需要去学习什么钢笔工具了,也不再需要去了解贝塞尔曲线之类的知识了,在Figma上绘制矢量是那么的简单。我们完全可以在Figma中绘制插画或者icon,导出SVG,再导入至Sketch中。但对于作为交互的我而言,需要绘制矢量图形的场景并不多,更多时候是用于自娱自乐。

另外,从上文的叙述中你或许已经看出,Figma参与的是我们的低保真原型阶段,此后确定下来的组件迁移至Sketch,它们将成为高保真设计稿。总之,Figma重协作的特点决定了它在需求改来改去的低保真阶段能够大放异彩(Axure:那我呢?),代价则是得重构设计稿,毕竟目前还没有Figma转Sketch文件的插件。

最后,是仅存在我理想中,未曾实践过的工作方式——在文章开头我提到过“希望让开发试试用组件拼界面”,当一个产品的工具属性较重时(譬如ToB产品),我们能否让用户像搭积木一样拼接界面,从而倒推用户心理?这种思路源于调研中的 “卡片分类法”,用户被请求将代表模块或数据的卡片进行分类,从而让测试者验证产品的架构。

基于原子设计的理论,设计师可以给出UI组件和模块作为积木,让真实用户用其进行“搭城堡游戏”,而Figma的优势将帮助这个想法变为现实。