话语权缺失的现状
还是回到 B 端设计师职业问题上，这几天在我们群里，反复讨论了一个问题，就是设计师如何能提升话语权，提升过稿率。
话语权缺失的主要问题概括起来，就是下面几点：
- 设计评审的时候，难以说服对方，最后往往落地的方案完全不是自己想要的。
- 设计的风格从一开始就不由设计师自己决定，完全是遵照的老板、产品的要求做。
- 设计不能参与评审，不参与一手的产品方案讨论，直接拿到需求开做。需求的改动非常频繁，但认为设计需要花的时间并不多，轻轻松松可以实现。
- 碰到实现上有困难的，以开发需求为导向，砍设计需求。
- 老板不在乎设计，觉得做出来就行，甚至没有意见和讨论空间。
- 开发不根据设计稿实现，不按对应参数做设计，导致落地差距过大。
- 推出具体的建议不被重视不被采纳，直接不了了之。
- 设计规范难以建立，不给出时间搭建，认为“又不是不能用”。
- ……
还可以讲 3 天 3 夜，大家自己对号入座。
话语权缺失是 B 端设计行业最严重的问题之一，远远比 C 端产品团队让人无奈。
简单分析一下两者的区别，核心原因就是前面分享中讲到的，C 端产品重增长，B 端产品重业务。
C 端产品注重用户量、停留时长、营收的增长，就不可避免的需要考虑用户体验、满意度，但凡有点经验的团队都会知道，个人意见拧不过应用市场里铺天盖地的差评和用户流失。
所以，面对捉摸不定的用户，打造一个优秀的产品就不会是一言堂式的工作环境，需要集思广益，不仅要产品自己有洞察力，也要设计师能充分从体验角度触发去理解用户，最大化版本落地后的效果。
虽然体验不代表产品成功与否的全部，但起码它也是一个重要的指标，所以设计师自然也是需要被倚靠的对象，是对产品本身有一定话语权的。但在 B 端中，情景就完全不同了。
B 端项目更多是一个附着于商业运作的工具，多数 B 端产品就是来解决商业环节中出现的某些具体问题。
比如一个 HRM 系统，目标就是让企业的人才管理和招聘可以更规范、流程、数字化，实现的目标非常的清晰，不是捉摸不定的 C 端用户。所以实现的难点往往也非常的清晰，那就是应该提供什么样的功能，能让这些业务需求被实现。
而 B 端系统不同于结构简单(相对来说)的 C 端应用，往往在开发层面非常的复杂，不像 C 端应用可以轻易实践 MVP 最小可行性原则投放一些简陋的版本进市场检测。
B 端系统如果不在一开始就搭建出一个扩展性强，健全的底层，那就等于建楼材料偷工减料，为后续施工增加无数隐患，早晚楼毁人亡，比如美国最近的塌方事件。
所以有一定 B 端项目经验，就会经历过团队开发对整套系统重构的经历，因为以前写的 “屎山” 代码已经累计到根本无法维护的程度，还不如推倒重建。
所以，技术的门槛决定了 B 端项目整体开发的周期偏长和难度偏高，这还不是最严重的，最严重的问题是对于小型团队来讲，往往能按需把这产品做出来，就已经谢天谢地，还指望中间增加一大堆干扰要素来拖延产品开发进度?
对于很多本身复杂的行业来说，一个 B 端产品开发一两年已经屡见不鲜了，虽然很多时候和老板、产品自己考虑不周、管理能力不足经验不足有关，但不妨碍他们明白当务之急必然是产品能被做出来并且落地。
所以，这时候你能指望他们再过度重视设计或者体验，增加不必要的开发成本来给项目添堵嘛?确实是只要能达到又不是不能用的状态，就已经是拼尽全力了。
再者，对于这些复杂的行业来说，业务本身的形态就很沉重，从整理业务到落地需求就是一个及其混乱又复杂的过程。如果你的工作每天是看一堆流程图、逻辑图，然后和开发反复沟通实现难度解释产品逻辑，那基本就能耗干你所有的耐心和精力。
在这种心态下面，就会导致负责人很不想再多废口舌和更多的人来解释产品的逻辑，比如再和设计从头解释一遍这么做的理由，或者再和设计针对一个按钮应该放哪里，用什么颜色这种事，设计只要按着已经大致定好能实现的方案做就行了，别操心别的。
这就是 B 端项目设计话语权缺失的根本原因，如果项目体验、视觉、交互能做到极致，换谁也不会不乐意。但矛盾点就在于，B 端项目有实打实高于设计师工作职能的其它要事需要优先实现，然后才考虑设计，这就是 B 端团队存在的真实环境。
所以，客观因素就摆在那里，让 B 端设计师自带弱话语权属性。那么，我们就真的只能当一个拼图佬?
B端设计师如何获取话语权
B 端设计师话语权偏低是行业还在发展过程中的阵痛，虽然这是客观事实，但不代表作为 B 端设计师你就永远抬不起头或者没有话语权了。
所以接下来，我就要分享一些对于 B 端获取话语权上的建议，希望可以给大家带来一些有效的帮助。
首先，我们要先描述一个对于常规项目通用的 B 端设计师标准。
第 1：视觉能力过关
最起码页面的输出质量怎么做都能达到平均线以上，不要出现连后端开发都会吐槽你做的东西怎么这么丑!
第 2：熟悉网页规范
尤其是前端规范，掌握基础的 HTML+CSS 非常有必要，以及对一些基本的框架能有入门的认识，保证设计出来的东西是能落地的，而不需要开发告诉你做不出来，或者实现成本太高。
第 3：交互基础扎实
对于常见的管理系统组件使用方法，交互形式有足够的认识，制定对应功能交互流程的时候，最起码保证流程完整，逻辑严谨。
第 4：组件化设计思维
可以很好的整合项目复用元素、规范，无论在视觉端还是开发层面，都可以按组件化进行元素调用，防止重复造轮子。
第 5：流畅的开发交接
完成设计以后，标注和切图可以合理的提交给开发，能让他们以最低成本和最快的速度实现设计稿的样式和功能。
第 6：严谨的工作态度
这个字面上来看并不是一个技能，但我还是要提出来。B 端设计中包含的琐碎细节太多了，如果一个很不把细节当一回事的设计必然会犯各种错别字、元素忘记修改、边缘不对齐、画布没裁好的低级错误。
低级错误累加到一定数量，同样也是工作能力差的表现，按我的工作经验和观察过的设计师，严谨的工作态度真的是一个需要培养，非常具有门槛的职业技能。
满足上面几个大点，你就可以当一个合格的螺丝钉了。而在争取话语权之前，我始终贯彻的想法都是建议大家先有做好一个螺丝钉的能力，甚至要能有做超级螺丝钉的能力。
因为必要的基础素养是在职场中可以说话硬气的保证，设计说到底是具有服务性质的职业，如果基本工作内容质量无法保证，那么谁都无法说服。你工作完成不好，解释得越多，就显得越聒噪。
换个角度思考，如果你找个 Tony 帮你理发，最终的发型效果是下面这样的，对方再怎么给你推荐纹眉、挑染、定型那都没有意义了，因为信任度已经没了，你只会想趁早和他一刀两断。
所以，在你自己都觉得上面几点做不好的时候，不要不甘心当一个拼图工，多做事少说话，钻研细节的问题，反而可以让自己得到更多精进。
而只要在大家对你的基础水平都没有任何异议，而且建立起对你专业度的信任，才有精力、有资格去争取自己的话语权。下面就进一步讲解话语权的来源。
话语权的获取并没有一个统一的模版，你只要实现一个固定的 A 标准，你就能做团队的龙傲天。我只能提供一个大致的思路，需要你们自己在实际的环境中进行判断。
首先就是你设计师需要对当前项目的紧要目标，或者说对领导的预期有充分的判断。帮助我们改变思维形式。
不是 “我觉得应该设计一个什么样的风格，产品更有逼格，更好看”。
而是 “团队要实现某目标，我应该如何通过实现设计来更好的达成这个目标”。
比如团队希望的是下个月就能上线，但工作量挤压得非常多，部分需求不明确，那么设计在提交方案或者评审的过程里，就一定要冲着节省时间和精力的方案去。在解释这套设计的过程中，就有明确的提供对应的设计理由、原因，这么做可以如何节省团队时间，为什么不做另一个方案。或者连另外一种方案也提供出来，阐述这么做的利弊，供团队自行选择。
我们给出的设计方案要能符合大家在这个阶段对设计的要求，这在一定程度上是属于职业人的 “眼力见儿”，但这不是纯跪舔的心态。因为项目研发是一个团队作业，英雄主义情节要不得，你的目标一样是为了项目的更好推进而牺牲一定的自我意识。
而在提供基本方案以外，是需要设计师自己可以更深度来理解项目针对的行业和业务形式的，不少 B 端设计师对业务的理解无限接近于 0。这种状态对于老板还是产品来讲是能看的一清二楚的，你连行业都不了解，还提用户怎么怎么想，有意义嘛?
业务的理解在于我们判断自己提供的方案是否能满足业务的需要，还是牛头不对马嘴。这保证你在各种会议和沟通上不会显得及其无知而且偏执。
还有对产品层面也是，需求是什么、有效性、逻辑是否合理，能形成自己的判断。不是让大家真实现产品经理一切职能，而是你能清楚产品应该做什么，怎么做，工作质量如何。这样你才可以结合业务形成有效的产品建议。
最后，就是和开发的协作了。一个优秀的产品、设计，都会充分认识自己的产出会对开发产生什么影响。如果远超开发水平、精力预期的需求，必然会导致开发的逆反情节。
就像老板让 UI 设计师做个淘宝的店铺建模，显然超出我们自己的能力范围或者预期，当然会让我们极度的不爽。
所以，每次在项目开始前，资深的设计是懂的和开发针对设计的落地边界进行规划和摸底的，并不是所有方案都给出最低的限度，而是按对方预期可以投入精力的极限，来合理制定设计内容，确保在双方能力范围中产出最优的结果。
很多人的误解是前端开发根本不屑于实现视觉层的代码，就喜欢磨洋工。但实际上都是工作的产出，每个前端都希望自己写出来的东西既好看又好用。但很多时候设计给的方案不但没啥说服力，又纯粹增加工作量，实现难点一点不考虑，那他肯定不希望承担这样的压力，直接进入弃疗状态。
设计和开发都是实施层的战友，是设计师需要坚持拉拢的对象，一个靠谱的设计可以获得开发的认同远远比产品容易(产品话语权也是要建立的)。而设计要做的，就是要在他能力范围里最舒服的实现界面的还原，成全他的成就感。
这当中就包含界面样式、组件化、命名规则、展示方式、版本管理、切图标准等多方面输出因素，需要设计师自己根据实际情况进行制定，没有统一标准。
以上这些工作都能做到，而且可以持续一段时间，你自然而然就会开始获得话语权，开始获得产品、开发、老板的尊重和重视。
总结
可能有些人会问，怎么看起来这么难，这些都能做成得变成多优秀的 B 端设计师?
没错，这就是需要用优秀的职业素养来争夺话语权。话语权不是只有设计师要争取，产品经理、前后端开发一样也要争取。一个团队中抛除老板本人、老板亲戚、投资人内线、甲方爸爸等不可抗力外，话语权的获取就是谁能力优秀对产品、项目的判断准确有效，谁话语权就大。
在整个职业生涯中，我见过非常多老板和产品处于弱势地位的情况，为什么?因为专业素养太差，驾驭不住设计和开发，每次产品评审的过程都是团队其他成员对他们的公开处刑。
所以获得话语权，就是用事实专业能力说服他们的过程，而有效的说服一定是站在项目全局的背景下而不是独立站在设计角度考虑的。
专业度高或低的人，一般都会尊重其他专业度高的人，而一个团队永远处于大家互看不顺眼、相互责难对立的情况，通常就是专业度都不高谁都不能有效说服对方，这种场景叫 —— 菜鸡互啄。
越是如此，越要冷静，不要管别人当前如何看待你，至少你要有信心和动力去争取他们未来如何看待你。如果你的工作环境实在无法改变，你就可以尝试换家公司继续尝试和积累经验。
话语权的争取不是一朝一夕，取决于你自身的属性。
放弃躺平，准备战斗吧……
