随着C端产品市场蓝海逐渐退却，目前市场上越来越多的企业转战到B端产品中，因此也越来越多的UI同学从事B端产品的设计，然而，难受的是B端产品对UI的要求并不高，甚至有些企业直接搬前端框架就能完成开发，所以UI同学可能在团队中很少有话语权，得不到重视甚至还经常被指派打杂工作，我以前刚出来做UI设计师的时候就特别想找C端产品的企业，因为C端产品不仅相对B端来讲话语权更高一点，而且兴许还能给自己带来一些好处，例如电商企业能买东西打打折啥的，但是事与愿违，工作那么多年都一直在负责B端产品的设计，从开始UI到交互最后转岗到现在公司的产品设计，因此今天我想通过文章给大家分享B端产品设计师全方位工作流程以及各流程的工作经验

前言：什么是B端产品设计师？

你们有没有发现一个问题，就是网上关于B端产品的文章数不胜数，可你认认真真把文章都看完后，回去再看一眼自家公司的后台系统依旧是看不懂，打开后台里面每一页都是表格，看上去都差不多，什么系统管理有啥用根本不知道，唯一能懂的可能就是排版配色侧边栏。

B端产品最重要的核心是产品业务，大家之所以看不懂系统就是因为不了解产品的业务功能，而B端产品设计师就是负责整个产品从业务调研（业务梳理）、需求管理、竞品分析、产品规划、原型设计、再到功能测试以及后续产品培训等过程的岗位（其实就相当于C端的产品经理），UI设计师转到这个岗位的优势就在于我们的设计思维能够对产品界面、交互流程进行优化，并且转到B端产品设计后无论是薪资还是话语权都会有很大的提升，所以下文想跟大家分享B端产品设计师平时的工作流程以及一些工作经验，希望大家看完后能对这个岗位有深刻了解以及帮助大家日后晋升。

1. 什么是B端产品？

想要成为B端产品设计师首先我们需要知道什么是B端产品对吧。

B端产品也叫2B（toBusiness）产品，使用对象是企业或组织。B端产品帮助企业或组织通过协同办公，解决某类经营管理问题，承担着为企业或组织提高收入、提升效率、降低成本、控制风险的重任。

说白了B端产品本质就是提供给企业用户完成某种工作的工具，核心是提效降本，例如钉钉、企业微信就是为了降低监督员工考勤成本而研发的工具 。

B端产品主要特点有4个（要是觉得抽象不理解也没关系，这里先给你们埋个伏笔，我后面跟你们解释时候会用到）：

特点一、目标用户是一个群体：B端产品用户群体是某个业务团队或组织，这一组人需要共同协作来完成工作，所以需要B端产品来帮助他们实现分工协作。

特点二、效能第一视觉第二：B端产品的目标是解决组织的某类业务问题，因此聚焦于流程，提升业务效能是最重要的，其次才到视觉设计。例如，产品设计时并不会过多地考虑UI设计，也不会为了几个按钮的摆放位置花费太多时间，业务人员不会因为美观问题而放弃完成工作。（“但这并不意味着B端产品设计可以无视视觉体验，近几年随着社会发展，企业用户的审美要求越来越高，因此B端产品对UI设计的要求也越来越严格”）

特点三、强调抽象和逻辑：B端产品背后的业务复杂度高，人员、分工、协作、流程、规则随时可能调整，这就需要产品设计有非常强的抽象能力和逻辑思维，将看似散乱无章的业务抽象出共性，进行合理建模和设计。

特点四、收益难以量化：B端产品要支持、解决业务问题，但业务成效的影响因素非常多，很多时候并非取决于B端产品设计的好坏。例如，采购部门的核心绩效是找到更多优质低价供应商，但这并不取决于采购软件设计的好坏，而更多地依赖于采购员的人脉和专业技能，以及管理考核体系。我们很难直接衡量B端产品上线的新功能对业务价值的贡献。这也是B端产品设计师经常面临的烦恼——难以外化项目效果。

2. B端产品设计师日常工作流程

