本周特邀前百度資深交互設計師薏薏來講講自己從交互小白一路升級打怪的過程，薏薏從純理科轉行設計，從 C 端近年轉行 B 端，求職、工作中踩過不少坑，今天將分享其中的一部分心得體會。

你是否和我有過同樣的經歷：當我們費盡心思、信心滿滿地做好了一個完成度很高的交互方案，可能被別人的幾句話就否定了。

場景 1

和 leader 確認交互方案時，剛講兩句就被 leader 全盤否定，導致自己帶著 leader 沒看一眼的稿子默默回到工位、從頭再來。

場景 2

和 pm 確認交互方案時，pm 一遍一遍提出疑問、還說了 A、B、C、D、E 各種想法，導致自己的方案反復修改、無法按時交付。

場景 3

向 boss 推自己的設計自驅方案時，無法得到 boss 的認同，導致最終無法爭取到開發資源、自驅項目最終流產。

場景 4

大廠面試官對作品集中的某個項目不斷發問，而自己卻難以給出令他滿意的回答，導致面試最終失敗、無緣 offer。

對新人設計師來說，方案被反復否定不僅費時費力，還讓人懷疑自己的能力、動搖自己初入交互大門的自信。那今天我將和大家一起分析什么樣的交互方案是經不起推敲的方案，如何呈現展示，才能讓我們的方案(至少看起來)嚴絲合縫，經得起別人的反復垂問和推敲?

呈現形式重要，但推導過程更重要

日常的瑣碎工作和求職準備會讓很多人忘記交互設計的本質。

從視覺設計師的視角來說，交互設計是對用戶行為的設計，這和用戶直觀可感受到的視覺設計有很大的不同。

從產品的視角來說，交互設計更偏向對行為細節和用戶心理的打磨，和宏觀、粗糙地設計整體產品框架有很大的不同。

交互設計師應該輸出的是整個設計推導過程：用戶在操作流程中的行為習慣、預期心理、使用場景、使用痛點的等等，而不僅僅是最終看似完美的視覺呈現形式、或者看似有條理，但是缺乏細節打磨的功能介紹。

這一點，常被初入行/非交互專業出身/小廠背景的設計師忽略。比較常見的兩種類型如下：

第一種是視覺出身、希望轉行交互設計的設計師。他們往往在方案中強調組件使用得當、文案引導清晰、甚至是使用了新穎的微動效等等，這些確實確實是好方案所需要的設計亮點;但如果整體方案缺少設計推導過程，憑空自己的主觀想法做方案，那么你的方案自然不堪一擊。

第二種是因為公司人手不足，承擔了偏產品工作的交互設計師，或者是校招生。他們往往在方案中有比較好的背景說明、方案推導，但是方案的呈現過于簡化，或者過于強調“設計思維”。最終呈現的形式類似 PRD，缺乏細節推敲。設計中有一個原則叫“美即好用”，當一個方案的呈現形式合理時，聽眾自然會給它更多的耐心，否則為什么你不直接去面試產品經理呢?

用閉環思維嚴謹地介紹你的設計

那么，如何做出一個經得起推敲的設計方案、一個嚴謹的設計過程?或者說什么才是交互設計這個崗位需要去重點強調、重點展示的?我認為一共有這幾點小技巧：

1. 永遠不要一上來就講設計圖

不管你是晉升答辯、日常對接、組內過稿還是面試講項目，作為一個交互設計師，永遠不要把一張設計圖攤開來就開始講細節：這里是什么顏色、那里是什么排版思路…這不重要。

交互永遠都應該以「項目目標」作為開場話題：pm 想做的是什么?要取得什么樣的結果?甚至集團、公司想要的是什么結果?甚至 pm 所想到的功能方案是不是合理的?這個方案為什么值得我們投入設計資源甚至技術資源?我們要做的是以目標為導向的設計，否則毫無目的設計所帶來的產物大多是四不像。

2. 用“用戶覺得”代替“我覺得”

挖掘、定位用戶痛點是交互設計師兩件最重要的工作之一，另外一件則是解決挖掘到的痛點。在你開始講你的項目之前，花幾分鐘和你的老板、面試官介紹你的用戶群體是怎樣的?用戶是在什么場景下完成整個流程的?他們有怎樣的心理預期和行為習慣?

