UI 設計師應該要會寫的文件

文/ Akane Lee

身為 UI 設計師，工作內容不是只有做 PSD 和切圖，只會這兩樣的叫美工。

基本一位合格的 UI 設計師必須要具備撰寫文件的能力，文件最低限度需包含：企劃書、規格書、Wireframe、Mockup、切圖、標示文件、UI Kit、UI Pattern、Guideline。

小學時的作文「我的志願」想當作家，當作家好啊不用出門就有錢賺，看這思想多單純多懶惰，結果現在變成設計師，只能把寫作當興趣了。

設計師在工作流程上會需要產出各種文件，請當成「存證信函」在寫，反正文件基本功能就是存證和溝通用。不管什麼文件都有幾個共通的要點：

• 不需口頭說明就能看懂。
• 有多詳細寫多細，避免使用「等等」（etc）這類詞彙。
• 版本控管。

我不是在上位的主管階，自始至今我都是第一線基層人員，就只分享第一線要做哪些事、具備什麼素養、懂哪些事。其他的等我爬上去經歷過了再說。

企劃書

這是 Planner 的工作，但 UI 設計師一定要具備 5W 2H 1E 的基本能力。

What 什麼：企劃的目的、內容。
Why 為什麼：企劃緣由、前景。
How 如何：企劃的方法和運轉實施。
How much 多少：企劃預算。
When 何時：企劃的時間。
Who 誰：企劃相關人員。
Where 何處：企劃實施場所。
Effect 效果：預測企劃結果、效果。

可以參考〈5W2H1E – MBA智库百科〉和 〈一分鐘學會企劃書撰寫！〉 這兩篇文章，寫企劃沒想像中那麼難，UI設計師要寫的也不過把 5W 2H 1E 條列出來的程度就好。

規格書

規格書分成 2 種： Functional Spec 功能規格書、Technical Spec 技術規格書。技術規格書是 RD 在寫的，和設計師關係不大，功能規格書才是設計師要注意的目標。

規格書定義出這個案子有哪些要做的事、需包含哪些功能，比如購物車、留言版、會員系統等等，和企劃書是完全不同的文件。

很久以前寫的舊文〈初學者的 Functional Map〉可以當成功能規格書的極簡化版，UI 設計師不需要到會寫完整又詳細的功能規格書，但一定要具備整理這份 Map 的能力。

規格書包含 Flow chart 和 UI Flow。Flow chart 為流程圖（包含使用者操作情境或功能 Flow）； UI Flow 則特指介面間的操作流程，兩者是不同的圖表。可參考〈流程圖 – MBA智库百科〉、〈初學者的 UI Flow〉

※ 延伸閱讀：〈工作清單：Functional Map〉、〈工作清單：UI Flow〉

Wireframe

正常的軟體開發流程一定包含企劃書、規格書，如果不這麼做的通常…咳…總之，到了 Wireframe 階段應該就是 UI 設計師熟悉的工作了。

Wireframe 一定要寫說明文字！
Wireframe 一定要寫說明文字！
Wireframe 一定要寫說明文字！

很重要所以要說 3 次。（這梗早被玩爛了）

有點像 User Story 但不全是，說明文字要註明該頁面上的各種操作、元件變化，參考〈各種狀態與突發狀況〉，能考慮越週到越好，事前預防總比事後發現有漏要硬塞來的輕鬆。

Wireframe 可以參考〈什麼是 Wireframe ?〉、〈為什麼要畫3次 Wireframe？〉這兩篇文。

※ 延伸閱讀：〈工作清單：Wireframe〉

Mockup

就是開 Photoshop 或 Sketch 之類繪圖軟體製作精稿，設計師最熟悉的工作階段，也最婊 RD 的一步。不要設計得超炫結果實作人員做不出來還怪 RD 學藝不精，看他們砍不砍死你。

和設計師聽到「就不能用比 #FFF 更白的顏色嗎」同感，對實作技術外行就不要充內行。Mockup 雖說是設計師最熟的文件、卻也是問題最多的文件，需熟知各平台規範、Web 框架，才不會搞一堆能看不能用的「個人作品」。

※ 延伸閱讀：〈工作清單：Mockup〉

切圖

切圖這工作可能在 F2E 或設計師身上，F2E 的工作剛好踩在各種線上比較萬能一些，若是 App 專案會由 UI 切圖。曾遇過設計師很高興的說，切圖被他們家 F2E 拿回去做，不再是他負責了…是圖切得有多不敷使用導致被 F2E 放棄？

各家平台不同，切圖的方式也大不相同。UI 設計師需熟知各家切圖方式並用可被輕鬆理解的方式切出合用的圖檔。

※ 延伸閱讀：〈工作清單：切圖〉

標示文件

當 Mockup 製作完成進入切圖階段後，需要製作一份寫明各元素尺寸、位置、色碼、透明度、字型、字級、檔名等資訊的文件交給 RD，RD 才會知道「數值」多少。別指望他們在沒有任何說明的情況下就知道這圖片怎麼用、放哪裡、間隔是幾 px，有這等神通力誰想當 RD。

這是件非常煩瑣又很悶的工作！幸好市面上很多工具可以加快製作過程。試過很多款，我最推薦〈標示文件神器：specKing〉，幾乎全自動了，按一按鈕就全部算好數值跑完，省事省力。

UI Kit、UI Pattern、Guideline

這三樣是完全不同的文件，常常被混在一起講，更甚者會連標示文件一起攪進來大亂鬥。

UI Kit

Dribbble 上很多設計師會把自己設計的某產品所有元件全部集中在一張圖上，這種文件稱為「UI Kit」。成套的 UI 元件庫概念，只有圖、不太會有文字說明，常見於原始檔，方便使用。

UI Pattern

剛好夾在 UI Kit 和 Guideline 中間。像 UI Kit 一樣用功能或用途分類、並集結元件，但又像 Guideline 說明各個元件要怎麼用（實作上要怎麼運用、不是概念說明）。

UI Pattern 分兩種，給實作人員看的就像 Bootstrap 那樣；給 UI 設計師看的 Pattern 會像《行動介面設計模式圖鑑》這書。

Guideline

拆分某產品系列所會用上的所有元素至最小單位，並分階層類別，需要大量文字輔助說明該元素的意義和運用規則。需透過審核機制才可變動其內容。公司所有成員都應可透過簡單的方式取得此文件，同等於公司的企業識別系統。

※ 延伸閱讀：〈設計規範要點〉

授權來源：嫁給 RD 的 UI Designer〈UI 設計師應該要會寫的文件〉