作为一名合格的UI，如果还不会写UI规范文档，只是停留在做图标的阶段，那么，要小心了。
我也是这半年来开始习惯了写规范文档，并且越来越喜欢这种对各个元素有约束的定义方式。
UI规范文档移动端开发的相对好写一些，网上也有很多范本，其实对UI来说，看着范本来写，并没有什么难度，无非就是定义一些触发区域和样式之类。我自己看过当当的H5规范，微信UI规范，大概了解了风格，后来再写的时候，就会慢慢形成自己的书写习惯。
今天就个人经验谈一谈UI规范怎么写更合适。
首先，要明确的是，规范文档是给谁看的。我们写UI规范的时候，绝对不是为了让自己逼格看起来更高，而是为了沟通更高效，以及界面做更少的标注（我自己用的是markman），有些重复性的样式，反复在界面标注，会导致最后的标注图密密麻麻，前端攻城狮拿到后也要鼓起勇气才能看下去，甚至标的太多，攻城狮们就难免有疏忽。一方面，规范文档交给前端开发，一些通用控件在规范文档中清清楚楚，看上去也会神清气爽。另一方面，自己在后续的界面设计过程中，也要参考规范文档，保证自己设计的界面的前后一致性。
所以，规范文档两个受众，自己以及前端。
其次，规范文档什么时候开始写。我的经验是从界面设计开始的那一刻，就要建立规范文档了，书写时，可以按照自己的设计顺序，确定好的设计元素都可以陆续加到文档里，一直到交付设计稿，文档有可能都是未完成状态，这里说未完成，是因为交到前端那里，真正开发时，可能会有一些不合理的地方，比如字号、颜色是不是协调、甚至突兀，包括一些CSS样式是不是不同浏览器表现不同等等，根据反馈意见，后期在界面调整的过程中，规范文档也要一并更新，是以我的规范文档向来命名 XXX（更新中）。（这么说起来，似乎还没有最终版呢~）
规范文档需要贯穿整个界面设计以及产品开发的过程。
规范文档需要写什么。这是重中之重，因为产品不同，所以差别也很大，但非常重要的一点是考虑到各种不同的状态下界面元素的样式。因为最近的工作都是B/S结构产品的开发，所以就会考虑一些鼠标经过之类的状态。移动端的规范，个人建议是先参考ios的HIG和google 的material design，尤其是2016年的MD，对各个元素定义的极其详细，所以省时省力，只需要在此基础上发挥自己的创意就好。web端不同分辨率下的样式要考虑到，哪些元素左对齐，哪些右对齐，哪些尺寸限定，哪些可以根据分辨率伸缩，当然了，如果你的团队采用响应式的布局，这些就不用考虑了。书写方式的话，因为自己之前有过一些CSS基础，所以可能会直接把一些CSS样式写到文档中。但毕竟很多UI是平面设计或者其他行业转过来的，没有任何代码基础，这也丝毫无影响我们的工作结果，只要把样式表现清楚就可以了，比如加深，变换颜色等等，当然，我个人建议是在PS里实现的效果尽量转成CSS样式，这个可以使用一些在线的工具，代码可以拷贝，非常方便。另外，现在强大的css3真的可以实现各种样式，所以小伙伴们按钮之类的就尽量不要再切图了。
移动端：以平台规范为基础。
web端：考虑到多种状态及定义不同屏幕分辨率的表现。
还有一个问题，就是规范文档里已经定义好样式的，界面图中要不要做标注，我的建议是可以备注上（见规范文档），不要因为文档里定义了，就理所当然的认为开发人员一定会理解哪些可以在规范文档中查找。很多前端沉浸在js的世界中哦。对他们来说，更有成就感的事情或许是写一堆判断，而不是100%的复现你的设计文稿。
如果想得到和界面设计效果图最接近的开发后的样式，就不要怕麻烦，界面标注中也可以有规范文档里的内容。
一份好的规范文档的定义非常简单，就是当你交付给前端的时候，他在开发过程中不会问你任何问题，当然啦，需要和界面标注配合。但实际工作过程中，这是不可能的，所以多和前端沟通，毕竟实现样式只是他们工作的一部分而却是UI工作的全部体现呢。
规范文档可大可小，附上一份今天完成的一个通用组件的规范。这是我写过最精简的了~
