设计师，一定要会做设计推动！

2024-2-16 博博设计思维

01）做设计推动的价值

设计之前的定位是支持角色，主要的能力有两点：

作为产品和用户之间的翻译官，把复杂的业务逻辑翻译成用户能了解的方案，让用户使用的更顺畅。

作为产品和研发之间的桥梁，把功能的界面描述，变成具体的操作流程、原型、标注切图，来提供给研发，让他们能把功能具现化的实现。

在这其中，很多团队设计和产品的工作是高度融合的，很多idea都是一起讨论出来的，所以无法对设计的贡献做具体量化，这就是不好回答设计价值贡献的原因。

为了解决这个问题，越来越多的设计团队在开始做设计推动，通过设计来找到业务的问题，然后通过方案来解决，这样就体现了设计对于业务的独立贡献。

在设计推动中，设计是项目的onwer，对项目的体验有更强的把控，很多有价值的体验点都可以按期落地。
除此之外，设计推动还可以提升设计团队在业务中的影响力，获得更多的资源，让设计在业务决策占有更多的主动性。

02）做设计推动的难点

做设计推动，对设计师提出了很大的挑战，需要他们在业务的角度，去了解业务、了解数据、挖掘问题。

通过对这3个维度的了解，来找到设计可以解决的切入点，并形成可以落地的方案，还要验证方案的可行性、推动方案能落地上线，来为业务解决问题，带来核心指标上的大幅提升。

我们准备了一个4步法，来让大家更容易做设计推动。话不多说，就来看看是4步吧。

03）4步教你做设计推动

第一：了解业务

对业务有全局的了解。很多设计师只关注需求相关的内容，对业务全貌并不了解，在这种情况下挖掘的问题，要不就是不被业务认可，要不就是解决后带来的价值不高。所以我们要了解：

了解业务目标
我们一定要了解业务的目标，不然就会出现，优化点虽然产品团队认可，但并不在他们的计划内，就会导致优先级很低，在非常长的一段时间内，不能被安排排期。
所以，我们一定要了解产品的目标，这样做的内容才是他们想要的，才能有资源安排上。

了解业务的运转关系
我们要了解业务下面各个功能模块之间的关系，包括数据的流动关系，数据和信息在不同功能模块之间的传递方式。不同功能模块的交互关系、不同功能模块之间的依赖关系，包括硬性依赖（一个功能模块的输出是另一个模块的输入）和软性依赖（合作、决策等），这有助于识别潜在的风险和瓶颈。

参与业务讨论和会议
多参与业务讨论的会议，这样就可以了解业务的动态和重要决策，这将有助于你更好地把握业务的方向。如果后续需要和业务进沟通，也会因为脸熟，沟通会更方便。

了解各个角色的分工
需要确定不同部门和岗位的角色和职责，了解他们在业务运作中的定位和协作方式。
需要了解各个部门和模块之间的沟通和协作方式，包括例会、项目管理工具、文档共享等。
这样我们可以知道角色对于项目有帮助，或者如果出现了问题，可以找到谁来解决。

第二：挖掘问题

问题的挖掘有很多渠道，通过对数据的了解、通过调研、通过业务的反馈，无论哪种方式，都要和业务目标靠近。

数据埋点
主动提埋点需求。很多情况下，设计师感觉这里有问题，但是没有客观的依据就没法证明问题的存在。数据分析是一个极好的方式，但遗憾的是，很多公司的数据埋点是产品提出的，设计需要统计的数据可能没有，这是就需要设计师提出对应的埋点需求。

用户研究
通过日常对用户的研究，来积累用户相关的问题，作为后续设计点的依旧来源。
通过这些访谈中的反馈，我们可以把问题的影响、出现的频次、用户的使用场景的内容都描述清楚。
如果要邀请其他角色加入，就要让其他人了解问题的对应的背景、紧迫性、重要性，这样才让对方更有意愿一起来解决问题。
这种协作和问题解决的过程，有助于设计推动项目的成功实施。

日常观察和使用
在日常工作中，无论是设计师还是其他团队成员，都可能发现产品的问题或体验瑕疵，比如用户的吐槽、发现的 bug，或者体验上的障碍等等。这些问题可以成为推动项目的切入点。

第三：推动方案

方案定义
一旦找到了设计切入点，就可以来定义：

设定设计目标：设计能解决问题的方向，以及和挖掘问题之间的关系
制定设计策略：解决这些问题的手段是什么
确定衡量指标：解决这些问题后，能带来怎样的价值，以及价值和设计的关系是什么

通过上面内容的定义，可以确定此方案的可行性，以及对于业务的价值。
目标和策略的定义，最好简单点说，不要说那些高大上的黑话，譬如顶层逻辑，底层闭环，链路赋能之类的。本来设计的专业名词让其他人理解就有成本，再加上这些黑话，就会让人不明所以然，就让人不容易理解。
反正就是要说人话，最好公司的保洁都能听懂。

为了能让多方认可方案，通常会开会汇报，来邀请更多的与会者，横向拉通共识，然后就可以开干了。这个方案包括：

定义内容：包括设计目标、设计策略、衡量指标等内容
方案初稿：具体的方案，建议以交互方案为主。在这个解决更多是阐述可行性，放视觉内容有些浪费，可能后续会有较大的调整
演示demo：制作演示demo要比干巴巴的讲ppt更有画面感。但是要注意时间投入，不要在demo上花费太多时间。demo是点睛之笔，不是必要内容，如果在上面花的时间太多，就有些本末倒置。如果有些公司不用ppt演示，用word或思维脑图汇报，我建议就不用加演示。

汇报要挑重点内容讲，大家的注意力是有限的，不要讲述太多细节，老板更在乎的是这件事解决后能带来什么价值，以及方案的运转逻辑是否合理。这个汇报一定要让你的老板参加，如果遇到一些棘手的问题，他可以帮助你解答。

还有，在方案设计阶段，最好邀请产品来做把关，他们可以为设计提供业务视角的建议，可以作为对方案的有益补充，这样可以增加提案通过的成功率。而且大老板们也希望看到多多团队在一起共创，体现了员工的主动性。

第四：落地把控

对于设计推动项目来说，最担心的就是推动过程中的风险问题。因为设计推动不像产品需求，有流程来保驾护航，有项目经理来进行把控管理（有些公司没有项目经理，就是由产品兼职），全程都是设计在推动，稍有不慎就会导致项目的夭折。所以和多个角色沟通，识别潜在风险，确保项目能安稳落地。

邀请项目管理角色
如果可能，专业的事情就应该交给专业的人来做，最好能要到项目管理的角色，来帮你分担这部分风险，确保项目的安稳落地。而且落地过程中的琐事非常多，有很多不是设计师擅长处理的，有这个角色的存在，还能让你安心投入推动项目中，减少无意义时间的损耗。

邀请产品来共创
如果可能，最好能和产品一起共创，通过这个过程，设计团队能够更好地与产品团队协作，确保设计与业务目标保持一致。这种紧密的协作方式有助于双边的合作信任，实现设计推动的成功落地。
如果有产品介入，就可以让他来写PRD。如果让设计师来写PRD，就会有质量问题，譬如缺少重要环节，策略写的不完善等等，毕竟设计师不是专业的。在落地过程中就会暴露这些内容的缺失，然后在进行补充，这非常影响工期。