各行各业都有着自己的规范，那么我们在做设计规范的时候，常常会面临着一些问题。本文大致总结了两个问题：规划缺乏生长性和可复用性。那么该如何解决这两个问题呢？作者对此进行总结，希望对你有所帮助。

最近一段时间笔者正好在梳理设计规范，在做设计规范的时候，经常面临如下几个问题：

（1）由于业务发展，规范不断在更迭，今天做的设计组件却并不适合1个月之后客户的需求。

简而言之，规范缺乏对未来的规划，缺少生长性。

（2）规范主要集中在业务组件上的思考，但是缺乏对业务流程的梳理，导致流程上复用率低。

（3）缺乏对整体信息架构的梳理，缺少全局上对产品的思考。这个优势在于避免重复造车轮，有利于合并同类项，让产品更轻量，更易用。

简而言之，规划缺乏生长性和可复用性。

一、应该如何预留生长性

大部分做中后台系统的同学，大抵都会站在“巨人的肩膀”上重新规划、设计组件。“巨人的肩膀”例如ANT DESIGN，大而全，在列表和表单组件引用时非常丝滑，但是却缺少精细化和对业务诉求的承载。

因此，大部分的同学都会结合业务诉求，形成一套对公司业务有强支撑和专业化的组件，做到小而精。问题是，设计同学在设计规范时，心里的那杆秤始终摆不平。定的太严谨，未来业务变化后，组件又需要重新开发，不可预期的提高了开发成本，定的太松弛，前端引用时会bug频出。

其实导致“秤不平”，最重要是缺少了生长性的砝码。那么什么是生长性，生长性的边界又在哪里，该怎样预留生长性呢？

1. 什么是生长性

生长性指的是产品方向变更时，设计组件仍能支撑业务诉求。比如原有组件设计时只考虑静态交互，而业务变化后需要新增可拖拽功能，方便用户快速处理信息。如果在设计组件时，就预留了生长性和空间，后期改动就只需要往上加，而不需要大改动。

再比如规范建立初期，业务是以国内为主，但由于疫情之后，国内僧多粥少，企业考虑未来出海，走差异化竞争。此时，国际化最直观的变化在文字和行高规范，多门语言，多种文字在相同场景下会出现承载空间不够或过于富余等问题。不同国家对部分结果页指示也会有文化禁忌，此时就需要尽量避免引起语意冲突的部分。如果规范预留了足够的生长性，业务迅速调整时，设计和开发也能无缝跟上，节约时间，抢占市场。

2. 生长性的边界在哪里

规范总体来说，是设计和开发共同的指引。生长性的边界在于“是否能做到清晰的指引”：开发在引用时，能否应对各种报错、能否处理极端场景，能否应对产品经理临时的小需求等等。这些都是判断生长性区间范围的衡量标准。

3. 如何在组件中预留生长性？

（1）通盘考虑报错

在设计报错提示组件时，需要整合多个业务场景下，除了需要通盘考虑样式之外，也需要和前端同学讨论是否会影响性能的变化。

大部分的报错可以分为：表单报错、列表报错、全局报错、业务场景新组件报错。报错提示如若不能同时适应这四种场景，就需要将组件做样式微调，分成四种报错样式，整合到规范中。

（2）定义极端场景

比如由于很多场景下，业务诉求很可能会在原有组件中加内容、加层级，而增加的工作量往往产品会直接交付前端同学实现，因此如果定义好了极端场景，设计同学就不必每个需求下都需要做微调，前端同学对极端场景做判断，即可轻松实现效果。（涉及到工作流程的问题）

（3）提前预留承载空间

首先，就需要厘清现有业务控件承载，比如页面区域工具栏，工具栏本身区域有限，而业务方在不停加工具，在设计初期就需要规划好，页面承载空间不够时，应如何处理，这样利于后期的延展。

（4）多端视觉和交互规范，确保品牌延展性

比如中台产品支持PC端、Pad端，就需要考虑同样组件在Pad下可点击区域大小、Pad交互习惯等。

比如，医疗SaaS产品，大部分私人医院都会要求产品支持Pad端。私人医院相对公立医院，更重视医疗体验，以及微营销。患者在候诊或者做康复医疗时，需要做健康宣导或者活动营销等。

因此在设计组件时，如果我们通盘考虑了该组件在PC端和移动端、Pad端的可承载性，便可以让品牌得到了最大化延展。

（5）无障碍设计

规范建立初期，服务的是大多数身心健康人士。随着业务拓展，企业品牌建立，对于残障人士的无障碍设计、老年人关爱模式，是否需要考虑其中。需要同时结合公司品牌定位，为产品预留生长性。而无障碍设计的规范，国内外很多知名企业已经根据残障人士的特点，有一套该如何搭建的引导，设计同学只需要顺延，结合业务，搭建自有的无障碍规范即可。

二、应该如何最大化规范的可复用性

流程上复用率低、产品过重缺乏全局思考根本原因在于，过度重视原子组件搭建，而忽略了整体架构和流程的梳理。

（1）引入共性流程规范

往往我们在工作中搭建规范时，会过度重视原子组件搭建，而忽略了流程梳理。规范上忽略了流程梳理，设计稿中也会难免遗漏一些场景，导致实际上线时用户体验不佳或者流程不丝滑。

举个例子：

例如在金融软件中，涉及到贷款流程，小微贷，企业贷，消费贷等，由于属性的不同，各个贷款流程在细微上有差异，也有共性。在梳理设计规范时，就可以提炼共性的贷款流程，封装组件。在前端开发时就可以节省不少人力。

再比如医疗SaaS软件中，会诊流程和日程流程：

• 日程：发起日程-邀约日程-再次邀约（未及时加入提醒）-记录日程。
• 会诊：发起会诊-邀约会诊-再次邀约（未及时同意提醒）-线上视频会诊（线下记录会诊内容）-上传会诊记录-跟进会诊后患者状况。

本质上，会诊也是日程的一个分类，但由于会诊涉及到多个角色的协同，分为普通会诊和多学科会诊，比普通日程更加复杂，是属于长期的工作流，因为会诊除了会诊之外，同时需要关注会诊后患者的治疗，以便下次会诊复盘。

将日程和会诊的共性流程进行封装，将为开发带来诸多便利。

（2）梳理信息架构

Z轴分布包含平面内部的分布和空间上的排序。平面的分布可以梳理各个一级页面、二级页面的框架层，便于设计组内同学在设计新页面时参照规范快速出稿。而Z轴上的空间分布，包含浮层、弹窗、提示等的出现次序和排列。提前规划好排列顺序，有利于组件冲突时，有可供参考的规范引导。

（3）文案规范

文案往往体现产品气质。梳理文案规范，有利于从产品上提升企业气质和形象。可以将文案分为引导类文案、描述类文案、报错类文案等。而文案规范梳理应该放在成熟期的产品使用。业务在蓬勃发展期间，还是应探索业务组件为主，文案规范可以往后延展。

以上是笔者结合项目经验的一点心得，希望能帮助到大家。