监级干货！3个章节帮你完全掌握B端设计师的工作内容

这一篇
 ，则只聚焦 B 端设计的完全具体内容进行介绍。

一、掌握B 端设计的设计师分析过程

虽然 B 端设计简单概括起来就是完成相应 B 端产品界面设计，但这只是内容一个很宽泛的解释 ，想要学习 B 端设计就要更进一步了解 B 端设计的监级节帮具体工作有哪些。

这首先涉及到对 B 端项目开发流程的干货个章工作理解，因为 B 端设计不是完全一个孤立的工作，而要完成项目中上游给出的掌握任务  ，再将设计成果交付给下游。设计师简单说就是内容完成设计任务  ，交付设计成果
。监级节帮

首先讨论设计需求怎么来的，一个正常的项目设计需求不会是直接产生的（设计迭代项目除外），通常需要经过一定的转化 。

这个转化的流程如大致如下所示 ：

立项就是确定要开展项目的决策过程
，领导层会确定一个项目大概要实现什么目标，解决哪些问题 。但这些决策都是比较宏观的，具体要做什么功能，每个功能包含的逻辑就要由产品经理去整理。

但 B 端的产品需求不是由产品经理拍脑门想出来的，它得符合业务的需要 。比如做一个仓储管理工具要包含货物入库的记录 ，但货物入库不是只发生在数字系统内的，而是真的要把商品运到相关仓库并摆上指定货架 
，然后再在系统上添加这条数据 。

所以产品经理就得去研究具体业务的细节，货品怎么运的，谁搬进去并负责验收的 
，最后记录添加谁执行的
，以及货品和仓库本身有哪些数据、信息是需要记录的等等。

了解完业务的要求，产品经理才能构思具体产品要放什么东西 ，这里还会参杂很多其它的考量，比如老板/客户要求，竞品的做法 ，员工的建议等。在综合分析各方面因素以后 ，产品经理再做出产品具体应该做哪些功能的决策，并设计原型编写功能说明（不一定有）。

产品需求不是产品经理自娱自乐的，这些需求信息等于设计师和程序员的工作任务 。虽然会有需求评审会议来解释产品的功能和设计的要求，但会议往往只有个大概 ，细节还是要靠自己会后去看。

而 B 端产品需求的特点之一 ，就是抽象……因为产品需求是围绕业务搭建的，而需求中的说明却很少能把面向业务讲明白
，于是就有很多功能点和交互要求是看不懂的 。

原则上只要产品给足够清晰的原型 ，设计师对着原型做设计够了。但如果对需求理解得不够彻底，是做不好设计和交互的。再者 ，实际工作中产品给到的需求说明往往非常的潦草 ，有大量内容时空缺的
，得设计师自己去填……

形成这个结果的原因有很多（主要是产品菜），后面会另外讨论 。但想要继续完成工作，设计师就需要进行—— 业务和需求的分析，也就是对着产品经理给到的需求去逆推业务要求和完整的功能逻辑。

这种工作很多人误以为是产品的工作 ，实际这和产品做的业务、需求分析是不同的，他做的是决策 ，而设计师做的分析是更准确地了解他的决策 。

我们换个场景解释，比如在室内设计需求中 ，客户给的房型规划草图上出现了开放厕所连着开放厨房的抽象需求，作为设计师 ，要做这么奇怪的设计就肯定得去了解他们想要那么做的原因（业务分析） ，然后再思考这么做的可行性和其它细节（需求分析）
，然后才会动手进行正式的设计。

这是 B 端设计分析优先级最高的事情
 ，了解我们工作的内容 ，而这对于程序员来说同样重要。很多外行可能会觉得这个步骤不合理 ，效率非常低，但这就是真实的项目环境 
，由一系列客观因素引发的工作阻力
，可以反感它但不是忽视它。

完成工作内容的分析外，B 端设计师还可能展开其它的分析步骤
，包括排期分析
、竞品分析、用户分析 、体验分析等等 。

要做什么额外的分析工作和项目要求、场景有关 ，不会凭空去做分析或是每次项目都按照一个固定的复杂流程执行 ，而这些分析的目标都是为了得出结论 ，对后续的设计形成指导意见 。

