B端产品设计『提示』功能的组件化思考

B端产品的业务种类繁多、流程复杂，导致用户处理业务时需要在多个功能模块间切换，一定程度上影响了工作效率，而每个用户真正常用的功能并不多，把B端产品首页设计成工作台，方便用户登录系统就可以立刻掌握工作进度、查看待办事项、快速处理业务。

更大的背景则包括：信息系统越来越多，信息爆炸。信息孤岛出现，信息无法实现集成与共享。信息仍是被动式的提供给需求者，无法实现信息的个性化存取。

工作台是一个帮助用户快速掌握工作进度及进入工作状态的导航页面。

工作台的设计离不开产品经理对现有业务流程、管理体系的深入了解和洞察。从用户角度来看，首页工作台是用户感知产品价值的重要“门面”。从设计角度来看，首页工作台是系统内体验范式及视觉风格的核心场景。

为什么将工作台定义为导航页面，而不是综合管理页面？工作台是为了让用户随时掌握各项工作的进展情况，快速进入需要处理的工作事项。

设计目标

提升使用者的工作效率，减轻工作压力；

串联业务场景，展示业务全景；

“工作台的设计围绕节省完成任务时间，以及实时掌握业务情况展开。”

两大类角色：管理者（偏基层管理者）和执行者（业务人员）。

管理者的核心需求是根据公司战略规划，对业务情况进行把控，如进度、质量、风险、任务分配合理性等。

执行者的核心需求是高效地完成任务，涉及分工协作、信息同步等方面。

管理者需要及时高效的查看数据报表，了解团队任务进展和每个成员的任务进度，掌握业务全景。设计时需要根据角色的工作岗位量化并展示他们关注的核心数据，包含正常数据和异常数据。任务进度包括团队及团队每个成员的分配任务数、完成任务数、任务完成率等信息。

业务人员每天的工作都围绕任务展开。上班后了解今日任务，然后按照规划开始工作，下班之前再查看任务的完成情况。如果没有工作台，任务分散在系统的各个模块，会需要花费很多时间去寻找任务，也可能遗漏任务。页面布局上可以通过归集任务入口、展示任务进度和剩余待办任务满足相应的需求。信息同步包括公司级信息同步和协同任务信息同步，一般通过通知公告模块、消息中心以及站外推送方式实现。

工作进度：

通常来讲，工作进度是指对某些项目或重点业务流程的进度监控，无论是项目里程碑还是审批流程，系统都定义了确定的阶段或状态。另一类工作进度则是对当前已完成工作量的汇总，一般没有确定的数值，比如日累计或月累计数据，可以同时显示设定目标值、个人历史值或全员平均值进行对比，在一定程度上可激励员工提高工作积极性。

对管理者而言，工作进度的意义更为重大，可以及时了解各个业务人员的任务进展以及整个项目的进度。

待办提醒：

待办事项/任务用于提醒用户当前待处理的工作事项，汇总数量后方便用户查看当天的工作量。不同角色的待办内容不同，执行者的待办任务更多的是工作内容，比如待审核订单、待发货订单、待处理退款等。管理者的待办任务更多的是流程审批，比如请假审批、报销审批、用章审批等，也包括管理范围内整体的待办任务，以便安排工作。

无论具体内容如何，在设计待办事项时都要遵循三个原则：第一，展示形式简洁，一眼就能获取所有关键信息；第二，要能够快速处理，可以当前页面直接处理，也可以链接到详情页处理；第三，如果有截止时间，需要重点标记出来，并按照截止时间升序排列；

待执行任务一般有两种呈现形式。一是仅放置任务入口，点击可进入对应的任务列表。这种形式适用于数量较多、需要批量的任务。二是显示任务列表项，点击可对任务进行处理。这种形式适用于数量较少、且独立于其它模块的任务。

待办任务的处理方式也是两种：简单的事务可以直接在当前页面通过弹窗进行快捷处理，复杂的可以按照“待办列表-待办详情”或直接进入详情页两种操作路径进行处理。

快捷功能导航：

