原创：黛西 Keep 设计体验与研究中心 2019-01-11 19:33:28

前言

设计开发语言已经不是一个新概念，早在 Yahoo 时代就已产出一套完整的 Yahoo UI Library，而目前很多公司也设立了组件团队 UX-Engineer Team 来搭建、应用与维护，甚至开发专门的工具支撑。
那么，在 Keep 发展了 3 年左右，相对成熟但没有基础中台组织架构人力保障的时候，如何由设计驱动，运用设计开发语言，来解决现阶段产品存在的问题，并创造更多设计之外的价值呢？

背景与问题

从解决问题开始到体系化收益，先看看存在什么问题。
以下是一段工作中的真实对话：

测试：“这个 Toast 的位置有点尴尬，我觉得放在上方比下方好，你觉得呢？@产品” 研发：“在上面好像明显一点？” 产品：“哪里明显就放在哪吧！”

「你觉得、好像、我感觉」我们每天都在工作、生活中做着各种各样的决策，不可避免的容易使用个人主观经验与感受去做判断，而互联网产品设计开发是逻辑严谨而科学的实践。在产品业务刚建立，只有一个产品经理和设计师的阶段，偏向主观决策难免会使得产品带上一些个人色彩。但随着团队的发展，从一人到多人，单业务到多业务，产品复杂度不断增加，加上 iOS、Android、Web、小程序等不同平台的特性差异，公共框架应更像同一个人做出来的，产品设计代码的公共部分应该有更多同质化的合并利用。所以当这些呈现在一个平台客户端之内的时候，如果我们缺乏客观有章可循的设计开发语言，就会产生产品内部、外部的各种问题。

一、外部体验层

外部问题
体验是「感」与「官」的结合，除了视觉观感的体验，如果底层交互行为没有统一的定义就会产生不一致的设计与代码，导致产品设计开发的臃肿，如：

相同场景下的弹窗文案不一致
从基础组件到垂直复杂大体量的业务和横向多条业务线中的体验问题会积少成多越发严重，容易造成用户感知的混乱，折损产品的易用性及用户的使用效率，不利于培养简洁一致的用户心智与沉淀体验品牌。

二、内部协作模式与效率：

内部问题
1. 随意新增产品设计行为样式
不断按照个人主观意识去新增样式、放任行为规则，会导致产品功能行为不合理，并产生大量重复的代码。
2. 缺乏严谨的底层 UX 规则
UI 底层的产品逻辑结构基础不牢固，UE 行为操作与规则定义不统一、不确定。
3. 产品设计开发协作困难
当我们对组件规范缺少系统的存储以及迭代机制，内部员工之间以及新增人员，会花费大量的时间在协作上面，造成内部消耗，形成不好的循环。
4. 无法快速支撑业务
基础设施资源利用效率低，当面对新业务时，无法应用设计开发语言快速搭建产品，影响构建产品壁垒的速度。

早期业务从零开始建立的时候，需要快速在混战中定位产品、建立业务，业务的体量和产品复杂度小，公司往往是依托某一个业务线生长开来。

单一业务线
为解决以上问题，我们使用搭建设计开发语言的手段，作为平台基础设施的公共资源，强力透传提供给全业务线应用，一定程度上弥补了对中台建设的不足，底层自下而上，从一致科学理性的源头触达给用户。

全业务线应用
无论产品如何升级、业务如何快速增长，界面、结构、操作应该保持一致而收敛，而不是新增、堆砌和过度设计开发。协作产品、设计、开发的角色建立一个更好、更快的产品。「更好」因为一致的体验更容易被用户理解，「更快」因为建立统一的设计开发语言后，面对新需求时可以直接调用，迭代组件时可以全局生效，实现从分业务线单个页面到集群批量修改迭代组件。甚至某些情况下，可以免掉 UI 设计与标注，业务可以直接根据需求调取代码库组件。

什么是设计开发语言

