B端设计师价值体现

深圳/设计爱好者/5年前/828浏览

版权

B端设计师价值体现

负责做过项目管理系统、crm系统、css系统的UI和交互设计，对b端产品的认知也越来越深，聊聊b端产品设计师如何体现自己的价值。

刚开始接触B端产品设计的的时候，觉得这类产品没什么太大的设计意义和乐趣，页面布局、交互样式跳不开前端框架的限制，设计的好坏也无法像c端产品那样通过转化率直观展示出来，直接推动产品功能迭代的阻力也大，在团队里设计师的角色也貌似没有开发和产品那样受到重视。B类产品中的运营属性也没有C类产品那么强，做久了总有种没什么成长的感觉，那么B类产品设计师该怎么做才能提升自己的能力，体现设计师在团队的价值呢？

前期调研

C端产品可以清晰的定义用户画像，业务逻辑相对简单，需求易于理解，设计的可发挥性更强。

B端产品从使用对象角度可简单的分为两种：

对内使用，即直接面向公司内部人员，产品周期走势与公司业务是强关联的，需求直接来源于业务，可以直观的定义用户特征、用户需求，产品功能定制化特性强，但是完全由业务驱动会导致需求变动会非常频繁；
对外使用，也就是某一行业通用的产品，如企业办公协作平台、客服系统、crm系统、财务系统等，面向的是公司决策层、管理层、执行层，产品功能要兼顾行业通用属性也要兼顾企业个性化需求，市面上往往有相应的竞品可分析和参考，这类产品用户调研的难度会增大，往往是公司决策层满意了产品才会引入到公司让员工使用，而这不同角色对产品的期待和定位会不一样。

所以B端产品设计之前需要做好前期调研，产品经理要深入了解行业现状、痛点、竞品、业务流程、产品期望，设计师要深入了解用户职业特性、行业特性、业务流程、产品期望。

定义用户画像

设计师要关注用户职业特征，多做用户访谈，包括决策层、管理层、执行层，了解他们的工作习惯、行业心理感受，工作环境。由于B端设计师不是产品的用户，无法和用户处在相同的场景中，最好能实地观察用户操作习惯。不同角色的用户画像，对系统的需求不一样，系统的使用权限也会不一样，这些是系统的权限控制和使用体验差异化的设计依据。

用户使用系统的时长、环境对产品会有不同的需求：

使用时间短：只为了完成一些特定任务去使用系统的特定功能，操作路径要避免繁琐，效率是根本，能一步操作完的就不要分两步；
使用时间长：上班开始到下班结束都要在系统上操作，除了高效还需要关注使用者的情绪，设计的时候需要注意视觉疲劳度和情绪愉悦度。

之前做crm系统的时候有涉及到电销（电话销售）部分，去用户工作场所观察过他们的工作环境和使用习惯，真正感受到了销售之间的竞争和压力。员工分了很多小组，小组的名字和墙上的标语都是虎狼之词，每个小组中有一人打通了客户的电话，整个小组都鼓掌，整体工作环境就是弥漫通话的声音、此起披伏的掌声、组长的宣言，他们面临业务指标、客户挂断电话等负面情绪，都要及时整理好心情，我调研的时候都不好意思太打扰他们，就坐在旁边听观察他们，必要的时候问些问题，当时我就问我自己我要是在这种环境下工作会是什么样的心态。

针对以上提出几个建议：

视觉感受：系统的色彩、界面风格从体验视角出发让设计有理可依。如设计客服系统时考虑到工作环境、使用时长从护眼和情感化角度考虑颜色、文案、插画元素；
场景驱动：同样的元素在不同使用场景和操作频率下会有不同的呈现方式，如筛选框，需要高频用到的筛选框直观的展示出来，低频用到的收纳起来；
情感诉求：工具类的产品通过情感化文案、音效、插画、新手引导为产品赋予温度；
实地访谈：观察在自然状态下用户是如何完成工作任务的，记录下发现点和疑惑点，也可以体验一下用户的实际工作，记录自己的真实体验和感受。

定义产品骨架

通过业务流程、用户使用习惯衡量系统信息布局，确定是以功能维度还是业务维度搭建产品骨架，以项目管理系统为例：

以功能维度：功能之间结构扁平层层递进，相互独立，用户对于产品功能很直观能快速的找到相应的功能，但是功能点会过于琐碎不便于观察项目的生命周期；
以业务维度：根据业务流程布局产品骨架，模块之间互有逻辑关联，能直观的看到一个项目的生命周期，但是操作路径会更复杂，需要对业务流程熟悉才能快速定位相应功能。