B端产品设计师的收入其实跟能力是成正比的，从零到一去构建一套B端产品，完成一条业务闭环是非常有挑战的，我们需要从开始的业务梳理、需求管理、竞品分析、产品规划、原型设计再到产品落地进行测试等一些列的工作，既要有产品宏观把控的要求，同时也要对产品细节进行观察，可以说是挑战与机遇并存。

2.1、业务调研

B端产品特点一：B端产品用户群体是某个业务团队或组织，这一组人需要共同协作来完成工作，所以需要B端产品来帮助他们实现分工协作。

因此B端产品最重要的核心就是理清各角色业务，解决业务问题。在项目立项后，我们通常第一件事情就是需要进行业务调研，与C端调研类似，B端业务调研的核心流程就是【明确调研目标】→【确定调研方法】→【执行调研】→【归纳总结】

1. 明确调研目标

B端产品的复杂度高，一般会涉及到多角色参与，并且你们有没有发现，很多后台产品的购买者其实并不是产品的使用者，例如决定使用钉钉打卡的一般是公司领导高层，但他们却往往是不用打卡的（哼！这万恶的资本家），那么在明确调研目标的时候我们应该是应该调研领导高层呢，还是基层员工？

其实无论是领导高层还是基层员工严格来讲都需要进行调研，并且高层与员工之间需求往往并不冲突，很多领导的意见跟员工是差不多的，都希望能够最大限度的提高效率。

针对高管调研我们需要了解核心目标、产品战略定位等，而对于基层员工我们则需要了解整个业务流程，工作的细节。

2. 确定调研方法

B端业务调研的方法跟C端的也差不多，万变不离其宗，无非就是问卷调研、用户访谈、轮岗实习等。这些方法都有各自的特点，我逐一给大家大致解释一下：

方法一：问卷调研

问卷调研是我们最常见的调研方式，特别是线上问卷，我们只需要通过线上给调研对象发送问卷，让对方填写即可，例如你们QQ上右下角经常会出现一个小弹窗内容是：【在吗？填写这个表格给你送10QB】这种，它的好处就是便捷，减少人力资源损耗，但是问卷在设计的时候需要注意一些细节，否则一不小心容易获取错误的信息，适得其反。

细节一：激励用户去完成问卷

还是QQ的例子：【在吗？填写这个表格给你送10QB】，这10QB就是去激励你去填写问卷内容的，要是没有这10QB你觉得用户会花时间进行填写吗？我就试过填写完它还不给我发QB，我当场就把QQ给卸载了。

细节二：注意问题答案的合理性

这里分两点，一点就是问题答案尽量不要超过5个，我见过美团让别人给他打分，然后0—10分一共11个选项摆在你面前让你选择，这用户其实对这零到十的程度是没有概念的，他们不清楚3、4分究竟是属于不满意到什么程度，也不会清楚6、7分是满意还是一般，我们直接换成【满意】【一般】【不满意】即可，太复杂了会影响用户体验；第二点是不要有引导性的问题，例如问题【你喜欢我吗？】然后答案就只有【喜欢】跟【喜欢到爆炸】，这样的设计就特别不合理，不喜欢我的人多得去了，人家就不能选了是吗。

细节三：避免幸存者偏差

就是做调研的对象需要广泛，B端产品涉及的角色非常多，所以做调研的时候需要遍及到各个层面的人群，千万不要以偏概全，以为高层喜欢复杂炫酷的产品就忽视基层一线同学的感受。

方法二：用户访谈

用户访谈其实就是通过一对一的问问题，通过问答的形式在用户身上获取我们需要的信息，最后做好记录。但需要注意的是在访谈前先准备好访谈问题大纲，想清楚需要了解什么内容，提前彩排好，避免现场紧张导致思维混乱，最后搞得双方都尴尬。

访谈结束后最好和访谈对象建立长期联系，特别是业务相关的人员，毕竟访谈时可能会有遗漏的点，如果后续业务流程中遇到问题了，能随时联系，寻群帮助。

方法三：轮岗实习

轮岗实习就是指产品设计师深入一线去体验业务人员的工作流程，这是最好并且有效的方法。（我们公司现在就是用这个方法，导致我动不动就出差。）