分析的细节就不在这里展开了 
，但有一点可以肯定的是，B 端分析中对体验、用户相关的内容占比是远远比 C 端低的。因为 C 端产品是服务用户的，而 B 端产品是服务业务的，B 端用户也只现实业务目标的一部分，比如公司招销售再给他们配置企业版微信 ，只是为了让销售快乐的吗？

分析的目标是为了执行做准备 ，是任何工作都应该开展的前置工作，不要只看网上的过度包装而单纯地将它们归类为形式主义和面子工程。

二、B 端的具体设计内容

完成前期的设计分析，下一步就要正式进行设计实践了。而 B 端界面设计的主要内容
，包含三个主要的部分 ：

1. 交互设计
2. 视觉设计
3. 运营设计

1. B 端的交互设计

交互设计，就是设计产品中不同功能的具体操作方式 。比如如何进入不同下级页面，如何完成表格的筛选，如何完成信息的编辑等等
。

通常交互的设计会使用线框图原型和连线注释来表示 ，但因为 B 端的视觉设计整体较为简单
，所以往往会两者混到一起设计，再一起交付和评审 。

但这并不代表交互和设计是一体的
，在 B 端设计的评审中
，团队对设计的重视更多集中在交互的合理性上，而不是视觉的美观度 。

比如下图案例 ，需求是在这个页面中展示指定工作车辆的轨迹
、任务
、节点、事件，还要展示若干关键的信息。不管设计师把视觉做成什么样 ，都要优先满足可用、易操作的要求 
。

除了整个页面的交互
，还包括很多组件模块的复杂交互，比如下图案例中，要增加自定义筛选列表信息的功能
，筛选条目不限，筛选内容 、规则自己决定。设计师的主要任务也是设计出满足各类操作需要的交互方式 ，而不是先想着怎么做才好看。

前文就说过，B 端的业务种类庞大、细节繁复，落实到产品层面就会出现很多抽象的、非常规的功能逻辑。这些需求是没有参考的
，所以需要有人去做出合理的方案，并给出细节和规则。

交互是 B 端设计中最重要且最有价值的部分
，而这主要是 B 端设计师的工作
 ，不是产品经理的。

2. B 端的视觉设计

B 端视觉设计即 B 端产品整体视觉内容  、要素的设计，这不是单指界面设计
，还包括品牌
、规范、动效、图标等视觉内容的设计。

首先说界面设计
，除大屏外 B 端界面的设计实际上非常简单，因为使用的视觉样式都偏基础，且页面的种类和版式也很固定，比如下面这些 ：

这种简单代表没有门槛，首先要将复杂的信息以简约、严肃、整齐的样式呈现出来 ，确实是需要一定专业性支撑的 。

另一个因素就是，B 端项目追求低成本 ，高开发效率 。而 B 端项目中包含的海量页面往往重复性又非常高 ，所以设计师如果重复去设计一样的内容，是没有效率可言的。

为了解决这种问题，B 端项目就非常依赖设计规范和组件库的应用 。但并不是指完全使用外部的第三方库（后面会单独说） 
，而是基于自己项目搭建的规范和组件库。

所以 B 端设计师最重要的视觉设计工作 ，是围绕最终界面设计的需要，去定义可用的 、详细的  、专业的规范内容，并在规范中融入项目的特征和品牌性，而最终得界面视觉只是规范的附加物
。

除了界面外
，动效和图标也是视觉的产出物。但是 B 端中对动效的使用要求并不高，因为这会增加额外的开发成本 。所以即使使用动效也会选择最简单的效果类型，而不是网上飞机稿展示的复杂动画特效。

B 端动效只在必要时增加 ，和 C 端动效不同的是，B 端动效更关注整体性和合理性，所以需要更深入在动效本身参数的调节和场景限制上。

最后就是图标的设计，虽然 B 端图标设计没有 C 端那么花哨，但在项目中往往会出现很多很复杂的工具图标寓意 ，就需要设计师自己构思图形并进行设计 。

