在需求階段最好和產品人員一起來探討需求文檔的細節，這對于交互設計自己理解整體的需求有幫助，也對他進行原型設計和撰寫交互說明有很好的幫助。
需求文檔大致包含的內容會有如下幾個方面：
背景描述：為什么開展這個項目?解決用戶什么問題?會有多大的價值?大致就是把項目啟動前做的功課進行一下總結說明，務必精簡明了。
用戶畫像：對用戶特征進行虛擬說明，闡明用戶情況。
信息結構圖：APP的內容組織結構。下面是舉例，簡單的給出微信的基本結構。
數據埋點：把后期需要查看的數據列成清單，比如說這個按鈕的點擊率，這個頁面的打開率等等，這個時候需要和運營多交流，對需要做埋點的地方理清楚。這對于產品上線后的數據分析很有幫助，數據也可以輔助產品功能的迭代。
二、交互設計
需求整理完成之后，接下來大致要進行的就是線框圖、頁面流程、高保真原型圖和交互說明的設計和產出。高保真原型是具體情況來定，有的公司有要求，有的沒有。
2.1線框圖：
力求簡單清晰的表達出每個頁面的視覺效果，這里最好不要加入交互，也不要搞的五顏六色，最好是黑灰色。每個情形就是一個頁面，把各個情況用頁面分別表達出來，一方面你會更加清晰APP整體的界面數量，另外設計也會更加清楚你想要什么，否則加入了交互，設計也不知道怎么點，你還得解釋半天。
比較類似之前的信息結構圖，頁面流程圖這是用各個頁面來做連接，視覺上更加清晰各個環節的銜接和跳轉。
對交互的要求會更高。需要比較完整的展現各個功能之間的交互動作，另外在視覺上盡量還原真實產品的樣子。(關于Axure，可以學習金烏的課程，很不錯，很多人覺得講的太羅嗦，但是你認真看下來還是很有收貨的)
我個人覺得，交互說明和高保真原型有重合之處，如果做了高保真，那么多數的交互動作基本上都可以展現。但是有些地方的交互動效是軟件無法搞定了，這個時候就需要你用交互說明了。
如果文字和圖片都不要說明的就直接用紙片來模擬。不要小看這種方式。
一般情況下，交互設計師講線框圖交給設計師，設計師就可以開工了。這個過程，交互也要多和設計去溝通，畢竟UI也會有自己的專業度，她會有自己的設計見解，這很正常。
四、項目執行
設計產出了，交互的工作也做完了，該去交給項目經理執行了，這個身份目前來看那只有很大的公司里才會有，一般情況下是由產品經理直接兼任了。這里需要提醒的是，在執行前，各種相關的規范要先建立起來。比如：
4.1apk、api文件的命名規范和不同類型安裝包的管理：
這里全是我個人的經驗，做好這些，會對以后安裝包的管理會有極大的幫助。我們當時把搭建了一個開發者環境，這個環境下的APK、API文件只能在局域網類使用，在這個環境下可以任意折騰和測試，不會影響到已經上線的應用。
開發者環境下打包的安裝包圖標和命名要和線上環境下的應用區別開。以后在續測試時就不會因為各個版本搞的手忙腳亂。
4.2.1開發版：純開發自己使用或者產品使用，其他無關人員一般情況下不會接觸到這個版本。網絡環境：僅特定網絡環境下使用(需要技術人員搭建環境)。
4.2.2公測版：經過產品和測試人員的詳細測試后，基本沒有什么BUG了，就可以拿出來給公司的人使用，也算是上線前的穩定性測試。網絡環境：僅在特定環境下可以使用(需要技術搭建環境)。
4.2.3商店版：準備提交到市場的APK、API文件。在經過開發版本、公測版的全面測試后，排除一切不穩定bug，此時打包的商店版仍然需要經測試人員的最后把關，最后一定要保證的是，準備上線的APK、API文件是經過測試人員的最后把關的，否則如果開發如果做了改動不通知測試和產品人員，上線后出了問題再改就晚了。
版本好號的管理，前期就要搞清楚，否則后面產品上線后，出現bug要改進，或者添加新功能后對老版本是否有影響，這個時候版本號管理的好就會起到很大的作用，一方面你可以隨時找出之前上線過的apk、API文件，另一方面面對不斷修改打包的文件不至于把自己搞混。
下面是我個人的意見，如哪個大牛有好方法可以分享出來。版本號始終是唯一的，是依次迭代遞進的，不要為了上線時版本號好看就去刻意干擾版本號，嚴禁搞多套版本號。
測試須知：
UI、交互、產品在技術人員開發階段，要多和技術人員溝通，最好是將大功能細化成小功能模塊，每次做好一部分就通知相關的人進行檢查，以免累計到最后問題過多修改動作太大。UI負責盯著開發是否按照自己的設計實現的，交互負責關注交互效果是否符合你的標準，產品負責關注各個功能的實現是否正確。
Bug管理工具：bugtags,bugclose等等，市面上有很多，多是免費的，即使是收費也不要在意那么點錢，借助bug管理工具能夠有效的提高測試人員和技術人員的協作效率。
