首页『长安娱乐注册最近看到很多美妆博主都在出什么红黑榜，其实就是在说哪些产品是有问题，不推荐大家使用，有哪些东西是可以安利的好物。想着B端设计当中，也会存在这一情况。然后我在打开 Ant Design ，浏览完所有的组件，你会发现：“组件当中也会存在红黑榜~”今天就趁着 618 刚过的这个时间节点，我也来“带带货”，说说B端组件当中的红黑榜

　　首先我先说一下关于红黑榜的定义1.使用频率高：也就是这个组件我们平时会频繁的使用2.黑榜：在使用过程中，会遇到诸多问题，导致无法正常使用3.红榜：往往会更满足B端产品的实际需求，对于组件有更深的认识

　　通过我的分享能够给大家有一个初步的认识，当然整个组件都是基于我平时的设计观察与使用，目的也是想和大家分享、避避坑，如果有什么疑惑，欢迎在评论区我们一起讨论~

　　树形选择在B端系统当中的出现频率非常高，比如我们常见的：表格、表单、各类详情页，只要涉及到层级结构的选择，都会有它的身影（注意，这里主要说的是树状的选择类组件）但是作为设计师，树形选择在使用的过程当中，会出现很多意想不到问题

　　因为树形选择本身这个组件的特殊性，它的大小需要通过内容当中的高度与宽度共同决定，而在设计过程当中，高度与宽度究竟为多少就要仔细的考虑因为在使用树形选择时，需要思考每一个内容的具体尺寸，太高太低都不行如果太低，展开树形选择就会非常的麻烦；如果太高，则在数据量较少的时候，会给人数据很空横向空间也是同理，也就造成了在设计时，需要深入思考

　　树形选择，作为基础组件，在应付复杂的选择需求时，很明显的会感到“力不从心”，无论是从它显示选中时的内容，还是大量的数据时的选择难度，树形在适用性上，都会大大降低，当遇到这类情况时，建议采取更多“业务组件”的方式来对选择进行优化

　　分类表单（也可以叫Tab表单，不过只是代称而已~）在B端产品当中也非常常见，它出现在复杂的表单当中，但是作为设计师，在真正去使用分类表单时，你就会发现会有非常多的问题需要我们去处理

　　对于用户而言，分类表单不能够完整的查看表单信息，每一个都需要来回切换。也就意味着填写表单的时候，我们不能通过滚动查看所有数据，而是要去点击每一个单独的分类里面，通过分类了解具体的表单内容同时必填项的提示，在分类表单也非常难以处理，因为其每一个独立，而作为用户，其实是不清楚具体哪一个分类里面有必填项，也会导致填写的效率过于低下（其实会有处理的办法，只是大家对于这类提醒都不太满意）

　　分类表单在编辑状态时，同样难以处理。当提交完分类表单后，我们还需要考虑数据在详情页里的展示形式，因为表单与详情页的映射关系，这时候在设计时，应该提供某一分类下的数据编辑，还是整个分类表单的数据编辑？其实这种情况，特别是初级B端设计师，处理起来也是非常棘手

　　顶部导航非常特殊，虽然在我之前 导航菜单 的文章当中提到过，但在使用顶部导航的过程当中，还是会面临很多问题

　　顶部导航最大的局限性便是展示数量太低，毕竟在空间布局当中，横向空间与纵向空间的差异其实是非常大的，顶部导航的高度设定不能过高，同时 二级、三级菜单 只能够使用下拉菜单，也就导致在导航菜单的设计当中局限性过大，并且项目一旦发展过后，不容易解决问题当然，顶部导航并不是一无是处，在许多工具型产品、官网 当中，顶部导航都有着它的一席之地，其实这类形式，更多是以内容为主的网站结构，才会采取顶部导航，也就是上下结构会更加合理

　　栅格严格意义上来讲不算是组建，但是由于很多设计师 误用、乱用，导致设计师为了栅格而栅格