设计开发语言是通过对具有一定量级的业务功能、内容进行拆解、归纳共性、拼装组合，尽可能从底层上给予标准的定义和场景分类，并进行设计开发的封装，以高效复用，取代重复的一次性设计开发，一定程度上实现组装产品页面。从而在提升效率的同时，保证产品设计的正确性和一致性，沉淀内敛高品质的体验品牌。
设计开发语言本身如何定义其实并不重要，某种角度上来说设计开发语言其实是对多人员行为与协同、业务增长复杂度的一种「人」和「事」的管理规范原则依据和工具。

什么是设计开发语言

一套优秀的设计开发语言在研发团队的配合下将成为产品发展进步的发动机

我们如何理解一个产品所处的阶段，决定了采取对应的工作方式，从而事半功倍。

产品不同阶段的设计开发语言方式

1. 新产品建立阶段
   在业务最初建立的时候，由于没有业务体量，无法抽取共性，从而无法被组件化。此时只能靠经验丰富的产品、设计、开发进行归纳，不对相同场景的设计增加主观的样式和代码。随着业务量级的增加，从底层基础样式和控件开始逐个明确，根据 UE 定义，匹配 UI Symbol，开发进行控件封装，存储在公共代码库，和业务解耦，同时供各个业务调取复用。
   2. 成熟产品
   成熟的产品如果没有一开始就进行组件化，比较适合在一个大版本的时候，进行大规模批量化的替换，从复杂的业务形态中抽取共性框架，强收敛、重统一，从基础元素、基础控件、基础组件，再到业务功能组件，分层进行。

那么，什么方式适合成熟 3 年左右的 Keep 呢？

我们没有一个设计驱动的大版本来进行，并且组件化决策是伴随 3 年阶段，UE 角色的加入，设计团队一些新的尝试背景下进行的。因此选择的方式是从感知最明显的基础组件入手，组织设计团队进行内部沟通，并与产品研发团队进行组件评审、封装组件，最后修复替换各个业务线以及公共基础部分不合理的地方，慢慢磨合搭建完整的设计开发语言工作流。以控件为单元，进行两周一次的迭代。

设计开发语言的目标

设计开发语言的目标
设计开发语言的前提是保证体验准确而合理，遇到错误的用法需要进行优化更正。为保证组件拥有尽可能长周期之内的稳定性，以及尽可能广的业务形态包容性。制定组件的时候需要关注到各方面的因素。

宗旨与法则

设计开发语言的搭建需要组件委员会发起者在源头上保证完整科学。在开始之初，就确立了决策价值观。
1. 规范组件化的目的不是为了限制创造，而是为了让创造者更确定、科学、高效。所有行为决策的价值归依是产品业务。产品业务永远比组件化本身更重要，业务第一。
2. 规范不是绝对、教条、冷漠、强制的。实际工作中总会有新增需求、存优化空间、情感化设计需求超出一般通用规范。保持克制的同时，允许基于强烈业务需求的规范突破；之后如果有足够的理由迭代组件，那么就进行组件深化。

设计开发语言和业务的关系

那么，我们开始正式着手吧！

实践

Keep 设计开发语言目录
这是我们基于 Keep 自己的业务内容，结合大量的国内外 Design Language System 调研，整理沉淀的动态迭代体系目录，自下而上分为 4 个层级：

Keep 设计开发语言结构
因为元素间的递阶性，我们需自下而上分层进行。

实例

一、对话框 Dialogs

实例一：对话框 Dialogs
第 1 步：了解业务，根源业务
从 5 条业务线收集了约 50 个对话框，发现并归纳其中的问题，如：操作区的按钮样式过多、对话框信息结构不一致、蒙层交互行为不统一、使用场景不匹配等。从中抽取通用框架，进行弹窗组件的分析与行业对标，组织设计内部沟通讨论，从而保证组件有足够的业务属性、完善科学。
第 2 步：与业务解耦的封装
基于输入的业务，统一标准、枚举元件。针对所有子类别进行场景边界的定义区分，赋予 UI 之前的 UE 规则。

