设计自驱

设计自驱是伪命题？这4步让你从零开始做到设计驱动项目！ - 优设网 - UISDC

想象这样一个场景：在晋升答辩会上，你从方案 1 讲到方案 49，终于讲完所有的 PPT，此时沉默良久的老板徐徐问出这样一个问题：

“OK，我知道你的设计产出是足够的，但是你作为设计，在项目中的价值是什么呢？你直接驱动了什么目标的达成呢？”——简直是当代交互设计师鬼故事。

今天我们就来聊一聊设计驱动的话题，什么是设计驱动？作为交互（or 视觉），我们除了搬砖当线框仔，如何才能提升所谓的“设计自驱力”？

什么是自驱

全程“设计自我驱动”，简单来说就是以设计的身份，主导（或者推动）一个问题的解决，或者提出一个暂时没有产品或运营想到的创新性解决方案。

有人认为设计自驱就是剥削，它让设计师除了画稿子的本职工作还得承担部分不属于设计的工作。虽然这么说其实也没什么问题，但我个人认为把“设计”这个工作的职责简化成“画稿”，其实一定程度上削减了这个职位的权限和影响力。有章法的设计自驱，是一种能提升自己影响力、从而让资源聚拢到自己身上的有效策略。

「举个例子」

假如现在有一位勤劳的设计师小 P，他准备为了老板的 KPI 去做一个设计自驱项目

自驱项目一共有 4 步：

1. 找到命题：寻找一个靠谱的方向去自驱
2. 对齐预期：让各方都明确自驱的最终产出
3. 推进方案：输出理想样式与 MVP 方案
4. 持续追踪：通过复盘形成正向反馈

好的命题能够让设计驱动项目得到各方的助力，而反过来，优先级低的、方向没有得到上下游认可的设计驱动项目很容易只有设计在自 high、推进和上线困难重重。因此在项目的最初，设计师就应该去通过各种渠道了解当前业务的发展重心。一般有 2 种获得这些资讯的方式：

1. 从上游获得信息。这需要日常保持和上游的良好关系。

平常产品来找设计时，往往产运内部已经对要做的事情有了决策，设计只能做执行而没有议价空间，所以在每个 okr 周期的开始时（比如年后、双月的第一周）和产品喝喝茶，闲聊一下最近老板近期的关注重点、准备发力的方向，对设计自驱非常有帮助。

2. 自行挖掘痛点。这需要比较强的行业洞察力与数据分析能力。

漏斗/转化数据、周期性的体验评估数据、用户访谈时用户的吐槽、日常搬砖时发现的 bug 或者体验痛点，都可以成为自驱项目的命题。注意整理清楚问题的背景、影响范围、收益和相关方，因为你需要用这份材料说服别人帮你干活。

「举个例子」

假如小 P 就职于一家正在极速扩量的电商平台，为了找到自驱的主题，小 P 先和设计老大、平常比较熟的产品、对接过的运营那里了解到，本季度老板主要想挖掘一下售前场景：App 首页的改版可能性，已经批了两个运营和产品组成了专项小组，在下个 Q 之前准备产出成形方案。

小 P 转头一想，去年似乎主要是把购物流程搭建完了，售前场景下基本没接到什么需求，现在整个平台就只有一个推荐流和几个分类榜单页，非常草率。

小 P 又看了一下平台转化率，数据的确比较一般，甚至自己试用公司 App 时，也在平台上找不着自己想买的东西，虽然价格有优惠，但是逛一会就累了，最终没有下单。小 P 推测可能用户也想看到优惠信息的集合，那么是不是可以在首页新增一个位置，推送优惠信息呢？——这事可能可行

有了命题以后，下一步是拉资源。这包含内部和外部两种资源：

1. 内部资源：主要是时间。