两种模式各有优劣，要以实际场景进行选择。用户使用系统的偏好也会受到日常工作中管理项目的习惯影响。这一点我们在做内部使用的项目管理系统也是踩过坑的，初版采用以功能维度进行布局，当时对接的项目经理认并没有对此产生异议，产品迭代过程中系统功能越来越多，项目的各个业务模块散落在不同的功能模块下，公司的业务发展更加注重项目回款、项目生命周期管理，这套架构已经不能很好的满足项目经理的需求。后期换了对接的项目经理沟通中发现他们在自己电脑上管理项目的文件夹都是项目名称命名，文件夹里的项目资料是根据项目阶段分类的，他们管理项目的习惯和系统管理项目的方式是不贴合的，据此我们对系统进行改版，以项目维度进行布局，上线后项目经理反馈管理项目更加方便和智能化，代替了不少纯手工的活，对于项目进度的把控力更强。

左图是sasaleforce系统导航是以业务维度展开的，从左到右依次是业务流程的走向；右图是功能维度，相似业务集合在一个功能模块下，常见XX中心，XX管理

确定系统内容布局，再根据页面的信息的承载量，考虑是否需要对原生的框架进行改造以适用业务，信息量大需要追求屏效比，让有限的屏幕承载更大的信息量，适当调整下导航，信息量比较少，那么可以个性化布局，创意发挥的空间就比较大。信息布局时要做好最小屏幕的适配，对于信息量很大，尤其是很多表格类的组件考虑到iPad的尺寸就好，适配手机的意义不大。

深入业务需求

B端产品的业务需求非常复杂，接到产品需求时设计师需要灵魂三问：需求的背景是什么、解决什么问题、达到什么目的，被动的接收片面需求只会管中窥豹，更详细的分析也可通过5W1H方式去提问。

以上三问基本可以帮助你甄别需求，哪些是真是需求哪些是伪需求。做公司内部使用的产品时，要是碰上不那么专业的产品经理或者没有产品经理，会面临公司成员人人都是产品经理的状况，每个人都可以提需求。

此时设计师可以利用自己的产品思维去甄别需求，而不是用户说了什么就要做，要敢于用自己的专业知识去过滤需求。

当设计师足够的了解业务，把自己当成用户而非设计师的角色来看问题，模拟一遍业务流程，看看现有的需求功能逻辑是否通顺，是否可以简化流程逻辑，是否可以通过交互体验设计手段来帮助解决一些问题，助力业务目标实现。设计师不能凭自己的主观臆断去调整需求，一定要根据实际数据或者业务场景去优化。

参与前端组件的定制

B端产品的开发依赖已有的前端架构，目前国内比较成熟的前端架构是ant design和element，还有些开源框架，使用现有的架构前端人员就不需要开发基础服务。ant design是阿里开发的一套前端组件，开发文档很全面，组件也很完善，也在持续更新，设计师根据产品调性对这套组件进行优化调整，形成自己的产品组件，把定制好的组件与前端开发人员交流，让前端组件尽量和设计组件保持一致，既能保证后期页面实现时保持较高的UI还原度，也有利于产品后期的迭代和优化。

这里补充一点：

可能会有些设计师会觉得B端产品直接套架构没有什么设计可言，陷在C端产品设计的思维中设计一些吊炸天的方案，效果却未必理想。

C端产品特性使得设计师需要关注最新流行趋势，视觉改版也会引发一波关注，如微信的黑白模式改版。

而B端产品业务信息量复杂、组件表格类居多、内容展示追求屏效比、前端开发新组建成本高，这些特性综合评估起来并不太适合个性化设计，也不能完全套用流行趋势，系统保持高效性、易读性、易操作才是根本。

那么界面如何做的更美观？可以从组件、布局、交互入手，设计的时候要考虑到开发成本，时间紧急或者开发人手不够的时候，新的交互形式或者样式往往是不会被采纳的，对于允许个性化的场景我一般都是设计两版方案，常规版和引入新的交互或者展现形式以供选择。

总之B端页面可以进行局部的个性化设计，如icon、布局、交互、插画、情感化的形式来凸显产品调性，秉持信息传达清晰是根本，效率>易用>美观。

跨部门协作

由于B端的业务特性，设计师除了对接产品经理和研发，会涉及到跨部门协作沟通需求或者推动一些功能。对于跨部门协作面临的问题就是大家都在专注自己的工作，关注的是自己的目标，时间不充裕的情况下不会帮助别人做本职工作之外的事情。这时候需要打造一个利益共同体或者共同目标把大家关联起来，既然协作涉及到了相应的人员，那就说明该产品与其有一定的关联性，把做这件事的利害关系以及找他协助的原因说清楚。如果对方还是不愿意配合就找与其相关的相关负责人，让负责人协调时间以及协助人员。

沟通前需要明确诉求，提前罗列好自己的疑问点、想达到的结果、想获取的资源等，避免无效沟通。面对面沟通会比文字沟通更有效，重要信息最好是面对面沟通。项目结束时，感谢协作团队。其实对于不占用自己太多时间的协助大家还是还是会乐意的。