?‍? Kitchen 3 发布 | 让你的设计秀色可餐

画板上传、Symbol 同步、数据填充、图表生成……这些 Kitchen 2 的功能模块很多用户朋友可能都已经熟悉。我们也收到了很多建议，告诉我们还有什么功能模块是值得在工具条上拥有姓名的。比如，很多朋友希望智能排版能够回归，而一些设计方法论相关的功能也是值得一做的。

我们的团队是有限的，但大家的创意和热情是无限的。所以 Kitchen 3 支持集成第三方插件。

犹如商场里可以有很多空着的楼层，如果你感兴趣，可以开发你自己的功能模块，入驻到 Kitchen 3 中。

短期 Roadmap

• 插件实验室：给一些实验性功能提供孵化田，快速创新，降低硬性迭代带来风险。
• 资产+概念：在不同的设计系统中往往会诞生出特定用途的设计插件，这部分插件也应纳入设计资产概念。
• 智能生成：栅格、高阶组件和复杂信息流的生成器。
• 规范纠错：依赖设计规范，智能识别设计稿不符合规范的地方。
• 精细化提效：设计资产的使用并没有覆盖完整设计流程，设计师还需在绘图、交互标注、出图、展示上人肉费力
• 交互/视觉用户分层：交互和视觉设计师需求差异很大，当前插件中为交互设计师量身定做的功能很少，但交互中对提效工具需求非常强烈，如流程图绘制、标注以及链路大图呈现等。
• 移动端/桌面端用户分层：融合大菠萝后，在设计不同载体的界面时对工具需求也有差异性。

长期 Roadmap

• 插件市场：当前 Sketch 插件开发门槛较高，可探索提供更简易的插件研发模式，建设插件生态。
• 插件文档：静待开放

「历史包袱」说再见

Kitchen 2 底层架构老化，诸如 WebView 弃用 等问题逐渐显现，在未来的 macOS 和 Sketch 大版本升级过程中随时可能导致 Kitchen 不可用，需要修复大量底层代码。目前混乱的代码导致开发、debug、测试等效率很低。这很可能导致产品的死亡，不利于工具后期成长。

底层架构回炉

重构界面、代码，提高可复用性和可扩展性。Kitchen 目前架构设计不合理，代码重复和耦合的现象严重，且 view 和 control 没有严格分开，导致 Kitchen 的功能模块代码不具备往 figma、云凤蝶等平台直接迁移的能力。

---

✨ 「焕然一新」体验升级

为什么要重构 Kitchen 3 界面体验：

• 原生体验：管理用户注意力，新系统致力于 Sketch 原生界面兼容性，使 Kitchen 符合 Sketch 原生视觉以及交互系统，减少使用过程中的跳脱以及突兀感。
• 重构系统层级：随着 Kitchen 功能逐步增加，功能入口暴增，急需重新梳理工具系统层级以符合用户使用逻辑，以及提升复用性为后续能力扩展留下空间。
• 优化使用体验：在功能和设计系统增加的情况下，需要致力于降低用户学习成本，符合通识性使用习惯，做到各项功能及时陪伴与反馈。

---

「C2D2C」设计工程化

维护一整套设计语言系统，同时基于这套基础系统，会针对各个具体产品、BU 衍生出很多子系统。问题就在于，每次要改基础系统里的组件或是规则的时候，就会不可避免地产生连锁反应，导致所有的子系统也要同步修改。

另外，到目前为止，类似的设计体系在设计文件和业务组件代码上都是分离的。设计师维护一套 sketch 文件，工程师维护三套组件代码（如果用了 Native 或者 小程序）。也就是说，Source of truth 有两个甚至多个。理论上来说，这会导致很多重复工作量：任何改动都需要设计师和工程师在设计稿和多份代码之间做同步。C2D 的目的就是让基于 React 的代码成为唯一的 Source of truth，通过一份代码渲染三端组件 + 生成 Sketch 设计组件。