在專案中，我認為流程是重要的，久了也會有默契，讓事情更有效率地進行下去的。
雖然可能每間公司都不盡相同，但如果遇到隕石式的神之開發環境，真的是會不知所措，沒有頭緒，通靈也無解。好在曾經以為的隕石，都被一一化解了(幸好不是真正的隕石)，而我最後會提如何解。

我之前應該都是比較偏向瀑布流的工作流程：

之一：

製作前期，PM 與需求端客戶訪談需求，畫 wireframe，或是拼貼視覺的草圖，來回溝通確認。
製作中期，PM 用確認過的拼貼視覺草圖，搭配建議的視覺圖、參考網站來描述需求給我，我製作設計精稿 mockup，需求端確認後，提供給前端工程師切版，之後再提供給另外的工程師上線。

之二：

製作前期，由 PM 與各需求端訪談需求，並畫 flow chart, wireframe(甚至是 mockup)等，來回溝通。
製作中期，我拿到 wireframe 確認需求、製作設計檔案，盡可能的從這邊開始規格模組化元件，再由 PM 去溝通設計稿，設計稿確認後即切版。
切版過程中，可能因為一些原因需要微調設計，但會儘量降低調動可能，在經過模組化的設計後，落實切版就也能順利模組化，達成一致性，例如：一致的按鈕、顏色固定成變數、卡片組件一致性等。
切完版後，交付前端工程師套入程式與框架，後續我也還會因應需求，在套版完的程式框架內，調整網頁版面或文案資訊。

其他聽說的流程：
製作前期，設計師就與 PM 一同參與需求端的溝通與說明，再由設計師製作 pototype, wireframe, mockup, 工程師切版套版上線。

有興趣的開發流程：敏捷式開發

開發種類：
瀑布流、隕石式開發

之前是如何把隕石解讀成一般需求修改的呢？

我想是要先知道需求者的想法，修改的核心原因，需求者的個性、對設計的標準是什麼都可以從中了解。
有時候太明確的修改需求，或是太不明確的修改需求，需要確認真正的核心原因是什麼呢？

• 先有相同認知共識的資訊
• 太過明確的需求，是要解決什麼痛點？
• 太不明確的需求，怎麼限縮聚焦？

延伸

講得有點多了，但暫時找到的相關文章：
大多數人口中所講的，大多不是他心中真正所想的需求，而是經過自己認知轉化後的規格。

需求像是睡美人城堡的藤蔓蔓延時：
軟體專案如何控制需求蔓延

有同感：
為什麼公司不做 Prototype 呢？

明天再來作設計流程的筆記