如何评价 Airbnb 发布的 React Sketch.app 工具?

Painting with Code Today, we’re excited to share a tool we built to help bridge the gap between designers and engineers working on design systems at scale. React-sketchapp is an open-source library that allows you to write React components that render to Sketch documents.If you’re a designer or an engineer familiar with React, you should feel right at home with the new library, and you can pla…
关注者
1226
被浏览
87145

32 个回答

很有意思的想法和实践。一边有人在尝试用设计工具生成代码(目前为止都还没有太靠谱的),一边有人在尝试用代码生成设计稿。本质上都是在试图打通编程和设计之间的隔阂。对于这个大命题,后面再细说。

具体到 Airbnb 的这个工具,其实他们有很切实的需求。首先公司大了,需要维护一整套设计语言系统;(比如 Material Design 之于 Google,AntDesign 之于蚂蚁金服)同时这套系统不会是完全定死的,会不断地进化、修改。另外,基于这套基础系统,会针对各个具体产品、BU 衍生出很多子系统。问题就在于,每次要改基础系统里的组件或是规则的时候,就会不可避免地产生连锁反应,导致所有的子系统也要同步修改。

另外,到目前为止,类似的设计体系在设计文件和业务组件代码上都是分离的。设计师维护一套 ai 或者 sketch 文件,工程师维护三套组件代码(如果用了 RN 或者 Weex,理想情况下可以只维护一套)。也就是说,source of truth 有两个甚至多个。理论上来说,这会导致很多重复工作量:任何改动都需要设计师和工程师在设计稿和多份代码之间做同步。Airbnb 的这个工具的目的就是让基于 React 的代码成为唯一的 source of truth,通过一份代码渲染三端组件 + 生成 sketch 文件。

野心很大,不过这带来一个问题:代码到设计稿的生成是单向的。这意味着以后任何对设计的改动必须以代码的形式来执行,也就是设计师必须得会写 React...

说来也巧,昨天这个项目的负责人 Jon Gold 在推上跟人争论,他说觉得设计师学不会 React 的人是在小看设计师。说实话,作为一个在设计和开发之间有点跨界的人,我对这样的系统是很欢迎的。但是你要说让随便一个设计师学会 React 是个很简单的事情,还真有点何不食肉糜的感觉。

总的来说,我对这套系统的看法是:想法很有前瞻性,但落地对团队要求极高。主要的原因在于这套系统就是想用一套生产环境代码通吃,那么组件中不可避免会混杂相当多的交互和工程细节。从工程师的角度说,一个普通设计师学了点 React 基础,你放心让他改么?如果这个设计师的代码水平都可以直接改生产用的组件了,这样的人又有几个?客观来说,能够负责设计系统的设计师,肯定已经得是设计师里面逻辑思维能力很强的那种了。但这样的以代码为 source of truth 的系统,负责基础组件的团队必须个个是设计和开发的高级跨界人才,衍生子系统的设计师也得有初级工程师的代码能力。

回到之前更高层面的命题:设计和代码的结合,到底应该是设计主导,还是代码主导?如果透过工具看产出的本质,最终生成的其实都是一堆数据结构。但是不同职位的人会有不同的看法。工程师会觉得代码主导是更靠谱的,因为代码本身描述数据结构更精确,也更 scalable;设计师则会觉得设计主导更靠谱,因为代码的成本过高,灵活性太低,限制了他们的创造性和工作效率。这里面本质上是设计作为创造性工作和实际开发工程化的工作方式之间的冲突。

能够跨界并且两边都很深入的人很少,一方面是能够跨越两种思维模式的人本来就少,另一方面是以目前软件工程和设计的教育体系来看,这样的人才难以体系化地量产(国内尤其)。如果从教育环节就开始针对性的培养,或许将来某一天这样的人会多起来。但目前而言,这样的人即使在国外也属于稀缺物种,而依赖这样的人才的设计/开发体系,也只有在极少数有条件的公司才有运行的可能。

