以前在還沒有 Figjam 之前，在專案的進行上都會出現重工的麻煩現象。為何說是重工呢？首先，PM 會先用 Axzure 或 Diagram 做一個初版的文字 Flow 或線框 Flow, 接著 UI 做完畫面再丟到 Overflow 上自己再建一個 Flow, 之後RD那邊又要把這份Flow轉成 PDF，或者自己再重建一個，然後加上 API 等資訊。
以上流程光聽就覺得麻煩，而且最麻煩的是因為三個部門分別都有獨立的Flow, 常常其中一個 部門稍微更新了他的 Flow 版本但沒讓大家知道， 就會出現一個流程各自表述的現象。
因此自從 Figjam 問世後，我就試著建造一個協作模式 Template，來解決這種重工又資訊不統一的狀況，最近終於發展出一個在合作上還算順暢的模組。以下大致介紹一下整個協作流程：
一、建立流程格式(UIUX/PM)
在開始製作流程前，我會先建一個流程 Template 讓大家去複製，才不會 PM/UIUX/RD 都用不同的邏輯來建立流程，對未來接手的人閱讀文件上也更容易懂。
二、建立文字版流程(PM/UIUX/RD)
在開始畫面設計前，會先定義一個初版的文字流程，通常會先由 PM 建立 -> UIUX 以User Centered 角度審視，與 PM 討論流程上需要異動的部分 -> RD 依照系統程式運行的角度審視，提出需要更改的地方，並在某些流程補上API key名稱和連結。
流程部分，通常會先建立出如上圖一樣的架構，分為主要狀態(主畫面)，與在不同操作情境下，每個主頁面的延伸樣式，並預留放畫面的位置。
Note: 這種歸類方式，也方便 UIUX 在設計時知道哪些畫面通常會沿用同一個 layout，只是會依據情境替換一些小元件，也就可以將此主畫面 component 化，未來要調動某個部分，更改主畫面即可同步到所有從此頁面延伸出的畫面，方便畫面的管理。
三、進行畫面設計(UIUX)
在 Figjam 上把文字流程訂好後，就可以把全部代表畫面的文字框複製並貼到 Figma Design檔裡，這樣在設計時可以清楚知道有哪些畫面還沒出，也可以知道哪些畫面其實還有延伸情境的樣式，流程裡沒寫到，再回去 Figjam 裡補上。
四、補畫面進流程(UIUX)
最後等到畫面和 prototype 都出完了之後~ 會將所有的 Frame 輸出成圖片貼到流程裡，補在事先預留好的位置，也可以在文字方塊中嵌入該流程的 Link，並在需要出 prototype 的畫面或流程上貼上 prototype link。這樣就完成啦~
Note: 實際上一個專案的 Figjam 檔通常都會變得滿複雜的(如上圖)，畢竟一個產品的流程會持續迭代(會有不同版本號)，每個流程之間也可能因為發生在不同情境，因此得獨立分區，另外RD那邊也會在此文件上補上程式端的流程。因此在同事跟你要流程A時，可貼給流程A的區塊連結即可，不要一次給主檔案連結比較好喔~(不然會找到死XD)
