转行B端，设计师快速入职指南

阿琦Aqi 2023-10-19 19:49:19

大家好，我是阿琦Aqi。我以前是一个C端设计师，2012年的时候进入了华为外包，开始了B端的职业生涯。结合近10年的B端设计实践和经验，我梳理了一下C端、平面设计师转为B端设计师所遇到的问题和挑战，帮助大家快速了解B端设计师及设计流程。

C端或者平面设计师转行B端设计师后，肯定会有很多的不习惯，我先简单的介绍一下B端。

一、认识B端

第一是媒介形式的不同。如果C端以手机为代表、平面以纸质广告和户外广告为代表的话，那么B端产品的主要呈现媒介是PC端或者是大屏，包含本地客户端和网页。

第二是面向用户不同。B端产品主要面向的是企业用户，企业通过B端平台来管理用户，运营和维护自己的商业活动。

第三是社会发展现状的需要。如果是前10年是移动互联网化，那么这10年就是企业互联网化。正是有了前10年基于移动端的技术和用户根基，企业互联网才发展非常迅猛。同时，越来越多的企业都意识到降本增效的重要性，都开始对既有的业务进行改造升级，以减少人力成本。

二、B端的特性

2.1复杂性

如果说C端是在解决一个问题，那么B端就是解决一堆问题。

你打开一个B端平台，会发现很多的业务，你随便点开一个业务，会发现有很多的功能。然后这个时候你有点崩溃了。不夸张的说，一个中等的B端系统有几百几千个功能是非常常态化的。

B端的复杂性还跟企业主体有关，每个企业的流程、业务即使完全相同，也会在审批、权限、角色等方面不尽相同。

B端的复杂性，要求产品或者交互设计师能够清晰地梳理业务逻辑，并将业务流程化、可视化。

2.2 B端的专业性

B端系统是专业的、垂直的，他是以企业的业务为基础的，旨在解决企业业务中的各种问题。

2.3 B端设计的误区

追求极致的用户体验。B端设计的目的首先是达成任务目标，切不可一味的追求用户体验。

以“你”为中心的用户视角。B端的用户涉及到管理员、使用者、操作者，用户体验存在于各个角色之间，不同的角色，使用习惯和路径存在差别。你可以沉浸式的去体验每个角色之间的差别，切不可用“我觉得”去设计，一定要基于数据和业界既有经验的参考。

三、如何快速熟悉B端产品

3.1借助产品经理快速熟悉和融合业务

刚入职，一般更多的是熟悉，团队领导也不会立即马上让你接手一个大的项目。所以在入职1-2周内，你需要把所在设计部门接触到的产品的B端平台先熟悉起来。表面上看1-2周的时间比较的长，其实很快就过去了，你需要有侧重点、有路径、有方法地去安排熟悉产品的计划，否则两周过去了，你可能才了解产品的冰山一角。

B端系统的庞大，决定了B端设计的复杂。如果想成为一名优秀的B端设计师，那么请你多跟产品喝喝茶，跟业务方聊聊天，在B端路径的前沿就要想着把需求了解清楚了解透彻。

产品经理掌管平台大小功能，基本上对平台的脉络都很清楚。借助于产品经理的帮助，你可以比较快的了解到产品经理负责的模块和业务。

一般入职后，产品经理会跟你全盘都陈述一下，所以你要抓住这次机会好好了解，后面可能就比较少有这么全面的一对一指导了，因为他们可能觉得你已经都懂了。

3.2借助测试人员跑通整个平台功能

第一，平台功能和业务可以询问测试人员。对公司产品第二熟悉的应该是测试了，测试人员在测试过程中可能都连一个角落都不放过。从每一次上线版本功能的跑通，测试用例的编写，到平台Bug的提交，测试对整个平台算是非常熟悉了。所以你想了解平台功能，也可以找测试人员帮忙。

第二，通过测试账号快速了解平台功能。你可以跟测试人员要一个线上环境的账号和测试环境的账号。线上环境的账号是真实的发布后的效果，测试环境可能包含尚且没有发布的版本，属于内部最新的环境。

第三，分角色带入式体验平台功能。B端跟C端不一样，C端可能最终呈现就是手机，而你就是直接用户。但是B端不一样，他存在于商业路径上的各个角色中，所以如果允许的话，最好要一个超级管理员账号，可以查看到所有功能。

按照不同的角色，将自己带入，感受当前角色下的功能。

第一遍带入体验，你可以漫无目的的查看当前角色下的功能，以增加对他的熟悉。

后面需要我们有目的的去查看。譬如我们想实现业务中的某一个功能，那么我们看看如何操作、如何到达、过程中有没有觉得可以进一步优化的地方。

如果有充分的时间，你也可以多跟测试人员沟通，了解测试用例，把测试用例跑一遍，以更深入的了解到平台功能。

四、参与B端项目立项

B端产品设计师，在入职后拿到的第一个相关的设计，可能是平台某一个版本的迭代升级，也可能是大平台中的一个功能。

项目立项，一般是产品经理牵头，约一个会议室，然后组织项目经理、交互设计师、视觉设计师、前端开发人员、后端开发人员、架构师等进行参会讨论。会议上，产品经理会把本次开发的版本需求进行陈述，明确版本上线的功能，然后让各个部门协助评估工时和人天。