　　因为在常见的移动端设计当中，是不存在栅格（主要是移动端横向空间小，使用不频繁）在桌面端的设计当中，并不是说栅格不好，而是很多时候设计师使用栅格往往会非常盲目，举一个简单的例子，在表格当中是否需要使用栅格？答案是：“不用使用栅格”，其实这类问题就是目前很多设计师的问题，因为会盲目使用，也就导致了我在做设计的过程当中，出现很多为了栅格而栅格的现象。后面有时间单独总结一下栅格主要运用在哪些地方，希望大家别盲目使用至于栅格应该如何使用，在我之前的文章当中都有提到，可以自行点击历史记录查看

　　滑动输入条在很多概念设计当中都会经常出现，特别是在 Dribbble 上的桌面端设计当中，是每一个设计师的标配，但是在实际的B端项目中，特别是桌面端的B端系统当中，滑动输入条是非常不合理的一个组件

　　因为B端产品当中，大多数的产品都是需要精准录入，并且数据的区间非常大，因此也就造成了滑动输入条，使用起来给用户的感受是非常糟糕的，并且由于大多数用户的预期还是以直接输入为主，这也就造成了现如今B端产品很见到滑动输入条的原因

　　面包屑导航在实际工作当中经常使用，因为在常见的B端系统当中，导航菜单以及信息结构，一定是非常复杂的（除非你的系统里面就只有一级导航菜单，并且没有其他的页面层级逻辑）

　　因此通过面包屑导航，能够让我们清晰知道整个页面的信息结构，通过面包屑又因为其小巧、灵活，无论你是在一个完整大页面当中，又或者是一个小的气泡卡片当中，面包屑都能进行承载，并且它还能够起到返回的作用，又能够清晰的展示页面的路径信息，是一个可以一举多得的组件

　　穿梭框相比大家的不会陌生，在设计B端产品的时候，或多或少都会有所涉及，与此同时，由于穿梭框本身复杂，再加上很多设计师会觉得它占比过大，因此不会去使用

　　今天安利穿梭框，其实是想安利这一类的穿梭类的组件，你会发现其实很多业务选择类的组件都会通过穿梭框的形式进行演变，比如我们常见的“国家城市选择、部门成员选择” 甚至表格当中的字段显示隐藏设置，这些都是传统的数据选择过后一步一步演变而来，因此这类穿梭框型的数据选择其实更加体现的是设计师基于目前的组件所进行的优化，而分析它为何这样做，这样做的原因，成为了穿梭框上榜的理由

　　折叠面板就像一个大的“盒子”，当产品经理在你的身后说着：“这个信息我要放，那个信息也不能落下的时候”，拖出一个折叠面板来解决这个问题

　　其实在折叠面板的使用过程中，主要是在详情页以及表格当中，因为折叠面板本身可以容纳很多信息，并且能够交代具体的层级关系，因此使用折叠面板能够有更多展示数据的可能性，即插即用，非常方便

　　在页面当中的任何地方，蹦出一个气泡卡片你都不会感到奇怪。其实气泡卡片我在日常设计当中，经常使用的一个组件，因为它能够容纳下任意的内容，小到一串文字、大到一个视频，都能够在气泡卡片当中进行使用

　　并且在信息当中，气泡卡片作为一个信息补充的组件，因此在系统当中，需要展示但是又不是那么重要的信息，使用气泡卡片，就会更加的方便

　　最后一个，自然逃不掉我们的锚点导航。感觉在我的疯狂安利下，越来越多的产品都开始使用锚点导航。因为B端产品必定是复杂且多的信息，自然而然我们在使用的过程当中要更多考虑信息的承载（锚点导航就不配图了，这个得自己用才行）而在使用过程的当中，锚点又不像分类那样过于绝对，不会强行分割过多数据，因此会更加易用同时它的兼容性会更强，可以出现在 表单页、详情页 等各个地方～它的好处实在是太多了，这里就不过多赘述了，用过的人都说好

　　黑榜：树形选择、分类表单、顶部导航、栅格、滑动输入条红榜：面包屑、穿梭框、折叠面板、气泡卡片、锚点导航

