工作流程
交互設計師的工作，不僅僅是輸出設計方案，還需要參與前期的需求討論、後期開發、測試驗收等等產品設計與實現的多個環節。拿到一個新的項目需求後，從設計思考開始，產品前期分析，設計產品，設計評審，用戶測試，直至產品上線。我們的工作流程如下：
項目展開的過程中，必然會產生一些輸出物，以下是我們歸納出的輸出產物以及可以同步的平臺彙總。
需求分析階段
需求分析是軟件計劃階段的重要活動，也是軟件生存週期中的一個重要環節，該階段是分析系統在功能上需要「實現什麼」，而不是考慮如何去「實現」。需求分析的目標是把用戶對待開發軟件提出的「要求」或「需要」進行分析與整理，確認後形成描述完整、清晰與規範的文檔，確定軟件需要實現哪些功能，完成哪些工作。此外，軟件的一些非功能性需求（如軟件性能、可靠性、響應時間、可擴展性等），軟件設計的約束條件，運行時與其他軟件的關係等也是軟件需求分析的目標。
越是高階的交互設計師，越要有產品思維，越要從產品全局、產品源頭去考慮用戶的訴求。所以這個階段雖然是產品經理、產品設計師更偏重的知識點，但作為交互設計師也應該逐步積累這方面的技能。
1. 用戶研究報告文檔
文檔的價值與目的
為什麼要進行這次調研？可以是為了確認產品功能是否好用，可以是瞭解用戶喜好，可以是為了推廣新產品。以這次調研為例，目的是通過用戶調研，理性瞭解用戶，根據他們的目的、行為和態度差異，將他們區分不同類型，然後從每種類型中抽取出典型特徵，賦予人群畫像，最終挖掘出不同人群對產品的偏好和潛在需求，以及對品牌的認知程度，從而指導市場推廣和產品設計。
文檔的目錄結構
2. 用戶畫像
用戶畫像是在真實數據的基礎上嚴格定義出的高保真虛擬用戶，是真實用戶的虛擬代表。用戶畫像不是真實用戶，但是在設計過程中代表了真實用戶，用戶畫像不是虛構的，是嚴格研究出來的。
此處需要區分人物角色和用戶畫像的概念，通常人物角色運用於產品概念早期，人物角色的信息通常是由我們編造的。我們希望人物角色與我們所收集了解到的內容保持一致，同時為了使人物角色更加栩栩如生，他們的一些具體細節可以是虛構的。用戶畫像則是群體定量統計分析，對用戶進行標籤處理，海量數據挖掘所得。需要特別指出的是，也有一部分人將角色和畫像視為同一個概念，只是隨著產品階段不同處於不斷變化的過程之中，功能作用也隨之不同。
用戶畫像的目的
為保證產品是為有需求的人設計，同時為產品設計提供依據。有助於瞭解並定位目標用戶，挖掘核心需求，豐富場景，進行趨勢預測。
3. 產品功能列表
當需求分析、篩選和評定優先級之後得出結果，交互設計師需要把產品功能以列表的形式展現出來。這是需求分析之後，提出解決方案的第一步。
產品列表的價值
功能需求列表的價值，一是幫助產品經理理清思路，二是幫助項目團隊的其它成員瞭解產品功能需求，好讓他們提前做好相關準備。
功能列表的內容：
- 模塊：一般來說，每個模塊下分 3~6 個子模塊是合理的，否則要考慮重新劃分。
- 子模塊：也就是一級模塊的二級分類，這裡就已經涉及到產品架構的梳理了，但這裡只是大致地梳理一下，後期在產品設計的下一個環節「搭框架」會進一步調整。
- 功能：要給用戶提供什麼功能，給這個功能起個名字。
- 功能描述：這個功能具體包含哪些操作，可以描述的具體一些，如支持用戶填寫基本信息可自由創建課程，進入課程空間就可對課程進行編輯和管理，還可發佈、刪除課程等。
- 用戶價值描述：也就是可以給用戶提供什麼價值。
- 需求優先級：這塊是整個 Feature List 工作中核心的部分，判斷的準確與否直接影響著將來產品的方向，我們只需要將我們之前評定的需求優先級照抄過來就好。
- 開發量：一般由研發部門的項目經理或者開發來確定。
- 投入產出比：簡單來說，就是商業價值除以開發工作量（或開發難度），當然每個團隊可以找出一個合適自己產品需求 ROI 的計算方法。
- 備註：覺得需要強調的，比較特殊的東西。
4. 場景故事板
故事板，起源於動畫行業。在電影電視中，故事板的作用是來安排劇情中的重要鏡頭。他們相當於一個可視化的劇本，故事板展示了各個鏡頭之間的關係，以及他們是如何串聯起來，給觀眾一個完整的體驗。
現在，「故事板」在產品設計過程中也被廣泛的採用，雖然產品設計故事板和動畫、影視製作故事板都是用一系列的圖片和語言組成的視覺表現形式，但是之間所表達的信息和目標用戶卻是不一樣的。
故事板的價值
我們在做「產品設計故事板」的目的是讓產品設計師在特定產品使用情境下，全面理解用戶和產品之間的交互關係。
原型設計階段
搞清了產品定位後，就到了原型設計階段，這個階段交互設計師需要撰寫交互文檔。交互文檔，即交互設計說明文檔。英文「Design Requirement Document」，縮寫「DRD」。 主要是用來承載設計思路、設計方案、信息架構、原型線框、交互說明等內容。
DRD 非項目必需環節，一般情況下也不會為交互設計師專門留出相應的時間預估。沒有這份文檔，項目也會繼續，但是可能項目會為此承擔不必要的溝通成本和時間成本。嚴重的話，項目的質量也會受到影響。所以寫與不寫，交互設計師需要做把握。
以下是 DRD 的目錄結構：
因為是非必要環節，這裡就不詳細介紹了。
在一款產品的設計過程中，功能結構圖是必須的，信息架構圖視產品和 PM 自身而定，通常我們初步確定了產品功能結構圖（產品功能框架）之後才開始繪製產品結構圖。在產品設計流程中，產品功能結構圖是產品概念化階段的初期輸出，產品結構圖是產品概念化的尾期階段輸出物，當產品結構圖完成後，我們對產品的基本模樣在心裡就有了一個輪廓。同時以產品結構圖作為繪製線框圖的依據，可以避免我們在產品設計中邊畫邊改，跳進死掐細節，不見森林的陷阱。
1. 流程圖的基本構成和常用符號
流程圖由特定的圖形構成，但具體樣子由圖本身的目的和閱讀者的閱讀習慣或約定來確定，所以使用的圖形並不是固定的，形式並不是最重要的，達到描述效果且讀者能讀懂即可。
2. 業務流程圖（泳道圖）
業務流程圖，不是操作流程圖也不是頁面流程圖。它是產品的整體業務流程，直接和業務掛鉤，可以說是產品的核心流程。
作用
通過業務流程圖，鑽研關鍵事件的流程，分析為什麼要這麼做，探索出更深層次的問題，從而對現有不合理的業務流程進行重組優化，進而制定優化方案，改進現有流程；闡述在項目中各個角色是如何產生相關聯繫的。
繪製規範/建議
- 讓涉眾參與，不要閉門造車：與業務流程圖包含的各個參與角色代表適時確認事情的原本流程，杜絕自己想象。
- 恰當的層次分解，不要將所有的環節都鋪到一張圖上。
- 逐漸深入，先抓枝幹：切忌一開始就陷入細節。
- 流程一定有開始和結束：用清晰代表開始和結束的符號來完成第一步和最後一步。
- 流程圖符號繪製排列順序：由上至下，由左至右。
- 同一流程圖符號大小宜相對一致。
- 編號：這是讓溝通效率提高的優化措施。當你有了編號系統，相當於對你的流程圖都賦予了唯一識別身份證號。 負責流程規則審核和優化的部分能夠清楚地在郵件裡傳達：H5.1流程優化，大家就更明確指的是什麼。
- 路徑符號應避免互相交叉。
3. 功能結構圖
功能結構圖就是按照功能的從屬關係畫成的圖表，在該圖表中的每一個框都稱為一個功能模塊。功能模塊可以根據具體情況分得大一點或小一點，分解得最小功能模塊可以是一個程序中的每個處理過程，而較大的功能模塊則可能是完成某一個任務的一組程序。用通俗的話來說，功能結構圖就是以功能模塊為類別，介紹模塊下其各功能組成的圖表。
作用
- 梳理需求，以鳥瞰的方式對整個產品頁面中的功能結構形成一個直觀的認識。
- 思考並明確產品的功能模塊及其功能組成。
4. 信息架構圖
信息架構屬於用戶體驗的結構層，是產品的骨架。一般是由產品經理或者更高層的管理人員給出大框架。除非是大的產品迭代，否則不會大改。
作用
- 幫助 PM 梳理複雜內容的信息組成，避免信息內容在展示過程中出現遺漏、混亂、重複；
- 作為開發工程師建立數據庫的參考依據。
信息結構圖構成要素
- 導航：網頁訪問者的訪問途徑。
- 頻道：某一個同性質的功能或內容的共同載體，也可稱為功能或內容的類別。
- 子頻道：某頻道下細分的另一類別。
- 頁面：單個或附屬某個頻道或分類下的界面。
- 模塊：頁面中多個元素組成的一個區域內容，可以有一個或多個，也可以循環出現，如文章列表。
- 模塊元素：模塊中的元素內容，以文章列表舉例，文章標題、文章摘要、文章發佈時間，這些都是元素，都是組成模塊的內容，同時他們也是可以循環出現的。元素的類型可以是文字、圖片、鏈接等等。
5. 任務流程圖
任務流程圖就是通過圖形化的表達形式，闡述產品在功能層面的邏輯和信息。它能夠更清晰、直觀地展示用戶在使用某個功能時，會產生的一系列操作和反饋的圖標。
作用
基於業務流程，進行任務流程梳理，闡述角色和程序發生交互的流程，你如何進行操作，系統如何進行反饋。
任務流程與需求文檔中的業務流程並不一樣。雖然它們都是流程圖，但業務流程更偏向於業務限制、後臺邏輯等，並不過分注重用戶的操作邏輯。而任務流程則需要關注用戶如何操作、界面如何反饋等，從而引導用戶完成用戶目標。
6. 產品結構圖
產品結構圖是綜合展示產品信息和功能邏輯的圖表，簡單說產品結構圖就是產品原型的簡化表達。
作用
它能夠在前期的需求評審中或其他類似場景中作為產品原型的替代，因為產品結構圖相較於產品原型，其實現成本低，能夠快速對產品功能結構進行增、刪、改操作，減少 PM 在這個過程中的實現成本。
7. 線框圖
頁面線框圖，是通過圖形化的表達形式，闡述產品在頁面層面的信息。
構成要素
- 頁面標題：即每一個頁面的對應標題，一般就是導航欄標題。
- 頁面內容：以黑白為主，保證信息規整易讀。
- 交互說明：用標籤將其對應起來，包括交互邏輯、操作流程及反饋、元素狀態、字符限制、異常/特殊狀態、相關規則等等。
- 主流程線：只需要畫出主流程線即可，千萬不能太多太雜，時刻考慮讀者的感受。
8. 交互說明的幾種類型
限制
限制，包含範圍值、極限值等。
範圍值主要指數據的取值範圍。比如，當你的界面上出現了下拉菜單、篩選按鈕、滑塊等控件時，你必須標註清楚它們的選擇範圍，否則開發人員就不清楚該如何設定，如圖所示。
極限值主要指數據的顯示限制。比如，最多應該顯示多少字數，過時如何顯示，是否折行等，如圖所示。
狀態
包含默認狀態、常見狀態、特殊狀態等。
默認狀態主要指默認顯示的文字、數據、選項等。這些內容需要註明，否則開發人員可能難以意識到這是用戶填完的效果，還是默認就有的。
常見狀態主要指針對某-一個模塊，經常遇到的一些狀態。這些狀態都需要在原型上表述出來。比如一個普通的積分模塊，一般會出現3種狀態:未登錄狀態、登錄後未簽到狀態、登錄後已簽到狀態，如圖所示。
特殊狀態一般指非正常情況 下的樣式、文案、說明等，如圖所示。
操作
包含常見操作、特殊操作、誤操作、手勢操作等。
常見操作主要指正常操作時得到的反饋狀態。比如一個普通的翻頁控件，在經過不同操作後會立即出現如下的狀態。
特殊操作主要指一些極端情況下的操作。一般，用戶不會這麼操作，但是-旦遇到極端情況，還是要想好應對措施，因為對於開發人員來說，不管是正常的還是極端的操作情況，他們都要去編寫對應的代碼。如下圖，是填寫用戶信息的例子，當不寫交互說明時，開放往往會遇到很多問題：如果已經勾選了2個人，再勾選第3個人，怎麼辦?如果勾選了「張XX」,下面區塊中會相應地出現張XX的信息，那麼這時候允許修改張XX的身份證信息嗎?假如允許的話，修改後「張XX」還保持勾選狀態嗎?表單提交後要新增一-個被保險人信息嗎?若修改的是除身份證號碼以外的信息，「張XX」 還保持勾選狀態嗎?提交表單時是覆蓋原存儲信息嗎?若修改後出生日期、性別與身份證號碼不吻合怎麼辦?……
面對各種複雜的情況，一方面，要和開發人員積極探討，看看有沒有其他的解決方法可以簡化各種邏輯判斷;另一方面，在得出結論後，要把交互說明寫清楚，避免出現讓開發人員感到棘手的情況。
誤操作主要指當用戶操作錯誤時的情況。不過我們在設計時要儘量避免用戶犯錯的機會。如圖所示，提示中已告訴用戶「庫存5件」，如果這個時候用戶在「數量」一欄中輸入「6」會怎麼樣呢?系統會自動幫用戶將其改為「5」省去用戶手動修正。
手勢操作主要指用戶使用移動產品時的操作方式。常見的有點擊雙擊、長按、捏、伸、滑動，等等。
反饋
用戶操作後得到的反饋動作，包含提示、跳轉、動畫等。
提示主要指操作後，系統反饋給用戶的文字說明等，如圖所示。
跳轉主要指點擊某個鏈接後，頁面跳轉到哪裡。設計師需要在原型;上註明跳轉時是「原頁面刷新」還是「新頁面打開」。如果是做手機應用的話，需要註明跳轉時的轉場方式，如圖所示。
動畫主要指用戶操作後，系統通過動畫的方式反饋給用戶。動畫給人的感覺比較友好、趣味性較強，是非常常見的一種反饋形式。比如刪除某條信息，該信息以漸變消失的形式告訴用戶:這條信息已經被刪除了。
在移動應用中，動畫反饋的形式更為常見。因此設計師一定要在原型上表述清楚動畫的形式，必要時可以製作-段動畫演示效果給開發人員。
更多交互說明的內容可參閱《破繭成蝶-用戶體驗設計師》
視覺設計階段
在視覺設計階段，交互設計師需要向視覺設計師介紹交互原型；對輸出的視覺設計方案，需要從交互角度予以評估，比如與交互設計初衷是否一致、內容的主次是否表達得當、是否有細節遺漏或錯亂等等。另外，這時DRD中的全局通用說明也將起到了很大的作用。視覺設計師可以通過全局通用說明，瞭解到整個產品界面中需要用到的控件、可複用界面、時間規範、卻省頁彙總，以便視覺設計師整理梳理視覺規範，防止出高保真時遺漏界面。
1. 全局通用說明
全局通用說明，指整個產品可通用或者複用的元素。一般是邊做文檔邊整理出來的，方便自己或者接手該項目的設計師直接調用。其次，對開發及時封裝可複用控件也是有參考價值的。
常用控件
常用控件類似UIKit，通常將極具複用價值的控制整理在一起，方便及時調用。
複用界面
顧名思義就是全局可複用的一些內頁，比如選擇聯繫人、獨立搜索頁等。
時間規範
在做產品的第一步，就應該約定一個時間規範。不然各個端開發出來，你會發現iOS是斜槓的，Android是橫槓的，WEB是圓點的。
缺省頁彙總
缺省頁一般包括加載失敗、加載中、網絡中斷和無數據的空頁面。為空頁可以按照模塊整理在一起，方便UI設計師最後一起設計缺省頁，保持風格統一。
2. 功能動效
用戶往往比我們預想中更能注意到頁面中的細節，動效除了要幫助用戶快速找到他想要的東西，達到他想完成的任務，也是一種可以給用戶傳遞情感的交互元素。沒有用戶會拒絕任何產品的錦上添花，而功能性動效對於產品來講，在滿足功能效率的同時，能夠帶來更多額外的附加體驗，是一種相對比較容易引發體驗峰值的途徑。好的交互設計師應當對這些功能動效有比較深刻的理解，在視覺設計階段可配合視覺設計師給產品加上合理的功能動效。
定義：
功能性動效是一種嵌入 UI 設計中微妙的動畫，有著明確、合理的目標
功能性動效的主要類型：
- 頁面空間轉換；
- 視覺信息反饋；
- 功能操作引導；
- 品牌與趣味；
頁面空間轉換類動效
頁面空間轉換告訴用戶對象和窗口的狀態是如何變化的，防止頁面轉換視盲，在空間上也能營造更好的印象。
案例：輪播 Banner 中的空間轉換動效
視覺信息反饋動效類型
具備良好用戶體驗的產品，都應該給用戶的每一個操作提供反饋，無論成功與否，反饋會使用戶覺得自己與屏幕上的元素進行真實互動。即便隔著屏幕，也能讓用戶看起來是在直接操作，增加操作的可控性真實自然的體感。
案例：操作結果反饋
功能操作引導
當用戶第一次使用你的 app 的時候，如果沒有幫助的話，他們可能會不知道如何操作。 我們應該給用戶提供一些視覺提示來告訴他們哪些操作是可行的。
案例：功能操作中的引導
品牌與趣味
為了避免與市場上很多 app 同質化，千篇一律的用戶體驗，品牌動畫可以成為一個產品的營銷工具，用來表現一家公司的品牌價值或者突出產品的優勢，同時給用戶一種愉快又難忘的用戶體驗。
案例：功能操作中的引導
關於功能動效的更多介紹可查看以下文章：《最常見的四種移動端功能性動效全面總結》
開發與測試階段
1. 驗收的常規流程
- 測試完成功能驗收，將代碼打包提交給設計師驗收
- 彙總驗收問題
- 將問題提交開發解決，跟進解決的進度和結果
2. 驗收的內容
- 交互流程
- 交互邏輯
- 頁面元素的交互細節
- 交互動效
- 操作的易用性與使用體驗
- 驗收到非本次需求的其他問題
- 移動端項目分別驗收iOS與Android端
蒐集用戶反饋階段
對於迭代中的產品來說，這一點需要持續關注。通常採用的方式是用戶調研、可用性測試、各種用戶反饋渠道蒐集。交互設計師需要分析用戶反饋問題的合理性、是否需要優化。對於值得重視的反饋，需要思考設計方案、推進實現。
1. 收集用戶反饋
想要收集用戶反饋並不複雜。對於線上的產品，可以在界面上放置一個「用戶反饋」入口，讓用戶在遇到問題時，直接填寫反饋信息。對於新產品以及重大的改版，可以通過電子郵件、首頁鏈接等方式主動發放調查問卷，收集用戶意見。如果你的產品有在線客服或是產品論壇等功能，也可以讓客服把每天諮詢最多的問題收集彙總給你，或是直接「潛伏」到論壇中看看用戶的吐槽，獲取第一手反饋資料。
對於移動應用來說，還有一個最方便簡單的辦法來收集用戶反饋，那就是應用市場。無論是蘋果的App Store, 還是安卓的Google Play， 又或者是豌豆莢、應用助手等第三方應用市場，都可以找到大量的評分、評論信息。我們可以好好利用這些免費的平臺來收集移動端的用戶反饋。
2. 可用性測試
可用性測試（usability testing）是一項通過用戶的使用來評估產品的技術，因為它反應了用戶的真實使用體驗，所以可以視為一種不可或缺的可用性檢驗過程。也就是說，可用性測試是讓用戶使用產品的設計原型或成品。通過觀察，來直觀的記錄用戶的感受和體驗，從而改善及提升產品可用性的方法。
可用性測試適用於產品發展的各個階段，包括前期設計開發階段到後期優化改進階段。做可用性測試價值在於能夠在不同的階段更加高效的發現問題，從而提高問題解決效率。
3. A/B測試
AB測試的概念來源於生物醫學的雙盲測試，雙盲測試中病人被隨機分成兩組，在不知情的情況下分別給予安慰劑和測試用藥，經過一段時間的實驗後再來比較這兩組病人的表現是否具有顯著的差異，從而決定測試用藥是否有效。
互聯網公司的AB測試也採用了類似的概念：將Web或App界面或流程的兩個或多個版本，在同一時間維度，分別讓兩個或多個屬性或組成成分相同（相似）的訪客群組訪問，收集各群組的用戶體驗數據和業務數據，最後分析評估出最好版本正式採用。
從對AB測試的定義中可以看出AB測試強調的是同一時間維度對相似屬性分組用戶的測試，時間的統一性有效的規避了因為時間、季節等因素帶來的影響，而屬性的相似性則使得地域、性別、年齡等等其他因素對效果統計的影響降至最低。
4. 一些注意點
注意android與ios平臺交互差異
尊重不同平臺的用戶習慣，是交互設計師在工作中應該注意的環節。在產品設計中，遇到兩大平臺不同的交互時，交互設計應當：提升用戶體驗形成模式做成控件庫，保持-致性差異不大的地方統一，減小研發和設計的成本。
android與ios十大產品/交互差異：
- 虛擬商品 支付規則和方式的不同
- 狀態欄交互的不同
- 下載方式和狀態的不同
- 軟件更新方式的不同
- 文字發送指令 位置的不同
- 退出浮層列表的不同
- 刪除方式的不同
- 導航欄tab交互的不同
- 消息推送機制的不同
- 複製文字後，剪切板狀態的不同
->內容轉載自優設網