快捷功能板块是承载用户常用功能的快链入口，可以节省到导航栏查找功能菜单以及进入页面查看功能入口的时间。满足的是用户个人偏好的需求，对于绝大多数用户来说，经常使用的功能只有几个，将常用的菜单或操作入口提炼出来，方便用户快速进入，省时省力，属于锦上添花的功能。一般会按照特定角色的工作职责预置几个默认的快捷功能，并允许用户自定义编辑。

同样的，可以直接在工作台页面以弹窗形式进行展示，也可以跳转至对应的功能页面。一般还包括应用搜索及查看历史搜索，以及最近使用的应用等功能。

通知公告：

企业的重大决定往往以公告的方式进行发布，以体现其正式性，也方便用户集中查看，同时避免用户错过重大通知；

核心业务数据概览：

核心业务数据的判定依赖对业务的足够了解。任务都完成了并不代表业务进展得顺利，所以要对业务进行分析，看哪些数据能够反映业务的真实情况。

消息中心：

消息系统一般包括普通提醒（如续费预警、有效期提醒等）、业务提醒（和业务流程密切相关的提醒，如待审批等）、系统公告（平台级的功能更新说明、营销推广活动，公司级的通知公告等）。形式上一般是独立于页面的悬浮消息列表，避免打断用户原有操作流程。

全局搜索：

包括对人员、消息、功能菜单、业务流程等内容的搜索。

工作日志：

工作日志是对每天工作的梳理。有的公司要求员工写工作日报，包括今日工作完成情况和明天工作计划，因此可在工作台添加工作日志入口。此外，系统还可以自动汇总日报提炼形成周报，并进行统计分析。

日程管理：

日程管理是从更加宏观的视角来看待整个工作安排。钉钉、飞书中都有类似的日志功能，对时间管理比较重视的企业会比较青睐这个功能。

业务场景比较简单的产品不适合使用工作台，可能无法提高工作效率，甚至会成为用户的负担。

对于不同的角色，需要的功能板块不同，相同功能板块的重要程度也不一样，因此要有针对性的进行合理布局。

工作台不是简单的功能堆砌，而是依据不同业务角色的工作职责和核心使用场景，将相应的功能和数据规划到一个页面进行集中展示。

少即是多，工作台设计以提高工作效率为目的，展示的内容不易过多，太多了容易给用户造成视觉疲劳，最好一屏展示完全。

参考：

工作台设计思路（东东方笔记 公众号）

浅谈B端产品设计-工作台篇（明天上线 公众号）

B端产品工作台设计详解（袁贺）

云台助手案例分享：B端产品该如何改版?（苏宁设计 公众号）

怎样设计企业管理系统的首页工作台（产品旅程 公众号 质量较高）

以电商和医疗行业为例，看B端工作台和消息系统的设计（司马特小分队）

研究规划 | 企业门户系统的规划与建设研究（数字化企业 公众号）

传统企业的数字化之路：如何打造一款企业级的工作协同门户平台（神马B端）

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 端的设计之路（上）

如何设计首页，我查了众多资料，发现市场上大多是介绍C端的产品主页，对b端产品的介绍比较少，所以本文计划以首页设计的形式，首页的内容指标，分角色、分不同权限的使用差别来介绍。

设计之前，先统一一个核心价值，首页设计不是我们的首页，不是展示品牌的首页，而是设计给用户看的，为了更直接有效的触达用户，为了给用户提供更高效的工作效率和降低他的工作成本。

如何设计，考虑到产品的设计，需要对用户进行访谈，了解用户的使用场景，分析用户对平台的期望。

产品门面的角度而言，首页可以作为一个数据平台，从产品价值与效率的角度来讲，首页可以作为一个工作台，产品业务架构的角度来讲，首页可以作为一个对导航页的补充。

一些设计首页的原则

首页尽量只占一屏，不要有滚动条

首页的设计核心是帮助角色快速触达业务

设计首页的内容板块时，最好要有内容标题，复杂内容要有tips提示

首页更加适合以图表格式展示，