最早关注到这方面是从 mschoening 的这几条 Twitter(需翻墙)开始

https://twitter.com/mschoening/status/847496408168976384twitter.com/mschoening/twitter.com/mschoening/

这里展示了一种可能,随着 Sketch 43 的发布,由于文件格式完全开源和 JSON 化,前端代码和设计稿的互相转换和同步是可行的道路了。

然后有人提到 jongold(react-sketchapp 作者,Airbnb 工程师)正在做一套东西,能够把代码渲染到 Sketch 文件中。当时 mschoening 的说法是:

I’m not very interested in the inverse but some folks are working on it.

接下来就是 react-sketchapp 的释出了。我们可以在项目 README 中看到,这是一个设计师使用 React 语法视觉稿的项目。

官网也罗列了你现在可以用这个做什么:

  • 管理可复用的设计资源。
  • 使用真实的数据和组件进行设计。

react-sketchapp 希望你用 React 代码来制作和管理 Sketch 视觉稿以及相关的设计资源(比如变量化的色彩系统和字体大小等,很容易的统一修改样式同步到所有组件)。

说实话,这个东西正式发布的时候,我还是有点失望的。按照现有的工作逻辑,设计稿是上游,前端代码是下游,如果已经能写 React 代码了,我为什么还需要出设计稿,不如直接出原型产品。大多数人关心的是如何从 Sketch 导出 React 代码,从而解决现有流程中的几个问题:

  1. 保证设计的可行性:解决设计难以实现的问题。
  2. 前端代码实现的还原度:解决实现和设计不一致的问题。
  3. 节省 UI 的开发时间:工程师可以把更多精力投入在数据和流程上。

对于这个方向,react-sketchapp 也给出了自己的看法,可以看出 Airbnb 想解决的问题和我们大多数人遇到的问题不太一样:

Is there two-way binding? Can I generate React components from Sketch? Nope. Isomorphisms are compelling but our focus is on tools that we can use day-to-day to improve the productivity of designers and engineers working on large-scale production applications. Getting production-ready semantics out of Sketch is more difficult than generating production-ready Sketch templates from React components. Our solution is to keep our our design system’s source of truth in code, and use react-sketchapp to compose & consume it. To edit our design system, we are free to leverage any technology that can create React components, or be compiled to JSX, such as: React-centric IDEs in-house design tools that are tailored to our workflow (whilst being backed by data, version control & semantic versioning) writing React components in text editors with our fingers

其中很重要的理由是,从 Sketch 到 React 代码的转换在实现上有难度,对制作 Sketch 的语义化要求很高。因为本质上设计师做 sketch 是而非带有逻辑和层级关系的


我们自己内部在尝试做一个产品遇到了类似的问题。我们希望设计师直接基于已有的组件和模板进行在线组装设计,跳过设计出稿阶段,直接导出高保真的代码片段。在研发和试用过程中发现,设计师对于页面的树形结构很难理解,上手成本较高,而且新平台的体验很难做到像 Sketch 这种专业设计工具那样顺滑。因此我们也观望和探索从 Sketch 直接导出 React 这个方向,相信社区中也有很多人有类似的想法。


那么 react-sketchapp 这个项目的现实意义是什么?

按照 jongold 在 Painting with Code 里的说法,他们似乎创造了一个新职业(设计工程师?)。在这种模式下工作的设计师写代码,有完整的工作流,使用真实的业务数据,按工程化的方式管理整个产品的设计系统,这也是 Airbnb 的设计团队在尝试的新的工作方式。虽然对于大多数设计团队来说这种模式目前很难落地(缺少这样的人),但是它的确打开了一个新的窗口和思路,在智能设计这个风口上,更多和工程结合的设计工具和产品会在 UI 设计领域的社区中展露出来。


很喜欢 jongold 引用的这段话:

“The strange and beautiful truth about the ‘adjacent possible’ is that its boundaries grow as you explore them. Each new combination opens up the possibility of other new combinations”
为什么?