我一直对建构Design system、Design guideline 很有兴趣，因为在建构的过程中，可以深度了解与思考各个元件的操作、适合使用的场景、享受制定属于自己产品视觉风格的过程。
以往的经验都是为单一专案整理出Design guideline，每个专案都拥有自己的风格。但这样的做法在团队运作一段时间后，就面临到团队人数有限，专案无限的状况。在资源有限的情况下如何达到不重工并加快开发效率，让相同元件的设计与程式码可以在不同专案重复利用，变成我们下一步目标。
于是，我们开始思考如何建构自己的Design system，不只是设计，也将程序模组化。
但在团队资源有限与同时有专案进度的情况下，并无法做到像Airbnb、Google Material Design、Ant Design、Atlassian这么完整。我们能解决的是先抽出共用元件，将其模组化，变成Common UI Library，让共用元件可以跨专案的使用。
建立Common UI Library 流程
（建立Common UI Library 流程）
当提出建置新元件需求后，我们会盘点他的实用性、必要性：
是否不同专案都会使用？
是否其他元件无法取代其功能？
这部分会直接影响要不要实际制作以及制作的先后顺序。接着设计师可以为了这个元件提案，提案包含：
提出后，团队的每个人都可以表达自己的意见。通常工程师对于「功能涵盖范围与互动操作」会跟设计师有比较多的讨论，原因是各自还有专案进度要做，所以会讨论现阶段这个元件要做到多完美、多通用。
实际操作后，工程师会Pull request 给团队做验收，验收项目包含：
视觉呈现
功能与互动操作是否达到预期
Code review
验收完成后才能Push到Common UI Library，这就是我们建立的流程。
建立了内部开发使用的Common UI Library: MTKUI 后，除了加快前端的开发速度外，最重要的是可以让设计师将重心放在流程规划的部分。
但这样的流程要维持不太容易。除了刚刚提到的各自还有专案进度要做，在这个流程里我们并没有指定是哪位设计师与工程师要负责什么元件或模组，靠的是自发性与热情。
当专案一忙起来，建置的速度就会延宕 ; 再来是前端技术日新月异，所使用的套件如果升级，免不了要再花时间调整。其他的缺点还有设计风格会被局限、建置后要花时间替换原本的元件等等。
所以拥有自己的Design system 是条不归路，组织要有共识并且愿意持续投入人力才会走得长久。
要有Design system 前，还是要先知道自己的需求以及想解决什么样的问题，才讨论需不需要建置自己的Design system。
开源前的准备
（开发时程表）
时间拉回到今年初，在知道了MCS Lite 有开源计划后，我便开始收集与Design system 相关的资料。
例如什么是一套好的Design system、需要具备什么思维来设计Design system 等等，用来检视目前设计得MTK UI 在开源前还有哪些地方可以调整或可以做得更好。特别提一下，我并不是从零开始，而是从现有的MTKUI 抽出Lite 所用的元件，做开源的准备，我们就称它为『MCS Lite UI』吧。
以下是我在开源前做的一些准备：
1. 命名的规划与整理
(Note)
从Common UI Library 抽出Lite 所用的元件，并做开源准备的第一步就是整理命名。
除了了解各元件正确的名称外，如何让整体命名逻辑一致，使用起来一目了然？这时脑中会突然涌现很多想法，例如需不需要加上底线呢？使用分隔线呢？还是用空格？要用大写还是小写呢？
决定命名逻辑的同时，也要想一下元件的最小单位是什么？要怎么划分？例如元件切割得越小、Symbol 化越多，可以调整的弹性越大，但整份Guideline 也会变得复杂，特别是当使用者要更改状态时。
以下是几个范例的观察：
比较之下，我发现自己的实际操作习惯比较类似Google Material Design，所以命名逻辑会比较参考它。
(我的Symbol 命名)
简化一个例子：组成一个基本类型的Input 包含Label, Input box, Input box 的状态以及Input box 里的提示字和输入文字。所以分类就会是：
input/default
input/_element/input box
input/_style/state/normal
2. Symbol 建制与Overrides 命名调整
（Symbol layer 与Overrides 命名）
延续刚刚提到的例子，input/default 由input/_element/input box 与input/_element/label 组成，组成Symbol 后你可以在右边的Overrides 看到各个Symbol layer 名称，名称太长就会以点点点显示，识别性低。所以接着要调整Symbol layer 命名，也就是左边橘色框框的部分。
（简化Symbol layer 命名）
调整命名后是不是更清楚呢？由于连结性已经建立，即便调整左边Symbol layer 的命名，任何修改还是可以同步，也可以让右边Overrides 的显示名称更精简，让使用者一看就知道这个是控制哪个元件。
所以其实在命名这阶段，可以依照团队需求或是个人习惯来制定，没有一定要遵守的规范。不过还是有些小提醒或曾经踩雷的经验可以跟大家分享：
不要用太具体的名称命名
不要用在哪个装置上使用来命名
例如Desktop modal/ Tablet modal。因为会有使用在其他地方的可能，可以改用大小来命名，例如Default modal/ Small modal。
