b端网站设计（b端产品设计首页）
本文目录一览：
关于B端系统的产品设计
过去的一年，负责的业务主要聚焦于平台运营，随着业务模式的成熟，也负责建设了许多营销系统。
本文将以此前实际设计的案例与大家分享 关于B端 系统的产品设计。
关于系统，个人认为是将 无序、散乱的业务抽象成中心化、标准化的有序服务。 而中台则在系统之上再上升一层，将 系统的共性抽象成通用服务。
而中心化和标准化的动机又是什么呢？较高频的动机有三条：
1） 业务模式足够成熟
2） 高频需求重复占用资源，且不具备复用性。
3） 旧有系统耦合性强，延展性弱。
在企业的早期阶段，一些非高频的共性需求并没有可依赖的中台系统。为了迅速上线及满足业务的需求，大多会将其耦合于该系统之中。
但当其他系统有相同需求时无法复用，需要额外开发相同的逻辑。不仅重复消耗资源，后续的迭代难度也会不断提升。
通过需求分析所确定的产品定位，能够明确系统要解决的 核心问题 是什么。而梳理业务流程，则作用在 问题解决的深度。
理解业务流程目的是梳理系统架构，从而划分系统的边界。边界清晰能够让系统各司其职，专注于自身的功能，并尽量提供可复用的能力。
以抽奖系统为例，输出其系统架构：
对于抽奖系统而言，它应该专注于抽奖的规则，如：抽奖次数来源、中奖概率、限中次数等等。
对于抽出的奖品是什么，奖品怎么发放，应该由奖品管理、奖品发放系统去消化；而奖品发放所触发的触达则应该交由触达系统。
什么时候应该将非核心需求抽象成中台系统，什么时候又应该耦合呢？个人认为应从其需求频次、强度以及投入产出比考虑。
在梳理了新系统与现有系统的耦合关系后，下一步则是确认中心化的对象，中心化的方式不同，其核心逻辑、功能框架也会不同。
以奖品管理系统为例，其中心化的方案可以有两种，如下图所示：
方案1以奖品作为中心，一个奖品将能够被多个业务方所使用。因其层级较少，产品、技术设计会更为简单，后续业务方的操作也更为轻便；
而方案2以奖品池作为中心，每个奖池的奖品相互独立，虽然方案更为复杂，但优势是其数据相互独立，更有利于成本核算以及风控。
当中心化的方案确定，系统的的核心逻辑及数据模型也就初见雏形了。
梳理功能框架相信大家都非常熟悉，本小节主要描述最小单元。 最小单元，指无法继续拆解的功能，其通用性的强弱也决定着系统的延展性 。
以下将以前端配置化系统为例和朋友们分享，以下的示例分别是最基础设计方式，以及有赞和笔者的设计方式：
1）固定组件、固定配置
第一种做法，是最基础的做法。它的思路是对固定的组件进行固定的配置。
以抽奖活动为例：
上图的两种抽奖玩法对应着两种前端样式，左侧是九宫格，右侧是老虎机。这两种样式对应着头图、抽奖模块、我的奖品及活动规则四个组件。
根据它们组件的共性，我们能抽象的最小单元是页面头图、页面底色、活动规则、抽奖按钮的颜色、文字等内容。
由于共性不足，它们的最小单元已经无法延伸。当后续增加新的模板“大转盘”时，我们就需要再次抽象并迭代，这种设计方案是非常不灵活的，而且最小单元很可能会再次减少。
最小单元共性越少，延展性越差，后续开发的工作量越多。
从九宫格的“我的奖品”、老虎机的“活动规则”来看，它们属于各自的私有属性，原则上而言我们也能够设计成配置项，但从投入产出比、延展性来看显得不太划算。
2）有赞：多种组件、独立配置
有赞的设计思路也是比较常见的设计思路，它的每个组件拥有独立的配置项。
上图分别是有赞中拼团、砍价组件对应的配置项，在图片的红框部分是商品模块的配置，同样是自动获取商品类型，拼团组件的配置项比砍价多了一个排序规则。
这种设计方式的优点是该组件能够很轻易的适配业务方的需求，灵活性能够达到最高。缺点则是组件的特性没有办法复用，某个商品模块或按钮的特性是无法复用到其他组件的商品模块或组件之中。
结合了上述的两种设计思路，根据实际业务方的诉求，笔者设计的思路为：多种组件、共用配置。
3）多种组件、共用配置
这种方式的设计思路是： 组件由模板与元素组成，模板决定元素的位置，元素负责视觉及交互的配置。
元素指的是： 文字、图片、线条 ，它们是本系统的最小单元。
其拆解示例如下图：
商品组件由图片、文字元素及按钮组件组成，而按钮组件由线条元素及文字元素组成。
关于元素的拆解思路如下图：
通过这样的解构，元素的交叉组合能够形成不同样式的组件。
当业务方有新的特性需求，只需要迭代元素的属性， 一次迭代所有的组件都能够使用这个特性， 即避免重复开发也保证了其复用性。产品、研发及测试的工作量的也大大减少。
除了视觉配置，另一部分则是交互的配置，其拆解如下：
最小单元在实际的设计过程中，还应权衡投入产出比， 不应为了解构而解构。
数据统计，有两点建议：定义清晰、数据独立。后者与系统架构有关，由于系统之间的相互依赖，会有关联的数据需要查询。
个人的经验是让系统尽量只消化系统本身的数据，对于关联的数据可以查询数据源让核心系统做整合，最粗糙的设计方式则是直接跳转至关联的系统查询。
1）角色与权限设计
根据组织架构以及权责范围，系统的使用角色所对应的权限也不同，常见的权限有增、删、改、查以及审批流。
2）版本计划
版本的计划。可以是对完整系统的分版本上线，也可以是对业务的预估推测系统后续需要延展的功能，这会非常影响系统的技术设计方案。
3）交互设计及文档撰写
随着业务认知的提升、技能的熟练，产品设计的能力可能会达到瓶颈 。 近期的想法是，面向价值设置需求优先级，不仅是企业、业务，还有支撑部门和自己。
以前喜欢做有难度的需求，但难度却不代表价值，我想好的产品设计一定能 帮助业务方带来可视、可观的数据成果。
给多方创造价值，才能够自上而下的推动跨部门协作，持续获得资源以及成长。
B 端到底用什么尺寸进行设计？来看我的实战总结！
什么是栅格？我这里就不做说明了。很多优设的文章都写的很清晰了。这篇文章仅从我最开始接触栅格所遇到的困惑和部分设计师始终纠结的点来和大家一起讨论讨论。
B 端到底用什么尺寸进行设计？
确定布局
要弄清楚用什么尺寸设计，首先要确定布局。我们常用的就是上下布局、左右布局、“T”字布局。其他布局基本上是这三者的延伸和拓展。上下布局一般是固定顶部，有点类似于 PC 网页设计，实际上也差不多。现在的B端设计中很多都会搭配着这种布局用，比如帮助中心、消息通知，客户入网申请等（这些我都遇见并做过）。左右布局和“T”字布局，一般固定左侧，右侧区域做自适应。
根据布局确定明确设计尺寸范围
我们看一下百度统计最新出来的当前计算机分辨率数据，从统计的数据中可以看出，小尺寸的屏幕是越来越少了。但是不是我们就要用最小的尺寸或者用份额最大的 1920 进行设计了？
显然不是按照这个维度来确定尺寸的。对网页设计来说，设计师差不多都知道有一个 1200 有效内容区域的说法。如果没有特殊要求，上下布局也是遵循这个原则的。设计师中绝大部分，包括我很多同事平时基本上用的 1920 和 1440 两种尺寸来进行设计。对于 B 端来说，不管你采用 1920 或者 1440，在做上下布局页面定宽设计的时候，遵循 1200 有效内容区域这个原则就是没有问题的，看了很多文章上面举例了 960、990、1024、1156 等等，大家都不用纠结，没有特殊要求，这些都没啥问题。
上下布局在 B 端设计中是一个补充，有的可能有，有的可能没有，所以用 1920 还是 1440 最好还是根据左右布局来，保持统一。两年前我看过一篇大厂写的布局的文章，用的是 1280 的尺寸，记得是说因为考虑缩小浏览器会发生遮挡或者挤压（别问我为啥还记得，因为当时对于尺寸纠结的太厉害，至今难以忘怀），现在因为技术等方面的发展，个人认为再用 1280 的做已经不合适了。1440 的尺寸目前做中后台是比较通用的，大家也可以参考看一下蚂蚁 Ant Design。至于 1920 的用来设计 B 端行不行呢？我认为也是可以的，我就用过，也没用户反馈说显示有问题，我就当他没问题了。不过我还是建议大家在做 B端设计的时候用 1440 的来做，特别是用户群很复杂的情况下，方便低分辨率的电脑查看。当然如果我们给某一企业做定制服务，那就没尺寸的问题了，照着客户电脑尺寸来就行了。
如何来进行栅格布局？
现在有很多插件可以进行布局，软件一般也有自带布局功能。这里不做陈述：
我一贯主张不要为工具所累，所以在各种诱人的 Sketch 插件面前，我总是提前思考下自己的真正需求，这款软件是将我奴役，还是为我所用？
这里介绍我常用的 sketch 布局。
这里我也创建了一个 1440 的网格系统，供大家参考，大家也可以根据自己的实际情况去建立自己的网格。
顶部高度没有特殊要求建议不要超过 100px，我一般就是 60-80px 内设定的；左侧可以根据目录内容自己设定一下，一般 200 多就差不多了。边距我一般设定 20px、24px。这样再对剩下的距离做栅格就行了，列宽保持偶数即可。
有时候做栅格的时候会遇到一部分列宽是 42px，一部分列宽是 43px，这种设定也是可以的，回归到栅格系统的意义，栅格本质上不是为了保证像素级精确，而是为了保证浏览视觉级别的秩序、协调与统一，所以大家没有必要纠结。
“没有绝对正确的栅格设计，只有最适合的栅格设计”，希望这篇文章可以帮助对栅格有疑惑的设计师们，同时也期待大家留言，大家一起学习探讨。
B端设计与C端设计的区别
首先我们要明确什么是B端，什么是C端
C 全称是 Customer 即消费者（泛指用户）的产品 ，个人用户或终端用户，使用的是客户端。例如：微信、网易新闻、网易云音乐、有道翻译官、网易考拉等等。
B 全称是 Business 即商家（泛指企业）的产品 ，通常是企业或商家，为工作或商业目的而使用的系统型软件、工具或平台。例如：京东云、阿里云、网易云、网易有数或企业内部的ERP系统等等。
明确了概念之后，接下来要了解他们的异同
（1）都要给人使用
（2）都要兼顾用户体验和业务之间的平衡：好用效率。但对于功能比较复杂的B端产品而言，想要做好用户体验不太容易，但不是不重要。
（3）都要坚守做产品设计的核心思想：在什么场景下为怎样的用户（客户）采取什么方法解决哪些问题
（1）目标用户
C端：个人用户，服务于每个脱离【企业】场景之外的人，也就是生活场景。
B端：企业用户，这个【企业】可以是一个组织、商家、团队。产品是给某类角色使用（项目总监、项目经理、项目顾问）。
（2）使用场景
C端：使用场景碎片化，存在于生活的各种场景之下，且自由度非常高。
B端：办公时间，讲究严谨的流程设计、贴近现实的场景面积、低风险、高效率、数据精确。
（3）业务和本质
C端：
通常只有一个核心功能，多个辅助功能，核心功能影响着产品的特色、定位、调性，而合理的辅助功能则会让产品保值增值、增强产品与产品之间的差异化。如果去除这些附加功能，产品的体验会受到一定的影响，但实际上并不会阻碍用户使用核心功能。eg. 去除了评论功能，用户依旧可以听音乐、去除了打赏功能，也不影响用户阅读文章和作者写文章。
C端产品其实是满足自我情绪，特性可以归纳为【分享】，[打赏]、[评论]都是基于【分享】的场景下，满足双方的情绪设定。
盈利方式：内容付费、广告付费、平台抽成、增值服务（VIP，卡券，权限等）
B端：
共同完成一个目标：日常使用产品工作的人，自己是无法独立完成一个任务的，他需要和周围的人协同完成一个任务流程的闭环
B 端产品的业务逻辑是复杂和多变的，尤其是权限系统，往往每个人都是流程中一个非常小的部分，就如上段所说，需要进行协作使用。也就是说，从功能架构上看，这些核心功能都是扁平的，他们分配到各种使用角色的手中，没有先后排名。
本质：满足用户的工作需要
盈利方式：按功能模块付费、按使用人数付费、需求付费、后期维护费用
（4）产品需求
C端：更多满足使用者的日常生活需求，所以需求来源会多样化一些。C 端产品就是站在上帝的视角，需求直接来源于用户的行为和反馈，从用户这里获取最真实的诉求。
B端：基于已有的「业务」形态，把传统线下工作，通过程序化、系统化、信息化转换为线上行为，使业务的流转效率更高，办公成本更低。需求一般来源于产品战略定位、各部门对接、租户（客户、外部付费者）的个性需求
（5）产品思维
C端：流量思维。做 C 端产品设计，我们一切行为的出发点，都是流量，流量直接影响着变现
B端：效率思维。如何提升企业的运营效率（既工作效率），解决的是「开源节流」中的节流部分。
（6）设计原则
C端：
要点：
a. 明确核心功能是给哪些目标用户使用的
b. 保持产品的场景多样化，突出核心功能：如何让产品的品牌设计辐射到更多的地方，如何在功能和体验上寻找新的亮点
c. 保持良好运营手段：C 端的用户是自由的（忠诚度低，随时可以换产品使用），所以需要通过一些运营手段来绑定用户的留存。
具体而言：
a. 把握关键时机：第一时间让用户知道产品是干什么的？能从中得到什么？亮点内容在哪里？是如何引导我使用的？所谓的「关键」时机反映在注意力理论下，对应的就是注意的「中心点」，反之为「分散点」。
A.中心点：「上次看到这里，点击刷新」的提示消息出现在此位置和时机是有讲究的：由于它们出现 在旧消息之前，新刷新的消息之后，用户的阅读注意力正在从新的信息流转到旧的信息流，中间会出现注意力断层的中心点。所以在此出现的提示更容易被用户察觉，提示内容才能发挥更大的价值，因此用 A 方案最合适。
B.分散点：消息提示在用户刷新之后出现在底部，虽然该方式在 toast 的层级里，干扰性是最低的，因为他的位置在底部，会适当减少用户浏览内容时所产生的干扰，但是从用户行为路径上看，显然不合适，用户的行为是要翻阅信息流，而它的出现方式与「翻阅」的行为是相违背的，反观还是会阻碍用户的浏览，虽然它的感知程度很强，能让用户第一眼发现这个贴心的功能，但是出现的时机不对，这就影响了用户体验。
b. 增加趣味性：「能引发用户的正面情绪，比如使人感到愉悦、有意思，能感染人、打动人、教育人，这是能够引起用户注意力的重要因素」
c. 增加创意性：推送提醒、各种红点提示、弹窗提示、嵌入广告、分享刺激、打赏刺激等。
B端：
a. 合理的功能与模块划分：在做产品信息架构时，就需要仔细考虑功能、模块的划分，客户常用功能模块有哪些，模块与模块之间的关系是怎样的
b. 严谨的业务流程设计
c. 一致性的操作体验：保持交互和视觉的一致性，让用户在使用时，能感到熟悉、亲切，能直观的了解到操作会带来怎样的结果。
d. 干净简洁的界面设计：B 端产品是为了工作而生，界面里往往都是「内容为王」，不易使用过于强烈的色彩对比，也不需要过于浮夸的设计，整体产品调性都应该尽量简洁，不要让视觉效果喧宾夺主，而应该减少干扰用户的「多余设计」
做B端产品的原则： 功能为主的设计原则、视觉服务于功能的产品素养。
参考资料：
C 端到 B 端的设计之路（上）
企业级/B端设计交互/界面规范(一) 简介
1. 前言
目前常用的前端框架为 Angular与Vue，个人觉得长久累积下来Angular 对于日后变化与动态表现会比Vue来的更佳，Vue虽然对于前端工程师较为方便好上手，但对于设计师维护两种设计规范是不大现实的，设计师只需要依据公司内部使用的前端框架维护一套设计规范即可。
接着开始介绍一下我长年使用的规范，一开始也是针对 Vue 设计，基本的设计规范可参考 Element 饿了吗即可。设计师一开始应该如何设计"设计规范 ( Design Guidline )"呢? 我对于规范当中的设计理论大多也是参考饿了吗为主，在参照其他公司的设计规范，依据自身公司内部的需求提取所需要的部分，先搜集完后在提炼，并且在日后维护继续修正调整。
2. 设计规范的目的
设计规范(Design Guideline)通常负责的为 UED 部门，国外一般也称"设计语言Design Language"，目的在于减少企业内部设计师重复劳动，并且提高设计师工作效率，帮助设计师能有更多的时间着重在思考、构思业务身上，在一定的基础上，设计师只需按照规范执行，透过设计规范公司的产品也能有一致性，包含交互行为、界面风格，最理想的状况下是衍生出自身的企业品牌，并且深刻于用户心中。所以设计规范不仅是一套规矩，肩负某种程度上公司能宣传的优势之一，尤其对于 B 端企业来说，一套能完全符合业务场景的设计规范，是经过不断的打磨与修正调整，能够扮演着教育客户角色，当然能够是服务于业务场景才是称得上好的设计规范。
3. 设计规范应用理论
原子理论 (Atomic theory) 为整套设计规范应用的基础理论，主要是由小的元素一步步堆叠成的最终页面等级的模板，透过长期的积累，不仅能从 交互视觉达成一致性 ，慢慢演化成模板、页面甚至是整个操作流程，这样设计师就能 高效地运用常见或者制式的流程 ，从而帮助设计师能有更多时间考虑交互上的细节，另一方面也能帮助设计师们 协作一个软件或多个软件时，能有统一的规范参考 ，背后隐藏的深意是透过不断的累积，进而形成互联网公司独有的产品特色或产品交互流程；当然以上是非常理想的状况下能够达成的目标，实现这些目标的基础也是端看设计师与前端工程师必须对规范有很深入的了解与熟悉，才能达到一致性、清晰、高效的理想境界。以下是原子理论的一些解说与图示：
原子（Atoms）：符号，为页面构成的最小基本元素。如颜色、字体，或是图标等；
分子（Molecules）：组件，由原子构成的简单 UI 组件。例如文字按钮，结合文字、按钮与图像，形成一个独立的分子；
组织（Organisms）：模块，由原子及分子组成的相对复杂的组织，在页面中可视为模块/样式层级；
模板（Templates）：原型，将以上的元素进行排版，显示设计的底层结构，在设计中对应的是原型图层级；
页面（Pages），将实际内容（图片、文章等）套件在特定模板，页面是模板的具体实例。
4. 设计目录
1. 规范简介
2. 规范原则
3. 设计视觉
4. 组建规范
5. 设计模式
6. 附录：规范文案
参考链接：
饿了吗
Angular (左下方有各大厂应用组件)
Angular for Material Design
Uber
Apple
SAP
B端网页设计规范
感谢作者 : Arche阿北
后台产品设计规范
以下数值为参考，请结合特定产品灵活运用。
1. 页面布局
统一尺寸
据统计，目前 PC 端用户屏幕分辨率占比排名前三的是 1920*1080、1366*768、1440*900，以 1440 来设计的话，向上适配或者向下适配误差会比较小。
适配方案：面向多个客户，后台产品设计功能型页面的尺寸统一为 1440*900，按照栅格系统原则向上或向下适配。展示型页面以 1440*900 为主，同时设计出极端情况（宽度为 1280 以及宽度为 1920）的效果图，力求实现前端实现效果和高保真设计图误差最小。面向公司内部的后台系统，由于各个职工电脑屏幕是统一采购、统一尺寸，所以开发适配的分辨率可以统一尺寸进行设计，这个尺寸根据公司内部采购屏幕的尺寸和分辨率选择即可（提前和前端沟通好）。
页面框架
页面框架主要分为左右栏布局和上下栏布局，还有其他的布局。左右栏布局包括顶部栏、左侧菜单栏、主体内容三大区域，其中顶部菜单栏、左侧菜单栏为固定结构，右侧主体内容根据分辨率进行动态缩放；上下栏布局包括顶部菜单栏和主体内容两大区域，其中顶部菜单栏为固定结构，主体内容进行动态缩放且需定义主体内容左右两边空白区域最小值；左右栏布局时，左侧菜单可收缩展开，收缩状态下固定宽度。
栅格布局
栅格系统的使用是为了解决自适应和响应式问题，从而更好地进行产品设计和产品开发。响应式栅格采用 24 列栅格系统实现，以满足 2，3，4，5，6 分比布局等多种情况。固定宽度 Column，将间隔 Gutter 进行动态缩放。
需要栅格化处理的内容的总宽度=23列（1列=1宽度Column+1间隔Gutter）+1宽度Column=24宽度Column+23间隔Gutter。
谷歌规定模块和结构之间要以 8px 为基准，布局间相对间距可采用 8px 以及 8 的倍数，但一些小组件（按钮、间隔、输入框）可以以 4 为基准。栅格布局是为了辅助设计，灵活运用，不要被它所局限。
尺寸设定
一般在整体区域左上角放置产品 LOGO 及产品名称，大部分系统顶部栏高度 48+8n，侧边栏宽度 200+8n。我常用的是顶部栏高度 56px，侧边栏宽度 200px，侧边栏收缩状态宽度 56px，右侧的侧浮窗宽度 400px。
相对间隔
定义主体内容的上下左右边距，定义主体区域内各模块的边距及安全宽度，超出内容区域的部分采用区域内滚动或整屏滚动，视情况固定导航栏。
2. 标准色
颜色分为品牌色、辅助色、中性色。根据不同产品的不同需求，可能也会将统计图、标签等进行统一标准色设定。
品牌色即产品主色，产品主色的设定直接影响产品气质和直观感受，也是产品直接对外的形象。品牌色要根据产品特性、用户使用场景、产品定位等进行选取，尽量做好色彩的延伸性，可支持换肤。品牌色的应用场景包括操作状态、按钮色、可操作图标等。
辅助色用于提示其他场景，比如成功、失败、警告、无效等。
中性色常用于文本、背景、边框、分割线等，需要考虑深色背景和浅色背景的差异，可以选择同一色相控制透明度变化，用来表现不同的层级结构。
其他色如统计图、数据可视化、多个标签的不同配色方案根据项目情况单独设定。
3. 标准字
后台系统常用的字体：windows 系统，中文 Microsoft YaHei，英文 Arial；Mac 字体，中文 PingFang SC，英文 Helvetica；除此之外可以选择的字体还有 segoe UI、思源黑体、Hiragino Sans GB等。
后台系统中常用字体大小为 12px、13px、14px、16px、18px、20px、24px、30px。
行高设定，根据文字大小及使用场景设置行高，一般行高=文字大小+6px/8px。
4. 图标
图标是 UI 设计中重要组成部分，一般分为功能图标和应用图标，以图形的方式传达概念，可以降低理解成本，使得界面更加协调美观。在后台产品中，图标的功能则更偏向辅助性，辅助用户对功能的认识。
除了某些常用的图标，有一些专业性的操作和词汇则需要设计师进行绘制，现在比较高效方便的方法是在 iconfont 提供的图标模板上用 AI 绘制，画板 1024*1024，提供圆形、正方形、矩形形状。图标尺寸按照 8 的倍数进行延展，绘制完成后生成 svg 格式文件，提交到阿里巴巴矢量图标库的项目组里，方便前端调用，调整大小和颜色更为方便，且能够优化系统内存和性能。
5. 按钮
按钮是后台产品进行交互设计是重要元素，提供给用户进行点击操作，是视觉上最引人注目的控件，具有一定的视觉受范性。常用按钮可分为填充按钮、线性按钮、文字按钮。
按钮的交互状态包括默认、悬停、点击和不可用。
按钮根据需求分为不同尺寸，大中小三个级别用在不同的场景，一般按照 8 的倍数设定。如高度分别设定为 24、32、40px。
规范整理时要规定不同类型按钮的宽高、圆角及文字大小，同时还要将按钮的不同状态展现出来。
填充按钮之间间距最小为 10px。
6. 导航
导航的类型有很多种，常用的比如顶栏菜单、侧栏菜单、折叠菜单、下拉菜单、面包屑、分页、步骤条、时间轴、tab标签页、胶囊菜单、徽标数等。
各类导航中的字体大小可进行统一设定。
顶栏菜单多为一级菜单，点击切换，或作为下拉菜单的父级，将子级菜单合理分类。
侧栏菜单为垂直导航菜单，可以内嵌子菜单。
下拉菜单的触发方式一般有鼠标悬停和鼠标点击两种。
步骤条引导用户按照流程来完成任务，一般步骤不得少于两步。
分页的高度设定为 24px、30px、32px，根据应用场景适当增减内容，比如设定每页展示数据的条数、跳转至指定页等。
面包屑用于说明层级结构，使用户明确当前所在位置，并且可以回到任一上级页面。
徽标数用来通知用户当前有未读消息，一般出现在图标的右上角或者跟在文字后面。
7. 表单
表单多由一条或多条列表项组成，单一列表项的类型有字段输入框、条件选择器。
字段输入框的标题和输入框分布方式包括左右、上下、无标题。左右分布是常见的对齐方式，比较适合 PC 端的使用；上下分布增加了表单的整体高度，视情况选择使用；无标题经常应用在登录注册，虽然减少了面积，但是增加了理解难度。
输入框的交互状态包括默认、输入结果、提示错误、禁用、获取焦点。
输入框的尺寸可按照8的倍数进行设定，比如 24px、32px，也可根据系统实际情况进行设定，我常用的输入框高度为 30px，宽度视情况而定，无圆角。上下布局的多个输入框上下间距为 20px，有错误提示时候竖向增加 10px 或横向显示在输入框右侧（预留出位置）。
表单中标题文字左对齐，输入框左对齐，标题文字距离输入框20px（多个长度不同的输入框算最长的）；标题文字右对齐，输入框左对齐，也是常用的方式。输入框内正文字体 14px，文字和左右两边边框的边距 10px。
选择器包括单选、多选、时间选择、开关切换、下拉选择、滑块选择、旋钮等。单选框多为圆形，复选框多为方形。
搜索框和选择框的高度为 30px 或按照 8 的倍数自行设定，通常和输入框保持一致。搜索框距离右侧按钮 4px，内部文字 14px。
单选多选框尺寸 16*16px，多个选项横向排列间距 16px，纵向排列间距 8px。
开关按钮外框 40*20px，内部圆形 16*16px。
8. 表格
表格在后台产品 UI 设计中占比非常大，用来展示数据、统一管理、作为详情入口，是最清晰、高效的形式之一。在设计规范中需设定表头高度、表格行高、表格列宽范围，同时也包括表格中的按钮样式、标签样式。
表格主要分为五大区域：选择搜索区、操作区、表头、正文、底栏。选择搜索区放置筛选框和搜索框，为用户提供按需搜索，可以大大提高用户效率；操作区指各种对表格内容进行增删改查、批量处理、配置列的动作；表头展示列标题，一般具有排序功能；正文主要展示各种各样的数据，要注意行高、对齐、分割、信息层级等，要考虑是否提供行内操作；底栏显示分页、总数统计等。
表格信息一般主要功能为增删改查，查看和编辑是最基本的功能，表格信息支持筛选、搜索、排序、分页。对可批量操作的表格数据在第一列增加多选框。
行高
表格行高可设置为表格内字体高度的 2~3 倍，主表格会间隔显示不同颜色，用于区分不同行数据、加强视觉流引导，展开单行的内置表格可采用纯色，选中行应有视觉上的反馈。表头要和表格内容有视觉上的区分。表格行高可采用 36、40、48、60 等。
行数
表格行数太多加载速度会降低，延长用户等待时间；行数太少会导致用户不断翻页，降低使用效率。比较合适的默认表格行数是 20 或 50，用户可以根据自己需求选择默认的行数。设定行数之后，如果每页行数多于每屏行数，可在表格内引入滚动条，这时可以固定表头滚动内容。
列宽
列宽根据内容字段长短需要有不同且合理的默认值，使得表格字段有良好的展示效果。列内容的长度固定时，列宽应大于固定宽度（比如时间、MD5、SHA1）；列内容不固定时，能预判最大宽度的按照最大宽度设定列宽（比如IP地址、MAC地址、姓名），不能预判最大宽度的设定列宽按照常用宽度，多于内容省略以「…」展示，鼠标悬停出现完整内容（比如详情、描述）。
列数
表格列不应过多，列数比较多的情况下应该合理进行合并、隐藏、删除或进行优先级处理。常用的方法有引入配置列，用户可自定义展示必需列以外的其他列；只展示重要信息，下拉展开列查看完整信息；在表格中引入横向滚动条，根据实际情况选择是否要始终固定基本信息列（如第一列是文件名）和操作列（最后一列的操作）。
对齐方式
表格内的文本应按照文本类型不同进行统一规范，如金额类数值保留相同位数小数，SHA1 虽然是一串数字但是其实那并不是数据而是一串编码，所以可以像文本一样左对齐。根据文本内容不同，对齐方式也应灵活调整，可采用文本左对齐、数据右对齐、金额小数点对齐的方式。数据前面有标签的，将标签前置对齐。类似 IP 地址、MD5、SHA1、域名这样的信息，也可以根据产品需要在文本前面增加「复制」图标，方便用户调用。
详情入口
表格内部数据的详情入口，将能点击下钻查看详情的内容以不同颜色表示，同时在表格行最后一列操作按钮部分放置一个查看按钮。
9. 反馈
包括弹框、侧滑框、骨架屏、全局提示、警告提示、消息提醒、加载状态等。分为模态框和非模态框，区别是是否会打断用户工作流。
弹框又称对话框，是叠加在应用主窗口上的弹出式窗口，以对话的方式使用户参与进来。
弹框
弹框出现时，主题内容增加一层遮罩 #000，透明度 50%，避免使用双层弹框，可同时采用有关闭图标的弹框和无关闭图标的弹框，引导用户对内容进行正确操作。如果设定系统内所有弹框均可以点击弹框外区域关闭， 则需要为用户新增或编辑内容的弹框弹出二级确认的弹框，或者再次进行交互梳理。
侧滑框
侧滑框又称抽屉，出现在右侧，固定宽度 400px，高度覆盖在主题内容之上，点击侧滑框以外的区域则收起侧滑框。
骨架屏
为某些特定数据提供数据加载等待时的占位图形组合。
全局提示
建议停留时间 3s，可根据文字字数调整停留时间，文字内容限制在 30 以内。
警告提示
用不同颜色和样式展示需要关注的信息。
通知提醒
消息通知和警告信息用通知提醒框，单个消息从页面右侧以抽屉的方式划出，用户可手动关闭，或停留 3s 后自动关闭。
10. 缺省状态
绘制不同类型的情感化插画表示缺省状态，如404、500、暂时没有数据、没有新消息等。
页面需要一个默认的底色，错误文字使用 14px，与情感化插画间距 20px，与按钮间距 30px。
11. 数据可视化
数据可视化部分可能是后台产品中对视觉设计要求较高的部分，使用情境为各类统计图、大屏展示页面等。
功能型页面的数据可视化可以引入图形化设计组件，Echarts、G2、d3等；展示型页面的数据可视化则可以做得更有趣，比如立体的统计图、粒子地球效果、灵活有趣的网络拓扑图等。
考虑到数据可视化可能会需要深色浅色不同的背景，在数据可视化统计图的色彩搭配上要注意颜色的拓展性。
发表评论
暂时没有评论，来抢沙发吧~