做B端产品最忌讳的就是脱离了业务凭自己的主观臆想去做产品设计，业务流程、需求都是通过拍脑袋想象出来，那是完全不可能做好产品的。

举个例子：以前我做UI的时候有个产品经理做一个教育系统，里面有一个安排考生考试的功能模块，老师可以对考生数据进行编排考试，等这个功能模块做出来落地以后才发现现实中老师根本就不能对考生进行安排考试，都是领导安排好，直接做一个EXCEL表格导入数据到后台即可，最后导致几个月的开发时间白白浪费掉，特别的可惜。

因此，我觉得无论我们是产品设计师还是UI设计师也好，如果有机会一定要走到一线去感受我们的用户，不能只是被动的接受需求，沟通是有损耗性的，只有成为那个深入一线真正的了解用户需求，而不是成为那个坐在办公室整天拍脑袋臆想的人，才能值得别人的尊重。

3. 最后归纳总结

刚刚说了我们调研的目的就是为了梳理角色业务流程，解决业务问题，在认真完成调研工作后，我们需要产出一份详细的调研报告去提供我们进行后续的原型设计，而报告一般是需求文档以及角色业务的泳道图（不知道啥是泳道图的看例子）。

需求文档以前已经说过了，然后泳道图，是一种活动图，能够清晰体现出某个动作发生在哪个部门。泳道图在纵向上是部门职能，横向是岗位（其实反过来也行）。绘图元素与传统流程图类似，但在业务流程主体上，通过泳道（纵向条）区分出执行主体，即部门和岗位来。

例如，我以前是做教育业务的，业务流程大概是：【教育局工作人员发布考试】→【考生报名】→【工作人员审核信息】→【审核完成安排考试】→【学生查看自己考试信息准备考试】→【考试结束工作人员安排老师阅卷】→【阅卷老师线上阅卷】→【阅卷完成，考生查看自己成绩】→【最终确认成绩无误】

这就是一个大概的核心流程，我描述的时候已经是最简化了，但看上去还是会很复杂，可一旦使用了泳道图整个时间线与角色任务就清晰多了，并且每一个框框就是一个页面，妈妈再也不用怕我把页面遗漏啦！

2.2、需求管理

在研发SAAS产品的企业中，产品的销售模式一般有两种，第一种就是我们常见的直接把产品出售给客户，根据项目经理与客户沟通好的需求进行交付，最后收取产品费与服务费。

而第二种是你们比较少听说（其实这种才比较常见，可是工作经验少的同学可能少接触），招投标方式，一些企业或者国家机关根据自身需求在网上发出招标文件，符合条件的企业根据自身产品功能写标书，接着提交文件，等到规定时间进行产品演示与专家答疑，最后甲方会在自家网站上公布中标的企业，这就是整个招投标的过程。

至于在这两种模式中如何去进行需求管理，我们先看最简单的，招投标形式：

如果未来大家遇到公司进行产品投标，那么只要在标书上的需求无论大小都需要做，因为投标就跟我们考试一样，一个产品功能模块不达标就相当于丢分，企业产品功能越多意味着无论有没有用都会得分，所以在招投标形式中KANO法则并不管用，更多的是分数为王，工作中我们还是需要给需求排列优先级，从P0—Pn，但是P0需求就是高分的需求，一直到Pn是相对低分数的需求，而分数的高低都会在标书上体现，也就是说甲方已经给我们排列好优先级了，但唯一要注意的点就是我们需要考虑开发难度，并不是越高分就越要冲，就好像考数学题一样，最后的大题固然高分，但我们要是没有能力去做，那就认认真真把前面的小题做好做对，一样不会比别人差。                    

第二种日常产品需求管理：

如果产品从0-1开始研发，我们常用于管理需求的工具是需求池。

需求池顾名思义就是用来放置需求的地方，我们把收集回来的需求放置到需求池中，然后利用就是KANO法则与MVP原则（最小可行产品原则，就是指开发团队通过提供最小化可行产品获取用户反馈，并在这个最小化可行产品上持续快速迭代，直到产品到达一个相对稳定的阶段）去判断每一个需求的优先级，然后编排开发顺序以及需求的负责人 。                

