發現多用户需要，建立明確需求 提出設計方案 製作設計原型 多用户測試和評估
還是有很多對互動設計有興趣的朋友會問我這個問題，並希望我能回答得詳細，具體到我工作中的每個細節。其實互動設計需要做什麼，會隨每個互動設計師的工作內容差異而不同，具體到每個專案也會有區別。下面分享下我們 WordPress 網站建設的設計師們是怎樣做互動，方式不一定是合適，希望大家多指點，共同學習進步。
發現多用户需要的方式有很多種，我們可以在多用户反饋裏收集到許多多用户提出的想法，他們希望我們能提供幫助解決問題的產品；我們也可以主動去觀察一些生活中的資訊，為靈感的迸發做儲備。
比如説日程管理專案，有不少多用户跟我們的郵箱反應説，他們忙碌的時候會忘記一些重要的事情，比如一些會議或者約會，所以希望網易郵箱能提供一個的日程管理功能，能夠幫助他們有效的管理和安排每天的日程。
確認了多用户的這一需要，我們的產品同事就會組織立項，把用研和設計組的同事呼喚過來一起進行調研，確定我們的目標多用户。
用研組會通過問卷調查等方式儘可能多的去收集資訊，互動設計師也會參與分析調研，組織會議幫助用研組完善資訊，我們會採取一些有趣的方式，比如一堆人在一起頭腦風暴，大家回憶各種相關的生活場景，然後把一些關鍵詞記錄下來。
這一步我們的目的是要知道：多用户想要什麼？
通過這些步驟我們提煉出一些重要的功能需求，接着產品組會整理出需求文件，設計師就位。
提出設計方案
通過調研，我們得到了大量資料資訊，並建立了明確的需求，下一步就是開始提設計方案。
這個階段我會做一些概念設計，類似於做實物產品時設計一個水杯，我會描述它説：我要設計一個旅行用的水杯，它能疊成一個小圓盤，喝水的時候只需要把小圓盤的圓心部分往下按，就能變成一個杯子。
互聯網產品也是這樣，需要賦予它一個概念，例如日程管理：這是一個的日程管理功能，通過使用它，我們可以有效的管理自己每天的日程和時間，以提高工作效率，並且不會再錯過每個重要的約會！
這些文字並不一定非是互動設計師所總結，但是互動設計師必須要做到對產品心裏有數，明確我們要做什麼。
同時需要進行的還有初稿設計，在這裏我所謂的初稿，並不一定是嚴格要求中的互動原型，可以是用 Axure 把主要的頁面流程做出來，也可以手繪草圖，只要能清晰表達設計構思的，什麼樣的方式都可以。
製作設計原型
製作設計原型，也就是常説的互動稿，區別於做設計方案時的初稿，這份互動稿我會盡可能細緻的把流程和具體操作形式表達出來。
考慮到做互動是一個迭代過程，我會在設計稿的頁為設計的產品做一份互動更新日誌，記錄下互動更新時間、版本名稱、更新型別、更新內容、參考需求文件與互動負責人。
這份更新日誌的意義在於：
更新時間-便於全程跟蹤記錄專案，掌握每個時間點 版本名稱-便於專案參與人員查詢上一版本的互動稿 更新型別-瞭解每次更新需求的性質 更新內容-清晰呈現每一次更新的內容，並提供一個直接去到更新頁面的連結，這樣在進行迭代時我們的夥伴不用一頁頁去尋找更新點 參考需求文件-便於專案參與人員查詢對應的需求文件 互動負責人-記錄每次迭代的互動負責人，並能方便工作交接
互動稿的製作過程，一般是用 Axure 做原型，像郵箱這樣視覺比較成熟且相對穩定的產品，我會偏向做高保真模型，我們會整理一個控制組件庫，這樣能提高製作效率；做一個全新專案時，黑白稿線稿都是可用的方式，如果互動設計師能對大概的視覺效果有把握，也能做得精緻些。這些我想大家都很瞭解，所以不多説了。
製作互動説明
之所以把這部分內容提出來單獨寫一段，是因為之前和很多做互動的朋友討論過該怎樣做好互動説明，大家各有看法，很難找到這部分工作的衡量標準。
互動説明書在整個設計過程中，也許只會佔用小部分工作量，但是作用不小，它能幫助我們減少溝通成本，輔助互動稿描述設計理念，表達互動流程，更細緻的展現我們的設計。
與做設計稿不同，個人認為，互動説明這部分工作，需要我們更多瞭解它作説明的物件，即產品經理、視覺設計師、開發人員的需求，從而達到真正的 “輔助” 效果，而不是盲目憑自己主觀去長篇大論，否則我們要為此花費時間，而且這部分工作只能沉積為一堆我們自己欣賞毫無意義的文字。
為此我曾與合作過的各組同事進行溝通，提煉出一些他們對互動説明的需求，不求全面，但求能説明一些問題。
1. 互動説明知名是圖文並茂（all）
便於閲讀和理解。
2. 頁面跳轉的説明（產品& 程序）
頁面跳轉是涉及多個頁面關係的操作，產品人員在看互動稿時，會更多去關注多個目的性的任務操作流程，而對頁面跳轉的記憶是有限的，所以需要頁面跳轉説明。
3. 互動説明能否考慮與產品需求文件結合（產品）
開發文件會涉及產品概念、技術方案、業務執行角色等內容，和互動設計稿有着緊密關聯，所以互動説明書與開發文件是可以相互做補充，整理成一份文件，這樣也能避免工作內容重複。
4. 對互動稿中不明顯的互動動作或隱藏的設定項作説明（產品& 視覺& 頁面構架）
細節和動作需要描述清楚，比如説滑鼠 focus 、 click 的動作，或 click 後是 loading 還是跳轉，這些平時都是開會上討論，但是參與專案的人員不一定都能記住，所以會需要在互動説明書裏做説明，並需要考慮到頁面構架組需要預留適應變化的結構。
5. 產品風格定位（視覺）
商務風？休閒風？視覺需要一個準確的產品風格定位。這部分工作不一定是由互動人員來確定，但在產品孕育階段中，設計稿討論以及不定時更新的資料調查，會使得產品風格定位漸漸明確，視覺的同事更多是參與設計階段的工作，這就需要互動人員將這些資訊在互動説明中記錄下來，以輔助視覺完成。
6. 極限狀態（前端）
比如一個列表長和短顯示。
7. 異常/出錯情況説明（程序）
這一點在互動稿製作和與產品溝通過程中容易被忽略。
有的設計師會疑惑：為什麼我做的設計説明書會沒人看？我寫的很詳細了，但是他們還是會問我一堆設計的問題！甚至，問我為什麼要做這個文件？
在這些情況面前，設計師應該做些思考，我們所製作的這份説明是否真正解決問題了呢？
一些基本的邏輯判斷和文字內容，產品人員已在需求文件中列出且在互動稿中已清晰呈現，例如原型中完整呈現的設定內容，或一個單選複選關係，這些內容我們再花時間去大篇描述，並無太大意義。
所以我的理解是，互動説明並不一定是一份文字，它不該是設計師的舞文弄墨，更不該流於形式做互動設計原型的複製品。
我們可以在互動原型上註釋，在圖上寫説明，或者是在和專案組發郵件時寫為郵件內容，當然也可以是 word 文件，PPT….
總之，我們要做到的是真正解決問題，讓互動説明書成為幫助專案中各組成員之間進行有效溝通、輔助理解設計內容從而達到提高專案效率的工具，並在需要的時候被製作。
產品基本功能實現後，我們會做多用户測試，設計是很主觀的，並且會受各種因素影響，所以我們的產品難免會存在一些意料之外的問題，通過招募多用户來使用我們的產品，我們能收集到一些使用場景中發現問題的反饋，並把這些整理成優化點，完善我們的產品。
同時互動設計師也要多用自己的產品，保證上線內容與設計保持一致。
這就是我對自己互動工作的一個相對完整的描述，互動設計師這個頭銜我領了不到一年，但是這一年學到了很多。我的感覺是，這是一份不難的工作，因為我自己也是一個多用户，我會在使用產品的過程中發現這樣那樣的問題，所以我也自然而然的想去解決這些問題，並在尋求方法中得到一定的積累；然而，這確實是一份很需要花心思的工作，設計方式自由，但是設計內容需嚴謹，疏忽了一個問題，就有可能為產品帶來極大的負面影響，甚至失去多用户的青睞。
要讓我們的產品保持良性發展，就要求設計師們不斷探索優秀的設計方法。
後，也希望大家能多分享各自的設計經驗，相互學習，讓我們的產品體驗越來越好！