在 B 端复杂业务场景下， 设计师 们该如何为自己增加 话语权 呢，本文从熟悉产品、分析问题、提出解决方案、转变设计思维4个方面探讨这个话题。
相关干货：
怎么提升 B 端设计师的话语权？来看大厂总监的分析！ 话语权缺失的现状 还是回到 B 端设计师职业问题上，这几天在我们群里，反复讨论了一个问题，就是设计师如何能提升话语权，提升过稿率。
阅读文章 >
相信很多同学都对设计的「被动」处境都深有体会，无论是主营哪个发展方向的设计，都会在方案评审时被其他职能：
“这个不够高级呀，你看其他竞品的就很有高级感”
“客户想要的就这种，实在不行，咱们抄吧”
“不行，我觉得你这交互也没多好呀，而且一换，那影响点就多了”
“你这还是不懂业务呀，为什么要这么设计”
“大哥，你这交互，开发工作量增了一倍，效果也不一定好吧”
....以上都我乱编的，但反正为了满足产品、开发、运营各个大佬的要求，我们得不断的沟通、改稿、评审...最后上线，还是会被 diss“其实这可以做的更好”。
所以“你怎么知道用户想要的就是你说的这种方案？”...敢不敢提出这种质疑？我不敢，但我鼓励大家这么做，因为这种想法或许是走出「被动」处境的一条路。咱们来一步步探索设计该如何走进方案共建，变被动为主动，提升话语权，在取得其他职能同学的信任后，将他们一网打尽。
先来说说我这边是由于公司整个研发流程调整，设计师需要与产品同学共建需求方案（在硬性的设计评审环节上也整体拉高了对设计师的要求）。我们需要在产品评审详细方案之前，就产出详细的设计方案（包含 UI+交互），意味着设计师需要前置需求分析、产出方案，节奏是快于产品同学的。
这一转变难吗，其实不难，难的是一开始仅意识到把排期时间提前，而设计思维还滞留在从前。怎么讲呢，相当于我们还停留在通过产品的框架方案，来牵头进行产品方案分析，与产品讨论方案的可实施性（简单点就是依然按照产品的方案规划来走）。但并没有跳脱出来，根据需求本身（融入实际使用场景，分析用户的真实痛点，质疑目前的方案框架是否就是用户需要的，是否有第二条更好的路）去思考，再说直白一点：产品方案≠解决方案。那设计师该如何主动出击呢，咱们具体拆分成小点讲：
一、入场券：你对负责的产品熟悉吗 问问自己，你对负责的业务有多熟悉（尤其是 B 端产品，想要有话语权的第一步就是要熟悉业务，不然没有人会认同你）。你得清楚自己负责的产品涵盖了哪些业务，服务什么客户，用户都有哪些，产品功能有哪些，主要功能都迭代到什么程度了...（不清楚这些的，请先自行回去恶补）。
了解业务最简单粗暴的方式，就是不限次数的操作，一有空就用，变着花样的今天虐这个功能模块，明天虐那个功能模块。只有这样当需求来了，你才知道是哪个功能负责的，好去针对性的找到对应的页面，线上体会现有的交互流程是啥。如果有时间，可以记录到体验画布当中，便于理清每项操作存在的意义。
二、登场：分析现有问题 这是最重要的，立足用户「主」场景，思考“你”为什么会提出这个需求，是想要解决什么问题（当前的做法是什么，有哪些不方便的地方）得到什么样的效果。带着这些问题，去审视产品方案（你现在是用户，所以一定要抱着审视的态度才行，不然很容易掉进陷阱）。“在这里加上 xx 入口，能不能解决我的问题，理解成本是不是有点复杂，这真是我想要的吗”。
因为 B 端产品，往往会涉及到两种及以上不同的角色，一个是设置者，一个是使用者，设计师需要在方案拟定中权衡对两种角色的满足（不要再当出图工具了，好的用户体验才是设计师追求的目标）。所以当出现了与咱们目标想违背的框架，就需要 battle，在 battle 的过程中，你会发现有时候产品对用户的主场景也是模糊的，没有好的方案取舍…这时候，作为专业设计师的你就该登场了，用你的专业，融入场景，告诉他按照这种框架设计，会出现什么样的问题（甚至会让其他职能都跟着方案陷入困境中）。没有哪个方案是完美的，所以解决方案的主次层级，就一定要分清楚（成年人不能既要又要也要）。
以上的操作流程，咱们一定要带入使用场景，先以场景为前提，设想自己是在什么场景下会使用，这样才有助于判断设计的优先级，使用场景是否全面（可能会影响设计交互）。顺便吐槽一下某 8 的 APP，用户体验真的是非常差劲，完全没考虑用户在多场景下的使用情况（如果有幸能被某 8 的设计老师看到，请真的去体验一下你们的产品交互，你们的设计仅考虑到了单一的用户场景，操作繁琐、反馈也不及时）。
这里再补充一点，除了第一步分析自己的产品，还需要分析同质竞品，不要只是看页面设计，更重要的是交互，多数据量时的交互。建议竞品分析可以深入一些，了解为什么要这样设计，有没有缺陷，用户有没有反馈过竞品使用情况如何。
三、表演：提出解决方案 对产品方案提出质疑后，需要拿出你的解决方案。还是从用户场景出发，按照用户的使用操作流程来梳理。把方案主次区分出来（大方向别跑偏了）。我们首先解决了什么问题（这也是用户最想要解决的），然后通过什么次级方式满足了其他角色在使用过程中的期待，最后这样做的可落地性（技术实现的可行性）。
这一点需要强调的地方是在方案拟定的时候，先不要着急考虑技术的实现可能，不然又会陷入被动（要相信你们公司的技术大佬，再难的方案他们也能实现，当然也要相信，人性是希望不要有什么技术难点）。因为我们的方案不可能只有一种，先满足业务需要，再满足技术实现，由深到浅的递进。
四、定局：转变设计思维 再次强调：不要直接用产品方案，不然你永远都会处于被动处境，你要做的是把产品方案转化为你自己的设计方案。这点确实是很难，因为我们要转变的不是单纯技术上的设计输出，而是设计生产思维，创建自己的思维体系。
按照被动的设计思维，盲目跟着产品方案走，可能造成设计方案最终呈现效果并不理想，暴露出来的会是：你们共建方案的时候，配合出了问题，却没有及时反馈…所以如果方案拟定过程中出现了多次沟通无效，争论无果的情况下，一定要向上寻求帮助，提出你的观点，让更多人看到你的思考。
综上：废话有些多了，但都是希望能为提升设计话语权打下基础，设计师的「存在感」不应该只是在设计评审环节。加油吧，做颗（永不）秃头的小白菜。
