如何把B端设计规范做活

2021-09-14 10:11:00

编辑导读：B端产品的性质与C端不同，B端产品团队在用户体验的重视程度上远没有C端团队高，因此对于B端设计师来说，自己的设计不能百分百的落地到产品中，个人的沮丧感比较强。如何将B端的设计做活？本文作者对此发表了自己的看法，与你分享。

人生就是一条条难走的路，路好走就不用走了，而难走才体现了价值。人生就是将死局做活的过程。

我们在生活中、工作中，总会出现“不知道该怎么进行下去了”的焦虑和无奈。

还记得高中体育考试跑800米，第一圈的时候每个人都很有冲劲，那会体力跟得上。当第二圈的时候，跑在前面的同学渐渐和跑在后面的同学拉开了距离，我就是跑在后面的同学里面的一位。我感觉第二圈就是喘不上气、迈不开腿，感觉就想放弃，太艰难了。然后只听见已经到终点的同学在帮我们呐喊加油，最后终于咬咬牙，蹭一下跑到了终点。而那些坚持不下来的同学则被安排到了下一节体育课再次进行考试。

我们可以发现，“不知道怎么进行下去了”这个念头出现后，如果不采积极的行动，就会让事情成为死局。学过马太效应的小伙伴应该知道，它是一种强者愈强、弱者愈弱的现象，比如穷人会更穷，富人会更富。

用马太效应也可以解释死局和活局，如果我们遇到“不知道怎么进行下去了”的情况，直接采用放弃，或者不积极采取行动补救，就会出现死局，而且如果我们一旦习惯了这样的做事方式，死局就会经常出现。

我们来看看同一种场景下，不同人不同的对待方式给他们带来的结果。

一、两个例子

1.【生活场景】男主人公和女朋友沟通

由于男主人公在女朋友生日当天加班，忘记给女朋友过生日了，女朋友等男主人公回到家后一直生气，不理睬男主人公。我们看看两位男主人公的做法。

男主人公A：

男主人公A：“为啥又生气了？”

女朋友不说话，头扭向一边。

男主人公A：“有啥事情就说啊。”

女朋友不说话，头扭向一边。

男主人公A：“不说算了，我睡觉了，加班一天了，累。”

男主人公A和女朋友的沟通陷入僵局，几天没有说话。

男主人公B：

男主人公B：“今天心情不好吗？可以和我说说。”同时泡了一杯女朋友最爱喝的热牛奶递过去。

女朋友不说话，头扭向一边。

男主人公B：“今天不喝牛奶啦？是生我的气了吗？让我想想我哪里做的不对了。”

女朋友不说话，头扭向一边。

男主人公B：“肯定是我做的不对了。你指出来，我一定改正。”同时表现出非常诚恳的态度。

女朋友噼里啪啦把她心里的话都说了，两人沟通后都互相理解对方，并且男主人公B答应明天给女朋友补过生日。

2.【工作场景】设计师和产品经理沟通

设计师（交互和视觉都干）和产品沟通界面上设计的想法，产品经理告诉他不用管那么多，只管按照产品经理的想法做就好了，其他无需思考。设计师感觉自己是个工具，提出意见不被接受，他对工作有点不满了。

设计师A：

设计师A：“产品经理，可以给我讲讲这个设计的目标、用户群体、业务流程吗，不然我不知道如何着手设计？”

产品经理：“原型上都画了，PRD上也写了，你直接按照这些优化交互吧，不要大改了，不然研发时间不够了。”

设计师A：“可是我发现原型还可以优化的，我们要注重用户体验。”

产品经理：“原型不优化了，你直接做吧。”

设计师A和产品经理很多次合作都是以上的结果，设计师A很无奈，还在怀疑人生。

设计师B：

设计师B：“产品经理，可以给我讲讲这个设计的目标、用户群体、业务流程吗，不然我不知道如何着手设计？”

产品经理：“原型上都画了，PRD上也写了，你直接按照这些优化交互吧，不要大改了，不然研发时间不够了。”

设计师B：“这样子啊，那能否把产品的相关资料发我，以及下次在产品前期就叫上我旁听呀。”

产品经理：“这个没问题。”说完，把相关资料都给设计师B了。

设计师B回去仔细阅读了资料，并且加班加点把自己认为合适的方案进行了整理，第二天拿去和产品经理沟通。

设计师B：“产品经理，我根据你的资料和原型，做了相关优化，这样子可以来带的好处是blablablablabla。”

产品经理：“你说的这个点不错，按照你的来；这些点因为要考虑客户习惯，所以保持原样。”

设计师B：“好咧，没问题。”于是，设计师B开开心心继续画图去了。并且往后产品经理都会询问设计师B的意见，两人一起为了做好产品而协同，如同战友。

二、B端设计规范落地的难点

以上两个场景，男主人公A和设计师A在遇到挫折，“不知道怎么进行下去了”的状况后，均采取了不积极的应对方式，导致了死局的出现。这在我们B端设计规范落地的过程中也频繁出现。