定义对话框结构
此时有机解耦的零件可以根据业务诉求，进行合理的拼装组合。将严谨的设计模式封装成组件，产生合理的代码，满足包容不断变化的「绝大部分」业务内容。当业务内容超出规范的部分，再看是否有强力的理由需要迭代组件。除此之外，不仅仅关注单个 Dialogs 子类别，而是整个浮层系统化的梳理。

第 3 步：应用支撑于业务
梳理已有业务中存在的问题和错误的用法，使用封装的组件进行快速替换。单个业务线增长、新业务建立的时候，使用封装的组件高效、高质量地支撑搭建产品。形成连贯一致的体验品牌，在更好更快的互联网产品迭代中建立产品壁垒。

合理的拼装组合
来源于业务、与业务解耦，高于业务抽取行为规范，而可以复用到业务中，从而形成体系的循环。

基础组件 A 需要经历的一次实践
对于一个成熟的 App，往回收的优化替换比从 0 到 1 封装本身更加困难重重，需要分基础平台部分与各个业务线进行明确和落实，使用 Keep 内部工具 Phabricator 推动监测项目进度。UE 充当项目经理，组织 PM、UI、研发，评审协作，确定统一共识并排查存在的问题，根据优先级分版本进行优化。

二、加载体系 Loading System

Loading 在产品设计中是无处不在的，是产品与用户保持沟通的一种提醒状态感知。

第 1 步：分类梳理，分 OS 平台进行标准封装
我们基于 Keep 业务以及研究行业标准，根据不同的场景结合 iOS、Android、Web 平台共性与异性，定义标准不同的 Loading 子组件类别：

Loading 的应用场景

Loading 组件示例

业务特殊场景不在组件化范围之内。没有绝对的组件化，只对基础通用的类型进行规范，既内敛又包容。但需要业务有强烈充足的理由，才可以突破规范。

特殊场景

第 2 步：组件化语言的应用
当我们封装好组件，真正应用的时候会关注到真实具体的场景，融入体验、业务等多方考虑，如：端内很多 Web 实现，为了使得产品类原生 Native 体验，我们的 Web Progress 只应用在第三方外部链接，而内部 Web 实现都是用品牌的秒表样式 Loading。
寻找端内使用不正确、不优、缺少、多余等问题明确到各个业务，逐个进行优化替换：

替换进度管理

除此之外，其他组件也使用了类似的流程与方法，进行了体系化迭代，推动了整体体验和协作方式的优化。

使用组件构成页面

体系产出沉淀

设计开发语言体系是完整、有机的，缺一不可的。一体化才是真正的贯彻执行。

Keep Design & Engineer Language System

Keep UE Guidelines

根据正确、合理的 UE 底层定义和规则，匹配对应的 UI 设计模式，直至合理规范的代码组件。

UE Guidelines

Keep UI Kit

目前我们是比较中型的团队，还无法有人力成本单独建立组件协同工具，我们暂时以 Sketch 的 Symbol 来协作共建。UI Kit 存储在云端，只要在云端更新，即实时全面的全团队更新。方便实际工作协作过程中直接拖拽，提升了确定性，同时可以从实际感官汇聚多个设计师对体验品牌的认知，改变了团队协作的方式以及界面设计的方式。从过去 「一次性」的单个页面设计到某种程度的积木式「拼装」产品页面设计。

UI Symbol 的构建也是多维度的：
• 不同的状态：Normal / Pressed / Disabled / Loading
• 不同的平台： iOS、Android、Web、小程序是否全部统一或是差异化分平台封装
• 不同的尺寸：局部 / 半屏 / 全页面
• 实际适用：深浅页面上的适用性
• 响应式布局组件：高效协同，可以在不同尺寸上面自适应

