项目背景与目标
为什么要做设计系统
司主营业务分别是向实体医院 的B端业务——智慧医院、互联网医院；面向用户的C端业务——能医、能医生，另外还有能护、慢病全病程管理，多形态、多线路产品并行，尤其是智慧医院与互联网医院历经4个版本迭代、介入1000+实体医院，覆盖6亿用户，需要高效响应各个区域实施团队的需求。
原有的4.0版本使用Sketch进行设计、有简单的设计规范，其他产品基于智慧医院风格、延伸设计。负责不同产品的事业部相对独立、相对应的产品经理、项目经理、设计师水平参差不齐、组件无法全局共享，导致同一公司的不同产品无法保持高度的一致性、响应设计需求效率相对较低，同样页面与功能组件改造成本偏高。
我们的目标
司主营业务分别是向实体医院 的B端业务——智慧医院、互联网医院；面向用户的C端业务——能医、能医生，另外还有能护、慢病全病程管理，多形态、多线路产品并行，尤其是智慧医院与互联网医院历经4个版本迭代、介入1000+实体医院，覆盖6亿用户，需要高效响应各个区域实施团队的需求。
设计系统的搭建
设计系统建立的基础是对业务场景的深度理解。
作为设计师，进行优雅的设计，是基本职责，但任何设计系统都不能只停留在视觉设计层面，视觉设计的一致性、优雅固然重要，但脱离业务场景建立设计系统，无法在真实项目中落地，终究只会成为设计师自嗨的产物。
风格设定
首先基与原子理论与8像素网格设计体系，设定整个设计系统的基础风格设定与板式。定义品牌色为基础的颜色体系、灰度体系、字体排版设计、圆角、阴影等，保证整个系统是在同一风格调性下搭建。
组件抽离
绑卡、挂号、问诊、缴费、查询各种就诊记录、问诊是智慧医院/互联网医院的核心业务场景。其中包含记录卡片、医生/医院卡片；输入表单、弹层、弹窗等共性组件，将这些常见的业务组件进行统一设计，便可以保证整个物业70%核心场景的一致性与落地的应用性
组件构建
基础组件构建的实例（业务组件）是业务落地的关键，交付到设计师/产品经理进行协作70%都是在实例层，要充分考虑到使用者的便捷性，通过开关切换、类型或状态的选择对基础组件进行控制与切换，转变成不同状态的组件样式。
建议在「原子理论」基础上， 再细化「元素」层，元素层是最小颗粒度、可以用作构建基础组件，保证基础组件也是可以通过切换元素组件来实现不同状态的切换。如：日历组件，我们需要使用日历组件来配合其他组件样式，构成不同的业务场景，如科室列表、医生列表等，同时需要快速切换不同日历视图。基于此，使用元素组件构建基本的日历组件，日历组件属于原子层级，如果不使用元素组件构建，直接用文字、形状构建，是无法做到快速切换单日样式，需要解组取变化不同的状态文字、文字和形状颜色，这样整个组件又会变得低效，只是在样式层。将所有元素作为一大组件分类，不打乱原子结构，也便于维护和全局替换组件样式。建议元素层不对外发布。
一个真正的组件需要满足不同样式、状态的切换，同时要注意组件变体的数量，减少冗陈，保持轻量化，太多的组件除了增加维护难度，也增加组件应用成本，在调用组件时，太多的组件，无疑是令使用者崩溃的。
我们可以使用Figma的组件变体+组件属性共同进行构建，组件属性可以无需不停的点击组件，选择要修改的对象，在组件本身修改，可以在侧边栏修改文字、切换组件、控制内容的显示与否，这将大大减少组件的变体数量，毕竟每一个变体就是一个组件。变体则可以用于组件属性无法满足要求时，同一类组件的不同状态。
以「功能列表组件」为例，组件需要支持图标更改、标题更改、开关模式、指引箭头是否显示、提醒信息、字段信息，通过不同组件元素的切换，转变成「功能列表组件」不同的状态。
单纯的使用组件变体构建，就会像下图一样，存在十几个组件（在我刚开始搭建组件库的时候是这样的，没有组件属性功能，每一个样式就是一个组件变体）。
使用组件属性控制图标的显示、文字的修改、字段信息的显示与修改、提醒信息的显示与修改、单选、多选、箭头的选择。显示与隐藏通过图层的显示与隐藏实现，这也是开发用的基本数据类型boolean（布尔型），文字修改通过文字属性实现，图标（图片调用搭建的通用图标库）则是在组件属性进行切换，在设置完成后，我们只需要一个组件，变体都不需要，就可以实现之前要十几个组件才能实现的效果，同时80%的操作都在侧栏，直接暴露，操作更便捷，无论是设计师还是产品经理，都可以轻松上手。
组件文档
完成组件构建后，将场景实例与公用组件，按照统一的布局规范与交互规搭建模板。模板可以更好的更快速的完成页面的搭建，使用效率进一步提升。模板无需所有业务、所有页面都要做，只需要搭建你人为的在布局上比较有代表性的页面。
模板
完成组件构建后，将场景实例与公用组件，按照统一的布局规范与交互规搭建模板。模板可以更好的更快速的完成页面的搭建，使用效率进一步提升。模板无需所有业务、所有页面都要做，只需要搭建你人为的在布局上比较有代表性的页面。