甚至在這個環節你可以把冷冰冰的、抽象的用戶數據串聯起來，講一個好像親身經歷的故事：比如你某次發現你們的用戶如何使用產品、他遇到了什么問題，你又是如何解決的?好的用戶故事能讓人快速感同身受，你也就不需要一遍一遍地向你的老板解釋你為什么要做一件事——用戶在這個場景下想要，就是這么簡單。

3. 介紹你的規劃和假設

每個交互設計項目上線前都是一個黑盒。用戶可能喜歡它，也可能不喜歡它。設計師之間、設計師和老板之間、設計師和產品經理之間打嘴仗永遠無法真正驗證一個問題，今天可能你發揮得好吵架吵贏了，明天可能發揮得不好只能回去揮淚改稿。

我認為為了真正說服你的聽眾接受你的方案，最好在介紹完方案后，直接說明設計方案中有哪些部分是基于推導和假設形成的：如何評估設計目標是否達到、如何進行后續優化迭代，如何制定數據指標?當然這對于一個快速迭代、或缺少數據基礎建設、孵化的產品線來說可能是比較難的，但這是所有大廠的工作方法。

4. 靠譜的方案輸出

上面講的所有建議都是針對設計展示時演講的建議。當然打鐵還需自身硬，一個交互稿能夠經得起推敲和詢問，本質上還要靠完整的方案輸出。

交互稿有有很多種形式，比較常見的就是頁面交互圖，講頁面、操作流程、組控件狀態、邊界情況描述清楚以供視覺、產品、技術、測試等同學使用。一些復雜需求，建議在方案初稿輸出后做可用性測試，這樣就不至于在評審、過稿的時候針對方案的復雜程度反復拉扯，可用性測試的證明足以一錘定音。

最后，我總結了交互設計的標準時間分布：

結合案例，到底怎么做?

最后我們再回過頭看下文章一開頭那些場景——想必現在你也知道問題是什么、該如何解決了。

場景 1

和 leader 確認交互方案時，剛講兩句就被 leader 全盤否定，導致自己帶著 leader 沒看一眼的稿子默默回到工位、從頭再來。

問題原因：在一開始需求分析階段就跑偏了，沒有搞清楚目標是什么就開始做方案，導致后面的方案全盤跑偏。

解決方案：不要過快地深入交互細節，而是要讓你的 leader 了解清楚需求的本質，對齊認知后再深入，不要被 pm 當時的方案帶偏。對方案時，可以使用數據等有利說明的方式講清楚背景和目標，讓上級快速理解需求。

場景 2

和 pm 確認交互方案時，pm 一遍一遍提出疑問、還說了 A、B、C、D、E 各種想法，導致自己的方案反復修改、無法按時交付。

問題原因：這類型的 pm 大多只看最終呈現、缺少對用戶行為邏輯的思考，非常容易陷入交互稿細節、拿不定主意。他們需要的是用戶體驗專業層面的建議，告訴他們應該采用什么是合理的。

解決方案：先把設計研究階段的結論同步給 pm，告訴他們因為是這樣這樣的問題，才有了最后的方案。溝通過程中避免一些不確定、顯得不專業的詞匯，如“我認為 XXX、可能 XX、應該是這樣的吧 XX”，建議使用“用戶在真實場景中是 XXXX、從用戶心理層面出發是 XXX、用戶習慣于 XXX”。

場景 3

向 boss 推自己的設計自驅方案時，無法得到 boss 的認同，導致最終無法爭取到開發資源、自驅項目最終流產。

問題原因：老板沒有看到做這件事的迫切性、投產比。

解決方案：和老板推項目時 PPT 非常非常關鍵。調研過程盡可能可視化出來，特別是數字、結論。方案要完整，最好配合視覺設計師呈現出最的頁面效果、用 DEMO 演示。

場景 4

面試官對作品集中的某個項目不斷發問，而自己卻難以給出令他滿意的回答，導致面試最終失敗、無緣 offer。

問題原因：大概率是存在兩點問題：1. 項目沒有達到設計閉環，缺少某一環節，比如設計研究不充分、缺少效果評估;2. 設計研究結論與設計目標、策略沒有完美對應，面試官質疑方案是否是以目標為導向、是否可以解決問題

解決方案：檢查整個設計過程中是否缺環節，特別是效果評估的數據指標應如何選取、如何分析;檢查設計推導過程和最終策略、方案是否對應，邏輯要嚴謹。