大部分做中后台体系的同学，大抵都会站在“巨人的肩膀”上从头规划、规划组件

最近一段时刻笔者正好在整理规划标准，在做规划标准的时候，经常面对如下几个问题：

（1）因为事务发展，标准不断在更迭，今天做的规划组件却并不合适1个月之后客户的需求。

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

（2）标准首要会集在事务组件上的考虑，可是缺少对事务流程的整理，导致流程上复用率低。

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

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

一、应该怎么预留生长性

大部分做中后台体系的同学，大抵都会站在“巨人的肩膀”上从头规划、规划组件。“巨人的肩膀”例如ANT DESIGN，大而全，在列表和表单组件引证时十分丝滑，可是却缺少精细化和对事务诉求的承载。

因而，大部分的同学都会结合事务诉求，构成一套对公司事务有强支撑和专业化的组件，做到小而精。问题是，规划同学在规划标准时，心里的那杆秤一直摆不平。定的太严谨，未来事务改变后，组件又需求从头开发，不行预期的提高了开发成本，定的太松懈，前端引证时会bug频出。

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

1. 什么是生长性

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

再比方标准建立初期，事务是以国内为主，但因为疫情之后，国内僧多粥少，企业考虑未来出海，走差异化竞争。此时，国际化最直观的改变在文字和行高标准，多门言语，多种文字在相同场景下会呈现承载空间不行或过于充裕等问题。不同国家对部分结果页指示也会有文化忌讳，此时就需求尽量防止引起语意抵触的部分。假如标准预留了满足的生长性，事务迅速调整时，规划和开发也能无缝跟上，节省时刻，抢占市场。

2. 生长性的边界在哪里

标准总体来说，是规划和开发一起的指引。生长性的边界在于“是否能做到清晰的指引”：开发在引证时，能否应对各种报错、能否处理极点场景，能否应对产品司理临时的小需求等等。这些都是判别生长性区间规模的衡量标准。

3. 怎么在组件中预留生长性？

（1）通盘考虑报错

在规划报错提示组件时，需求整合多个事务场景下，除了需求通盘考虑款式之外，也需求和前端同学讨论是否会影响功能的改变。

大部分的报错能够分为：表单报错、列表报错、大局报错、事务场景新组件报错。报错提示如若不能一起适应这四种场景，就需求将组件做款式微调，分成四种报错款式，整合到标准中。

（2）界说极点场景

比方因为许多场景下，事务诉求很可能会在原有组件中加内容、加层级，而增加的工作量往往产品会直接交给前端同学完成，因而假如界说好了极点场景，规划同学就不用每个需求下都需求做微调，前端同学对极点场景做判别，即可轻松完成作用。（涉及到工作流程的问题）

（3）提前预留承载空间

首要，就需求厘清现有事务控件承载，比方页面区域东西栏，东西栏自身区域有限，而事务方在不停加东西，在规划初期就需求规划好，页面承载空间不行时，应怎么处理，这样利于后期的延展。

（4）多端视觉和交互标准，保证品牌延展性

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

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

因而在规划组件时，假如我们通盘考虑了该组件在PC端和移动端、Pad端的可承载性，便能够让品牌得到了最大化延展。

（5）无障碍规划

标准建立初期，服务的是大多数身心健康人士。随着事务拓宽，企业品牌建立，对于残障人士的无障碍规划、老年人关爱模式，是否需求考虑其中。需求一起结合公司品牌定位，为产品预留生长性。而无障碍规划的标准，国内外许多知名企业已经依据残障人士的特色，有一套该怎么建立的引导，规划同学只需求顺延，结合事务，建立自有的无障碍标准即可。