首页上半部门一般显示数据，下半部门一般展示快捷功能和功能导航，

一般进行设计时，尽量聚焦到角色的日常工作中。

产品首页的常用设计板块主要包括几个点：数据展示、图表内容展示、功能导航、快捷功能、个人信息、内容包括资讯和通知信息。

数据展示

数据一般是公司管理层比较关注的业务运营数据和公司管理数据，数据展示时，数据相对独立时，一般采用图标加文字的方式，数据较多时，一般采用折线图，一定要选择符合数据特征的图像。

内容展示

内容一般包括资讯和通知信息和公告，一般展示在首页。

功能导航

一些高频使用的功能可以考虑使用在首页，设计方式以图标为准。

个人信息

一般设置在导航栏

快捷功能台

设计的目标是要用户快速触达功能和业务，提升用户的效率，该功能的设计不宜复杂，操作可以在工作台完成即可，尽可能简化设计。

视觉

保持整洁和简单即可，与整体导航风格保持一致，不能抢占导航的视觉中心。

再次重申，首页设计的意义是提高角色的效率，使客户快速触达业务。

B端行业是一块神奇的领域，对于普罗大众来说它是陌生的，也是神秘的，大部分的普通用户无法接触到这背后的产业链条，然而生活中的一切都与其无时无刻地产生关联，我们使用的每个物品都是从其生产加工-制造-分销-流通-零售等等流程，最后到达我们消费者手中，而我们接触最多的只是零售这个环节而已，其背后的供应链关系却是非常复杂的。

由于本人最近同时在做装修行业的B类和C类产品，对这个领域有一点小小的思考，所以在这里做一个简单的分享。

首先，根据 用户角色 我们来区分一下B类和C类用户的区别，这里以装修行业为例：

C端用户即装修业主，指的是有装修需求和潜在需求这类群体，其用户画像大多数为刚购新房有强烈的装修意愿但不知如何装修的小白用户 ；

而B端用户用户角色就要复杂很多了，我们现平台的B端用户主要有装修公司、设计师、建材商、采购商等等，而每个角色端都有非常多的使用者，比如装修公司里面就有管理员、老板、客服、设计师、项目经理等等一系列的使用者角色，并且每个角色的使用场景和使用目标都完全不一样，所以这也大大增加了B端产品的角色权限等功能的复杂性； 

然后再对比一下两者 流程 之前的区别：

C端用户的使用流程相对来说比较单一，比如一些浏览、发布、下单等操作流程，所以对C端用户来说，我们需要尽量简化其任务流程，通过运营和设计的引导促使其完成这些操作；

而B端用户的使用流程就比较复杂了，就拿装修为例，装修公司从装修前接单到最后装修完成竣工大大小小的流程至少有几十个，就算是主要的的节点都有十多个，流程周期一般都是几个月甚至更久，而且有相当数量的流程节点是在线下完成的，这对B端产品的设计带来了极大的挑战，大多数的线下场景的所带来的问题会更复杂，所以对于B端业务流程的设计会提出更高的要求；

最后看下其二者 使用场景 的区别：

C端用户的使用场景多数是稳定的，比如app和pc，用户通过固定的用户端就能完成所有的任务，不管是室内还是室外都是在一个相对较为稳定的环境下完成的，所以C端用户对沉浸式的体验拥有更高的要求；

而B端用户真实的使用场景是比较复杂的，比如一个装修公司设计师用户，他可能前期需要在pc端上去派单，然后在手机端上接单，然后给业主打电话沟通量房，线下量房时用app签到拍照等等，回去在pc端设计方案，最后再次跟业主沟通报价方案，线下签订装修合同，手机端同步更新等等这些操作。当然真实的场景会更复杂多变，这里涉及到大量的线上和线下对接的使用场景，所以我们在分析B端用户的使用场景的时候需要更深入的思考，需要更加具象地还原每个用户角色在不同的流程下其真实的使用场景是什么样子的，角色与角色之间是如何进行信息的交互，而不是仅仅局限于线上的使用环境，要把线上和线下融合在一起才能真正明白使用者的使用场景和其心理模型。

