交互設計流程中，基本按照以下3步驟進行：
第一：初步的需求分析
在初步的需求分析當中，你需要做的是什麼呢？
1、與需求方溝通，獲取最直接的信息來源；
2、與PM溝通，瞭解產品的信息重點（PM負責產品的整個規劃運籌，瞭解這些信息，有助於架構整理設計方向的籌劃）
3、儘可能的方式，瞭解一些項目目標、背景、原因等方面的外部因素（在一些項目中，可能是由公司高層來決定項目的方向，所以儘可能的去了解多方的需求）
這個過程中，可能是在產品規劃的時候，去參會瞭解，或者是在更前期的頭腦風暴中瞭解產品大致的方向，有很多不確定及變化因素，這個時候，項目還沒有真正的到交互設計階段，但交互設計師要積極參與到項目中去，在前期就對項目有所瞭解。
忌諱，這樣……….
1、需求拿來即做。——需求沒有經過初步分析過濾，交互設計師拿來就開始進行。導致的最終結果：交互設計師直接淪爲產品經理討論產品方向的工具。
應該怎麼做？——交互設計師應該基於前期的參與瞭解，及個人的經驗（有必要甚至可以叫上對應產品線的用研分析師一起），對這個產品進行初步的判斷，這個產品的可行性及合理性，如果根本不合理，這個產品就可以返回進行產品重新規劃中………
2、需求不加分析。——需求沒有經過中級的分析，交互設計師就開始着手進行。導致的最終結果，交互設計師陷入汪洋的產品規劃討論中。
應該怎麼做？——基於前一步的判斷，產品比較合理，可以接收進行。但是，這個產品給過來的需求，缺失了哪方面的東西，這些東西在我們具體架構中起着重要的作用。交互設計師應該對這個產品進行中級的分析，提取我們需要的東西，讓需求方進行提前準備。
ps：其實在有些公司，如果有比較強大的PM的總體把控組織的話，這個初步需求分析，可能會在立項及相關的溝通中解決掉。但在PM不夠強大的時候，IA其實分擔着這部分工作，而且這個過程中，發現交互設計師的前期判斷溝通還是很重要的。以上兩種情況，在項目中也見到有人遇到類似的情況，在前期糾結了1個月，還是裹足不前，其實，這些在前期的分析中都可以避免掉。
第二：具體架構設計
前提：需求方已經確定通過了產品前期規劃，並且具體的需求已經80%完備，就可以開始着手進入到具體的架構設計階段了。
一定要記得：Think first，Design next！
其實，在做一個需求或者產品的時候，我們動手做的時間只佔了10%——20%，80%——90%的時間在前面的階段。
前期遇到一個“手機定時提醒”的一個需求，當時對應人員的處理，只是根據需求方的描述在具體頁面加一個輸入框及鏈接，而沒有分析對應的業務需求及相關任務聯繫，導致只做出來了20%的東西，漏掉了80%的東西，反覆修改調整了4次。只見樹木，不見森林，在具體的元素中迷失了…………..
1、詳細需求分析階段
確定着手做具體的產品了，就需要進行詳細的需求分析階段了，在這個階段，我們需要做的：
1、梳理需求，找到最核心最真實的業務場景、功能。
2、瞭解業務功能邏輯，有助於進行交互流程設計
3、對信息進行初步的整理、篩選、分析
傾聽業務的心聲，分析討論業務的邏輯、目的、內容，梳理業務特殊需求及模擬用戶的邏輯。
2、任務流程階段（Task Flow ）
任務流程是根據前期PM提出的業務邏輯流程，根據用戶的操作及心理模型搭建出來的任務流程圖，任務流程圖，是梳理主流程任務，瞭解核心功能目的，清楚不同的場景，業務流程直接關係着頁面流程及場景頁面的設計！
3、頁面流程（Page Flow ）
頁面流程，是架構必須的步驟，它能從整理角度把握整個架構，是整個架構的網站地圖（sitmap），包括頁面的整個流轉，頁面的入口、出口等。
在架構圖交付物中，頁面流程也是整個框架的第一步。
4、線框圖（Wire frames）
在線框圖中，基於前面的分析準備，爲了展示信息結構、功能設置、用戶操作使用習慣，我們要在裏面做哪些呢？
1、展示主要的內容、功能
2、對整體的佈局、結構進行考慮
3、考慮信息的位置、順序
4、用不同的字體字號、顏色（黑白灰色）展示出其層次、輕重
在做具體的線框圖中，一般按照這3個小步驟進行，其實，這種先後順序在小的修改及項目中，可以一起進行，但涉及到較複雜的大項目，還是按照先後順序好些，不然，把它們混雜在一起，往往容易遺漏很多東西。
第一步：最正常的狀態展示——線框圖
根據8/2原則，展示出80%用戶能看到的最正常場景，確保它的信息操作順暢、一致性。這樣做，容易使你抓住主要用戶，排除其他干擾信息，思路明瞭清晰；有助於能先從整體角度把握產品框架、流程，不至於陷入小細節的糾結中………..
第二步：全場景的狀態展示——線框圖
把正常場景設計出來以後，就要進行分模塊的全場景架構設計了，如果場景甚多，建議，先列出全部清單，在逐個進行設計。上面示意圖爲購物車1、2的場景展示，其中只是列出了部分，因爲屬於操作型頁面，所以要把全部的狀態展示出來，整體有30多種，所以，用這種方式，就不怕漏掉了。
第三步：交互說明文檔——線框圖
交互說明文檔，是基於全場景架構設計出來之後，最終要交互出來的交付件，這個文檔更傾向於給具體的前端開發及後臺開發人員的。裏面主要包括的內容有：
1、異常狀態（報錯、提示位置、最長字符、報錯文案場景）
2、全部頁面跳轉（鏈接、button、彈出框、新出窗口、原頁刷新……）
3、列顯示最多條目、輸入框最多字數、
4、點擊的交互前後展示狀態，點擊中的交互形式……
ps：在做架構中，會發現很多人在一些事情上迷失掉，花費了很多的時間，所以這些也是在交互設計中需要注意的問題：
1、精美細緻並不重要！——把真正的視覺塗色交給UI去做吧，他們更專業。（但架構展示要易於理解主次、信息層級的排布）
2、選擇性價比較高的工具——不要把時間花在學習工具上,工具只是輔助想法的實現，是爲了提高我們工作效率。
3、從最簡單的開始，逐漸補充細節——要培養全局觀，再注重細節修改。
4、線框圖不是“畫”出來的，而是想出來的，是確認出來的——在做的過程中，多溝通，多交流。
第三：檢查糾錯
最終我們的交互架構，怎麼確保產品符合用戶的需求呢？這就需要我們架構後的檢查糾錯步驟。對架構的檢查糾錯，可以分兩種：
1、基礎自我檢查。
這是做完架構之後自己的糾錯檢查。
包括：這是什麼網站？（名稱、logo、說明）；我在哪兒？（網站定位、麪包屑、導航、操作入口明確）；有什麼？（導航、目錄、分類）；能回嗎？（返回、新開窗口、導航、麪包屑）；相同功能、文案統一、表達一致嗎？
2、原型測試驗證。
最終做出來的架構，需要設定一定的場景或者任務流，找用戶進行測試，是否能按照正常的用戶心智模型進行。——任務排查
交互設計的工具和方法
工具：
紙和筆、Axure、Endawer / Mindmap/ conceptdraw、OmniGraffle
方法：
概念圖、可用性測試、卡片分類、角色模型、故事版、任務走查、任務流程、頁面流程、交互設計說明等