自從看過 Burn Your Portfolio: Stuff they don’t teach you in design school, but should 這本書後，就想整理個工作清單出來。工作流程這回事通常是公司訂的很難更改，但自己的工作領域內弄個 SOP 、整理出標準作業流程和待辦清單是被允許的。就從 Functional Map 開始吧。

一份完整的 Functional Map 該包含下列內容：

圖片（動畫、影片）

• 圖片尺寸
• 來源（非必備）

圖片尺寸

可以的話，圖片尺寸能越早確定越好，如果只能提供100x100的小圖，設計師絕對不會搞個滿版大圖的 Wireframe 出來，節省修改時間。

來源

雖然不是必備，但圖片來源最好能早點確認。內建在 App 裡的圖和連網下載的圖是不同的，起碼要多考量「萬一沒網路的時候這張圖要怎麼顯示」的問題。

文字

• 標題
• 副標
• 內文
• 時間、Tag、備註…等等各種文字和其用途
• 來源（非必備）

想要減少 Wireframe 來回修改的次數，就必須提供詳細的內容給 UI。所有的文字項目種類全部都要提供，臨時多插一行文字進去不是按下 Enter 鍵挪個空白塞進去這麼簡單的事。

狀態

各種情況都有可能會發生，列舉較常見的幾項：

• 有網路、無網路、網路狀態不佳
• GPS
• 電話
• 會員系統
• 各種會員身份
• 下載檔案
• 地圖
• 搜尋
• 編輯
• 操作中斷
• 無資料

等等還有很多，詳情參考：各種狀態與突發狀況

除了圖片文字之外，「狀態」是必備、且肯定會來回修改改改改改不完的大問題，因為思考再詳細都會有超出預期的突發狀況。能在事前規劃得越詳盡、就不會老發生定版後要找個地方硬塞功能或內容的情況。

廣告

• 廣告尺寸
• 形式
• 來源（非必備）
• 運作規則

比如 Google AD 應該是最常見與最容易被運用的一種廣告收益模式，即使如此你也要讓專案參與者搞懂這個廣告的運作模式，設計師才能配合產出更適合的作品。尤其是產品收益都靠廣告的時候，更應該讓所有人知道公司要怎麼賺錢。

（如果你曾抱怨自家設計師怎麼都跟藝術家一樣搞不清楚狀況又不食人間煙火，試著讓他們了解開公司不是做慈善，商業考量也很重要，出來工作是為了賺錢不是身體健康，有收益才發得出薪水等等現實面，他們會比較能妥協某些部份的修改。）

其他

• 語系、國際化

如果你的產品跨國際、且不同國家有不同的功能，絕對要交不同版本的 Functional Map。光文字長度不同就很有頭痛的部份了。

（還有些沒想到的部份，像是遊戲類的我就不熟，在此不亂講…）

任何現有產品已使用的規則

這一條比較複雜，很多時候不是開發新產品而是維護或改版、擴增功能，就得遵循原本的設計風格、操作流程。不能因為 PM 或 BD 丟下一句：「參考現在有的產品就好啦我不要寫了」就放過他們。該寫明的文件還是要全部列出。（該是自己要寫給別人的文件請乖乖面對現實。）

• Style Guideline
• 平台規則

Style Guideline

最知名的 Style Guideline 就屬 Google Design 這份了。是一種對產品有用的規範文件，可以和設計部/設計師師討。如果公司沒有這種文件…免洗的一次性產品就算了，想長期經營品牌的話請訂定一份。

平台規則

如果這次改版同時動到很多平台如 iOS、Android、Web、Desktop 等，最好每個平台都製作一份不同的 Functional Map。每個平台都有不同的操作規定，也許某個功能在 iOS 上有、但 Web 上卻不存在。這部份一定要清楚且明確地製成方便對照的圖表讓專案成員能快速理解。

結論

既然努力整理出這份文件，未來我自己的產出就會照這份 List 跑了。（希望也能照這份清單驗收別人的產出，有缺漏就退件XDDD）

（如果你不知道什麼是 Functional Map，可參考：初學者的 Functional Map 。）