在設計有四年快五年的時間，大部分都是從實戰經驗中去不斷摸索產品開發的流程。從視覺傳達的背景出來，在用戶體驗的經驗都是在實際開發中去摸索出來的。不是理論派，只是根據我本人的經驗摸索出來的設計方法，也不會用太多高深的詞彙說明。
以前搜尋怎麼做產品設計？究竟是要從什麼步驟開始的這件事情，大部分看到的文件都是在說明工具怎麼運用的，發現顯少有人去針對這塊做說明。所以我想在這邊用我設計的經驗，稍微記錄一下我摸索出來的設計流程。
1.Flow Chart
我常把 Flow Chart 形容為產品的大骨架，像是這個骷髏一樣，如果沒有大的骨架無法支撐你整個身體。
目前在 AlleyPin 擔任產品設計師，AlleyPin 致力於打造醫療產業數位化，透過 LINE 打造一連串的醫療數位服務。也因為我們面對的產品需求都是因應市場變化需要快速迭代的功能，所以在產品設計上我們都是先求有再求好以最小可行產品 MVP (Minimum viable product) 的方式開發，但初期在摸索設計流程上也很容易在業務帶回來的 User Story 上迷失方向，做出來的東西花了很多時間但是成果卻不如預期。
圖為某個流程中的 Flow Cart
現在只要是新的功能需求，在著手設計前我都會先用 Flow Chart了解整體流程。使用 Flow Chart 能夠確保團隊中的成員，都了解產品在新功能的操作上邏輯的一致性。
2.Functional Map
Functional Map 就像是產品裡面的細部骨頭，有了 Flow Chart 這個大骨架支撐整個產品，但我們還是需要有其他的細部骨頭讓產品運作。
在這個部分我們可以釐清哪些是因為新功能而需要增加的欄位，也可以讓前端工程師或是後端工程師在系統端裡面有哪些資料是新的需要被重新規劃的。
製作 Functional Map 我會從目標去拆分出「母功能」、「子功能」與「資訊」的節點來發想。目標通常是根據上述中的 Flow Chart 與 User Story 作為發想，並將功能條列後將資料填充至子功能的子節點下面。可能會根據功能大小會有層層不同的節點。在設計的過程中也會不斷的需要回來看 Functional Map 來把資料填充至設計裡面做規劃。這個環節很重要的是開發產品的團隊可以對此產品的功能做總覽。
圖為某個後台的 Functional Map
3.Wireframe
設計師從Flow chart取出產品任務流，從 Functional Map加入正確資料到框線圖中。我將 Wireframe 稱之為產品的肉身
Wireframe 的環節非常重要，是讓負責此專案的所有成員對產品初步真正認識的階段。在多次的經驗中，製作完前期的 Flow Chart 與 Functional Map 整個團隊其實還是處在霧裡看花的階段。 大家對於產品都有不同的想像，但設計師必須擔任這個將產品肉身打造出來的人。
我傾向於直接製作 High-Fidelity Prototype，可以更確定設計上要如何編排，以及大家會對於產品更有共識。
Wireframe 在繪製的時候我會依照單個功能的 Flow 做橫向的排列，有助於在 Demo 時大家不會在各個功能上失焦。在製作 Wireframe 的過程中我會盡可能地確保所需的資料都在上面，避免到 UI 上才思考。這樣可以讓思考專注在介面的資料上而不會被有關 UI 的部分影響。
圖為由左至右的功能流程
以前曾做過將所有功能大辣辣的全部展示在同個畫面中的Demo，結果團隊的成員們都無法在會議中專注在某個功能進行討論，是一次非常失敗的經驗。
4.UI
UI的步驟其實就是比較廣為人知的部分，初期我在設計產品的時候都會想反正功能小小的就略過上面的步驟，但經過幾次經驗後，發現上面的做法其實真的缺一不可。如果少了上面1～3的步驟，在 UI 的階段反而會很容易做出只有外表，但是功能還有架構都很不明確的產品。
我通常把 UI 的部分稱為產品的 Skin，有關產品的膚色、髮色、五官相關的，在 UI 這個環節才開始思考。
在設計我會使用統一建置好的 Design System 以確保公司產品的一致性 ，那在UI這個環節基本上就是最簡單的。因為先前我們有比較詳細的High-Fidelity Prototyping 在執行設計的時候就可以快速的將元件從元件庫拉至畫面中。
關於如何快速建置 Design System 及如何在Figma上製作UI之後我會專門再寫一篇文章解說(老高語氣)
最後
我覺得自己在產品設計師的路上，進步的最快的方式是從生活中不斷的去思考打造產品的可行性。或是參加一些黑客松，都可以幫助自己在短時間內提升產品的思考能力。平常也可以養成批判其他產品好或不好的習慣，都可以有效提升設計能力。
