想象這樣一個場景：在晉升答辯會上，你從方案 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，在群內分發給相關人員。這個項目最后圓滿結束。

歡迎關注作者微信公眾號：「白話說交互」