我們以前基本的流程是，領導或甲方提出需求，然後產品分析需求，並且根據需求畫出原型圖，然後根據原型圖出設計稿。 出完設計稿團隊評審，過後交與前端製作靜態頁面，然後靜態頁面，交與設計稽核，過後交給開發人員，進行動態資料的新增。 新增完之後，釋出測試環境，產品測試領導稽核，成功後，直接釋出產品環境。或進行版本迭代。 這是整個的一個設計，開發，部署的流程。 根據前面的，在補充一下，前面的所有流程中的靈魂是原始需求提出者，但人隨著客觀條件的變化，思維認識會有所不一致， 所以產生了文件，文件是貫穿整個流程的一個靈魂。 而產品是整個流程中文件的編寫者，因為產品最能接觸最原始的需求，對需求的理解更深刻或專業，所以他會有一個文件出來。 這個文件是需要交付給設計，讓設計在設計過程中進行參考。 前端看的另外一個文件。互動設計師出互動文件，一般的公司沒有互動設計師那就是由產品來出的互動文件。 有的互動不過於複雜，就沒有文件，只是郵件。 有時候說，不要這個郵件行不行，那怕是最簡單的原始東西，沒有檔案或郵件是不能做一個後期測試回溯的依據。 產品文件表示頁面的流轉或資料的走向，互動文件描述頁面複雜的互動或各個使用者表單與使用者發生的各種互動。 另外2個是，要架構師或專案經理出的需求文件，需求文件是對整個專案的歷史背景，系統開發軟硬體要求，或版本資訊，等等。 另外一個是由服務端工程師提供的介面文件，這裡邊包括一些請求型別，傳參的數目與鍵名，還有服務端返回的引數名約定等等的，這些文件是開發中的靈魂，也是以後測試回溯的標準或依據。