　　其实，我们在做B端设计的时候，你会发现要解决的就是组件设计。这里讲到的所有内容都是基础组件，实则在工作当中用到的更多的反而是基于基础组件之上，所演化而来的业务组件。但是业务组件确实是一个“深坑”，里面的特殊性、业务场景、具体问题，我们就在后续文章一起聊聊

　　用户是为了工作而使用这个产品，因此他们必然要长时间使用产品，而且是沉浸式使用，同时使用频率是可预测的，他们并不能带着个人喜好去使用，不能说这个产品太难用了，我就可以不用了，比如我们上下班打卡，公司要求用A产品，你觉得不好用，就推荐大家使用B产品，对不起，虽然你是产品真正的使用者，但决策权和付费者是高层领导。所以个人的情绪左右不了使用场景。所以B端产品更讲究严谨的流程设计、贴近现实的场景面积、低风险、高效率、数据精准。它是为了解决工作上的问题而生，寄生于企业制度之中，被产品的用户体验影响着工作效率。

　　B端产品的本质则是满足用户的工作需要，但这从来不是单一的功能就可以满足的，这里一定包括了多项功能的组合及嵌套应用支持。B端产品的业务逻辑是复杂和多变的，尤其是权限系统，往往每个人都是流程中一个非常小的部分，就如上段所说，需要进行协作使用，这里不能穷举出每个业务，因为不同的公司业务则完全不一样，公司可以对该产品当中的功能选择性购买或租赁，而对实际用户来说，这个产品没有功能的层级，自己负责哪一块，哪一块就是他的主要任务、经常使用的功能。也就是说，从功能架构上看，这些核心功能都是扁平的，他们分配到各种使用角色的手中，没有先后排名。

　　产品则是服务于企业用户，这个“企业”可以是一个组织、商家、团队，是某种经营的主体，当然使用者也是个人，不过这个“个人”是代表了组织中的某个角色而已。这类人无论性别、年龄、地区有何差异，他们都是一类角色，比如企业中的：项目总监、项目经理、项目顾问，我们的产品要提供给这类角色使用，而不是某个人使用。

　　所以功能设计需要是多个业务功能满足特定人群的多个需求、多个场景，它所面对的用户具有特定的职业属性，也就是说它的用户只会在“工作”的场景下使用它，有些还是强制使用，个人没有选择余地，因为付费者是企业领导，而不是基层员工，而使用最多的反而是基层员工，所以B端产品的用户关系会比C端更集中、更垂直，做功能设计时，要权衡付费者和使用者之间的利弊，他们要求产品的时效性，注重如何满足企业用户的既定目标。

　　产品设计者对于用户的需求在一定程度上是可知的，所以B端产品是辅助用户行为，比如我们要做一个企业报销系统，这些流程和工作行为已经有一套标准的流程了，我们只需要将这些场景转化为流程设计。那这个系统会存在哪些场景，只需要找到相应的使用角色一聊就能挖掘出来，而且场景相对较固定，不用考虑用户是不是喜欢这个功能，因为这是公司制度要求，不喜欢也得用。因此在设计初期，我们要做的就是充分挖掘相应的功能需求，尽量把流程做到完善，而在设计上要有：合理的功能与模块划分、严谨的业务流程设计、一致性的操作体验、干净简洁的界面设计。

　　，即在做产品信息架构时，就需要仔细考虑功能、模块的划分，客户常用功能模块有哪些，模块与模块之间的关系是怎样的，当然有些产品版本是通过客户需求进行个性化设计的，比如有的客户要求为他们企业单独设计一套工作流程，那么怎样组合该客户的功能模块呢，这也是做B端产品经常遇到的需求。

　　B端产品不用揣测客户打开产品会干什么、引导他干什么，因为他是工作软件，在使用时，客户必然有明确的目的，需要什么他自己会打开，因为都是他们自己最熟悉的业务范围。所以做B端产品不光要学习本职岗位的技能，还要了解目标客户他们的工作流程、业务知识。

　　无论是B端还是C端产品都是应该遵循这一点，这是互联网产品最基本的素养，即：保持交互和视觉的一致性，让用户在使用时，能感到熟悉、亲切，能直观的了解到操作会带来怎样的结果。

