功能規格書、產品規格書、系統分析、需求分析等等，是 PM 或 SA 或其他同事的工作，反正不是 UI 的工作，很多 UI 不願意去接觸這類文件，（就說了字太多圖太少設計人看不下去、有沒有懶人包？）但看不懂這些文件的 UI 絕不能被稱為好 UI…連這個軟體要做什麼都不熟悉、一知半解，要怎麼說服別人設計的介面是適合這套軟體（或網站）的好介面？
別人不知道，但我沒辦法得知所有功能、就沒辦法開始設計介面。搞不清軟體想幹嘛的情況下有辦法設計介面…降乩這招我沒練過、也不想練。介面設計不是某某人隨便交待幾句：這個 APP 是社交型的喔、要做會員系統喔、要有留言功能喔就可以打發掉的事，這和美工背後指點江山的說詞有什麼不同？這個字要放大一點喔、改成紅色喔、顏色要再更亮一點喔…
學會看規格書是非常重要的能力，連客戶的需求是什麼、同事要用什麼方式執行這個專案都不知道，啊是要怎麼設計介面？就跟什麼細節都沒講、劈頭就問妳怎麼報價一樣，遇到這種詢價方式我都很想回他一句：「不賣！你去撿屍，還不用錢。」
規格書是專案執行到一定程度、快要簽約了才會變出來的產物，但 UI 有可能在提案階段就被抓進專案裡協助製作畫面（每間公司不同、看制度流程）。與其坐在原地等規格、我會自己動手整理一份簡易的圖表，說明客戶需求是哪些、必需包含那些他沒提到的功能才能解決客戶遇到的問題。沒有 Functional Map 就沒有 UI Flow，我也不能理解為什麼 UI Designer 可以在功能不清的情況下變出 UI Flow。
初學者在 Functional Map 上易犯的錯誤
1. 亂加功能
初學者通病，剛入行的時候我也中槍過。千萬不可以覺得應該有這個功能會更完整而自己偷偷加上去。
「規格書上寫什麼就是什麼、不要自作主張！」
比如說某個 App 是介紹最新音樂專輯，UI 覺得介紹頁面缺少圖片很沒說服力，規格書上也沒有提到這一頁會顯示圖片，所以自己在 Wireframe 和 Mockup 加上專輯的封面大圖…看起來很合理，但會害死人。規格書上沒寫所以當初在估工時沒算進去、萬一簽約時沒人發現，等到開工後的某一天突然發現多了這項…客戶又咬死當初約簽下去就包含這條不認帳…圖片要從哪裡來？API 怎麼接？合約白紙黑字簽在那裡又不是清朝的尚方寶劍吞下去就不計較。
看到問題一定要先問清楚才執行，最起碼也要和相關人士討論一下吧？這種現象常見於搞不清楚專案執行方式的 UI 身上。
2. 亂加特效
左邊滑一下、唰～地飛進來；右邊點一下、嘩～地飛出去。視窗掉下來要彈跳一下、這邊圖片要轉個幾圈、那邊文字要有能飄飄然的動感…去跟 RD 這樣講啊，他如果只翻白眼給你看就是他修養太好。新手 UI 很常犯這個毛病，以為講幾個形容詞就能解釋到讓 RD 聽得懂。就算他聽得懂好了，特效越多工時就越長，一般情況下光寫功能、除蟲都來不及了還要幫忙處理「唰～地飛進來；嘩～地飛出去」。這麼抽象的東西、放美術館裡就好，不要拿出來增加同事的工作負擔。
3. 不懂裝懂、或不會主動問
規格書上寫著，客戶指定要 sidebar、cover flow，看不懂這是什麼好歹去 google 一下或問人好嗎？之前帶過一個新人，問她什麼都說懂、HIG 懂、Photoshop 懂、HTML 懂、CSS 懂…還真不知道 iPhone NavBar 什麼時候是 100px 高、Dreamweaver 滑鼠點一點叫會 HTML、CSS…不懂就問啊、多問幾次就會了。不會也要老實說啊，打腫臉充胖子和欺騙我的 感情 信任有什麼兩樣？出社會又不是學校，還指望別人主動過來教喔？同事這麼辛苦多負擔保母一職，該不該給人家點津貼？早點發現問題可以早點治療、到後期爆炸了把整票同事扯下水、還怪同事怎麼不教？只能說、職場很危險的還是快回學校去吧。
怎麼把需求變成功能？
我念的研究所規定畢業一定要辦畢業展，每個人都要展出一份作品，於是打算做一款跟畢業展有關的 App。既然是和「展覽」有關的 App，最起碼要有展覽資訊吧？也要放一下到底有哪些參展作品和作者介紹。如果只是單純的放資訊，會不會太乾太無聊了點？加上掃 QRCode 會自動跳出語音導覽的功能如何？
如果把APP要包含哪些「資訊」，和哪些「功能」分開來整理，就會便成這樣，簡易版的 Functional Map 。
展覽資訊是一定要的，包含時間、地點、展覽主旨。
作品要有作品簡介、要放大圖，也要有作者照片和簡介。
要放幕後花絮，我們班感情可好得呢！就算這只是個自爽用的資訊也沒關係。
功能部份，因為不打算花錢架伺服器，在一切都用現成免費資源的限制下訂出這幾樣：
路徑規劃：用 google Map，FREE。
Facebook 粉絲團：直接開 inappbrowser，free。
QRCode：就那 25 個作品、直接寫死在 APP 裡。
語音導覽：播放音訊檔，內建功能。
因為時程關係，拿掉我本來很想要的 AR 擴增實境，不然應該會更炫才對…（負責製作的 RD 表示：我怎麼會娶到妳這個麻煩精？）
我自己在用的 Functional Map 差不多也長這樣而已，頂多長得更整整漂亮一點。其實整理功能很簡單，聯想、分類、像樹狀圖一樣發展出去並條列出來就好了，能幫助思考有沒有什麼功能漏掉沒想到、有什麼資訊需要呈現卻沒寫上去等等。透過這份 Functional Map 才能設計 UI Flow、畫 Wireframe，大幅降低初期考慮不周導致專案後期要硬塞功能把介面搞的很醜動線很差的機率。
Functional Map 記得 Mail 給 PM 和 RD 一份，請他們檢查有沒有疏失遺漏或做過頭。等他們都確認了再進行下一步。不要傻傻的自己一個人幹勁十足，之後被打掉重做再來抱怨公司不懂你、同事討厭你、大家都把麻煩扔給你。搞不清楚狀況、不曉得團隊合作的人、比專業等級不足的人更惹人嫌，有這種隊友…誰還需要敵人啊！