要注意的是，无论需求是项目经理在用户手上获取的还是你亲自进行用户调研都需要深刻思考用户最迫切的痛点是什么，人的本性是贪婪的，我们不能一味的满足用户，如果所有的功能都能实现，那其实我们会什么都想要，我也更想要一台会飞的手机，但事实上就算苹果手机没有做屏幕指纹解锁也并不会影响他们的销量。

此外，B端产品并不像C端那样容易上手，它的目的在于提高用户工作效率，所以产品要是越复杂，用户学习成本就会随之提高，当用户学习成本大于产品带来的工作效率，那这个产品就会失去它存在的意义。

所以在B端产品的需求管理中，我们更多需要思考那些非做不可的需求，把最小可行产品先落地，然后再小步快跑进行产品迭代即可，千万别成为思想的巨人，行动的侏儒，需求是会随着时间而变化的，只有产品落地了我们才能知道哪里不足，快速跟进。                

2.3、竞品分析

竞品分析是我们快速了解业务流程、进行快速借鉴的最好方式，但B端产品与C端产品有很大的区别，B端产品不像C端那样可以从应用市场里找到竞品，或者存在大量的测评或文章，B端产品要找到竞品是非常困难的，因为不同公司的业务流程、模式都不一样，需要的系统也不同，如果真的做，难度非常的大，并且难以在公开渠道获取竞争对手的产品信息，因此很多时候竞品分析时选做的。

但是如果要做，也会有一些渠道能获取到竞品：

1. 寻找同类型的SAAS产品时，可以尝试在竞争对手中获取产品的试用渠道，一般的SAAS产品都会提供试用渠道的，我们可以通过获取试用名额去体验竞争对手的产品，从而分析自家产品优劣，拓宽自己的思路。

2. 
   

3. 与业务同事沟通，在轮岗实习的时候与业务同事进行沟通是否使用过其他同类型的后台产品，问一问出自那个厂家的，有什么特别、好不好用等信息，结束后回家整理信息。

4. 
   

5. 通过搜索信息渠道进行搜索。可以通过【人人都是产品经理】或者【PMCAFF】等渠道搜索有没有相关的文章，又或者找同行业的产品设计师一起沟通经验，这种方法往往是最靠谱也是成长最快的。

6. 
   

以上方法都能帮助你快速找到B端竞品，但是在分析的过程中往往并不是信息太少，而是过多。做产品最重要的倾听用户的真实需求，千万不要以为竞品设计成那样子就符合用户需求，从而蒙蔽了自己的眼睛。

2.4、产品规划

凡事预则立不预则废，很多时候我们在做原型设计前都必须先对产品的整体框架进行规划，特别是像B端产品那样多角色并且业务复杂的系统，否则当我们在做原型设计的时候会手忙脚乱，不知所措。

B端产品中，产品规划要完成的工作一般是产品信息架构设计、角色权限梳理以及数据埋点方案等，我把一些工作的重点介绍一下：

产品信息架构：

B端产品信息架构设计与C端产品类似，我们上面已经得出了业务流程的泳道图，知道了产品大致有哪些页面，而信息架构则需要具体到产品的一级菜单、二级菜单有哪些、每一个页面中需要哪一些操作（后台系统一般的操作几乎都是增删改查以及导入导出），并且每一个页面中需要哪一些字段等都要在产品信息架构中体现，这样我们就能很直观的看到整个产品的大概是否合理，方便及时调整。

例如在考勤系统中，考勤工作人员在考勤记录中可以查看的字段是考勤姓名、身份证、第一次考勤时间、第二次考勤时间、考勤状态，而在考勤设置页面就可以设置考勤组、班次管理、考勤规则等，这些细节都可以像我一样全部细化到信息架构中，而信息架构的深度和广度大家我上次已经讲过如何分析，这里就不再重复叙述了。                

角色权限梳理：

B端产品特点三：强调抽象和逻辑：B端产品背后的业务复杂度高，人员、分工、协作、流程、规则随时可能调整，B端产品是涉及到多角色共同去完成任务的，并且业务也相当复杂，这是B端产品与C端产品最大的区别。