因为设计往往是一个支持性的角色，日常还是得搬砖；而设计自驱需要占用人力去做调研、分析等暂时看不到收益的前期工作，因此和设计内部对齐预期，明确投入的精力和阶段性产物、最终目标就非常重要。一旦项目迟迟无法推进，就能及时抽身。

2. 外部资源：主要是产品和开发。

假如第 1 步做对了这一步就无需担心。否则很多设计自产自销的想法最终都无法匹配到研发资源，或者优先级很低，上线时被改的面目全非。

「举个例子」

小 P 先找到老板，描述了产品想搞的事情，并且把自己的初步计划和排期讲了一遍，表示得花 7 天研究研究，再花 3 天出点尝试稿，再花 2 天修改和测试，大概月底能让这个想法进开发，先约定下周同一时间过进度。老板表示略有耳闻，可以考虑。

调研部分和平常做设计没有什么不一样，此处略过。只说在设计自驱中，设计需要充分发挥自身的特长：那就是可以在不需要研发的基础上，把方案做的非常高保真，用华丽的页面和流畅的体验去打动老板推动方案。但是也同样因为设计处于产品研发比较下游的位置，离决策层比较远，所以往往这些方案的推进会遇到各种各样的阻碍，因此为了应对阻碍，需要提前想好最小可行性方案。

因此，自驱设计的产出分成两个部分：

1. 理想形态的搭建。

假如完全没有技术上的阻碍、当前业务形态的限制，什么样的设计是符合诉求的、合理的。这部分的设计可以多一些时间打磨的更精彩一点，最好做成 demo。因为你会在后续汇报中不断的用到它。

2. 最小可行方案（MVP 方案）。

也就是做到什么程度就可以上线观测了，也可以理解为你作为设计最低接受的底线。低于这个底线，这个项目就不能往作品集里放了。上线之后假如数据正向符合预期，那么应该从 MVP 方案不断向理想形态过渡和迭代。假如这个自驱点是你自己挖掘的，那么请准备好冷启动的策略思路。

推进的过程是整个自驱流程中最痛苦的一个阶段，你的想法会被各方挑战和修改，因此在这个阶段需要灵活运用设计验证的手段，通过小规模用户测试、访谈、内部试用等等的形式来验证你的设计是靠谱的，是优于线上方案甚至其他思路的（这里理想状态 demo 又起作用了）。

「举个例子」

小 P 经过一系列艰苦卓绝的调研后，发现平台的核心用户的确对折扣非常敏感，除此之外，品牌、季节节日也是主要吸引用户下单的原因。而当前页面上按品类划分的榜单点击率一般般。因此小 P 感觉，是不是可以大刀阔斧的修改页面架构，主推折扣、品牌、季节节日三大场景？

但是和产品battle过几轮之后，小P发现，虽然产品和运营都参加了调研，也认可当前结论，但可能产品还是怕步子太大扯着蛋了，于是推出了MVP方案：在推荐流第一排的左边第一个格子加上折扣榜单，然后再参考点击率变化，从而决定要不要继续往下走

走到这一步以后，项目最终结果好不好就看运气了。这也有两个可能：

1. 假如效果很好：

作为设计请及时复盘，详尽的复盘文档能够向设计内部以及上下游证明你付出的精力。产出节点、产出物与复盘越清晰，项目成功后其他人想要摘桃就会越困难。当然不可避免的，每一个成功的项目都需要分一杯羹给上下游（也就是产品、运营、开发等等），让他们在各自场合有汇报空间，这样才能使得整个自驱的流程往良性循环发展。

2. 假如效果不太行：

还是应该复盘，理清楚哪些坑将来可以被规避。但请及时观察老板的动向，做好这个方向短期内被放弃的准备。保留产出物、及时止损，避免被内部/外部推锅。

小 P 的项目最终结果还可以，小 P 连夜制作复盘文件，并且把 demo、调研故事、尝试的方案整理成汇报 PPT，在群内分发给相关人员。这个项目最后圆满结束。

欢迎关注作者微信公众号：「白话说交互」