由于B端产品的性质与C端不同，B端产品团队在用户体验的重视程度上远没有C端团队高，因此对于B端设计师来说，自己的设计不能百分百的落地到产品中，个人的沮丧感比较强。

有很多设计师问我：“产品团队让我出好看的设计规范，我非常尽心的设计好了，但是等他们开发完走查，我的设计稿基本没有被落地。问研发原因，研发解释是研发周期短，下次会按照设计稿开发。但是发现，这就是忽悠人的假话。”B端设计师感觉越设计越没有兴致，想和研发说，你自己设计自己开发吧。

我们发现，这就进入了死局，设计规范只存在纸上。那为什么会出现这样子的情况呢？这里我总结了一些B端设计规范落地难的原因。

1. 产品性质

B端产品是为企业服务的，企业更注重产品的性能、数据安全、平稳运行、功能强大等方面，用户体验和视觉会放在靠后的位置。不是说不重要，而是要看具体情况，和产品的生命周期也是息息相关的。

2. 用户群体

B端的目标用户为企业中有决策权的管理者，决策者决定了是否购买；使用者是带有角色属性的企业员工，企业员工更看重产品能否提升他们的工作效率，系统是否稳定，而不是界面是否特别美、动人。而C端的目标用户为普通的老百姓，只要是会上网的用户都是C端的目标对象。C端用户的决策较为感性，喜欢美的事物，特别是女性群体。

3. 业务逻辑

B端产品的业务逻辑比C端复杂得多，光处理业务逻辑已经让研发很头疼了，如果在按照设计稿原封不动的还原几乎要了研发同学的老命。因此B端的研发一般不会百分百还原设计稿，做得好的会让视觉上看起来大差不差、马马虎虎；做得差的基本只是用了设计稿的某些部分，其他部分自创了。

4. 研发水平

以前B系端统研发是前后端合一起的，前端的界面开发工作会由后端工程师承担，虽说现在前后端分离了，界面工作是专业的前端工程师在做，但并不是所有面向B端业务的企业都做到了如此，还有很多还处在改革的前期。所以B端产品的研发水平从两方面讲：第一、很多企业还是后端在承担一部分前端界面开发工作，对设计稿还原基本不如意；第二、前端工程师的开发水平参差不齐，如果公司没有强硬要求按照设计稿接近百分百还原，很多前端会随意开发。

5. 开源组件

现在B端产品都默认使用组件化开发，我见过一些设计师做了漂亮的设计规范，但是开发只是借鉴了设计稿的布局和交互，组件并不是按照设计稿开发的，而是在开源组件里面找相似的直接替代，这就导致了设计师在走查时候发现产品实际情况与设计稿不符，感觉自己的稿子做了等于没做。

三、如何把B端设计规范落地下去

B端设计师感觉到产品设计规范很难落地到产品，感觉自己的价值得不到体现，感觉工作已经找不到兴奋点。然后很多设计师就索性采取不外乎这两种方式：一种就是离职（说公司哪里哪里做的不合理，不适合自己）；另一种就是直接让这种情况延续下去了，反正推不动就让它烂着。总结来说就是让设计规范无法落地成为死局。

先不评论这两类设计师做得如何，我只想和设计师们说，如果选择了成为B端设计师，那么设计规范落地困难的实际情况要能理解，同时，我们也要积极采取措施，尽量推动产品研发靠近设计规范。那我们可以如何做呢？我给大家总结了一些将“设计规范做活”的小技巧。

1. 产品目标

作为B端设计师，制定产品设计规范只是我们其中的一部分工作，我们还需要充分了解产品长期、中期、短期及本次上线的目标，这样有利于我们跟着产品的步伐走，不至于脱离他们。通常设计师纠结规范有没有落地，而产品直接声明本次不用在乎，但是设计师觉得，这是为什么呀？这就是设计师不了解产品目标的原因。

2. 组件库

B端产品不会对页面上所有的元素进行从0到1开发，特别是对于通用型组件，B端产品都会直接使用开源的组件库，例如Element、Antd，这样可以极大的提升研发效率。因此我们设计师还需了解产品要使用的开源组件库是哪个，去学习组件库可支持的一些特性，一些常规性功能尽量不要自创，延续组件库给出来的即可；非常有必要个性化开发的部分记得和研发工程师有效沟通，让他们提前知道这么设计的意义，避免到了研发阶段，研发工程师选取式开发。

3. 沟通边界

设计师可以与产品负责人充分沟通设计规范的边界问题，包括设计规范本次设计到什么程度，哪些方面尽量控制。并且在形成设计规范的过程中可以和产品负责人多次碰撞，避免按照设计师的视角去输出一个对产品来说根本没必要的设计规范。比如产品负责人觉得组件图标使用开源组件库自带的即可，不用去优化，那么我们可以在这块上暂且先不考虑。