最近在做公司的一個新項目，心血來潮想總結下我做這個項目的工作流程。因為一直都有想寫一篇關于自己工作流程的文章，終于把思路理清楚，開始碼起來。
任何的工作都是不簡單的。本文主要就是描述我個人的工作流。實際工作中做的內容可能會比這里描述的還要詳細些。
附上目錄，然后再對其中提到的流程項一一進行解釋。每個人對產品的理解不一樣，工作的流程也許也不一樣。這里僅是我的一些總結，要是看官們覺得毫無價值一笑而過就是????。
1.溝通需求+搜集資料
當接到設計任務時，具體要看和你對接的項目經理或產品經理給到你的文檔到底有多細致，如果不清楚的地方當然就是溝通了，工作中溝通是很重要的。從接到的文檔中，了解、分析需求，搜集相關產品資料。這次我接到的是APP功能清單文檔及已完成的web端管理平臺地址和賬號。
在不知道產品背景、產品目標、目標用戶的介紹。只能從web端頁面，功能清單了解到該應用是一個管理及監控蓄電池的應用。溝通知道，應用的用戶群是電站的保安及管理人員。
之前在掘金看到一篇用戶體驗的文章說到產品的分類 。
產品分類：功能型的的平臺類產品，關注的是任務，所有操作都被納入一個過程，去思考人們如何完成這個過程。信息型的媒介類產品，關注的是信息，產品應該提供哪些信息，這些信息對用戶的意義是什么。
看了到手的相關資料后，知道這是功能型產品。也明白了產品功能框架不算復雜，信息流分支也清晰。開始資料搜集過程：
- 搜競品
會到App Store搜索同類產品，把能想到的關鍵詞都拿來搜一遍。由于很多都是供內部人員自己使用的產品，即使下載了APP，沒內部賬號是看不到應用內頁的，只有看看應用商店的截圖，然后截圖保存下來，方便隨時查看。 - 網上查資料
我還會到網上搜一搜，看有沒有同類產品的網站，進入網站看看關于產品的介紹，以此了解這到底是個什么應用。在看了十幾或者二十幾個產品后，心里面應該大致有個你要規劃的APP的信息架構了。之前有看到一位筆者的文章說會參考上百個APP。時間緊任務重的親們還是平時多積累，以免要用時才發現時間不夠。
2.梳理產品信息架構
我一般會用xmind來梳理，對照著功能清單、web頁面、同類產品截圖，梳理飛起來。
信息架構其實也就是你要設計的這個應用的信息層級。信息架構梳理完了，這個應用的功能也算規劃完了。接下來就是出交互稿了。
3.繪制大致交互線框圖+對接上游
交互的過程主要是負責與上游的對接，把需求轉化為功能，推動項目按照計劃完成。上游即是交給你設計需求的人，或許是產品經理、項目經理、市場部等，也可能你的終極大 boss提的需求@～@
通過axure的站點地圖其實就可以大致看出應用的結構。站點地圖的結構與xmind梳理出的產品信息架構是保持一致的。規范的交互稿是應該配上更新日志的，記錄交互稿的更新信息，便于日后的查看。
業務流程圖：描述應用內個功能間的業務關系、順序和信息的流向。
交互稿：交互稿包含了流程圖、界面圖、交互說明等。
飛機稿：用于存放被廢的頁面，以防后期可能會用到。
交互稿的站點地圖每個人有每個人的建立方式，只要便于查看，結構清晰就好。此次應用的線框圖其實是并沒有畫完的。項目經理希望盡快給出可供開發直接使用的頁面，即交互在視覺稿中進。因此后續就沒畫原型，直接上手視覺效果圖了。
展示一張交互稿頁面，頁面中大致包括：頁面必須的元素、交互說明。平時也會畫web端的原型，放張比較干凈點的，交互細節說明比較少的，web端很多都是靠溝通和概要設計去說明了設計思路了。
今年5月下旬的時候負責的這個模塊的設計相關工作。一些頁面的跳轉都是直接與負責這個模塊的開發人員及時溝通進行的。
4.視覺設計
- 定風格
首要任務就是解決主功能頁的設計，以此確定整個應用的視覺風格。主要確定的內容包括顏色、字體、圖標三大塊。 - 出視覺設計規范
風格確定以后就可以出一個對應的視覺規范。視覺規范主要應該包含:規范說明、顏色、文字、圖標、控件樣式等。后續的設計都參考這個規范，同時也保證了界面輸出后風格的統一。當然規范是死的，設計是活的。針對應用中的特殊頁面，我們需要先學會規范，遵循規范，再去打破規范設計。 -
加入UI成員，趕進度
定下設計風格，出個別頁面和視覺規范后。我的工作算是完成的差不多了，再加入一個UI妹紙，趕設計稿，追進度就OK了。在設計過程中，我也會經常和UI妹紙溝通，確認頁面元素，畢竟沒出原型嘛，還是溝通解決問題了。
首頁樣式篩選
5.對接開發+優化改善
視覺稿的設計過程中，都是出一部分，然后與項目經理確認。確認后的頁面就開始切圖定位，上傳SVN通知相關開發人員。開發人員在未拿到視覺圖的時候，前期有接到原型圖的就按原型圖搭界面框架，切圖到了就替換。沒有原型的也會看功能清單摸索著搭。出的視覺稿只要確認后，就會立即切圖定位給開發。Android和Ios并行。
開發完成后，就叫開發人員給你的手機安裝個測試下。或者公司有多的手機，你也可以借一個來測試。主要是測試下實際開發出來的和效果圖的區別。我會把開發出的界面截圖，傳到電腦和效果圖對照著審。最后把不同的地方標注出來，以文檔的形式發給對接的開發，麻煩他們對照著調整下。
最后補一點小結
整個的流程其實也就是把需求轉化為功能，功能轉化為設計，設計成功落地實現的過程。
我在本項目的角色是典型的UI/UX 通包的小團隊操作模式。這樣做的好處是你前期就可以了解業務情況與產品架構。這樣在規劃和設計起產品時就可兼顧到“好看易用”。
- 溝通非常重要，有什么需求上想不通的地方，要及時的反饋，有效的溝通。
- 設計工作中的交互稿是要做到信息交代得越詳細越好，越精確越好。如果由于時間不夠，無法做的很完善，那么就需要你和開發耐心溝通了。
- 設計交互稿、視覺稿的時候盡量不要頻繁更新，會給人一種【很不專業】的印象，開發也會很煩你頻繁的改動。
- 在設計產品中遇到瓶頸時，要想著換一種設計方法跳出現有的邏輯，或許就是另一翻天地。