除了一般图标外，国外 B 端产品的 3D 图标上镜率也很高，因为 B 端项目的决策者往往都非常迷恋“科技感” ，所以设计师要投其所好就会添加 3D 图标元素增加科技氛围。

但除了大屏
，3D 元素的应用频率是非常低的，它们只是边角料而不是设计的主体 。经过这几年的发展，这类 3D 素材已经非常庞大，可帮助设计师快速完成相关图标的引用和设计。而不是忽视设计的主题投入大量的精力去完成边角料的工作。

3. B 端的运营设计

对于 B 端来说也有运营设计的需求，而这分两种情况出现 。

第一种就是提供 SaaS 类服务的 B 端项目 ，项目本身是要拿来卖的 ，要面向外部的客户。所以需要设计对外的官网，以及类似 C 端搞促销和不同主题的活动物料。

另一种情况，则是企业日常运营中的设计需要
，比如开一些讲座
、商业论坛  、内部活动、宣发路演等，也会让 B 端设计师来设计相应的物料内容，如广告牌、背景墙
、PPT 、邀请函、手册等。

除了这些内容
，只不准也还会有其它偏平面的设计需求。因为 B 端产品的团队往往规模比较小（节省成本），所以很少会配置专属的平面设计师
，而这部分需求自然是交给 UI 设计师完成。

但相较 C 端行业来说
，B 端平面的输出要求偏商务、正式，所以不需要那么花哨，对技术要求也比较低，更容易学习和输出。

三、B 端设计的交付跟进

对于所有设计行业来说，完成设计稿都不代表设计工作结束了，还要完成对它的交付，以及跟进设计的具体实施。

在 B 端设计行业，设计师在完成项目设计以后
，要将设计稿交付给程序员
，包括交互说明 
、规范文档 、界面样式 ，以及界面的标注和切图
 。

前面三个都是把已经做好的内容整理好发送给程序员 ，或者在云服务产品中添加程序员的账号让他们直接访问即可 ，比较容易解决，而标注和切图却是最复杂也最关键的部分。

标注就是提供设计稿中的属性参数
，以及对一些特定功能
、交互、设计细节的说明 ，让程序员可以准确的还原设计稿中的内容。

切图则是提供界面中无法用代码实现的图形文件，比如图标 、背景图、特殊标签、等级勋章等图形 ，让程序员将它们置入到真实页面中去。

交付方式越合理，则开发出来的界面效果越准确，反之则问题越多 。但多数初级 B 端 UI 设计师只简单的将标注和切图步骤理解成是将设计稿上传到蓝湖中去，而并不懂如何控制标注和切图的细节，所以导致最终开发效果和设计稿相去甚远（这个以后有空也会另说） 。

即使提供了标注和切图，收尾的工作也还没结束 。一方面开发过程中程序员会产生一系列的疑问，或发现设计稿中的各种问题 ，于是设计师就需要进行解释
，或优化设计稿。

另一方面  ，开发即使把界面做完以后，也不会直接上线，会进入“内部测试”的环节，也就是内部测试可用性和找出问题的阶段 。

测试可用性找 BUG 主要是测试工程师 QA 和产品的工作，但设计师也不能置身事外，因为已实现界面的样式会和设计稿存在大量的偏差（就前面说的问题），设计师需要把偏差找出来 ，并提交问题给程序员进行修复 ，并检查修复后的结果。

我们称这个步骤为 —— 设计还原度测试。对于界面设计要求高的团队 ，在这个阶段要耗费的精力和时间是最多的
，因为设计到开发的转化有大量的参数和细节要做匹配 ，所以错误会层出不穷，这就要检验设计师和工程师的耐心程度了。

完成测试工作以后 ，项目就部署上线了
，设计师当前项目的工作就结束了 ，开始下一个项目或迭代的轮回
！

结尾

以上就是 B 端设计师的主要工作内容，虽然举例以网页管理界面为主，但除了大屏项目外，不管是 B 端移动端还是桌面端、定制设备上的设计流程和设计内容都大体相同 。

一个优秀的 B 端 UI 设计师，一定是具备围绕项目目标统筹全局提高项目开发、使用效率的多面手 ，而不是光画界面和拼组件的产品原型填图工。

作者 ：超人的电话亭