我们在设计功能模块时，所有的功能都是在同一个后台系统中的，而不同角色登录系统后能够查看那些页面就是根据我们角色权限梳理好后进行权限配置的，因此在规划阶段我们需要先理清系统各角色的权限有哪些，然后记录下来进行后续配置，而这些都是考验我们前期业务调研是否足够认真细致。

在人员角色权限表格中，一般横坐标为角色，纵坐标为权限，圈代表有对应的权限，叉就代表没有该权限，这样我们就把抽象的业务画成图标，后续进行角色权限配置。

数据埋点方案

什么是数据埋点

数据埋点就是在系统中利用特定的流程去收集一些信息，用来跟踪应用使用的状况，后续用来进一步优化产品或是提供运营的数据支撑，通常包括访问数，访客数，停留时长，页面浏览数和跳出率等。

简单来讲就是我们面试时候经常提到进行数据分析，根据数据进行迭代优化，而这些数据就是根据我们的数据埋点来进行收集的（不然你们以为有时候做大数据页面时里面的数据是开发同学自动收集给你的吗？）。

现在数据埋点的主流方法有两种：

第一种是自己公司开发同学在产品中注入代码进行统计，并且搭建公司相应的后台进行查询（就是大数据页面），这种一般是大公司或者统计量不大的系统常用的做法，因为自己研发可避免数据透露给第三方，相对安全。

而第二种就是利用第三方工具进行统计，他们会提供一小段唯一的JavaScript代码片段注入系统的一个公共JavaScript文件中即可，工作量非常小，部署十分方便，随后他们就会提供统计后台给我们查看数据信息，在这个过程中，我们其实只需要出好埋点方案，告诉开发同学需要统计那些数据即可。

例如你发一条朋友圈想统计点赞率，那么需要统计的数据就是每有一个朋友点赞就记录一个，最后一共50个朋友点赞那点赞数就是50，假如你的朋友总数为300，那么点赞率就是【点赞数】/【朋友总数】=50/300=16.7%，那你就可以判断这个人的人缘一般，不像我，我的点赞率都是95%左右，人见人爱你懂吧。

目前国内的第三方数据埋点工具特别多，例如GrowingIO、百度统计、神策等，对于后台数据统计，百度统计会比较专业一点，而他们每一家的优劣点我这里就不逐一展开描述了，有兴趣的同学可以自己探索一下（估计你们也没有兴趣）。                

2.5、原型设计

当我们完成了信息架构、角色梳理、数据埋点等一些列前期的产品规划工作后，原型设计其实已经呼之欲出了，我们更多的是把框架画成产品页面，最后完善细节。

B端产品原型设计时需要注意的点（PS：本人主要用Axure进行设计，所以这里观点也针对Axure，其他软件我没用过，不多做评价）：

1. B端产品跟C端不一样，B端产品大部分都是网页，所以使用Axure进行设计时，一个Axure页面就对应系统中的一个页面，页面间利用连接进行跳转，弹窗则利用Axure的显示隐藏功能，一般没有特殊要求，不需要用中继器等复杂的控件。

2、B端系统大部分页面虽然都是表格，但是不代表可以随意糊弄即可。如果公司没有规定模板的话，可以直接使用Element或者是Ant design提供的Axure后台模板，我之前的文章也有提供后台的元件库模板，必须善于利用模板，设计时做到简洁统一，避免相同控件样式都不一样，显得特别不专业。

3、尼尔森十大可用性原则在B端设计真的很有用，需要常记在心。统一性、灵活性、防错性等等..尼尔森十大可用性原则在B端产品的地位非常的重要，我以前一直想写一篇尼尔森十大可用性原则在B端产品中的使用，但是现在网上关于这个的文章到处都是，所以大家千万不要看了就忘，一定要灵活运用在设计当中。

4、整个产品必须要完成业务闭环！！我知道很多同学是UI设计师转岗到B端设计的，在逻辑思维上可能并没有特别灵活，但是B端产品的功能模块是环环相扣的，我们设计出来的产品必须要做到业务闭环，不能有多余的字段或者多余的功能，用户走到最后完成不了最终业务，这是作为一个B端产品设计师最致命的。

原型设计的重难点—权限设计

