@黃紅藝Designer ：還沒有跨入交互設計的門檻時，總是想明確的知道一些客觀、確定的事情。比如，想知道交互設計的具體流程是什么，交互稿到底長什么樣子，Axure 中的Case 用例怎么用以及加載動畫怎么做，總希望有人能給一個交互設計的原型案例作為模板。

本篇教程適用對象為入門1~2年的設計師以及各大院校的設視覺專業學生，通過講解學習方法和思維方式進行解析如何快速提升，希望對大家有些幫助。

今年很多文章都猜測對話式交互會成為2017年熱門趨勢，但關于對話式交互的解讀還不是很多，本文詳細分析了對話式交互的優缺點和應用場景，強烈推薦閱讀。

一、要想火，傍大腿

對話式交互，顧名思義，就是像兩個人對話一樣的交互方式。可以是文字的，也可以是語音的。我們每天都用的微信，你說一句，我說一句，就是典型的對話式交互。

編者按：很多新人交互設計師做出方案后一直無法和產品經理達成共識，而他們可能都沒意識到，一個專業的交互設計流程就可以解決大部分問題。

王鎮雷：首先，要感謝我的 Leader 和師姐，在他們的幫助下，我才理清了這個交互設計流程。

雖不敢說這套方法一定是最優的，但至少是我工作以來一個專業上的里程碑。

話不多說，直接開講。

日常工作中，常見但錯誤的交互設計方法有：

• 產品經理提了需求，立馬動手畫圖；
• 設計中才查看競品，并且沒有特定分類，想到哪個看哪個；
• 執著于具體的設計細節；
• 提交/評審方案時，沒有設計過程，直接提供稿子講解結果。

普通應用在起初的三天里每天會流失77%的日活躍用戶。

        你肯定不想你的公司發生這樣的事情，為獲得新用戶而投入了眾多資源，而大多數用戶僅僅在首次訪問之后便馬上離開了。如何改善這種情況呢？即你需要通過創造完美的訪問流程為用戶留下非常棒的第一印象。

隨著網絡傳輸速度的提升，視頻在網頁中的應用越來越多，也越來越廣泛，帶寬和流量對于網頁視頻的限制已經不再像5年前那么明顯。而移動端設備的性能的提升，在移動端網頁中使用視頻也并不顯得吃力。所以，今天我們常常能在不同的網頁中看到各種不同功用的視頻。

常言道一圖勝千言，而視頻比起圖片所能承載的信息量更大。如果能夠有效的使用視頻，它對于用戶的吸引力會非常明顯——它可以更好的傳遞情緒，更加富有表現力，能讓用戶更容易“感受”到你想要傳遞的信息。不過，相比于其他元素，視頻都比較“重”的媒體，使用的時候要謹慎。

@薛斯塔 ：交互設計師和產品經理的協作問題是產品設計中的一個老大難，我在工作中經常會聽到同行對產品經理們的血淚控訴。作為交互設計師，學會和團隊中不同的角色協作是我們的專業能力之一，如何溝通、影響乃至于推動自己的設計方案進行實施是每一位設計師需要去磨練的，這不僅僅是那份執著，更是一種技巧。

下面進入譯文。

在互聯網行業，交互設計師還是一個相對比較新的職位。因此，在工作中我們常常見到產品經理過多介入交互設計師的工作，甚至有的團隊直接讓產品經理來做交互設計的工作，這是為什么呢？實際上，在互聯網發展的早期，這確實是同一個人的工作！產品經理的職能之一就是支持和協助部署交互設計方案，以確保產品的方案可行性。隨著互聯網的成熟發展和工作職位的細分，交互設計師這個被細分出來的角色被定位出來設計產品的交互方案是威脅到了產品經理的工作范疇。

因此，在日常工作中，產品經理和交互設計師這對冤家是一直在暗中腳力的，交互設計師的方案每每遭到產品經理的質疑甚至是無視，這其中有專業能力層面的合理分歧，當然也夾雜著一些主觀層面的感受之爭，最終導致的是產品經理經常性的忽視來自體驗設計團隊的一些方案建議。那么，我們如何才能改善兩者之間的合作關系，從而使兩者能夠客觀的協作制定合理的體驗設計方案呢？

@凌霜設計 （Frog Design交互生）： 作為一名交互設計師，如何更好地與項目里的其他人合作？如何更好地利用大家的時間？團隊經理用畫圖的方式跟我解釋了一下，有些問題并沒有直接的答案，但是我覺得解釋的方式很有趣，我憑著記憶把它們重新畫了一下，和大家聊聊合作的問題。

今天和我的經理聊了一下最近工作上發生的事：上周做了什么，這周和下周準備要做什么。剛剛結束了設計階段（Design Sprint）1，和客戶開了遠程會議，收到了許多的反饋意見，各個方面的都有。

現在項目正處于一種（我覺得）特別尷尬的階段：視覺設計師只出了初步的幾個概念圖，程序員還在準備框架，尚未開始寫代碼，但是根據原先的計劃，這周就要開始開發了。作為交互設計師，一方面留著一大堆反饋意見還沒有反映到線框圖中，另一方面設計階段2的任務已經要來了。雖然還沒有開始設計，但從可能的流程上來看，任務量巨大，是一個特別復雜的系統，不光是設計一個新的交互方式，還是新的工作方式和商業模式，心里真沒底。

我把自己的困惑告訴了經理：作為一名交互設計師，如何更好地與項目里的其他人合作？如何更好地利用大家的時間？他用了畫圖的方式跟我解釋了一下，有些問題并沒有直接的答案，但是我覺得解釋的方式很有趣，我憑著記憶把它們重新畫了一下，和大家聊聊合作的問題。

什么是敏捷開發（Agile）

先說一下總體的合作方式，我們用的是敏捷開發（Agile）的方式。維基百科上是這么解釋的：

敏捷軟件開發（英語：Agile software development），又稱敏捷開發，是一種從1990年代開始逐漸引起廣泛關注的一些新型軟件開發方法，是一種應對快速變化的需求的一種軟件開發能力。它們的具體名稱、理念、過程、術語都不盡相同，相對于“非敏捷”，更強調程序員團隊與業務專家之間的緊密協作、面對面的溝通（認為比書面的文檔更有效）、頻繁交付新的軟件版本、緊湊而自我組織型的團隊、能夠很好地適應需求變化的代碼編寫和團隊組織方法，也更注重軟件開發過程中人的作用。

如果把這種方法簡單視覺化一下，就如下圖：

我們整天都在說用戶體驗，設計師要站在用戶的角度思考問題，幫助用戶解決問題，優化產品操作流程及視覺層級的排布，作為設計師我們這么做的目的到底是什么，我們為什么要為了一個體驗細節和產品去討論，去爭執.

13年底，Intercom 的產品VP Paul Adams 在 Intercom 官博發表了 一篇博文 。文章講述了網絡上設計社區里普遍存在的一種現象，大意是“許多設計師在社區中分享的作品往往是為了炫技，而產品的邏輯通常都經不起推敲的，真正優秀的設計應該從更高的層面出發，而不只是做表面上的工作”。

文章發布后，在 Twitter 、HN 及博客評論下引起了反響。雖然部分內容在一些設計師眼里看起來比較有攻擊性（也就是俗稱“開噴”），甚至還帶有些地圖炮，但是文中關于“設計的四個層次”以及“when..I want to..then I can...”等設計觀點和方法論都非常值得我們回味并運用到工作當中。