通过上面三个差异点的分析，能够大致了解了B端和C端用户设计的差异性， B端用户角色众多且复杂，用户操作周期长流程冗长，使用场景多样化；而C端用户角色比较单一，用户画像明确，操作流程简单舒适，使用场景稳定。 因此我们在做产品设计的时候针对其不同的特性去做差异化的设计，比如B端用户角色众多的问题，如果按照每个角色都去做定制化功能，那么这个产品最后肯定是不堪重负的，那么我们的思路是做功能模块化设计，把角色和角色之间的区别用权限来隔开，不同的权限拥有不同的功能，然后让装修公司自己去定义角色和权限，这样就实现了功能可配置的差异化设计。

从宏观的维度来看的话，B类产品从某种意义上来说是为了实现价值最大化的一个过程，其主要是为了价值创造；而C类用户更在意的是个人价值体现的一个过程，简而言之为价值实现。针对二者的区别，体现了两种不同的设计方向和思路：

C端：1、价值传递；2、场景触达；3、氛围营造；

B端：1、价值呈现；2、任务管理；3、高效协同；  

比较常见的是对同一类数据的字段全部修改。

B端产品的字段就更多了，经常一个页面，涉及到多处的字段修改，常见的解决方案是，把所有的字段都放在一个页面上，用户想改哪个就改哪个，然后统一提交。

这样做的优点，是聚合了所有要修改的字段，统一入口，用户查找方便，可批量修改的字段一目了然。

但在b端产品中，我们会面临多场景，用户选择难，关联逻辑多的问题，经常有修改有大量前置条件，如果全部在一个页面展示，扩展性差，冲突多。

每个字段，每个场景的批量修改旅程和体验是不一样的。针对以上问题，我们可以按以下步骤解决批量修改的问题

第一步，对批量修改的字段进行分类

我们可以按场景，类型，角色，权限进行过滤，然后在看字段是否可直接修改。

1.无关联字段，可直接修改的字段，例如：备注

2.有关联字段，调整一个字段，需要对其他字段进行关联调整，例如：调整地址，联系人，电话就可能需要同时调整

第二步，整理每个修改的旅程地图

针对每个批量修改，在B端产品中，可能都是个针对不同场景需求的小功能，所以对个别修改，我们同样要梳理旅程地图和流程图。

第三步，字段的分类归类设计

无逻辑关联字段，可按场景，使用频率，进行分类

无逻辑字段，如是同一类型，可以归类在一个修改页面，减少用户的选择成本

例如备注

第四步，对每个场景，有逻辑的字段，进行页面聚合设计，关联设计。

保证修改字段时，所需的条件都在一个页面上。

有关联逻辑的字段批量修改，修改页面可能有多个关联的字段需要修改，对关联的触发，我们要落在主要修改对象上。

例如：规则是，地址如修改为外地，必须更新联系人和电话。本地则不强制更新联系人和电话。

我们的交互触发点就要落在地址上，对输入地址进行判断，按规则，启用对应的字段修改。

第五步，所有批量修改页面，聚合在一个批量修改的入口内

采用hover的交互方式，保证用户快速选择要批量修改的字段。

至此，一个针对B端产品的多字段的批量修改，我们就完成了。

用户可根据自己的角色和场景，快速选择要操作的修改

下拉显示修改内容更直观，更易选择

批量修改扩展性更好，有更多修改字段也不怕

提交时只需提交当前任务的结果，不再同时提交多个校验，减少报错

这样做批量修改，是不是更好呢

从道的层面来讲，我认为有两个大的板块，一个是进行系统设计的思维框架，一个是产品经理的认知理念。思维框架是指在进行产品设计的时候的思维指引，先想什么后想什么。而认知理念呢，是指对于用户、需求和价值的判断依据，涉及到产品经理对于工作的深度理解。

先说思维框架，我认为产品设计最基础的思维框架就是用户体验要素。

