B 端设计也是 UI 设计的一种，它的输出环境只存在于电子屏幕中，所以统一使用 RGB 色彩显示模式即可。
RGB 即光的三原色，因为每个像素点是由 R 红色、G 绿色、B 蓝色三种颜色的不同色彩强度混合而成。所以 RGB 色的表示可以由 3 个颜色各自使用 0-255 中的数值来呈现，比如：
这是 RGB 色彩最标准的记录方式，但显然看起来特别的不直观，或者说不方便。所以在计算机中，为了方便记录和调用，使用了一串十六进制的代码来指代具体的 RGB 色。
理论上，我们只要使用 RGB 模式，随便你怎么选色，只要记录 16 进制码进行复用，你就可以在任何文件、设备中获得相同的色彩。
但在实际显示效果上，不同的系统、设备、浏览器都有自己的调色板，“解释” RGB 代码后给出的色彩就有偏差。比如一样的中文不同方言、语系、背景的人可能听出不同的意思，比如牛子，我以为它是类似“晴子”这样的姓名，至于你们的理解嘛……
相关行业为了避免这样的问题，提出了 WEB 安全色的概念，即这些色彩在不同的显示环境下，能实现最接近的色彩效果。
那么安全色都有哪些呢？网上有很多地方都有对应的色卡或者工具帮助我们选色。建议使用 Google 的 MD 色卡，这套色彩最全，使用范围也最广的颜色。
我们可以通过下面这个链接中的网页工具，帮助我们快速实现选色和复制色彩代码的操作。
网站链接：https://www.materialpalette.com/colors
当然，设计 B 端界面并不是只能使用安全配色，这只是一种建议，可以尽量确保主色，尤其是辅助色使用安全色，而中性色可以自由定义（下面会提）。
第 2 件事，自然就是讲讲该怎么配色了。和 C 端设计类似，我们主要的目标就是在项目设计过程中定义出 主色、辅助色、中性色 三种色彩类型，并把它们应用到合理的位置中去。
只是，针对 C 端来讲，B 端的配色更功能化，更理性，也更简单。我们要学习 B 端配色首先要排除那些花里胡哨的案例，比如下图这种。
过度花哨的颜色会干扰我们对界面的实用和对信息的识别、检索效率，除非是一些政绩工程用来当 “花瓶” 的数据大屏，否则我们首先要排除颜色过度应用的选项。
那么什么主色、辅助色、中性色，我们先简单做个说明。
主色，即你这套产品中的品牌色彩，是整套项目最核心，重要性最高的颜色。主色的选择通常和你的品牌相关联，比如腾讯云的蓝色，阿里云的橙色，七麦的绿色。
辅助色，则是用来在系统中进行强调、标识、区分的彩色系统。品牌或者 C 端设计可能会通过辅助色和主色搭配实现个性化的配色方案，但是在 B 端是没有这种诉求的。辅助色应用的目的性更强，是完全贴合操作效率来制定的。
比如下方是国外流行框架 StarBootstrap Admin 中使用的辅助色，它们都有对应的功能寓意场景。
中性色，则是这套系统中色彩使用的相关灰色，因为灰色是没有色相、冷暖的区别，所以我们也称它们为中性色。主要应用在文字、背景、分割线等基础元素中。
B 端的配色，即了解这三个色彩类型以后，能正确制定合理的颜色，并应用进项目中去。下面，我们分别对每个类别进行简单的讲解。
1. 主色的应用规则
B 端的主色也就是产品的品牌色，多数 B 端项目中，主色不需要 B 端设计师自己选，在项目开始前就会有相关的品牌色、LOGO，直接复制色号即可。
和 C 端配色最大的不同是，品牌色在这里很多时候只是 “吉祥物”，它的存在用来宣示品牌本身的存在，但并不是任何情况下都直接参与界面色彩的填充。
假设品牌色是紫色、荧光黄、暗棕色之类的，那么这类颜色本身的内涵、寓意是难以满足功能需求的，我们要尽可能减少它们的出现面积、频次。
在 B 端设计中，主色的应用是最不需要大面积填充的，即使它是常见、耐用的蓝色、橙色，主色的填充主要只应用在下面这些类型内容中：
2. 辅助色的应用规则
有了主色，我们就要为项目添加其它色彩了。
B 端彩色的搭配原则只有一个，那就是 —— 能省就省。我们不是设计一个让用户发出感叹的色彩丰富绚丽、细节众多的视觉平面，而是设计一个用来使用的软件系统。所以前面举例的那些花里胡哨的反面案例，就一定要在正式项目中敬而远之。
用专业术语来说，配色过程要遵守 “奥卡姆剃刀原则”，如无必要，勿增辅色。
而为了满足功能性需求，可以为 B 端项目添加的辅助色类型其实也非常的有限，按寓意划分常见的也就以下几种：
相信看到这里，你们脑海中已经有画面了。我们会为正确使用绿色、链接使用蓝色、警示使用红色等等。这些都是具有普世性的颜色，与用户的长期经验吻合，没有识别的成本。
而如果为了个性而个性，对辅助用色另辟蹊径，相当于在异国自驾时使用蓝灯行棕色停的系统，异国风情是有了，说翻车也就翻车了。
所以，针对 B 端辅助色的使用上，如果自己没有把握和经验，可以套用下方我们整理的 RGB 安全色，填充到页面对应的元素中去：
用谷歌色卡各选 3 个同类色出来，并进行标记
3. 中性色的应用规则
B 端的辅助色找起来不难，难的是中性色的使用和搭配上。
任何完整的 B 端的项目，同一个界面中都包含了多个模块、层级，以及数之不尽的文本字段。在这么多的内容中，我们要根据模块、文字的权重，选择合理的中性色填充。
新手很容易迷失在中性色的配色过程中，往往一套界面做完以后，使用的灰色或黑色透明度数量根本无法统计，非常的混乱。
所以，为了避免这样的情况，我会建议从开始设计之前就定一套中性色，并将它们添加到设计软件的色彩画板中，每次填充中性色的时候直接从这个色板中选择即可。
那么如何制定这套中性色？首先要理解在电子显示器中，人眼对偏冷的中性色是耐受的（舒适），所以专业的 B 端项目中，中性色都带有一定的冷色色相和饱和度，比如下图是 Element 中性色在拾色器区域的分布，就并不是全灰的。
所以加入冷色是有必要的，同时，我们用 HSB 色彩模式中的 B 值作为中性色灰度的主要量化标准，全黑时 B 值为 0，白色为 100，每个定义出来的灰度都可以用 B 值作为代号，如 B20、B40 等。
我们根据这个标准，定义出 5-8 级的中性色，就可以满足项目中的大多数场景。
虽然会有一些项目会使用透明度来制定灰度等级，比如黑色的 80%、40% 透明度，但我更建议将透明度使用场景和实际色值定义区分开来，只有在色彩的不同状态（选中/失效等）下再应用透明度。
有关 B 端配色的部分也就先说到这里，B 端配色远远比 C 端更简单，也更枯燥。可以使用的色彩范围更小，套路也更一致。我们要做的，就是将它们合理进行填充。
B 端设计也是 UI 设计的一种，它的输出环境只存在于电子屏幕中，所以统一使用 RGB 色彩显示模式即可。
RGB 即光的三原色，因为每个像素点是由 R 红色、G 绿色、B 蓝色三种颜色的不同色彩强度混合而成。所以 RGB 色的表示可以由 3 个颜色各自使用 0-255 中的数值来呈现，比如：
这是 RGB 色彩最标准的记录方式，但显然看起来特别的不直观，或者说不方便。所以在计算机中，为了方便记录和调用，使用了一串十六进制的代码来指代具体的 RGB 色。
理论上，我们只要使用 RGB 模式，随便你怎么选色，只要记录 16 进制码进行复用，你就可以在任何文件、设备中获得相同的色彩。
但在实际显示效果上，不同的系统、设备、浏览器都有自己的调色板，“解释” RGB 代码后给出的色彩就有偏差。比如一样的中文不同方言、语系、背景的人可能听出不同的意思，比如牛子，我以为它是类似“晴子”这样的姓名，至于你们的理解嘛……
相关行业为了避免这样的问题，提出了 WEB 安全色的概念，即这些色彩在不同的显示环境下，能实现最接近的色彩效果。
那么安全色都有哪些呢？网上有很多地方都有对应的色卡或者工具帮助我们选色。建议使用 Google 的 MD 色卡，这套色彩最全，使用范围也最广的颜色。
我们可以通过下面这个链接中的网页工具，帮助我们快速实现选色和复制色彩代码的操作。
网站链接：https://www.materialpalette.com/colors
当然，设计 B 端界面并不是只能使用安全配色，这只是一种建议，可以尽量确保主色，尤其是辅助色使用安全色，而中性色可以自由定义（下面会提）。
第 2 件事，自然就是讲讲该怎么配色了。和 C 端设计类似，我们主要的目标就是在项目设计过程中定义出 主色、辅助色、中性色 三种色彩类型，并把它们应用到合理的位置中去。
只是，针对 C 端来讲，B 端的配色更功能化，更理性，也更简单。我们要学习 B 端配色首先要排除那些花里胡哨的案例，比如下图这种。
过度花哨的颜色会干扰我们对界面的实用和对信息的识别、检索效率，除非是一些政绩工程用来当 “花瓶” 的数据大屏，否则我们首先要排除颜色过度应用的选项。
那么什么主色、辅助色、中性色，我们先简单做个说明。
主色，即你这套产品中的品牌色彩，是整套项目最核心，重要性最高的颜色。主色的选择通常和你的品牌相关联，比如腾讯云的蓝色，阿里云的橙色，七麦的绿色。
辅助色，则是用来在系统中进行强调、标识、区分的彩色系统。品牌或者 C 端设计可能会通过辅助色和主色搭配实现个性化的配色方案，但是在 B 端是没有这种诉求的。辅助色应用的目的性更强，是完全贴合操作效率来制定的。
比如下方是国外流行框架 StarBootstrap Admin 中使用的辅助色，它们都有对应的功能寓意场景。
中性色，则是这套系统中色彩使用的相关灰色，因为灰色是没有色相、冷暖的区别，所以我们也称它们为中性色。主要应用在文字、背景、分割线等基础元素中。
B 端的配色，即了解这三个色彩类型以后，能正确制定合理的颜色，并应用进项目中去。下面，我们分别对每个类别进行简单的讲解。
1. 主色的应用规则
B 端的主色也就是产品的品牌色，多数 B 端项目中，主色不需要 B 端设计师自己选，在项目开始前就会有相关的品牌色、LOGO，直接复制色号即可。
和 C 端配色最大的不同是，品牌色在这里很多时候只是 “吉祥物”，它的存在用来宣示品牌本身的存在，但并不是任何情况下都直接参与界面色彩的填充。
假设品牌色是紫色、荧光黄、暗棕色之类的，那么这类颜色本身的内涵、寓意是难以满足功能需求的，我们要尽可能减少它们的出现面积、频次。
在 B 端设计中，主色的应用是最不需要大面积填充的，即使它是常见、耐用的蓝色、橙色，主色的填充主要只应用在下面这些类型内容中：
2. 辅助色的应用规则
有了主色，我们就要为项目添加其它色彩了。
B 端彩色的搭配原则只有一个，那就是 —— 能省就省。我们不是设计一个让用户发出感叹的色彩丰富绚丽、细节众多的视觉平面，而是设计一个用来使用的软件系统。所以前面举例的那些花里胡哨的反面案例，就一定要在正式项目中敬而远之。
用专业术语来说，配色过程要遵守 “奥卡姆剃刀原则”，如无必要，勿增辅色。
而为了满足功能性需求，可以为 B 端项目添加的辅助色类型其实也非常的有限，按寓意划分常见的也就以下几种：
相信看到这里，你们脑海中已经有画面了。我们会为正确使用绿色、链接使用蓝色、警示使用红色等等。这些都是具有普世性的颜色，与用户的长期经验吻合，没有识别的成本。
而如果为了个性而个性，对辅助用色另辟蹊径，相当于在异国自驾时使用蓝灯行棕色停的系统，异国风情是有了，说翻车也就翻车了。
所以，针对 B 端辅助色的使用上，如果自己没有把握和经验，可以套用下方我们整理的 RGB 安全色，填充到页面对应的元素中去：
用谷歌色卡各选 3 个同类色出来，并进行标记
3. 中性色的应用规则
B 端的辅助色找起来不难，难的是中性色的使用和搭配上。
任何完整的 B 端的项目，同一个界面中都包含了多个模块、层级，以及数之不尽的文本字段。在这么多的内容中，我们要根据模块、文字的权重，选择合理的中性色填充。
新手很容易迷失在中性色的配色过程中，往往一套界面做完以后，使用的灰色或黑色透明度数量根本无法统计，非常的混乱。
所以，为了避免这样的情况，我会建议从开始设计之前就定一套中性色，并将它们添加到设计软件的色彩画板中，每次填充中性色的时候直接从这个色板中选择即可。
那么如何制定这套中性色？首先要理解在电子显示器中，人眼对偏冷的中性色是耐受的（舒适），所以专业的 B 端项目中，中性色都带有一定的冷色色相和饱和度，比如下图是 Element 中性色在拾色器区域的分布，就并不是全灰的。
所以加入冷色是有必要的，同时，我们用 HSB 色彩模式中的 B 值作为中性色灰度的主要量化标准，全黑时 B 值为 0，白色为 100，每个定义出来的灰度都可以用 B 值作为代号，如 B20、B40 等。
我们根据这个标准，定义出 5-8 级的中性色，就可以满足项目中的大多数场景。
虽然会有一些项目会使用透明度来制定灰度等级，比如黑色的 80%、40% 透明度，但我更建议将透明度使用场景和实际色值定义区分开来，只有在色彩的不同状态（选中/失效等）下再应用透明度。
有关 B 端配色的部分也就先说到这里，B 端配色远远比 C 端更简单，也更枯燥。可以使用的色彩范围更小，套路也更一致。我们要做的，就是将它们合理进行填充。
文章来源：站酷 作者：百度MEUX
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
大家是不是时常困惑于，B 端的表单设计体现不出高级感？设计发挥的空间特别的少？
那是你没用对发力点~
B 端：设计表单页面时，一方面须尊重用户的习惯，不要在不必要的地方体现差别。总结了 4 个思考问题：
案例：以创建公众号消息自动推送为例
另一方面要考虑信息层次。
搞定了基本要素后，我们开始考虑如何表现信息层次。
在了解什么封装度和信息密度前，我先跟大家讨论一下。什么是表单之间的关系。
我所认为表单之间的关系分为 3 种：
优点：
平铺所有需要填写的信息，适合内容项较少、内容项无法按照相关性分组的表单
缺点：
使用场景：
当需要完成一个简单快速的任务，输入少量信息即可完成创建
优点：
用于复杂任务时，拆解任务进行编排，适当的任务分割，可以降低用户出错率
缺点：
使用场景：
适用于大型、复杂任务
优点：
减少不必要（非重要）的输入项，能适当的减轻用户认知负担
缺点：
使用场景：
特殊场景下使用
那么用一条完整的链路来表达就是：
了解完表单的结构关系知晓利弊后，那么应用在我们实际的场景中表达就是如图所示：
封装密度高且信息密度低
△ 图中案例，仅做示例说明
将一个复杂的任务表单，进行封装后，看起来任务量是不是也变少了？操作起来也不是很复杂了？
小结：
分析了解表单的结构关系，判断表单，寻找共性的内容，将他们封装为一个卡片，也可以封装成一个组。主要的目的就是减少用户认知负担，提升操作/使用效率。
关于使用何种布局方式的判断，应从信息的复杂度和关联性两个维度去梳理。根据信息的复杂度和相关性模型，选用相应的信息呈现方式，选用合理的布局方案来承载详情页的内容。
1. 信息的复杂度和相关性模型
△ 来源：Ant Design；来源链接： https://ant.design/docs/spec/research-form-cn
2. 区隔方式
根据各个信息之间的相关性，判断各个信息模块之间的亲密度，通常情况下，相关性强的内容尽量靠近，相关性弱的的内容尽量拉开层次。
△ 来源：Ant Design；来源链接： https://ant.design/docs/spec/detail-page-cn
3. 注意事项
文章来源：优设网 作者：交互思维
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
在 C 端设计中，不管是给车载客户端、手机客户端、电脑客户端设计界面，都有比较具体的规范需要我们学习和遵守。
而唯独 B 端设计，或者说网页设计，我们在网上是找不到具体详细的规范资料的。因为无论是蚂蚁的 AntDesign 还是 Element、Clarity 等 B 端设计系统，其规范都只是针对自己这套产品的设计说明。
当我们不使用这些框架，要完成自定义设计，那么新人就完全不知道该怎么下手。所以，今天这篇内容，就是针对 B 端设计所需具备了解的基本规范进行说明。
帮助大家快速了解和掌握 B 端设计所需的规范知识。
B 端设计是 UI 类设计中的一个大类，它包含了非常多种面向企业、商业的客户端类型，包括电脑、手机、平板、大屏等等，针对不同客户端和系统，基础规范都有一定的差异。本文主要集中在 WEB 端的管理界面设计。
WEB 管理界面虽然看起来和一般的网页差别很大，但说到底，它也是网页的一种，它遵循网页设计的基本原则。我们对规范的解释以网页基础规范为框架展开，并会加入一部分 B 端特有的设计元素规范说明。
主要包含的规范内容包含下面这些模块：
规范的解释，会涉及到不少网页前端制作的知识点，建议立志在 B 端进行深耕的设计师，都要掌握 HTML + CSS 这些前端知识。
我们过去做过这个系列的详解，可以通过下方的链接查看：
还要声明一点，规范中总结的内容，包含 “规则” 和 “建议” 两种类型，规则指的是浏览器、代码等限制产生的硬性规范，而建议则是我根据自己经验整理出来便于大家理解的内容。
在自己的项目中，如果出现 “建议” 无法适应的情况，那么完全可以根据实际场景来做决策，不需要拘泥于我给出的数值和限制。
下面，就开始进入正题吧！
首先，我们来解析一下 B 端布局的规范，即界面排版应该遵守的基本原则。
在前端 HTML CSS 的知识中，需要定义不同 DIV（或其它标签）的长宽数值，并将这些大小不一的矩形进行排列、移动、嵌套，来实现界面的视觉样式。
换句话说，所有置入画面中的元素都包含一个矩形的外边框，无论是文字、图标、图片、按钮、标签还是符号。
所以，在界面的布局中，无论我们使用什么样的内容、字段，对于前端的页面来讲都只是无数矩形的排列过程。我称这种布局的设计思路为 “矩阵布局法”。
矩阵布局法是设计方式和前端开发方式的统一，提升开发阶段实现设计稿的效率和准确性，是每一个专业 B 端设计师都需要具备的素养。
在此基础上，我们还有几个统一的原则需要遵守：
1. 数值使用标准
在 UI 领域中，元素尺寸的定义不像平面设计大多以比例或“感觉”来制定，更多是使用手动输入数值的方法来完成。
主流的系统、规范都会建议我们通过网格化参考工具来辅助我们进行布局设计，比如 Android MD 系统使用的 8*8 网格系统（常用电脑分辨率可以完美支持）。
也就是说，在这个系统中，元素的外边框、间距，都是以 8 的倍数来设置的。这样无论我们在设计还是在开发过程中，对于使用的数值都会有相应的默契。
但是，以 8 的倍数为基准的设计，跨越的幅度有点太大了，比如一个图标，当你觉得 16px 小的时候，那下一档 24px 页可能太大了。所以，我的建议是对于相对比较复杂的项目来说，使用小一级的 4*4 网格来设计，会更兼顾灵活度和数值的统一性。
即设置元素的尺寸、间距的时候，我们都用 4 的倍数来完成，当你觉得元素的长或宽不合适，就对它进行 4px 的增减，比如下面的案例：
要警惕的是，4px 的基准，是针对元素视图边框的值，文字字号、图标栅格等次级内容，并不会受到该原则的影响。且该原则只是一个设计基准的 “建议”，而不是限制，在特殊场景中可以选择打破它。
2. 固定和响应尺寸
使用 4 的倍数完成设计，并不能解决 B 端设计中的所有尺寸问题。因为在 B 端的实际应用中，我们会加入响应式的逻辑，即页面元素尺寸随浏览器窗口的变动而变动。
所以，在设计 B 端界面元素的时候，我们要考虑两种场景，固定尺寸和响应尺寸。
固定尺寸即不管环境发生什么变化，它的大小是定死的。比如图标、标题、LOGO 等元素。而响应尺寸，则是一个 “未知数”，是需要一定的计算规则 “求得” 的。
比如还是搜索栏的案例，搜索框响应尺寸，而搜索按钮是固定尺寸，那么在不同的宽度下面，它们显示的效果如下：
要理解响应式尺寸对应规则，除了了解 CSS 中 Width:auto 属性值的使用外，最简单的就是搞清楚 UI 设计软件中的响应式布局功能。
元素是响应还是固定尺寸是我们在设计过程中就做后决定的，而不是等设计做完以后再看图说话。所以了解固定和响应尺寸的内容，在我们定义组件的过程中就要通过软件的响应式功能进行设置，并需要在后期的标注和文档中进行说明。
3. 常用的界面布局
最后，就是 B 端界面设计使用的主流布局形式了。虽然网页因为画布比手机大得多，设计的灵活性更高，但在 B 端中可以应用的布局形式也不多，只有固定的几种。因为 B 端页面布局中有几个常用需要预留的坑位：导航、标题栏、工具栏、内容区域。
主要使用左右或上下布局两个方向：
左右布局的形式，通常是左侧作为导航区域，顶部作为工具栏使用。这种做法通常是因为系统内模块较多，需要的导航数也多，用户需要经常切换到不同模块中去，所以左右分栏的布局可以很好的提升操作效率。
而上下布局中，则是面向一些处理场景、功能比较简单的平台，导航模块少，且切换的频率不高，主要的操作都集中在内容区域的设置上，没有边栏的影响还能提高操作的专注性和效率。
要使用哪种类型的布局，需要根据当前的项目功能做决定。但即使选择了其中一类，也并不代表我们的工作就结束了，还需要在这个布局的框架下做进一步的规划。
比如，我们需要制定内容区域多栏设计的比例划分、复杂表单填写系统中的内容引导栏、列表条目展开的侧边栏形式等等……
每套项目都需要先确定页面的布局框架，然后再开始针对具体页面、业务内容进行设计，保证整套系统操作方式的一致性。
文章来源：优设网 作者：超人的电话亭
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
随着项目的不断发展，设计团队在不断壮大，设计师之间的协作也越来越多，相应的沟通和协作成本在不断增加。如何才能更高效的合作，并把设计质量和一致性做的更好，是我们需要去解决的问题。
本文将以 QQ 动漫设计系统为例，分享一些过程中的思考和经验，抛砖引玉，希望对大家有所帮助。
在项目初期，团队设计师的协作方式是通过一个本地的 sketch 规范文件，以复制粘贴的方式来复用一些元素和控件。在设计师协作人数不多，UI 控件改动频繁的情况下，这套流程可以比较快速的完成需求。
但随着项目逐渐成熟，协作设计师人数变多、UI 控件逐渐趋于稳定且需要复用的地方逐渐变多时，之前流程的不足就逐渐凸显出来。
1. 更新通知缺乏自动化
文件更新难以做到及时有效的通知到所有设计师，且需要人工在群里发通知，告知大家更新了文件。有些设计师暂时可能没有相应的设计需求，可能会忽略更新后的文件，造成设计的不同步。或者等到需要的时候才去群里找更新的规范文件，版本容易搞错且费时费力。
2. 全局组件更新困难
由于组件样式是通过复制或修改的方式应用到界面设计中，当规范文件更新时，无法智能的自动更新修改相应的组件，需要设计师人工核对哪些地方有修改。这样很难保证大家的设计版本都能得到统一的更新，当大家使用的组件版本不一致时，输出的界面就会出现杂乱无章的情况。
3. 代码复用率低
开发没法全局调用代码样式，有些样式可能需要反复复制使用，耗时费力，并因此产生的代码臃肿，还会直接影响产品性能。
鉴于设计师目前多使用 sketch+xshow 的工作流程，而 xshow 正好也具备云端管理的能力，故决定以 xshow 作为桥梁，建立一个基于 sketch+xshow 的云端设计组件库，以非常低的迁移和学习成本完成流程优化。
优化后的流程是把 sketch 本地组件库通过 xshow 上传至云端服务器，设计师通过 xshow 云端功能添加到 sketch 中，并在设计文件中嵌入这些云端组件。
这样做能很好的解决上面说的问题：
1. 更新通知自动化
更新文件不用再靠人工在群里发通知，设计师也不需要去找文件，而是在 sketch 中会自动进行提醒。一旦有更新，会在右上角显示提醒消息，设计师只需要点击提醒，下载最新组件文件即可完成更新。
2. 全局组件一键更新
当更新组件库文件后，界面中所有之前使用过云端组件的控件元素都会自动比对更新前后的差异，方便设计师判断是否更新。这种更新最厉害的地方在于，更新是全局的，也就是一旦你确认了更新后的内容，所有界面都会自动按规范进行更新而无需设计师再逐个筛查。这样做既能保证设计稿的一致性，也能大幅提高设计效率。
3. 开发效率和质量大幅提升
开发通过代码把一些常用的样式进行封装，在一些高度复用的场景中直接调用。一方面可以通过调用的形式减少重复样式代码的复制，精简代码，降低软件包体积，另一方面也可以减少不必要的工作量还能方便后期维护。
想要高效解决问题，正确的方法很关键，这里我们用到的方法就是原子设计理论。2013 年前端工程师 Brad Forst 将此理论思想运用在界面设计中，形成一套设计系统，包含 5 个层次：原子、分子、组织、模板、页面，这套理论为组件库的搭建提供了思路和方法。
在实际搭建过程中，因为组件库的搭建工作量往往比较大，需要先明确流程和分工，主要包括以下几个关键步骤：
1. 明确工具流程
因为是搭建云端组件库，所以首先需要有一个云端工具进行管理。针对以 sketch 为基础的云端组件库来说，常用的工具流程包括 sketch cloud，各类云同步盘，第三方云数据库自主部署等等。我们选择的 sketch+xshow 工作流也是基于 xshow 具备云端管理功能，与其他流程本质上是一样的，大家根据项目实际情况合理选择就好。
2. 全面汇总并分类
按原子理论由小到大来对常规控件进行汇总并分类。对于 QQ 动漫项目来说，常见的控件类别包括：颜色、字体、图标、按钮、导航、状态栏、弹窗、列表、标签等等。每个项目所需要整理的组件不尽相同，原则就是对要复用的元素进行整理。
3. 制作样式模板
为了便于维护和提升合作效率，将组件库拆分为几个不同的独立文件，每一个文件由组件库搭建小组成员独立负责，减少混乱。
如果是有多位设计师参与时，因为组件库的元素存在相互调用的情况，会遇到到底谁先做的问题。解决流程分 2 步：
QQ 动漫组件库一共分了 5 个不同文件，分别是：基础、操作、导航、反馈和内容。
4. 搭建本地组件库
1️⃣ 确定命名逻辑
提升设计效率，是组件库存在的重要目标之一，而合理的组件命名起到了至关重要的作用。组件的名称要保证通用性，太独立的命名可能不够兼容其他场景，也会让使用的同学产生误解。
对于组件命名，要多与使用的设计师一起探讨，因为每个人的习惯都不同，方不方便因人而异，所以需要做一些平衡。
比如在做图标命名逻辑的时候，纠结于要先按尺寸分（图标/序号类别/尺寸/图标名），还是按功能分（图标 / 序号类别/尺寸/图标名/状态），不断调整多次，这时候就需要找大家一起探讨，怎么才是最方便的。
命名的方法是尽可能按共用属性由多到少的顺序来整理。比如，图标共用的尺寸属性多，就把尺寸归到上层；如果图标功能分类比较集中，那就把功能名称归到上层。根据实际项目和设计师使用情况的不同，会有不同的命名形式，命名确保效率就好。
在梳理组件库结构命名时，先用思维导图描绘一份结构化地图，方便前期讨论及调整。明确层级关系后，用在多人合作时进行参照，从而统一组件库层级。在做这份结构化地图时，需要列好全部分类、层级、具体名称及示例。
2️⃣ 颜色
颜色库的设计，需要将产品中可复用的颜色汇总并分组，比如品牌颜色，按钮颜色，图标颜色，装饰颜色等等，这样可以使得用到颜色属性的组件更加灵活。颜色的命名规范是：序号_功能/浅色 or 深色/序号 _ 属性 / 序号 _ 状态。例如，04 _ 按钮色/浅色/01 _ 常规按钮/04 _不可点
3️⃣ 字体
字体样式需要做全字重、颜色和左中右三种对齐方式，因为按目前 sketch 的组件逻辑，还不能修改嵌套字体的属性。这些属性可以对应到组件的命名上，字体组件的命名规范是：大小/序号对齐方式/属性/用途，例如 42px/1 居左/常规/主文本。
边做边检查。由于文字组件需要的命名特别多，很容易出错，所以建议是最好每做一组，就检查一遍。检查的时候打开组件样式，如果在组件预览中发现重复或者结构不对的地方，及时调整。
多行文本行高要注意。文字的行高要尤其注意，一定要在前期检查好尤其是多行文本的行高。如果行高前期设置不对的话，非常影响后面文本的扩展性，在用到多行文本时会遇到麻烦。想回头修改的话，因为是最底层的原子需要逐个调整，所以代价是巨大的。
所以一定要开始设置字体组件之前就确定好行高，比如 QQ 动漫组件库中的文字行高统一用文字大小的 1.5 倍，并取偶数作为文本的行高。当然，这里的行高也不是完全规定死，有时候也需要视情况而定。
文本的粗细。文字的粗细也是要在一开始的时候就要设置周全，最好是给所有字号的文字都设置好不同粗细的组件，尽管可能开始用不到，但会提升文字的扩展性，不然后面添加就会比较麻烦。
4️⃣ 图标
图标组件最关键的地方在于使用逻辑和图标规范。比如，我现在做的图标逻辑是：图标/类别/使用场景/具体名称/尺寸/不同状态，主要是按使用的频次来整理的。也可以有其他逻辑方式，以方便使用为准。
图标规范也会影响组件库的整理和日常使用，在做图标组件时，需要定义好图标的最大范围和最小范围，嵌套起来使用才不会出错。图标的规范要严谨，同一个尺寸下的图标视觉面积要保持一致。不然在大小这个层级就会出现，虽然是相同尺寸的图标切图范围，但图标的体量看起来却并不一致。
将纯色或渐变图标中的颜色剥离，并使用颜色组件进行嵌套，这样做既方便替换又能减少图标组件库的复杂度。
对于图标的多种状态，建议做在同一个层级中方便选择。
对于图标来说，直接对画板设置切片即可，不需要再加切片框。如果你的组件库之前用了很多切片来导出图标，可以用 Automate 插件直接清理或设置全局的切片，非常方便。
5️⃣ 控件
有了颜色、字体、图标这些基础元素后再来制作组件就会相对简单很多，只需要通过拼装把通用性强的组件做出来即可。这里可能需要注意设置好布局方式，让内容盒子随着内容的变化而变化。新版 sketch 的布局设置相对于老版本的确实会方便很多，理解起来很容易，所以这就不多讨论了。
6️⃣ 代码组件化
在开发侧进行前端 UI 组件库的封装，实现从设计到开发的样式统一，提升效率和质量。
在优先级上，代码组件化跟 UI 组件化可以同步进行，开发先写好框架，然后随着 UI 组件化的逐步确定，代码也进行相应补充。
5. 构建云端组件库
本地组件库构建完成后，即可通过 xshow 上传至云端，再由 xshow 直接添加到本地 sketch 中，完成整个使用流程的搭建。
6. 权限与维护
为了更好的维护云端组件库，避免更新混乱，需要成立组件库小组，只允许组件库小组成员有编辑权限。日常需求中，如有新增组件，需提交给组件库小组成员审核，通过后方可上传至云端组件库。
在制作组件文件的过程中，需遵循先自测后上传的原则，避免在上传后发现一些诸如命名错误、遗漏、嵌套混乱等问题，造成麻烦。
7. 编写规范文档
文档的作用是给相关同事查阅，形成标准化使用流程。一些在组件库中难体现的设计说明、未形成组件元素的使用规则或一些常见问题都可以写在文档里。
8. 问题与技巧
1️⃣善用插件，提高效率
我其实是一个非常喜欢“偷懒”的人，但凡需要重复，批量的工作，我都觉得应该有更聪明的办法。这里我推荐几个我在做组件库中经常用到的小插件。
2️⃣不断测试
组件库的设计过程中，一定要边做边测试，尤其是在前期确立逻辑的时候，要不断检测是否真的好用。
3️⃣内容更新权限与维护需要专人专办
举例：假设我负责字体，那么后续所有的字体更新相关都只找我来修改。若其他人在组件库内找不到相应的组件搭建页面而又特别高频使用，需要向组件库小组提出申请，并由对应组件库管理员进行更新，不可以私自修改组件库内容并上传。
组件化思维不仅仅应用在 UI 领域，甚至在各行各业都需要建立组件化，比如对于一些时效性非常强的新闻产品，就需要针对突发事件内容模板化，以期能第一时间发布；如果想追热点，组件化能够使得产品具备随时跟进热点的能力，提升市场竞争力等等。
组件化是一种思维模式，也是如今设计师必不可少的能力。通过组件库提升效率能够让设计和开发有更多的时间去打磨产品细节，从而打造出对用户更加友好的产品，赋能设计的价值。
文章来源：优设网 作者：腾讯ISUX
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
5分钟带你了解服务设计的原则、案例及常用方法！
我们常说，现在是体验至上的时代，用户对产品的使用不再是单纯的需求满足，更要获得满意的体验。服务设计的发展为我们改善用户的体验提供了新的思路，从本质出发，任何产品都是在提供某种服务，服务的质量从根本上决定了用户的体验。
什么是服务设计
服务设计一直在我们的生活中，我们无时无刻不在体验着各式各样的服务。荷兰一家专业的服务设计机构31 Volts是这样描述服务设计的：“如果有两家紧挨着的咖啡店，出售同样价格的咖啡时，服务设计是让你走进其中一家而不是另一家的原因。”这个描述很生动，同时也说明了服务设计的作用。
其实服务设计的定义还有很多，行业内不同的专家和学者都有自己的理解和解读，不管定义如何，重要的是服务设计的思维方式，可以帮助我们从全局改善服务体验。
服务设计的原则及案例说明
2010年在《This is Service Design Thinking》一书中，作者首次提出了5个服务设计基本原则，这些原则之后也被广泛使用，但随着服务设计的不断发展，其中的一些原则也需要重新去审视和思考，因此在2017年作者将其更新修订为6项。
a.以人为中心(Human-centered)
以人为中心的设计理念在产品设计、交互设计等领域已经得到了广泛的应用，服务设计当然也没有例外，以人为中心就是要站在用户的角度上看待和思考问题，考虑所有被服务影响的人。
在日本，农产品市场存在这样一个问题，农产品批发商无法及时从种植者处了解农产品的相关状况、收获量等信息，因此他们也就无法与要购买农产品的人进行谈判，这样造成的结果可能是粮食的浪费。日本的一家软件公司NJC（Nippon Jimuki Co. Ltd.）发现了这一问题，他们希望利用自身能力（软件方面的优势）去解决这一问题，因此将目标设定为：创建一个可以提供有用数据而又不给农民或农产品批发商带来负担的系统。
最终的产出的结果是Fudoloop这个应用程序，通过Fudoloop，批发商可以提前一天从农民那里收到信息，进而协调买家的各种要求。Fudoloop的使用者分为两种，一种是需要更新农产品信息的农民，一种是从Fudoloop上获取农产品信息的批发商，Fudoloop分别为两种用户进行了设计。
图片来源：Fudoloop
在设计Fudoloop时存在这样一个问题，农产品市场中的相关从业人员普遍年龄较大、受教育程度低、软件使用经验很少，面对这样的用户，显然通常的软件设计并不符合他们的需求，因此Fudoloop的界面设计非常简单且信息突出，从事农产品相关工作的人员可以轻松的使用Fudoloop完成农产品信息的更新，而不会因为学习产生很大的压力。Fudoloop还在大型农业贸易展览会邀请了一些行业内的人员和用户参与到了产品的体验中，并收集了他们反馈的建议，以改善产品。
图片来源：IDEO
NJC在设计Fudoloop时充分坚持了以人为中心的原则，考虑到服务涉及的不同用户，并根据用户本身的特点和需求进行设计。NJC的CMO佐藤贤一是这样评价Fudoloop的：“当简单、以人为本的思想汇聚在一起时，创新就会发生”。
b.协作(Collaborative)
这条原则说的是，不同背景和职能的利益相关者应该参与到服务设计流程中，收集多方诉求，发现不同看待问题的角度，才会更好的解决问题。
在美国旧金山，有一所学校和Revolution Foods这家餐饮公司合作，为学校内的人员提供丰富的、营养的午餐，但是实际来餐厅就餐的人数与预期相差很大，数据显示，有72%可以承担起午餐费用的人并没有来到食堂吃午餐。经过调查发现其中的原因，很多学生等校内人员并不愿意排长队或者匆忙的吃完午餐，因此他们选择了去校外享受午餐的时间。
为了改善这种情况，这所学校请来了全球顶尖的设计咨询公司IDEO，他们与1300多名学生、父母、营养人员、董事会专员、校长、老师和社区团体等利益相关者一起工作，重新去设计了学校的午餐，并且制定了针对三种年龄的就餐体验的建议，完成了饮食、就餐空间、新技术使用等多方面的优化和设计。
图片来源：IDEO
最终，学校完美的改善了午餐服务的体验，这其中包含了所有利益相关者的想法和工作，因此设计成果也被人们所接受，越来越多的校内人员会选择学校的午餐，之后，这种设计模式也被旧金山的许多学校采纳和推出。
所以，服务中涉及到的利益相关者有很多，多收集他们的想法与建议，甚至让他们参与到服务设计中去，问题会得到更好的解决。
c.迭代(Iterative)
迭代是一个不断接受反馈不断优化的过程，如此重复执行，让产品变得越来越好。服务设计也需要迭代，不要避免犯错误，而是从错误中学习和改变，同时也要不断的收集各方的反馈信息，这些信息是服务进行迭代的核心所在。随着互联网的发展，迭代的思维早已渗透到每一个互联网产品，此处就不再过多解释。
d.有序(Sequential)
服务设计应该是一系列相互关联的活动，并且是按照顺序进行的，精准的把控服务每一个环节的节奏，用户才能获得更愉悦的体验。
以外卖为例，用户的使用过程包含订外卖时的商家选择到下单过程，下单后配送外卖，用户收到外卖和用餐后这几个过程，而服务的提供者主要包括商家、平台和外卖小哥，为了保证用户能够获得流畅的服务体验，需要各个服务提供者在服务展开的不同环节推出优质的服务，如下图。
在订外卖时，平台会为用户推出“超值优惠”“限时秒杀”等优惠活动，商家推荐、订单历史等商家选择渠道，以及不同的筛选条件，以上的目的都在于帮助用户快速找到自己期望的、合适的商家。在用户选定商家后，进入到选择商品并下单的过程，一方面，商家会推出优惠的活动、推荐菜品等，另一方面，平台也会给出自己的优惠。
下单后，用户面临的是一个配送过程中的等待时间，为了缓解用户在等待过程中的焦虑情绪，平台会及时更新和推送外卖小哥的状态，如到达商家、取餐中、与用户的距离等，同时会给出用户预期的送达时间，若超过预期时间用户还可进行催单，商家可以联系用户表达歉意，整个过程用户对配送状态是可视的。
用户收到外卖时首先会与外卖小哥接触，包括与外卖小哥提前确定取餐的时间地点，取外卖时的短暂对话等，这些都会影响用户对服务的印象，因此外卖小哥需要保证服务态度的礼貌和友好。收到外卖后，食品包装首先给到了用户对商家的第一印象，然后是餐品是否符合用户预期，让用户满意。
在用户就餐后，首先平台要提供给用户评价的功能，用户可以分享自己就餐的感受，商家也可以通过平台为用户提供更多的优惠，引导用户能够再次回到商家订餐。
从外卖的案例中我们可以看到，服务是一个过程，是需要有序展开的，每一个环节的体验都会影响到用户对服务的印象，在恰当的环节提供恰当的优质服务，才能确保用户的整体体验。
e.真实(Real)
服务本质上是无形的，应该用“物理元素”来可视化，这样可以用户的服务记忆，增强用户对他们所接受服务的感知。
同样以上述外卖为例，商家为用户提供餐食，这部分是借助美团这个平台和外卖小哥来完成的，用户和商家的接触仅仅是送达的餐食，因此无法通过像到店体验一样，让用户感知到商家提供的更多服务。
为了让服务变得更加“有形化”，商家就需要花费更多的心思，如图，商家为了增强用户对服务的感知，一般会在在包装上花费很多功夫，精致的包装让商家的形象更好且更加值得信任，一些有趣的包装还可能让用户的心情变得愉悦。另外，商家也可以通过一张便利贴的温馨问候或者赠送小礼品等方式让用户更真实的感受到服务，通过这样的手段，即使用户并没有真的接触到商家，体验也会变得很好，商家的形象也会提升很多。
图片来源：古田路9号
f.整体(Holistic)
整体就是要着眼于整个用户旅程，考虑用户与服务的每个触点（触点的概念后文会进行介绍），并兼顾多方利益相关者的需求。也就是所谓的全方位服务体验，考虑服务环境的方方面面，没有任何遗漏。这个原则实施起来并不是那么简单，从整体角度思考问题会使问题变得复杂。不过在服务设计中，是有一些方法和工具是可以帮助我们完成整体思考的，比如服务蓝图。
服务设计的常用方法-服务蓝图
a.服务蓝图简介
服务蓝图是一张图表，通过列出在每个阶段发生的、不同角色执行的所有活动，显示了服务的整个过程。如图所示是一个服务蓝图的简单示例，垂直方向上展示服务中的利益相关者，水平方向上为用户的历程，也就是用户经历的不同阶段。在服务蓝图中有两条线，一条是可见线（line of visibility），可见线上方为用户可与之交互的服务，也可以称之为“前台”，可见线下方代表的是后台进程，用户无法看到但需要给用户提供支持，后台进程还可以存在内部交互线，用来表示内部人员的联系。用户与前台服务之间存在另外一条交互线（line of interaction），用来表示用户与服务之间的接触。
图片来源：Service Design Tools
明确了服务蓝图的大致框架之后，还需要注意服务蓝图中一个非常重要的概念——触点。触点就是在服务的各阶段，用户和产品、服务、后台产生的接触，每个触点也是服务可以进行展开和优化的方向。
b.Uber服务蓝图绘制
为了明确服务蓝图的绘制和分析过程，下面将结合下图所示的Uber服务蓝图进行说明。
图片来源：Medium
(1) 明确用户历程
用户使用Uber打车服务主要可以简单分为以下三个阶段：注册（下载APP - 新用户注册），乘车阶段（下单 - 等待车辆到达 - 乘车 - 到达目的地）、乘车后（付款 - 评价）。
(2) 明确利益相关者
用户与之产生互动的前台服务人员为司机，而设计师、开发人员、项目经理等负责后台的服务支持，以保证Uber按照预期的目标运作。
(3) 明确前后台活动
一方面，需要明确和用户接触的前台活动有哪些，Uber打车服务中和用户产生接触的主要为司机及车辆，因此需要确保司机是合格的、车辆内部的环境是干净舒适的，同时司机在与用户接触的过程中需要提供礼貌的问候和交流，满足用户在乘车过程中的要求，完成乘车费用的收取，提醒用户离开前带好随身物品，以及评价乘客等。
另一方面，用户对后台的流程可能并不了解，但需要明确哪些后台活动和支持会对用户产生影响。比如在用户下单时能够自动获取用户定位，告知用户预期的时间和价格，以及发送给用户司机的状态等。
在明确前后台活动时，我们可以以用户历程为线，分步骤进行分析，确保每个环节中涉及到的前后台活动没有被遗漏。
(4)明确关键触点
在服务蓝图中我们可以标注用户与服务的主要接触点，针对触点进行设计是提升服务体验的一个重要和有效的手段。
在Uber打车服务中还有一些需要注意的触点，一是等待时间，这包括用户发起乘车请求后、付款时以及评价司机时，等待时间是造成用户体验较差的一个原因，因此需要注意标注出这些触点，并想办法优化，在服务设计中需要注意相关环节的应尽量简单，减少用户的等待。另外需要注意的是会对体验影响较大的触点，如司机态度不友好、乘客下车时忘记带随身物品等，可能造成失败的服务体验的触点应该精心地去设计，避免这样的情况发生。
通过以上过程我们完成了Uber服务蓝图的绘制，从中可以获取到Uber打车服务的整体概貌及其相互关系。
///
结语
服务设计的思维能够帮助我们从全局的角度去审视和思考，发现更多改善服务的可能性，从而为用户提供更好的体验。因此对于产品和设计等相关人员来说，不能仅仅把目光放在产品本身，而是要从服务的角度去正确看待产品和用户的关系，以用户为中心，找到用户与产品的每一个接触点来进行服务设计，这样才能保证用户在整个流程中都能得到好的体验。
文章来源：站酷 作者：百度MEUX
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
先看目录！
1.什么是流量分发
2.为什么要做流量分发
3.首页中流量分发的类型
4.流量转化模型
5.流量如何分配的
6.设计案例与流量分发
7.如何衡量流量的效果
相信大家对流量并不陌生，我们在运营的口中经常会听到这个词：流量。运营通过各种手段和策略吸引用户来接触、使用我们的产品，从而吸引到了许多的流量，流量越多机会也就越多，比如一家奶茶店门店选址要考虑的最关键因素就是人流量。
流量分发的本质其实就是用户需求分发，我们设计师的价值就在于如何让这些流量发挥出更大的价值，让流量价值和用户价值相匹配。流量就像是一片海，海水通过不同的分支流入大陆形成了江、河，如果没有这些分支，那么这些水永远无法被利用，发挥出它们的价值。流量分发我们最常见的方式有：搜索分发、算法分发、社交分发、人工分发、付费分发
举一个比较典型的例子：海底捞在进行流量转化之前，并不是单纯的在店门口给用户一排座位让用户去等待，因为这部分用户就像没有被分流的海水是死的，这时候的用户其实也有自己的目标，就是消磨时间，那么海底捞就提供了一系列服务让这部分用户活动起来，比如给零食、玩具、做指甲等等，于是这部分用户其实就相当于进入了就餐流程的分支，提前享受服务和餐厅提供的福利，除了提升用户体验以外，也消化了大部分的流量。试想一下如果一下来了许多客户，但你只有十几张椅子让用户等待，势必造成更多的损失。
流量是无序混乱的，只有到它应该去的地方，它才会有价值。产品与用户双方都需要有清晰的目标，产品提供解决方案和导流不同的场景，用户负责完成目标给业务带来价值。
流量分发最典型的就是电商产品，因为业务目标非常明确，就是实现gmv的提升，但同时其用户的需求场景也是相对来说很复杂的。那么一个好的流量分发策略，可以大大的减少用户完成目标的时间和精力，也让产品可以准确的掌握用户的需求流向。
流量不分发或者错误分发就会造成更多的消耗，什么意思呢？我们举个例子，譬如下方的模坑app首页，首页中虽然提供了搜索、分类和标签栏不同模块，但是核心的内容显示区域则只有一张预售产品的大图。我们知道用户类型非常多，这样的布局对于小白和第一次用此款产品的小白来说会十分迷茫，因为最显眼的内容中并没有他们想要获取的信息。我们不求满足所有用户，但至少需要覆盖大部分用户和核心用户，此外，这样的形式就像一个漏斗，只靠一个出口漏水，效率自然不高。
同时为了达到最大化，流量的分发并不是单向的，而是并行、串联的。比如你可以在通过搜索找到某件商品，参与活动、运营板块、商品分类、网红直播等等区域都可以发现这个商品，同理，你想要购买视频app的会员，不仅仅可以去个人中心，你还可以去详情。所以流量就像一个大网格，单纯的给漏斗戳几个洞还不够，甚至要把这些洞用很多根管子串起来。
流量分发可以帮助盘活新业务以及寻找新的价值，例如我们之前的电商产品在前期是以时间轴为核心的消化方式，商品以单品列表平铺的形式展示，在产品发展过程中形态会发生变化，单纯以这样的形态承载用户需求肯定是不够的，所以更多运营板块和推荐可以分担这部分“旧”流量。
我们在移动端的首页可以常看见的类型有：搜索、宫格型板块、信息流、banner、fab等。
搜索给有明确需求的用户提供了入口，同时在搜索这个显性场景中我们也可以细化出更多的场景给流量提供更有效的支持
例如搜索场景下除了热门搜索、搜素历史以外还可以提供不同的分类内容推荐。
逐渐走下神坛的banner，曾经可是在UI界叱咤风云，在当时由于他是首页占比一哥，很多产品在首页规划中都认为banner会承载大部分的流量，尤其是像淘宝等电商产品，banner不仅仅可以靠图片吸引用户，在做一些大促活动时候还可以变成氛围担当，和导航栏上下呼应。我们说首页是寸土寸金的，但是大家发现没有，banner的流量和他本身的价值可能不相匹配。也就是说虽然他面积很大，但是用户点击率相比于其他板块并没有什么优势，甚至还低。所以淘宝目前的首页已经看不到banner了，这个区域可以放下更多的运营区块和流量入口，当需要它的时候再配置起来就可以了。
这个板块除了业务分类的“金刚区”以外还有运营活动的配置区域，我们先来说以业务划来划分的流量入口，以这样的形式来分配流量是常规的手段，当然他也是有利弊的，有利的地方在于几乎每个业务板块雨露均沾，至少是在同一屏幕中呈现，还可以左右滑动切换更多。弊端的话就是层级深，并且用户浏览效率低不聚焦，对于那些泛浏览型的用户并不友好，因为你进入一个业务板块后发现内容自己 不感兴趣需要就需要再返回。所以这样的分流更适合深度使用产品的用户
那有没有另外一种形式可以分配流量给不同业务板块呢？当然是有的，比如tab标签，有了tab标签，泛浏览的型的用户会更喜欢，他们能更快的找到自己喜欢的内容，比如bilibili、腾讯视频的首页，这个当然也和产品目标有关，他们希望让用户看到更多的内容，让产品更扁平化。
那么你即想扁平又想让用户直观的看到业务板块分类怎么办呢，你可以这么做，就像大众点评一样上边是宫格，下面是tab标签
Fab和cta可以说是比较另类的存在了，几乎就是你想让用户去点，那你就放，所以这样的入口流量路径就比较单一，无法沉淀和升级流量，是短期目标的形态。fab的这样的悬浮入口会一直在首页显示，通常产品为了吸引用户会将其设计的比较吸引人，比如添加动效等，但是fab也会干扰用户正常浏览界面，所以一般可以用透明、伸缩的方式解决，不过伸缩要考虑用户实际操作，避免频繁的伸缩造成的更多干扰。
大部分产品对于泛浏览用户的匹配场景都是提供信息流，但是单纯的给信息流依然无法让用户深入沉淀，所以需要在信息流中穿插一些分流入口，譬如品牌、话题、活动、排行等，让用户有更深入的浏览，这样才能促成转化。
流量获取很容易，但是我们的目标并不是让用户进来逛一圈就走，所以流量的转化我把他以这样的模型展示，也就是说流量从获取到沉淀再到最后的进化过程。
获取新流量的方式很多，例如社交分发、线下活动引流等等，内部流量也可以通过打通多个板块进行流量互换。但是这些流量是表面的，不做进一步整合也就没有实际价值，所以我们需要将其沉淀下来。
流量就像过江之鲫，如果你想让这条江里有更多鱼，你首先需要有个兜来留住这些用户，为了不让这些鱼继续游走，你可以给更多丰富的食物、创造更好的环境。如何让鱼更好的在这里生存呢，要让他们熟悉你的一切，要让这些鱼在其中发展、繁衍，所以当我们用内容吸引住用户后，要让用户留下来成为深度用户，这个前提就是让用户更长时间的使用产品，如何提升产品使用时长呢？譬如通过智能算法在很多断流的板块提供偏好推荐、帮助用户预判场景、社交互动、让用户有成就感、积分体系、个人成长系统、个人品牌塑造等。
之前两步依然是在存量市场里盘流量，这是对的，从十四五国家发展规划来看，我们能看到一个关键的变化，就是从“速度”到“质量”的变化，如果你的流量已经完成沉淀，那么可以不着急找增量，而是找进化的方法。当然以下是我个人的一些思考，仅供参考。从浅层到深入，从深入到高效，从高效到创造，所以当你的流量已经比较成熟的时候，可能更多需要让这些用户再创造新的内容，他们可以利用你提供的产品创造自己的玩法，即便你不提供任何的帮助也可以形成生态，甚至还可以帮你引入增量市场。
譬如玩社群的都知道，引流简单，但是要维持社群的热度和培养超级粉丝是很难的，但是一旦你做到了，那么这些人就是帮你创造更多的价值，所以你需要一个庞大且智能的基建，还有更好的服务。
判断流量分配是否合理的标准不在于多和广，而在于核心价值与目标是否达成。譬如内容型电商（抖音、快手）和传统型电商（淘宝、京东），内容型电商的流量是依靠内容带动电商去转化，更多的是依靠内容的质量，而传统型电商依靠的是商品，那么在这两个产品中，前者的流量更多还是要流向内容而非商品。
再举个例子，在首页的板块中，我们默认流量从大到小是板块越靠上的越多，越靠下的越少是吗？也不是，板块的分配是需要结合用户需求的，比如你规划的板块视觉上很明显但是从数据上看流量很低，那么这个板块就是有问题的，或者板块不明显但流量很高，这些都不是正常表现。
所以流量分发之前就要确定好，分发的目的和希望达成的目标。是能够让新用户更快了解产品，还是让成熟用户在使用时更高效，或者大力宣传新业务等等，不是一股脑儿随大流的把蛋糕切成几块。
不知道有没有在做抖音的小伙伴，抖音的流量分发让很多人搞不明白，其实抖音属于一个强运营平台，当用户制作一个视频发布后，他的流量并不是全部来自于已经关注你的粉丝，一部分是通过判断你的视频内容和质量分发给相应标签、可能会喜欢的用户。但是快手和抖音不同，快手的社交分发策略更重，用户发布的视频，已经关注的粉丝分发到的比例会更高，这样用户的互动也会更强。
通过一些设计案例我们来看看设计在流量分发中起到的作用。
流量与曝光是有关系的，为了争取更多的曝光我们可以采用这样的方式进行设计，通常我们可以看到横向滚动结束后进入下一级界面需要点击更多，但点击的成本就高于滑动，所以在这里可以让用户直接通过滑动进入下一级界面，增加曝光。同时滑动是承接上一步手势操作，很连贯，相比点击的效率也会越高。
我们经常在用产品的时候能看到同一个界面可以从多个不同的入口进来，比如像小鹿茶app点击下单跳转到商品列表，也可以直接点击底部第二个tab切换过来。比如你可以在夜宵板块和品牌板块都能找到kfc，让一个区域的流量不仅仅从单独的方向流入，这样可以满足更多用户的场景需求。像淘宝的商品流量来自多个不同的层级
还有我们可以将更深层级的业务板块提到上一层级，提高子业务板块的点击率和曝光，譬如贝壳在下方的tab板块中除了信息流内容外还嵌入了精选、人气、热门三个分类。还有类似像德邦app这样的工具型首页其实版面利用率太低，本身产品功能不多其实不需要划分出这么多板块，让每个板块流量这么分散，可以直接在首页中加入查单号的功能，并且将寄件收件历史平铺在首页。
淘宝商品详情中会有店铺和店铺推荐内容，方便用户查看更多偏好商品，提高客单价。具有电商属性的社交产品在用户图文中可以添加商品链接、标签、话题等等。还有淘宝在首页的feed流中点击商品会进入另一个feed流，这里的商品又进行了算法权重的加持，会更加准确与多样，由于本身处于逛场景的用户，在这一步再次帮助用户进行准确选择，可以提高转化，当然了，这样中心化的分流方式对于商家而言不太友好。
衡量流量分发的效果，我们可以查看板块的点击率（UV/PV）和预期。比如在某个周期中，有100个人进入这个界面，而这个界面中的banner最终点击量为1000次，那么这个banner的点击率为1000/100=10，平均每人点击了10次。点击率越高，该入口的流量自然更大。
每个产品对于活跃的标准不同，比如一个商场衡量活跃用户数会算那些进来蹭空调的大伯大妈吗？还是衡量那些有消费行为的顾客，同理一个产品计算活跃不是单纯看每天有多少人登录浏览就算活跃的。
那么观察活跃度有什么用呢？比如我们之前做一个大促活动，每个板块都有活动，但是大促结束后，只有童装类板块的日活流量在持续下降，于是我们通过相关调研，发现是因为童装类的品类太少，用户没有逛和再次购买的兴趣。
一波流量进入后，我们不仅要看他们去了哪里，还要查看这波流量在这里做了什么，于是我们通过查看页面停留时长可以判断一些问题，比如
1. 如果用户在本该停留时长长的页面反而停留时间短可能是当前内容不感兴趣、看不懂、闪退、临时有事等等
2.反之，在本该停留时间短但是用户停留时间长，说明可能文案排版或者解释的不清楚、用户可能在思考、临时有事等等
一波流量进入后，可能进入更深级界面也可能停留原地，那么还有一部分可能就直接离开了，查看流量的流失可以帮助我们判断以下问题
1.如果用户在进行某个多步骤任务，当我们发现其在即将完成时退出了，或者在中间步骤退出了，那说明可能出现了某些问题让用户进行不下去
2.用户可能对当前流程没有预期，也可能觉得有风险也可能是对某个地方产生不满
流量就像是一群被标记过的小白鼠，从哪里来到哪里去，中间做了什么，都被我们记录了下来，那么页面访问路径也是我们查看这些流量去向的关键指标，例如cctalk在冷启动后默认打开发现页面，我们进行了一些用户的调研，发现90%以上的同学在进入后都会切换到上课这个界面，这里可以思考的是作为产品我们发现用户有这样的行为，需不需要对产品进行优化，产品这样的设计是否考虑到的是新用户和培养用户习惯让更多课程有曝光。其实这里可以做一些判断，如果用户近期有购课、上课的记录和行为，默认打开上课板块。若新用户或者长期没有上课行为的用户则默认打开发现界面。这样就可以起到更精准的分流。
8.总结
流量诚可贵，流失就白费。
今天分享就到这里，你学废了吗？
文章来源：站酷 作者：应骏
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
设计是沟通，是人和人、人和物之间，通过某些形式传递和反馈信息的过程。
设计时刻都在为产品或商业提供有价值的帮助，例如产品转化率的提升、品牌好感度的提升、还有商业变现等等；与此同时 创新性的设计，很可能会带来数据上的质变，体验上的颠覆，甚至是改变某个领域的发展方向。
-
设计的本质，是对人性视角的转化。
通过洞察用户在产品使用过程中的痛点，提出全新体验的可能性，实现体验和业务的平衡；
设计不是产品可视化，它是全局的，是通过用户视角对设计机会点的洞察。
-
设计包括，但不仅仅是形式。
形式是设计的外层映射，设计本身是广义的；设计形式是设计理念的承载，是设计满足用户需求、实现商业目标和呈现品牌调性的具象化结果。
-
设计的价值在于创新，探索出解决问题的更多可能性。
设计是通过创新思维，对问题本质的探寻和对常规框架的突破，为体验和业务赋能。
-
设计是价值导向的，需要为业务负责，为行业负责；好的设计，需要能比常规方案产生更多价值，驱动业务和行业发展；设计不是单独的原型图或者视觉稿，而是一个全局性的创新型解决方案。
我们在做的设计，是大设计。
文章来源：站酷 作者：乐信用户体验设计
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
QQ 购物号是专门为 QQ 用户定制的购物平台，2020 年随着疫情过后，整体电商行业开始恢复阶段，QQ 购物号计划了今年双 11 大促季活动，活动的业务目标是希望强化特殊样式设计来促进购买转化，驱动整体大盘消耗与效果提升。为此如何通过设计赋能业务，从而突破增长的瓶颈呢？
购物号是属于 QQ 的订阅号服务，整体的曝光位置并没有很好，而且这次大促设计的落脚点只通过外层的样式和推送页面的广告内容进行展示。
以及要如何去满足不同电商广告主的投放诉求，和不同素材规格的投放适配，这都是需要去考虑和解决的问题。
1. 通过品牌关键词定义视觉情绪版
QQ 购物号用户群主要还是 00 后为主，这些年轻群体的购物趋势变化非常快，审美要求也越来越高！
所以前期思考了大量的关键分别为：活力/期待/年轻/狂欢/心动/发现/热爱，最后确定以活力/热爱为这次大促季的品牌关键词
2. 不同时期变化
随着大促运营节奏的慢慢展开，视觉侧也需要考虑到相应的视觉变化去引导用户的感官，避免用户审美疲劳。
尝试前期的预热阶段通过特殊视觉吸睛，第一眼先抓住用户的眼球，进入狂欢阶段，则可以利用动效加持来进一步吸引用户。
1. 让容器层面提升专属感
通过多方案从常规到异形多结构卡片探索，这里为了避免品牌标识压在广告素材上会有遮挡问题，同时又要突出品牌标识。
所以前期预热期选用卡片 F 更能强化品牌感，可以让用户更有代入感，当到了狂欢期选用卡片 G，通过扩大视觉着色区域，提升品牌专属内容曝光优先级，增加用户吸引力。
2. 利用情感化氛围与用户沟通
从前期的分析得出 QQ 购物的用户群是非常年轻的 00 后，所以整体视觉上需要运用更具年轻和活力的情感化氛围。
通过品牌字体上使用现代硬朗风格，巧妙的融入气泡元素，提升大促氛围，在传播上结合 QQ 购物的品牌符号。
包括品牌头像以及卡片的氛围图形也采用气球泡泡，彰显活力感。整体保持一致的视觉体验。
对于整体色系上延续 QQ 购物的品牌基调，轻渐变暖红色更能营造年轻、购物、活力的调性，让用户更有情感上的共鸣。
3. 通过动效不断激发用户的行动力
整体的动效节奏通过吸引-激发-共鸣-行动四重奏来进行，让用户更深刻去感知大促狂欢期的感知。
比如在外层入口上通过动态头像来吸引用户注意力，当用户进入 QQ 购物号后，利用带有大促品牌的礼包彩蛋来制造惊喜感，吸引用户抢礼包。
再通过卡片若隐若现的动态图形去烘托氛围感达到用户共鸣，以及行动按钮的微动效触发用户行动。
4. 高效适配于不同规格广告位
QQ 购物支持投放多种广告位，因此定下整体视觉风格后，快速对不同规格广告位进行适配复用。
广告主提供不同素材规格均可适配投放，降低广告主成本，也让用户达到视觉的统一体验
经过这次官方活动大促的主视觉风格塑造，我们沉淀下来整套视觉框架结构。
通过制定设计规范可以让广告主自定义皮肤模版，以及分不同行业模版，比如拼多多五周年的定制模版以及在寒假期间推出的 K12 教育行业模版。
不仅降低广告主制作成本，也通过更吸睛的皮肤模版提升促进购买转化，驱动整体大盘消耗与效果提升！
本次活动的数据指标目标达成，整体的增长环比 19 年的双 11 和今年的 618 均有了较大幅度的提升！
在设计策略与运营策略配合优化下，11.01-11.11 的广告主整体预算消耗超出 4 千万，完成预期超出 16%，也提升用户的转化率。
回顾整个双 11 大促活动，我最大的感悟是要有全局观！
前期基于对产品目标的了解，从更高的角度去理清产品思路定下设计策略，结合个人设计手法不断的打磨细节。当然整个过程会碰撞出很多思考和纠结，需要不断的实践、验证。
随着广告主对品效要求越来越高，未来电商的广告形式也开始随着精细化运营的方向发展，这些变化可能对商业化设计师来说，或许是一种挑战和机遇
文章来源：优设网 作者：土拨鼠
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
工作中我们常常会听到或在撰写交互说明时提到“从底部向上出现弹层”、“出现浮层”、展示“对话框”、弹出“弹框”、“出现对话框”诸如此类的话术。我相信大家对“浮层、弹层、弹框、对话框……”等称呼常常也会感到困惑。到底什么时候应该称呼为“对话框，什么时候称呼弹框”，此类相似的组件又是如何分类的，应该如何应用、如何设计。
恰好笔者近期在设计弹出层组件，本篇文章将结合自己的实战经历，自己对弹出层组件的理解和设计经验分享给大家，希望帮助大家对弹出层组件有更清晰的认知和理解。
首先我们看一下弹出层组件的定义：当触发某项操作时，在页面上方展示的弹出层容器，容器内可展示文本、按钮、列表、标签、表单项等内容，英文名称定义为 Popup。
△ 弹出层组件的构成
根据弹出位置的不同，我们又可以将 Popup 组件细分为如下 5 种样式。
△弹出层组件的 5 种样式
看到弹出层组件的样式，想必大家已经联想到日常用的比较多的组件了，比如“Alert 确认框，picker 选择器、基于场景的筛选组件”等。弹出层组件是十分基础的组件，基于该组件我们可以开发通用性组件以及场景组件。从“形式”角度来看，“浮层、弹层、弹框、对话框……”本质上都是弹出层。
“浮层、弹层、弹框”是泛指的称呼，两大官方平台也都根据自身的规范对相关组件进行命名。Material Design 和 iOS 官方规范中的弹出层组件如下图所示，并且笔者从“功能”角度出发整理了组件之间的对应关系。后文会详述每种组件的定义及应用。
△MD 和 iOS 规范中的弹出层组件
在详述组件之前，还需要向大家传达一个概念“模态”，即平时我们常说的“模态弹框”（弹框可理解为是弹出层的一种样式）。并非有一种组件的分类被称作是“模态弹框”，而是当弹框采用了“模态”的设计手法时，我们将其简称为“模态弹窗”。
iOS 官方定义为：
“Modality is a design technique that presents content in a temporary mode that’s separate from the user’s previous current context and requires an explicit action to exit. Presenting content modally can:
Help people focus on a self-contained task or set of closely related options
Ensure that people receive and, if necessary, act on critical information”
翻译过来即：模态是一种设计手法，它使用一种临时性的模式将用户之前看到的内容与当前看到的内容进行区分，并且需要通过明确的操作才能退出该模式。模态呈现的内容可以：
帮助用户专注于一个独立的任务或一组紧密相关的选项，确保用户收到关键信息，并在必要时采取行动
由此可见，弹层是否为模态弹层可以根据具体的使用场景进行定义。在 iOS 官方中定义的模态弹层通常包括：Alerts, Activity Views ,Share sheets, and Action Sheets .iOS 13 及后续的系统中将 Fullsreen 也作为模态弹层进行使用。MD 中的 Dialogs 组件均为模态，而 sheets 组件不采用模态设计手法。
警示型弹框均采用从页面中间进行弹层的方式，MD 和 iOS 中组件的样式略有不同，但其使用场景和功能相同。都是在重要信息提示、需要用户确认的操作、以及破坏性操作之前进行提示，警示型弹窗会中断用户的任务流程，影响用户体验，因此需注意其使用频率。
△警示型弹框 Alert Dialog
使用场景：通常在系统级信息的提示，例如权限的获取、系统通知，需要明确告知用户的信息，以及破坏性操作前使用。
△警示型弹框应用
根据用户在弹层中需要完成的任务内容和任务数量，又可分为简单型和复杂型弹层。
简单型弹层
常用于在弹层中展示内容，需要用户进行选择的场景，该场景通常只需要用户完成一种任务，比如通过点击的方式，完成信息的选择或分享。在 iOS 中采用从底部向上弹层的方式，而安卓平台多使用在页面中间弹层的方式。
弹层中是否存在操作按钮可根据实际应用场景去确定。通常选择项条目较少或内容简单易于识别时，可不需要「确认」按钮。而在选择项条目较多时或需要用户作短暂的思考才能确认选项时，可增加「确认」按钮，允许用户有修改选项的机会。
△简单型任务弹层的组件样式
△简单型任务弹层的组件样式
弹层中信息的呈现方式又可分为“列表”和“网格”两种，大多种场景下，均可使用列表展示内容，更加符合用户从上到下的阅读习惯；而在分享场景下多通过网格的方式将分享渠道展示出来，增加屏显的内容，同时提高用户查看信息的效率，具体样式可参考上图。
使用场景：简单型弹层多用在信息的筛选、排序和信息确认的场景下使用。且在目前市面上的绝大多数应用中，除原生的安卓应用外，大部分应用都采用从底部向上弹层和从顶部向下弹层的方式。
△简单型任务弹层的应用
复杂型弹层
复杂型弹层中通常承载的信息量更丰富，包含多种组件，需要用户完成一系列的任务。
涉及到信息筛选时，通常采用侧边弹层组件进行展示，且弹层上的信息仅支持垂直滚动查看，不支持水平滚动查看，且通常采用“非模态”的手法，方便用户快速取消当前弹层。在 iOS 中并无“Sheets:side”组件，但是在 iOS 系统中，很多 APP 应用在复杂的筛选场景下也都采用侧边弹层的方式。
全屏弹层会将当前页面中的全部信息遮挡，更方便用户聚焦于当前需要完成的任务，避免用户的注意力被分散。通常采用模态的设计手法，仅当用户触发确认、取消或关闭操作时，弹层才会消失。一般全屏弹层中需要包含标题、操作按钮、内容区域。用户在全屏弹层中需要完成多个任务，因此内容区域中也会包含多个组件。例如“按钮、输入框、标签、开关、列表、日期选择”等。
△复杂型任务弹层的组件样式
使用场景：通常用于完成复杂任务的表单信息填写、内容筛选、搜索和内容展示。
△复杂型任务弹层的应用
需要单独说明气泡框组件
在 iOS 的官方定义中，气泡框组件应用于 iPad 应用程序，在 iPhone 应用程序中，通过以全屏模态视图而非弹出框形式显示信息，来利用所有可用的屏幕空间。但是，组件被定义后并不是一成不变的，而是随实际场景进行应用的。例如，在手机端，气泡框组件更多被用于简单信息的展示与选择。
△Popovers 气泡框的应用
小结：
笔者按照使用场景、信息的复杂度、功能的相似度等，将弹出层组件归纳为两大类“警示型和任务型”，并且枚举了常用的 MD（安卓系统遵循的规范）和 iOS 两大规范中定义的弹出层组件，方便读者对弹出层组件有更清晰的了解。需要说明的是，由于业务场景是复杂的、多样的，各位设计师也需要结合实际的业务场景和设计目标，灵活的使用组件。
△弹出层组件的类型与使用场景
1. 设计目的
首先需要理解我们为什么要设计组件，组件最终设计的目标是什么，笔者从“设计侧和技术侧”两方面谈谈自己的理解。
设计侧：规范的组件设计，对内有利于全公司的设计师对组件的使用有统一的认知，明确组件的使用场景，避免误用和错用组件，并且方便新人设计师快速学习和上手，提高设计效率。对外也有利于保证设计上线后的一致性和规范性，方便用户对本公司产品建立统一的心理认知。
技术侧：通用的基础组件，具有可复用性，能够减少重复开发，大大提高开发效率。
组件设计的最终目标可归纳为保持设计的统一性，提升用户体验，同时提高设计和开发的效率。因此，组件设计是非常有必要的，那么到底如何从 0-1 开始设计组件呢，下面我们来看组件设计的详细思路。
2. 设计思路
其实组件设计的基本思路是通用的，不仅适用于弹出层组件，还适用于其他基础组件的设计。通常我们会从组件的定义、用法、构成、种类、行为与状态五个方面进行组件的设计。
△组件设计的思路
回归到本文所讲的移动端弹出层组件，组件设计时需要考虑其“通用性和可复用性”。基于此原则，将弹出层组件进行拆解，如下图所示。它包括：
△弹出层组件的拆解
从上图中可看出，本文第一部分提出的 Popup 组件是最基本的弹出层组件，基于该组件可进行任何弹层组件的开发。因此，在弹层组件设计时将 Popup 组件抽离出来作为最基础的组件进行开发， 还可以进一步开发通用的弹层组件和高频使用的场景组件。由于上文中已讲 Popoup 组件的构成与样式，且由于该组件相对来讲比较简单，因此不过多赘述。下面以通用组件“Picker 选择器”和筛选场景下的高频组件“筛选器 Filter”为例进行说明。
1. Picker 选择器
定义：用于从一组预设数据中进行选择的控件。
用法：
构成：标题、按钮、内容（当前选项和其他选项）
△Picker 选择器组件的构成
种类：根据选项间是否存在级联关系可将其分为 2 类，普通选择和级联选择。
△Picker 选择器组件的分类
行为与状态：状态，给出单列选项和多列选项的常态页面以及选项被禁用的状态页面。行为，需要定义完整的组件交互逻辑，从入口->弹层出现->选项查看->选择目标选项->弹层消失的完整逻辑进行说明。
△Picker 选择器组件的状态
△Picker 选择器组件的交互流程与行为说明
当完成以上全部内容的撰写时，可对本组件开发出的效果进行说明。例如：
2. Filter 筛选器
Filter 组件是基于公司移动端产品均存在的高频“筛选”场景而总结的场景（业务）组件，其设计思路和上方描述的通用组件的设计思路相同，笔者此处只强调 2 个重点注意事项。
场景组件在设计时遵循“加法”逻辑，从而提升组件的复用率。组件内容分区块进行封装，从而增加组件的灵活性。
△筛选器组件
在上图所示的筛选场景中，单类目和多类目筛选若均为高频的使用场景，那么单类目和多类目筛选组件均可以抽离成组件并进行开发，且多类目筛选可基于单类目筛选组件进行开发。但是多类目筛选组件是无法覆盖单类目筛选组件的，组件开发不同于设计稿，设计稿可将多个类目删除掉只剩余单个类目，但是组件的代码逻辑不遵循此删除逻辑。在原有组件的代码上修改的开发成本要高于重新开发组件。因此，如果要修改多类目筛选组件的逻辑，不如重新开发出单类目筛选的组件。这也是需要我们牢记的，组件设计需要从“原子组件到复杂组件”，遵循由“简单到复杂”的加法逻辑。
而在组件开发时通过“goup”的形式进行封装，可使组件更加灵活。例如，当业务场景是需要通过“输入框”组件输入筛选条件，只要将 Group 中的内容改为“输入框组件”，即只需修改该 group 下的代码即可，筛选器组件的其他逻辑仍然可复用，这就提高了组件的通用性和复用率。
当然，Filter 组件还需要考虑很多设计细节，例如类目名称是否显示为当前筛选项名称、重置的逻辑是什么、确认筛选后页面信息会如何变化、筛选项支持单选还是多选等等。复杂的场景组件通常是由多个原子组件组合而成，因此组件的逻辑也更为复杂，组件设计的整体流程和交互细节也应考虑的更加全面。
文章来源：优设网 作者：土拨鼠
蓝蓝设计( www.lanlanwork.com )是一家专注而深入的界面设计公司，为期望卓越的国内外企业提供卓越的UI界面设计、BS界面设计 、 cs界面设计 、 ipad界面设计 、 包装设计 、 图标定制 、 用户体验 、交互设计、 网站建设 、平面设计服务
蓝蓝设计的小编 http://www.lanlanwork.com