即使是新入职的设计师，我们在前期对产品进行熟悉后，在接到这种小版本需求的时候就不用感到很紧张了。会议后，产品经理会拉群把需求发到群里给大家详细查阅。我们需要根据需求文档，看一下需求稿转化成交互原型、再到视觉效果图、切图以及上线前的还原度走查所需要的时间。

设计师要求：评估工时。需要你准确给出设计所需要的时间，别忘了把切图和还原度的时间也算上去。还原度是最重要的事情，需要的时间可能会占设计时间的二分之一。假设你评估当前版本需求视觉设计需要6人天，那么提供切图1人天，还原度走查3人天，总共视觉设计需要10人天。

五、项目启动及设计任务开展

项目启动后，可能是新的版本需求，如果之前的平台功能没有类似功能或者之前的操作体验非常不好需要优化，我们可以展开脑暴，从自身产品出发，如果想实现类似的功能，应该怎么设计。多脑暴出几个交互设计方案以达到目的。

再脑暴出2-3个设计方案后，我们可以去查看友商的相似功能的操作。有什么优点和缺点？有没有更加直观？操作有没有更加便捷？对比友商平台后，我们再反过来看一下自己的想法，进行优化和调整。对比竞品的目的：一是吸取对方的优点，二是保留主流的、用户形成习惯的操作，避免用户犯错。

设计过程中，对既有的平台组件库你可以加以利用，对新的操作行为你可以进行创新。我们一定要以业务功能实现为目的，在开发能力、项目开发周期允许的范围内进行设计，不可过分追求完美主义。

六、设计评审

6.1 交互设计评审

首先要评审的是交互原型。交互设计师需要组织评审会议，定好会议室，通知项目经理、产品经理、前端开发人员、后端开发人员、架构师等参会。

交互原型是比较重要的一环，如果产品经理提供的需求文档是文字需求的话，这里的交互原型就可以清晰地看到文字转化为可视化图形了。

交互原型中，你可以清晰的看到页面跳转逻辑、不同功能划分。交互设计师可以根据需求文档对每一个功能点进行操作演示和陈述。参会人员有不懂直接提问，交互设计师进行解答，解答过程中记录下需要修改的地方。

交互设计师在某一个功能点尤其是新的功能点进行陈述的时候，可以截取部分竞品加以对比，展示出自己在设计中做出的优化。这么做的好处：一是让开发等相关人员了解竞品情况，第二是给设计提供有力的支撑以促使评审顺利通过。

第一次的评审可能占用的时间比较多，如果修改比较大可以再组织第二次评审，如果比较小，可以单独找相关人员直接沟通和确认。

评审技巧

1、交互设计师在评审过程中尽量保持黑白色设计，不用加以颜色修饰，避免颜色修饰给其他人造成干扰，因为我们此次评审的目的就是功能实现和操作体验。

2、交互设计师可以在评审会议召开前找相关人员进行提前沟通，这样做的好处可以让大家在会议开始前就已经对设计有一定的认知，会议过程中提出的问题基本上都是小问题了，从而大幅减少开会时间，提高开会达成效率。

6.2视觉设计评审

交互原型定稿后，视觉设计师可以展开设计了。

视觉设计师和交互设计师是相通的，视觉设计师同样需要脑暴和参考竞品。因为是B端平台，风格基本是既定的，除非是平台非常大的改版，所以视觉设计师可以集中性的去脑暴相关功能的设计。同时，查找相关竞品，了解竞品在呈现、点击触发后的所有界面展示效果。

结合组件库、前期的脑暴和竞品参考，视觉设计师就可以进行出图了。

视觉稿完成后同样按照交互设计师的评审流程进行视觉稿评审。相关技巧也同样参考交互设计师。

七、还原度走查

什么是还原度？通俗来说就是指前端开发出的页面效果还原视觉设计稿的程度。这里通俗来说是前端人员负责界面的搭建，也不排除有部分后端人员参与界面搭建。

还原度走查这份工作，可以说是细腻的也是残酷的，走查过程中会遇到各种揪心的甚至是言语上的冲突。

所以，
还原度走查超级技巧，请做到如下：

第一，一定要控制好自己的情绪。因为刚出来的界面效果，是前端工程师为了上线赶出来的，会跟视觉稿差很多。所以请你客观冷静对待，不要焦虑着急，也不要有任何的情绪反应，最重要的是不要灰心。

从开发的角度来说，实现功能和逻辑是他们主要的精力投入，不是说他们不认真，他们需要在版本上线前保证功能的正常使用。

与设计师接触比较多的是前端工程师，和前端同学搞好关系，可以给还原度走查提供很大的帮助。

第二，还原度文档撰写。按照角色，按照操作路径，有条不紊的梳理每个流程上的界面的问题，对界面进行标注，并告知前端开发人员如何修改。所有问题进行编号，记录到文档中。

第三，界面调整。跟前端开发人员确认修改时间，尽量让他们留出一下午或者某一段时间用来集中性的处理你的还原度问题。前端开发人员改好发版后，你要对测试环境中的界面进行二次走查，检查前一轮问题是否已经ok，有没有新的问题，如果有需要再次记录并安排修改。直到走查达到90分才可以上线，比较难的或者历史性不好修改的问题可以迭代到下一轮版本。

第四，表扬信。走查环境过后，一定要大张旗鼓（邮件形式）地对本次走查进行邮件感谢，抄送项目相关人员，明确本次走查分数，修改问题多少，已解决问题多少，需要下次版本协助的问题是什么。这是软件或者开发质量管理的流程，也是对其他人员参与帮助的感谢。