《用户体验要素》是美国著名的用户体验咨询公司Adaptive Path的创始人Jesse James Garrett在2001年美国发表的，引入国内大概是在2008年。

这本书虽然主要是指导web端网页的用户体验设计，但是他所提出来的这个五层次模型可以衍生出产品设计产品的整个思考层次，所以我们在看这本书的时候，除了理解模型本身，可以根据自己的情况去吸收里面“术”层面的指导。

用户体验要素中最核心的理论就是五个层次模型（如下图），给我们提供了一种思维层次结构和指引，一方面告诉我们当前的思考是处于哪个台阶上避免思维的混淆，另一方面告诉我们完整的设计应该包含哪些层次保障设计的完整。

第一个层次：战略层

与C端产品的自主性相比，B端产品的需求更加依赖于业务侧的输入，有的时候业务会比较强势，会直接表达需要对系统的改造要求。然而，无论是处理小的需求还是主导大型的项目，还是规划整个系统，作为产品经理最首要的就是重新审视用户需求，也就是从战略层出发，来识别用户、需求、目标。

为什么要重视战略层？因为产品的设计是从需求出发的，如果对于真实的需求识别不到位，那么解决方案和后面一系列的设计都可能会成为无用功。

PS：这里不会详细讲述用户需求分析的具体方法，后续会讲到。在本文所讲的，是希望产品同学在对待所有的需求时都能产生条件反射——谁？有什么问题？期望是什么？并以此定位出系统的用户、定位和目标。

第二个层次：范围层

上一个层次如果说是在问题的诠释上，那么从这一层开始其实就到了解决方案的层次。

在明确了系统的设计目标，产品同学就将给出问题解决的方案，然而方案本身也是有层次的，最开始的应该是功能范围和流程。

也就是，我们要知道我们要做些什么事，系统的改动点是什么？涉及到的系统流程是什么？系统之间的关系如何划分？

书中提到的有一个点可以注意一下：在进行功能范围设计的同时，不要忘了内容的设计。比如，对于C端产品来说，做了一个购物网站的首页，不仅仅要规划出导航、搜索、一些广告位，更要规划好导航、搜索推荐和广告位的内容定位，协同相应的运营部门一同进行规划。对于B端产品来说，在设计系统的时候一定要思考匹配的运营机制是什么，需要哪些资源做哪些投入？才能保障目标的实现。

第三个层次：结构层

结构层重点是指信息架构，可能是多个功能之间的联结关系，在C端产品的设计中需要重点思考。

常见的结构包括：树状结构、矩阵结构、线性结构。

B端产品设计也要思考功能结构，比如哪些功能是可以独立存在的，哪些功能是有关联关系的，哪些功能是有层级关系。做好了信息架构的设计，系统的体验和延展性会得到更好的发挥。

第四个层级：框架层

框架层包含两部分：界面设计和导航设计。界面设计是指在某一单一页面上交互功能的设计问题。而导航设计就比较好理解了。

C端产品的形态比较多，所以在界面设计上，需要更加深入的结合用户偏好习惯和使用场景来进行权衡设计。

而B端产品相对比较简化，但是也要遵循基本的设计原则。一个是注意选择合适的界面元素：注意交互功能表达适宜性；二是注意界面元素的摆放位置。第三个是注意用词和提醒（B端产品专业性较强，需要注意系统概念的设计与用户理解之间是否存在偏差）

这部分可以参考尼尔森十大可用性原则，具体看看如何进行界面设计。

第五个层级：表现层

表现层对于互联网产品来说主要是指视觉设计。

视觉设计要关注的主要包括：视觉焦点、对比和一致性设计。

对于一款产品来说，框架设计和视觉设计就像是店面的装潢，不仅家具要摆放得体，更要有设计风格，最好能创造一种氛围感，与店铺品牌的风格，用户的偏好以及消费场景相匹配。

而B端产品的表现层，产品经理不用过于的关注，但是需要保障一些基本的原则，比如色彩的统一性，页面字体和大小的规则的标准化等等，这样才能让用户有一些较为明了清爽的体验。