在角色业务梳理的时候我们已经说过了，B端产品是涉及多角色共同完成业务的系统，权限设计就是设计师通过合理的设计，然后去配置不同角色拥有各自的页面与操作，从而能够进行各角色能够有条不絮的进行操作的能力。

权限设计是B端产品最重要的环节，也是很多B端产品设计师面试重点考题。

有细心的设计师一定会发现，无论看不看得懂系统都好，每一个后台只要是管理员账号都会有一个叫【系统管理】的功能模块，而这个模块正式用于权限管理的设置。

一般软件系统中用户的权限包含三部分：菜单权限、操作权限以及数据权限。

菜单权限是指这个用户账号能不能查看这页面，例如考勤管理员能够对考勤进行设置，那么他就有这个页面，普通员工没有该页面，那他就没有对应的页面权限。

操作权限是指用户有没有增删改查或者其他按钮操作，例如管理员能把张三进行删除，那么他就有删除的操作权限，注意的是，操作权限是在菜单权限之下的，试想，如果你连页面都没有，那就别谈操作按钮了。

数据权限指的是各个角色在每一个页面中能看到的数据范围，例如广东省管理员就只能看到广东省的人员数据，就不能查看隔壁福建省的人员，不然这口水都得流出来了。

在权限设计时，我们常用到RBAC权限模型，RBAC是目前已经成熟的后台权限模型。在传统模型中，我们会直接把权限赋予给用户，而在RBAC模型的概念则是把权限赋予给角色，再把角色赋予给用户，把角色作为桥梁并且重复利用起来。

RBAC模型的玩法特别多，在页面上测呈现方式会根据实际业务不同而有所改变，但是万变不离其宗，因为内容太多且抽象，这里不细深入，大家如果想进阶成为B端产品设计师的话，欢迎来一起探讨。

2.6、数据分析

还记得我曾经说过，任何事情都注意闭环，而数据分析分析就是整个产品设计的闭环环节。

我们从需求调研获取需求，到管理需求、竞品分析、产品规划、原型设计再到产品落地后数据分析，再根据数据结果去得出结论获取新需求做下一次的迭代，如此循环把产品做得越来越好。

在产品规划时，我们已经做好了埋点方案，等到产品落地运营后即可通过数据后台查看相应的数据，数据分析的方法论很多，像GMV、点击率、转化率等。我这里列举一些例子，例如像我们写公众号的，就会查看文章点击率，例如粉丝1W，点击率才只有1K，那么这篇文章的点击率就是10%，而点赞率就是点赞数假如只有200，那点赞率就是200/1000=20%。

再比如你设计了一个功能后，从以前用户购买商品率的20%提高到现在的50%，那么这个功能就是成功的设计，可以进行下一步的迭代争取提高到80%。

大家千万别小看这些数据，对于一些大企业来讲百分之一的转化率可能就是上亿的营业额，并且这些数据也是将来我们跳槽涨薪时最有力的武器，做产品设计最重要的就是数据，它很多时候就代表着我们的工作能力。

3. 最后总结

其实无论是B端还是C端产品，设计师都发挥着至关重要的作用，仅仅是侧重点不同而已，除了上述工作，B端产品设计师往往也要负责产品落地后的产品培训以及收集反馈信息等，工作中越是处于产品的上游就越考验我们的软实力。虽然看上去我们需要掌握的技能很多，但真正重要的知识，或者在实践中被反复使用的知识，只占全部知识的20%。换句话说，B端产品设计要在培养自己的技能时，着重搭建知识骨架——20%的知识。20%的知识是固态的，是根本和基础；80%的知识是液态的，是不断更新、动态变化的。 

还有就是很多设计师都吐槽B端产品都是表格，难以展现设计师的实力，但我却认为B端产品的乐趣并不在于他的形式，而在于他的逻辑，如果你仅仅是看到他都是表格而忽视了系统真正实际的作用，那你就难以成为一位合格的B端产品设计师。

好了，文章的最后希望大家有所收获，如果有所疑问或者需要一起探讨的欢迎留言或者联系我，很高兴与大家一起学习，共勉~

Powered by Froala Editor