　　B端产品是为了工作而生，界面里往往都是“内容为王”，不易使用过于强烈的色彩对比，也不需要过于浮夸的设计，整体产品调性都应该尽量简洁，不要让视觉效果喧宾夺主，而应该减少干扰用户的“多余设计”。

　　做B端产品必须要维持：功能为主的设计原则、视觉服务于功能的产品素养。这也是为什么很多B端产品喜欢用蓝色系的原因，因为与蓝色相关的负面信息很少，同时色彩上也不会过于强烈、刺激，一般人都不会排斥它，并且色彩含义也为“理性”、“商务”、“科技”，这就更适合B端产品的特性。

　　在前面我们分享了长达两万字的 B 端设计规范解析，对规范从软件层面到实际项目执行都做了详细的说明，具体可以看下文回顾：

　　从零讲起 B端设计规范和组件库应该怎么做？实操讲解 B端设计规范和组件库应该怎么搭建？组件应用 B端项目设计规范、组件库搭建详解

　　呕血巨制｜B端设计规范搭建·真·看这一篇就够了光有文字内容当然还是缺点意思，所以我额外录制了一个原子核的系列，来帮助大家理解如何创建B端项目设计规范。

　　近几年对组件认识发展的趋势来看，相对于追求组件化，控件库的通用模式不再是那么的热衷，转向符合本产品本业务的组件模块更精细化和更多的延展可能，因为只有贴合业务变化的组件才能够得到更好的迭代。市面上能够看到的移动端本就挺少，移动端基本和业务贴合紧密，组件模式更不太会拿出来了。从本业务的一些角度，理解下组件和业务的相结合的方式，这里不从基础的组件元素讲。仅供参考。

　　讲述前先回顾下关于自己业务类的web端制作组件规范的时候，有一系列比较完整组件分类并且统一，操作主体是小众且是专业人士，一般情况下不会轻易改变组件类型、组件样式，更多考虑是操作的严谨性和业务的复杂性。移动端是一个个体患者，对操作和对使用都会提出一些便利化的要求。本次内容是对已存在的项目多条业务线进行描述，应该解决的移动端组件规范标准问题的总结，算是手把手教学了。各个大V公众号、平台对建立组件库的讲述都很细致，这里从参与业务的角度来整理规范，整理符合本公司业务发展的组件，不会完整讲述某个场景，大家可根据自己工作内业务线进行对照梳理。一直到现在整理组件规范也是为了快速反应业务的效率，输出页面，甚至演示操作界面，供与甲方对接的直观感受。整理“规范”（下边会解释是什么样的规范）后的一个直观样例是为一家医疗机构的科室输入一套实用小工具的演示界面，快速搭建起来的。时效性是目前能达成目标的快速要求。

　　一、建立组件规范的条件真正建立规范是有前提条件的，还需要同前端多次深入沟通（这里需要注明下，不是建立规范，就一定要搭建组件库了，组件库维护太费事，可能情况下多和前端沟通，哪些组件样式还能复用的，前端就明白了）。并不是在所有情况下都需要建立规范的。即使多个项目，也将它拆分成主次业务线来看涉及到哪些模块内容。

　　以上浅浅的例子描述子业务线里穿插着共同的组件，患者、医生、科室、表单，这些可以单拎出来作为组件模版进行复用。

　　具体业务名称不展示，比如说业务方面涉及到康复、随访、远程、宣教、互联网医院等，可能有着共同的因素：患者信息、健康宣教信息、医生信息、填写上传资料等等另外单个业务可能对应的各个医疗机构也有大同小异，大同也就是共同因素了。

　　贴合场景需要，组件是在核心信息的基础上添砖加瓦的，所以不要为了设计组件而精心制作。基础组件：按钮、图标、布局（栅格）、分割、间距、输入框、选择器、弹窗、卡片、列表、文本