响应式布局组件

Keep UI Redlines

UI Symbol 像单个积木零件，是拼装的散落原料，一个完整有机系统的设计不只规范单独的元素。UI Redlines 则是将控件组件按单元进行罗列集合，关注元素之间的布局、间距关系、和位置，更偏 UI 的标注和 UI 强相关的简单说明。

UI Redlines

Keep Writing Guidelines

文案在产品设计中无处不在的，对于普通用户对互联网认知，文字的直接性是要远远高于 UX 模式的，是直接与用户沟通的重要载体，同时是关乎用户体验、业务转化、品牌塑造的重要组成部分。如果我们去责备用户而不是激励用户，总是让用户花时间去理解上下文、重复已知事实…长久下来给用户的消极感知会不断折损体验。我们修改统一了 Keep 端内几百处文案表达之后，针对遣词造句的原则以及界面书写规范沉淀了完整合理的 Writing Guidelines，甚至融合了心理学的范畴，让所有的产品设计行为有章可循、科学严谨。尽可能的抵抗一切的主观意识。

收益

当全面、准确、前瞻的设计开发语言逐步搭建，代码也按照控件、组件开发。形成了良好的存储、协作、与迭代机制。实现快速效率完成基础产品搭建，解放基础人力去着眼产品问题解决以及面向未来更多的可能性。

全局更好的调取 & 迭代组件

尽管设计开发语言第一批建立者封装与线上优化收敛的工作非常困难，而之后的工作中，收益会不断的体现。解决本文开头提及的一些问题之外，还包括统一线上产品，使用现有组件不断的去满足新业务的诉求。
更快、更好还体现在：业务只要调取了组件，当组件源头迭代的时候，可以在全业务线联动生效，实现集群批量化修改，取代过去割裂的单个页面各自发展的弊端。并且高效高质量的传承了体验品牌。

后续

一、维护与迭代，应用适应阶段

在搭建完 1.0 版本之后，仍有大量工作需要进行：
「事」方面：控件与组件是固定的，而业务需求是复杂而多变的，UI 样式相比 UE 规则，要更容易执行，规则难以被全部封装，因此需要全体人员的思维意识与执行，此过程需要不断的跟进推行。
「人」方面：增强全体产品研发团队的闭环原则，加强公司级的公用意识。

二、设计与开发更紧密

1. 共同建立培训机制
   实际工作的过程中，为确保组件化设计开发的贯彻实施，需要有产品、设计、开发成员的协作机制保证，包括对新员工的培训，组件代码库文档化等。
   2. 应用业务
   全面的业务应用，帮助业务达成指标。建立 UX-Engineer 机制，使用「封装」的基础设施资源，一方面不断的修改优化线上，另一方面更快更好的支撑新的业务需求。在一段时间周期约一年左右，可以地毯式更新 App 中不合理的部分。

总结

本次设计开发语言的搭建，是 Keep Design 伴随交互团队的搭建开始着手的。UE 是一个综合性很强的岗位，充当虚拟的平台角色和项目经理，以建立极致的用户体验为目标，从公司和产品的阶段出发，专业透传与强力驱动，让全体产品研发团队相信与改变。

无论是什么岗位，Title 不重要，设计师从解决问题出发，发现更正确、更有价值的事情，驱动解决问题，把正确有价值的事情做到极致，对产品设计保存匠心和敬畏之心，不随意主观的新增，让一切的产品设计开发行为有理有据。

以上，是关于 Keep 设计开发语言的实践与思考，感谢全体产品研发团队的努力，在有限的时间精力支持下，让我们「好看」的 Keep 更有了逻辑与科学严谨的改变。任何伟大的产品都是一步一步开拓建立的，Keep Design 将继续前行，以极致统一的设计语言给用户友好、稳定、有信赖感的使用体验，用更美、更酷、更好的设计助力「Make the World Move」的愿景，愿你 Keep 健康。