吉林省住房建设安厅网站安全管理,高校建设网站的特色,汕头房产网站建设,建设网站必须要服务器吗目录
设计系统
设计系统的定义
设计系统的优势
设计系统存在的问题
设计工程化
设计系统探索
设计系统落地实践
Design Token
Design Token 实践
设计工程化理想方案构想
展望
参考文献 近几年围绕业务中台化的场景#xff0c;涌现出了许多低代码平台。面对多组件…目录
设计系统
设计系统的定义
设计系统的优势
设计系统存在的问题
设计工程化
设计系统探索
设计系统落地实践
Design Token
Design Token 实践
设计工程化理想方案构想
展望
参考文献 近几年围绕业务中台化的场景涌现出了许多低代码平台。面对多组件、多页面、跨平台的复杂场景如何保证整体的用户体验一致性减少用户认知和负担提升用户使用效率便成为业务迫切需要解决的问题。本文从组件化角度聊聊设计工程化是如何解决模块化与规模化的问题。 从传统软件工程的思路出发组件化是解决复杂模块的抽象、复用及统一的常用解决方案。那么对于中台设计来说是否也能借鉴软件工程学的思路来解决设计遇到的模块化与规模化的问题呢这便是近几年设计工程化所讨论并尝试解决的问题。 设计工程化源于 2013 年 Brad Forst 提出的原子设计理论Atomic Design理论使用一种有条理创建模式库的方法结合软件开发的组件化思想从最原始的原子出发逐层构筑更高级别的组织以解决设计模块化的问题这就是设计系统的前身。 设计系统 设计系统的定义 设计系统是由设计语言和模式库构成在设计原则的指导下通过统一的协作语言和科学的管理方法组织起来并创建体验一致的用户界面的系统。其目的是用于提高设计师和研发人员沟通效率协作效率的实用工具也能够更为客观地反映用户的需求。建立有效的设计系统不仅能提高设计决策和协作的效率也能减少系统出错的可能性。
设计系统的优势 沟通效率以往由于双方专业知识领域的差异而不好理解的概念变得清晰了许多例如在讨论组件的视觉呈现和交互逻辑时往往需要不少的沟通和反复调整的成本如今也因为规则的约定而顺畅了许多 一致性产品在跨项目、跨平台的场景下借助设计系统约定的规则使用一致的设计语言来避免产品快速迭代中可能遇到的视觉交互体验不一致问题 文档化将设计语言、设计规则、模式库文档化详细说明组件的外观交互适用场景等可避免设计研发无根可循 模块化组件化使用有限的规则来指导设计和研发这样可实现设计研发关注点分离并且利用原子化设计理论逐层构筑模块、模板、页面等 可维护性原子化的应用增强了模块的独立性使得设计和研发的迭代更新变得高效当一个模块需要更新时使用这个模块的更高阶模块也能够同步更新 协作效率设计系统的引入解决了设计和研发两种角色在产品迭代链路中信息丢失和同步问题大部分未遵循设计规则的组件模块能够被及时发现并抛出
设计系统存在的问题 自 Google 推出 Material Design 以来各个大小公司的设计团队都花费了大量时间整理并发布自家产品的设计规范。用百家齐放来形容并不为过并连续三年占据设计领域的热度榜。甚至有些规模不超过10人的小团队也都投身到设计系统的整理中似乎变成了每个设计团队的 KPI。
经过各个团队的验证目前设计系统存在以下需要好好思考的问题 整理耗时定义所有的设计规则和约束以及基础和业务组件的整理都需要经过大量的讨论不仅仅涉及设计团队内部的沟通也涉及各个业务线研发团队的外部沟通。 维护成本设计系统是需要不断维护并迭代的并非一劳永逸 缺乏创造力业务迭代受限于设计系统的规则和约束创作的空间少了但也带来了产品体验的一致性 复杂度高模块化可降低系统的维护成本但相反地会提高模块之间的耦合度使得产品创新性难以提升 如果从长远的角度看一个好的设计系统不仅仅要能支持当前阶段的设计和研发工作也要能支持一个团队的整体协同工作更要能支持从规范本身出发不断地进行演进和创新。
设计工程化 设计系统的流行推动了设计工程化的发展下面对设计工程化的讨论主要分为两个部分第一部分是以设计师视角出发的设计系统探索第二部分是以工程师视角的设计系统落地实践。
设计系统探索 以产品生产链路来看设计稿作为生产的上游输入源资源的生产方式和管理方式直接影响下游如研发生产的交付效率。设计系统的引入对于设计师来说必然得主导系统的落地运行以保证设计资产的质量与流通顺畅。 但设计系统的落地强依赖于生产工具的能力传统的 PhotoshopAI 等设计工具缺乏资源管理维度的能力。在现代设计工具如 SketchFigma出现以前设计系统往往需要借助第三方平台提供的插件并按插件规范命名图层组织设计资源才能生成设计系统文档。设计规则和约束依旧无法很好的融入设计工作流于是在 UI 设计工具领域出现了 Figma, Sketch 等新宠尝试将前端工程化的思想带入设计领域。 设计师在完成样式设计后研发工程师需要按设备的尺寸还原设计的排版布局意图。这造成了 UI/UX 和工程师之间的职能错配和重叠问题工程师似乎承担了不少设计层面的实现任务。Figma 将组件化思想融入设计工具的同时还引入了 Variants 等概念。让组件的响应式设计任务回归设计师由设计师把控组件交互的各个形态。同时也因为颜色变量、文本样式、图层样式等运用复用思想的特地引入设计系统的运行与维护设计资产的流通也顺利进入设计师的日常工作流中。
设计系统落地实践 作为「设计系统」执行方的设计师与前端工程师日常工作分别是在两个差异化较大的工作流中进行的。常规流程是设计师在设计工具Sketch、Figma中完成页面设计后前端再参照绘制好的原型稿和标注稿在代码环境中还原视觉稿 UI/UX。
但在这个过程中时常会遇到以下问题 ·前端如何高效的获取上游设计的更新 ·视觉稿中可复用的设计系统原子如果准确地传达给下游 ·视觉还原工作还能提效吗
前端如何高效的获取上游设计的更新 设想这么一个场景在产研交付的过程中设计师在视觉稿中做的每次修改都希望能快速响应到最终的产品中尽可能做到敏捷。而实际工作中设计上游变更后会告知前端存在少数变更不告知的情况前端再打开包含标注信息的设计工具和代码编辑工具完成需求修改。在这个场景中设计师会通过口头或文字罗列视觉变更点存在一定的沟通成本和信息丢失问题。在最终产品交付上线前还会经过一轮「设计走查」环节敏捷开发中经常忽略的一环可能又会产生新的设计上游变更如此反复。
视觉稿中可复用的设计系统原子如何传达给下游 一个成熟的项目往往会有自己的设计系统设计原子作为系统中可复用程度较高的模块已深度整合到设计工作流中。但由于设计和前端领域的概念不互通导致可复用的信息不能有效传达。虽然设计师会整理包含字号层级品牌色板卡片阴影等信息的设计规范文件但这些信息往往不能在视觉交付稿中很好的展现。要理解视觉稿中的设计原子前端需要了解设计工具中的概念如 Sketch 的图层样式、SymbolsFigma 的 Variants 等等。设计师是最了解页面样式复用逻辑的但真正实现页面样式的却是前端工程师这不可避免产生视觉还原误差。
视觉还原工作还能提效吗 设计师在绘制好页面视觉稿后前端需要将视觉稿还原成可交互的页面按古早的分工这里需要三种角色参与分别是视觉设计师、页面重构工程师负责 HTML CSS 等 UI/UX 逻辑和前端工程师负责数据渲染等逻辑。本质上视觉还原就是将设计工具中的视觉稿描述转换为 Web 能理解的数据描述即 HTML CSS。而这一块的信息转换工作正是团队近一年来尝试攻克的点团队立项的「Deco 智能代码项目」通过设计工具插件从视觉稿原始信息中提取结构化的数据描述D2C Schema然后结合规则系统、计算机视觉、智能布局、深度学习等技术对 D2C Schema 进行处理转换为布局合理且语义化的 D2C Schema JSON 数据最后再借助 DSL 解析器转换为多端代码。 智能代码解决了视觉还原工作整体的效能问题但具体怎么让设计系统完美衔接研发工作流降低设计研发协作成本提升最终产出代码的可维护度正是 DesignToken 可以发挥作用的地方。
Design Token Design tokens are the visual design atoms of the design system — specifically, they are named entities that store visual design attributes. We use them in place of hard-coded values (such as hex values for color or pixel values for spacing) in order to maintain a scalable and consistent visual system for UI development. -- Jina Anne 用上述 Design Token 之母的一段话我们可以这么理解 Design Token。Design Token 是一种以平台无关的方式来表达设计决策的方法以便在不同领域、工具和技术之间共享。在设计系统中的Design Token 代表了构成视觉风格的可复用的设计属性例如颜色、间距、字体大小等等。Token 被赋予一个特定的名称color.brand该名称对应于某个设计决策定义的值#3271FE。 但有别于设计变量Design VariablesDesign Token 是一个具有平台无关性的抽象层该抽象层的命名约定为设计属性创建了一种通用语言可支持跨应用跨平台跨框架使用。
Design Token 的工作流程如下 按照 W3C Design Token 兴趣组最新拟定的草案Design Token 主要涉及三个部分
令牌Token 设计工具Design Tool
设计工具如 Figma、Sketch、AdobeXD 等负责生产并维护设计系统中的 Tokens。
翻译工具Translation Tool
翻译工具是将 Design Token 从一种格式转换为另外一种格式的工具如 JSON to CSS。
Design Token 实践 在「Deco 智能代码」项目中研发可以给项目关联特定的设计系统DSM如「京东 APP 设计系统」其中包含文本样式图层样式调色板等设计原子。Deco 在做布局样式还原时会优先使用设计系统中已有的 Design Tokens 并进行替换并会标记设计系统中暂未录入的设计变量例如不在设计规范中的色值字体大小等。 Design Token 的引入除了可以给布局还原的代码做样式精简外还能为视觉走查提供便利。因为 D2CDesignToCode的技术方案中产出的代码视觉还原度可以达到将近 100%设计师可以更多地关注自身视觉稿的设计系统覆盖度借助上述流程中被标记的「设计变量」列表可以十分方便的确认设计误差例如设计规范中规定的背景色为 brand-color-bg: F7F7F7但代码还原后的背景色未被替换为brand-color-bg而是 #F6F6F6。
设计工程化理想方案构想 设计工程化解决的是规模化效率化的问题。首先从角色分工上按职责划分任务涉及视觉呈现层面元素边距字体颜色大小等的工作交由设计师负责研发只负责业务逻辑的功能开发。而设计稿到产品的视觉还原功能可结合 D2CDesign To Code和 Design Tokens 来实现。D2C 负责页面视觉和响应式设计的自动化还原工作Design Tokens 负责把设计决策产生的设计因子整合到开发工作流从而完成设计系统在设计和研发产研链路中的落地串联。 通过上述方案我们可以初步实现设计稿静态页面还原 响应式设计的工程化。即解决了 UI 到研发的链路打通问题。那对于设计系统中的交互逻辑的部分即 UX该如何实现工程化呢 以往的组件交互逻辑如按钮的点击交互下拉菜单的展开动画大多是由设计师口头或简单地画组件的分镜状态来跟研发进行协作的。缺乏交互规范即使设计系统文档中有明确的交互设计规则研发之间也会存在实现方案的差异无法保持交互统一性和可维护性。 Figma 给出的解决方案是在视觉稿中直接绘制组件交互原型再借助 A2C Animation To Code插件转换为动画描述文件Animation JSON Schema最终通过动画解释器Animation Parser完成 UX 链路的转换工作。
以上便是现阶段设计工程化落地的解决方案。
展望 设计工程化探讨的不仅是产品设计系统的搭建过程也是设计和研发两种角色的分工转变及协作效率提升的过程。设计系统是一个具有包容性且充满生命力的东西包含从组件库到设计语言的结构化体系以及应对不断变化的创新迭代过程。Design Token 恰好是打通设计研发工作链路的一把钥匙但不应该只有一把。 好的设计系统可以在产品的一致性和品牌的创造性表达之间取得平衡好的组件化思路也应该能最大化运用设计系统的价值。在未来随着技术的推陈出新比如 AI 画图尝试通过机器学习的方式生产艺术画设计工程化也会有更多可探索的方向。
参考文献 探索 Design Token 现代 Web 开发困局 万字长文从产品设计到发布的全链路智能化 设计工程化三部曲 https://juejin.cn/post/7122711998839652389#heading-13 Ant Design 设计工程化 https://zhuanlan.zhihu.com/p/344336425 提效神器 Design Token 的探索与应用 https://juejin.cn/post/7120150297808207909