　　功能区是业务的核心入口，多个功能也需要划分主次，在布局和视觉上做出相应的区分，并且功能入口的数量是根据业务不同而变化的，所以提供多种样式是有必要的。对主功能区，可能性的一排二、排三、排四都展示出来，基本覆盖多个业务场景需要。副功能区，也是如同主功能区一样，不过在视觉上要略显靠后，这些工具的制定虽然是医疗机构，但使用主体是患者，所以在一些比较专业晦涩难懂的名称时，会附加注释性的副标题注语。

　　患者展示核心信息是患者姓名、性别、年龄。可进行多绑定就诊人，为方便问诊，可即时切换就诊人，再者就是给已有健康卡的患者添加说明标签，以及健康卡二维码

　　日期有分这三种：日历/月历/周历不管是这三种的哪一个，患者的目的是要查看指定时间的信息是否满足自己的需要。基本信息：日期+周几医生查看有哪些任务在进行中，哪些任务是已经处理完成的了。又或者是查看“历史记录”，这比较少数。以三种日期选择更合适的呈现方式月历一般在自然月份里选择需要，通常会和周历组合使用。周历是在约号源的时候用，在当前日之后的规定的日期范围内约号。日历一般会在预约时间周期用，通常以月为单位的。

　　医疗机构主要信息是机构名称、机构分级、专科或是综合、简介以及配图信息对于初诊患者来说，选择可以增加可靠性的医疗机构，需要在基础信息上增加更多的信任度元素，比如说在某专科排名、获得称号，这个场景大多出现在互联网医疗平台上，定向合作医疗医疗，基本无此项内容。

　　医生信息在多个场景下出现，但基础的信息是医生姓名、职称、擅长。场景一：筛选的科室内，医生信息有姓名、职称、擅长；场景二：医院科室下，预约挂号的列表，有姓名、职称、擅长，预约挂号按钮；场景三：搜索结果，医生信息有姓名、医疗机构、科室、擅长、问诊类型+价格如果是互联网医院，还会在场景三的基础上再加上一些问诊数据，问诊评价，专业资历等信息。

　　健康宣教的目的是进行科普，提升患者的正确的医疗认识，所以不会像C端那么要求抓流量。宣教列表主要是科普文章标题以及相应配图，在此基础上可扩展，补充宣教文章发布时间和浏览量。甚至更细化点，增加本篇文章的主旨标签等信息。

　　以上几个描述的样例，通过从组件的主要信息向外扩展辅助信息，有效的扩展信息能够帮助组件更好的应用于增长业务需要。掌握好组件的利用，对以后的构建交互方案、与前端开发对接和沟通会有更好的收获。

　　你需要在页面上显示大量各种各样的内容，可能包括文本、列表、按钮、表单控件等，而你又没法把它们都显示在页面上。

　　同时，还可能有一些适用中央舞台模式的内容需要在视觉上优先处理，需要把面板收起。

　　1、这些模块为界面上的主要内容提供注释、修改、说明或支持。（例如：WPS右边的快捷键、样式、帮助、资源）

　　3、对不同的用户来说，它们的价值并不一样。（例如：图中新手入门指导，老用户可能并不需要）

　　4、甚至对同一个用户来说，这些模块可能有时候非常有用，换个时间就不一定了。当

　　5、这些模块之间可能彼此没有多大关系。当用到Tab和折叠面板时，这两个模式会把各个模块组合到一起，表示它们之间有一些关联，而可收起面板不会对内容进行分组。

　　这也是渐进式展开原则的一个例子—只在用户需要的时候，需要的地方立即显示那些隐藏的内容。

　　总的来说，想让界面保持整洁，通过对内容进行分组和隐藏是非常有效方式。而可收起面板、Tab、折叠面板、可移动面板，这4种模式正是有效方式的工具。

　　可以利用引导性的文字来表示这里可以展开（例如：更多），也可以利用三角形的图标来表示这里可以展开。

　　也可以在打开和关闭这些面板的时候加上动画效果，这样会让打开和关闭时的过渡更

　　如果有多个模块要用这种方式来隐藏，可以把这些模块放在一起，或者用Tab、折叠面板来组织，还可以把它们分开放在主界面上。

　　如果发现大部分用户都打开了一个默认为关闭状态的可收起面板，那么应该让它默认打开。