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