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