UI设计的规范标准有哪些
UI即User Interface(用户界面)的简称，UI设计是指对软件的人机交互、操作逻辑、界面美观的整体设计，好的UI设计不仅是让软件变得有个性有品位，还要让软件的操作变得舒适简单、自由，充分体现软件的定位和特点。
在飞速发展的电子产品中，界面设计工作一点点的被重视起来，做界面设计的“美工”也随之被称之为“UI设计师”或“UI工程师”，其实软件界面设计就像工业产品中的工业造型设计一样，是产品的重要卖点，一个产品拥有美观的界面会给人带来舒适的视觉享受，拉近人与商品的距离，是建立在科学性之上的艺术设计，那么，UI设计的规范标准有哪些呢？
一、轴
轴在UI设计中是最基本、最常见的概念，也是用来组织界面结构的重要核心。
简单说来，轴是在设计的时候组织一系列元素的假象线，在下面的设计图中，轴以虚线的方式被标注出来。
1、对齐
轴最常见于对称元素的使用，当元素被布置成轴对称的布局的时候，会给人有序感。就像生活中绝大多数的事情一样，我们更倾向于享受有序的的东西，它们令人感觉平稳、舒适、平易近人。
最简单的一个例子就是iTunes程序中的专辑列表的设计，所有的专辑列表在界面的左侧保持对齐，围绕虚线轴轴对称。
2、强化
虽然轴是一条假想的线，但是如果周围的元素的边缘控制得足够整齐，这跳线会在视觉中变得更加“明显”的。
最好的例子是城市中的路灯构成了道路两旁建筑物之间的轴，如果一边有建筑一边没有，那么这种轴线的感觉不会那么强烈。
从产品设计的角度上来看，Twitter的时间线设计就是一个很好的案例，左侧的头像和右侧的推文共同塑造出缝隙中轴线的感觉。
3、运动
当我们碰到某先线条的时候，视觉会很自然地沿着这些方向运动，就如同我们站在街上，会自觉地沿着街道的两头走动。两个端点决定了线，界定了开始和结束的地方，线或者说轴线的存在会引导和提示运动的方向。
SoundCloud中，音轨沿着一条既定的水平轴线运动，随着音乐的播放，音轨自然地自左向右匀速运动（具体可查看马海祥博客《如何利用动效设计吸引访客的注意力》的相关介绍）。
4、连续性
如果终点是不确定的，那么你通常会沿着轴线的方向浏览/运动，直到你找到感兴趣的东西，或者感到厌倦并关闭应用。
在建筑学中，未清楚界定的终点非常少见，因为建筑的修建通常没法永远持续下去，但是UI设计则不一样，无限地滚动下去是无比受欢迎的设计手法。
Pinterest的APP中就是这样做的，持续不断的图片沿着中轴线的方向持续不断地滚动下去，只要你有兴趣一直观看下去。
二、对称
当元素被均匀地放置在轴线的两侧之时，他们构成了对称的关系。当元素被精准地在轴线两侧一一对应之时，它们就形成了完美对称。
1、平衡
对称令整个设计更加平衡，当元素与控件在轴线两侧处于相同位置之时，会给人以协调和谐的设计感。
当我们在规划街道两侧的房屋建设的时候，如果左右两侧都是5间大小一致的房子，当你走在街上的时候这种平衡的设计会令人非常舒适，这是平衡给人的感受。
Rdio的APP设计就遵循着这样的设计规则，屏幕两侧的控件是相同的规格，这类布局很适宜阅读，用户会自觉地自上到下，从左向右查看。
2、不对称
如果轴线两侧的控件布置不再是一一对应尺寸相近，那就是不对称的设计，不对称的设计会给人明显的失衡感，可能会令人不舒服，但是也能造就残缺美，当然这要看你具体怎么做。
虽然Pinteret的APP设计在整体上是沿着中轴线对称的(宽度一致)，但是两边的界面控件并非是对称的，它们的高度并不一致，位置也是错落的，稍微一点的落差都会被眼睛捕捉到，而这样的差异让用户无法准确地左右顺序阅读，不对称设计打破了设计的平衡性和舒适性，但是也可以缓解了规律性设计带来的视觉疲劳。
三、层级
当某个元素出现在比其他元素更重要的位置的时候，层级就出现了。
1、尺寸
如果一个设计元素在尺寸上比其他的控件更大，就会区分出层级。毫无疑问，我们查看某个设计的时候，通常会被最大的元素吸引到。如果一个建筑物有5个出窗户，其中一个是其他四个的两倍大，我们的注意力自然而然会被吸引过去。
通过尺寸来区分文章列表层级的典型就是稍后读应用Pocket，顶部的轮播文章拥有更大的图片，它的位置和尺寸会令我们一眼注意到（具体可查看马海祥博客《详解移动端设备页面尺寸设计原理》的相关介绍）。
2、形状
如果一个控件在形状和形态上同其他的不一样，也可以让它独立出一个层级，不规则的设计同样会令人侧目，建筑物的正面拥有五个相同的窗户和一闪大门，你会立刻注意到门的独特之处。
在Instagram的个人信息页中，圆形的个人头像在方形的图片中别具一格，非常抓人眼球。它会让人意识到，这个独特的东西，更为重要。
3、位置
位置的存在同样能彰显层级的不一样，在圆圈之内，中心位置的东西比边缘部分的看起来更重要，位于轴线顶端的控件会显得比其他部分的优先级更高。
以设计应用Path的设计为例，时间轴顶点处的用户头像就明显比时间轴上的其他部分更重要，而这个地方正好展示的也是用户头像。
四、韵律
UI设计和建筑设计同样有着韵律之美，重复的模式会营造出独特的节奏之美。
1、模式
理解韵律最直接的方式就是听歌，音乐拥有节奏感，绝大多数的音乐遵循着相同的节拍，节拍就是音乐模式的一部分。
这方面最典型的APP是Airbnb，APP列表中每一间房子都占据一个模块，模块中有着大小相同的图片，价格、位置和房东信息和图片的相对位置一定，且排版匀称舒服，两个模块之间的间距也相同，当你浏览的时候，熟悉的节奏会让你清楚地知道上哪看关键信息。
2、间断
当节奏被间隔打断的时候，会形成不同的层级，听歌的时候，均匀的节奏被其他的音乐元素打断的时候，你会意识到这是比较特别的部分。
在Twitter的APP中，推文和推文保持着相同的样式，均匀的节奏，但是其中的“推荐用户”一项有着不同的样式，它插入到推文列表中，打破了整个信息流的节奏，凸显出不同的层级，会很快抓住你的注意力。
高质量的规范文档是一个优秀设计系统的代表物。我们详实地描述每个 UI 组件的设计与代码规范，来帮助设计师高效地作出决策，推动开发速度。编写高质量的文档需要前期规划和一系列合理的流程来辅助，付出的成本相当高。
这个系列由六篇文章组成，致力于描述编写组件规范文档的过程。本篇我会从目标读者、文档内容、文档结构开始。然后会涉及案例，设计与代码指南。这些内容来自于我自己这些年的实践经验以及社区里大家所分享的知识。
那么我以一个问题开始今天的主题：文档的目标读者是谁，他们需要什么样的内容，作为编写者我们该怎样组织文档结构来作出清晰的表达？
文档的目标读者
首先：你要弄清楚谁是你的文档的主要读者。
工程师，设计师，还有公司里的所有人！
当一个设计系统包含了代码指南，工程师们显然会是读者。那么一个只包含了代码指南的设计系统应该服务于设计师吗？如果文档里只包含了设计规范而没有代码（如 Material Design），工程师还是读者吗？
在我看来，两个问题的答案都是肯定的。规范文档是从不同的角度来服务于多种角色的。
除了设计与工程，它还服务于其他人吗？很有可能，特别是当文档所在的设计系统已经成为产品的基石时。简短有效的介绍对于 PM（产品经理） 很有价值，QA（测试） 则比较关注案例部分…等等。
规范文档是从不同的角度来服务于多种角色的
很多设计系统团队还会把自己的系统公开出来，在体现共享精神的同时也能起到吸引行业人才的作用。所以文档应该能够体现团队的专业与严谨。
文档的主要目标是：为设计师、工程师和团队里的其他角色服务，让他们能够高效地做决策。
Takeaway：设计系统的效应和影响力不只覆盖设计与工程，一个成长中的系统必将会服务于更多的角色。
工程师，接着是设计师，然后才是其他人
为所有角色服务并不意味着平等地服务所有角色。工程师每天会查阅 10 次或更多次文档，他们甚至会把文档与代码编辑器窗口并排排列！设计师的访问次数应该是少于工程师的，其他角色则会更少。
所以谁是最重要的？以我的经验来看，设计系统最初就是为了工程与设计之便，由工程师和设计师建立的。即使其他角色也对其有所贡献，但他们仍是偏次要的。因此我们首先需要确保工程师与设计师的需求能够得到满足。
设计师与工程师优先级最高
那么，工程师与设计师孰轻孰重呢？我最近参与设计的设计系统项目中都需要同时服务于两者，为设计和代码制作规范指南。我也在一些企业的文档中看到了对其中一方的过多偏见，或者是有将他们的目标完全分离开的倾向（稍后我会解释）。有很多维度需要考量：设计系统的目标，他们的使用频率，内容深度、质量、生产成本，以及和他们日常工作的相关度。
设计师 vs 工程师
Takeaway：读者的优先级由很多因素决定。要有预期：工程师和设计师的需求会有冲突，并尽可能地优化和处理这些冲突。如果实在不行，就要偏向于距离最终产品最近的那一方，通常是工程师。这就意味着工程师优先，设计师其次。
文档内容
规范文档是连接读者与内容的媒介。内容会有不同的格式或模块，因此成本也各有差异，而你需要最终把它们编织在一起。
文档内容模块：简介和案例文档内容模块：设计参考和代码参考
抽象地来看，规范文档的内容通常包含以下四种模块：
介绍：组件的名称，以及一段简明扼要的介绍。（必要）
案例：这个组件的各种形式，状态，尺寸等等其他要素，比较好的做法是用代码直接把这些展示出来，而不是不可以交互的静态图片。（必要）
设计参考：比如什么时候应该用这个组件，允许的做法与不允许的做法，以及视觉、交互、文案方面的指南。（推荐）
代码参考：包含 API 和其他实施及部署方面的指南。（必要）
不同的模块会有不同的制作成本
「介绍」写起来当然非常的短平快。结构优秀的「案例」也是值得投入成本的，并且写起来会越来越顺手。工程师也需要一个合理清晰的「代码参考」。但是，真正有效的「设计参考」可能会非常耗费成本。
横轴：细节的丰富程度由浅到深。纵轴：制作成本由低到高
请点击输入图片描述
Takeaway：规范文档可以包含很多内容模块。所以需要团队在前期就进行充分的讨论，对每种内容模块做出符合自己团队和产品价值的判断，再投入成本去制作。
文档的信息结构
设计与代码：分开还是合并？
在实践中，设计师往往会自顾自的发布或更新和自己相关的内容，工程师也一样。这样的惯性行为会在无意中增加设计与工程的距离。所以大家需要在前期就对文档的信息结构达成共识。
谷歌的 Material 文档生态就是这种距离感的代表。 Material’s design foundation 优先服务于设计实践, 而 Material Design Lite，Polymer Project，Android Developer’s，Material UI (built for React) 都是服务于代码，和设计规范绑定的并不紧密。
请点击输入图片描述
这种分离的状态其实是有意义和理由的。因为 Material 是一个操作系统的底层系统，跨越了许多框架，团队，平台。它的复杂度在某种意义上超越了目前世界上所有的设计系统。但你要知道大多数的设计系统并不是服务于一个操作系统的，因此不会发展至如此复杂的形态。
对于像我们一样的产品团队来说，设计和代码分开是符合共识的。这种做法能够给分别为两种角色设计符合他们需求的体验。
组件设计规范与 API 和代码规范分别放在两个网站上。来自：Atlassian
请点击输入图片描述
这种做法也有风险。随着时间推移，两个网站可能出现不同步的现象：
设计与代码的分类逻辑出现差异（最简单的例子就是 Loader 和 Spinner 的命名：代码里叫 Loader，而设计里则叫 Spinner）
功能差异：设计规范里出现了代码不能实现的功能，或者代码里加入了设计里没有考虑的功能。
你可能会觉得这样也挺好，毕竟设计和代码本身就是两个领域。至少对于文档的写作者来说这种分离还是挺方便的（只用考虑自己的需求，管理自己的进度）。
但真正的读者需要的是一个「真相的唯一来源（Single source of truth）」。如果你是一个对设计和代码都有需求的读者，你会发现自己不停在两个网站间切换，两个地方都有对你有价值的内容，这感觉就像是在打网球时陷入了拉锯战。
Takeaway：要慎重地看待设计与代码的分离。虽然一开始方便了内容作者和发布者，但之后会有风险。这种做法也可能会在潜移默化中造成设计与工程的距离扩大。
合并内容的两种方案：堆叠还是切换？
例如 Morningstar Design System 是把设计和代码放在一个页面里，读者就能找到完全统一的命名，指南，功能描述。
一个页面之堆叠式：把设计和代码放在一个页面中，纵向滚动来查看。
请点击输入图片描述
堆叠式的布局方式会使得页面变得冗长。当然还有一种方式是使用 Tab 来切换内容。
一个页面之切换时：把设计和代码放在一个页面中，通过 Tab 来切换内容。
请点击输入图片描述
Takeaway：将设计和代码混合在一起是有可能的，大家可以按自己的需求来选择以上两种布局方式。
按类型来为内容做排列和编组
不论选择那种布局方式，文档内容的模块结构和顺序应该是保持一致的：
简介
案例
设计参考
代码参考
其实只要把「案例」放到读者一进来就能看到的地方，把设计和代码参考放在一步点击就能达到的地方，就是一个不错的设计了。下面是几种行业内比较有代表性的模式：
左：IBM Carbon 模式 中：Hudl's Uniform System 模式 右：Lightning Design System 模式
请点击输入图片描述
IBM Carbon 认为代码更应该被优先展示，将交互用法和样式分别放在其他的 Tab 中。Hudl’s Uniform system 把顺序反了过来，设计优先于代码。 Salesforce’s Lightning Design System 把代码和组件案例放在 Tab 上方，默认选中开发者指南这个 Tab，而后两个 Tab 则被奇怪地留空了。
Takeaway：把简介和案例放在一开始最重要的位置，接下来的模块则没有唯一的方案，需要大家自己做出符合自己团队情况的判断。
若页面很长，则为读者提供定位导航
你的文档页面越长，越需要给读者清晰的认知，要让他们知道这个页面里会包含哪些内容以及当前所处的位置。纵向的定位导航栏是个不错的方案：一直固定存在于页面右侧，在滚动时同步追踪位置，并且可以包含子标题。
Morningstar Design System 在文档页面右侧设计了一个两级的定位导航栏
请点击输入图片描述
Takeaway：不论选择哪种形式，最重要的是在整个系统中保持逻辑一致，符合读者的预期与心理模型。
展示设计？展示代码？还是都展示？
把设计和代码融合，就会有读者只对其中一个方面感兴趣，他们会提出自己的意见：
设计负责人可能会问到：我能把这些代码案例和指南隐藏掉嘛？
工程师可能会问：我能把这些和设计规范有关的文字隐藏掉嘛？
可以考虑加一个选项或按钮来允许隐藏设计/代码内容。比如：
Design Only：把代码指南、代码片段和属性表等等都隐藏起来
Code Only：把视觉样式指南和文案指南都隐藏，但还是要把一部分交互用法指南保留着，这对工程师们也有用。
UI 设计师的职能大体包括三方面:一是图形设计，软件产品的产品“外形”设计。二是交互设计，主要在于设计软件的操作流程、树状结构、操作规范等。三是用户测试/研究，这里所谓的“测试”，其目标恰在于测试交互设计的合理性及图形设计的美观性，主要通过以目标用户问卷的形式衡量 UI 设计的合理性。
UI设计目前的前景还是很不错的，很多企业都缺少 UI设计师。而且可以看到的是，现在社会的发展，更多的智能机和智能机器人研发出现，这些都离不开UI 设计师。所以说 UI 设计的是很有前途的，是不会失业的。而且 UI 设计门槛不高，要入门也不难的。
从工作内容来说，UI 设计在当前的互联网领域、科技领域可以说无处不在，
好的 UI 设计能够明显提升用户的使用体验,从而给产品带来更多的附加值,所以UI 设计对于互联网产品是非常重要的。目前 UT 设计通常分为两个大的工作方向，一个是交互设计,另一个是视觉设计。
总的来说，UI 设计相比较于编程而言，还是非常适合大众学的并且就业前景很广阔。学完 UI 设计，能获得一份稳定而又不失乐趣的工作，同时有利于追求更高品质的生活，在艺术领域可以获得更多的启迪。
一、字体
iOS的字体：
中文字体：苹方 / PingFang SC
CSS：Font-Family：PingFang SC
英文、数字：Helvetial
Andioid的字体：
中文字体：思源黑体 / Noto Sans Han
英文、数字：Roboto
二、规范
1、 iPhone界面尺寸
2、 iPhone图标尺寸
3、 iPad的设计尺寸
4、 iPad的图标尺寸
5、 Andioid的图标尺寸
6、Andioid的dp/sp/px换算表
三：小结
iPhone的主流设计尺寸：750x1334 px
1242x2208 px
Andioid的主流设计尺寸：720x1280 px
1080x1920 px
