过往业界的 D2C 方案,更多集中在 C 端场景。B 端 与 C 端做设计稿转代码的关键区别是什么呢?
- C 端页面,周抛/月抛型页面占比非常高,多为展示类,交互较为简单。 对组件识别的诉求不强烈,仅对最终视觉还原效果要求高,可采用绝对布局等方式,对代码可维护性要求不如 B 端页面苛刻
- B 端重交互,同时看重代码可维护性,必须能实现真实组件识别,将设计图层识别为具体某个 lib 的 某个 module,才可保证后续可维护性。属于核心级能力,做不到这一点则无法真实落地应用
Semi 作为中后台场景的设计系统,能力必须满足 B 端场景的基线,才能真实落地业务。以下有三点是 Semi D2C 与其他方案最大的区别:
不依赖标注,原生提供 Semi UI 组件级识别能力,与设计系统打通,更低成本应用于 B 端场景,支持 Semi 主题定制 & 转码
Semi D2C 方案提供了精准到组件级 props 的识别能力,对全部 Semi 基础组件的全部设计形态,都提供了识别能力,不需要研发手动对组件进行标注。
换句话说,设计师使用这套 UI Kit 搭建出的设计稿,设计稿上的组件全部都能被转移成真实的组件代码,不再仅仅是渲染后跟设计稿长得一样的无意义 div。
业界也有一些 D2C 工具也提供了强大的组件标注能力,但由于没有与 Design System 做很好的打通,所以在实际的使用中需要人工将组件以及组件属性进行标注,依然存在一定的使用成本。同时由于缺乏对底层组件库的掌控以及场景建设,对使用场景中有较多限制。
不改变设计师使用习惯,无需重新学习
我们在 2021 ~ 2022 年调研过 Figma 平台上公开可用的 C2D 工具,它们基本都选择了将组件作为一个实例绘制在画布上,之后无论是创建实例还是切换组件形态都需要通过一个 Figma 插件操作。
然而,在实际的设计流程中,设计师可能并不习惯打开一个插件创建和更新组件,这会影响设计师的使用效率,同时实例也并非是设计师习惯的消费方式,他们更习惯于通过 Figma Variant 变体的方式切换组件形态。
(上图-设计师使用 Figma Variant 切换组件形态的过程)
Semi 提供的方案允许设计师继续通过 Figma 变体的方式使用组件,与原有的设计流程一致。对设计师而言,无需通过额外安装插件操作,与原有习惯保持一致,如以往般高效。
高度可用的设计组件 (For Designer)
C2D 并非 Semi 首创的生产方式,在之前业内已经有一些先驱产品进行过探索,他们支持导入第三方组件库转为设计组件。
但这类通用型的方案,在抖音团队的应用场景中,无法完全满足我们的诉求。主要存在以下方面的局限:
- 转出的 UI Kit 大多不具有 Auto Layout 能力,在内容发生变更后,往往需要费时费力地再进行宽高度、位置等细节的调整,无法达到设计师可用的标准。在设计稿的生产流程,会给设计师带来剧增的使用成本。本质上属于成本转移,牺牲设计角色的工作习惯或者效率去换取研发效率的提升,方案本身是不够合理的,在推广落地过程中也注定会有很大的阻力。
- 同时,由于定位是通用型工具,无法感知设计系统的细节,缺少定制化支持,对于组件内的某些特殊 CSS 写法(如某些情况下伪类、伪元素、绝对定位等),无法很好地兼顾,导致 C2D 的产物与代码实际渲染效果可能有偏差。并且也无法很好地支持组件嵌套,组件内的自定义内容识别等实用功能。
- 另外它们的组件也没有使用设计变量,这导致设计师很难通过 design token 自定义这套组件的主题(部分设计师需要基于基础组件维护一套具有业务风格的设计组件)。一旦设计师定制了主题样式,就没法继续直接使用这类工具转化出的 UI Kit。
与通用型方案相比,Semi 由于自身掌控底层组件库资产,可针对性做迭代适配修改。对 Semi 组件的支持天然可以做到更全,更合理,我们 C2D 的产物,可以产出更合理的图层结构,以及 Auto Layout 支持,同时还能兼顾主题定制等业务真实场景。设计师使用成本不会有明显变化。