我的產品設計文件演進史
從事產品設計工作至今，我製作產品設計文件的方式有許多變化，這篇文章試著整理我怎麼看待這些資訊架構的規劃工具，以及認知演變的過程。
如果你希望獲得 Soking 的課程、讀書會以及 UX 講座訊息，歡迎留下你的 Email，訂閱最新的 UX 活動通知：https://subscribe.soking.cc/遊戲設計時期
2006年大學畢業後我的第一份工作是遊戲企劃，從這工作上開始建立軟體產品設計相關的文件觀念以及知識。
當時的設計文件重視表格、文字描述，對於視覺化的要求較低，最多是附上流程圖的形式。但我自己是個從小蒐集各種遊戲攻略本以及遊戲雜誌的無可救藥奇幻迷，所以忍不住在企劃書附上自己開 PS 畫的假想地圖。
雖然事後我知道在早期文件中自己畫的地圖最後不會用於製作（3D遊戲的地圖設計是另外一門學問），但是視覺化之後大家討論比較來勁，降低了取得共識的門檻，這是最早我對於規格文件視覺化的經驗。
遊戲設計是一個仰賴大量內容產製的工作，遊戲企劃同時要規劃需要量產的內容以及為了製作內容的編輯器，在沒有編輯器的早期狀況下，我也試著用 Excel 製作許多模擬的效果。
這份經驗讓我日後在規劃網站或APP服務時，會比其他設計師更重視內容量產所需要的功能或流程，也就是俗稱的後台規劃。
好的後台內容產製工具可以組合出豐富的變化來支持前台所需要的彈性，減少每次前台調整就需要疊床架屋增加網站平台的違章建築。
網路新創公司時期
2010年之後有段時間我在網路新創領域工作，經歷了新媒體、電子商務、點數應用、網路直播等領域。
這段時期的工作很雜，新創公司意味著工作範圍模糊，看到事情就要撿起來做。例如在新媒體公司報到的第一天，發現只有我跟老闆兩個人，六個月後的規模卻是五個網站。
我寫稿採訪、架設網路直播設備、談合作、找作者邀稿、跟工程師一起開發網站，這個時期的產品設計工作的特色就是混亂、要快、別想太多。
這個時候的設計文件欠缺了流程的概念，我只把主要的畫面生出來，其他部分都靠跟工程師與UI設計師在白板上溝通與腦補，或者是先讓產品上線了看能做到什麼程度，再討論怎麼調整。
因為每個人都身兼多職，開發又快又急，往往從規劃到第一版本上線只有一兩個月的時間。
因為溝通的過程沒有留下文件，有時當我們想知道某個流程的現況，居然只能去開上線的產品來重新測試才能確定流程（最緊迫的時候連測試站都沒有架設）。
可想而知這個時期的設計文件都是碎片化的狀態，事後很難具備參考價值，算是用後即拋的東西。
創業時期
人待在新創圈久了容易被洗腦，覺得人生是不是就該衝一波，走上創業之路挑戰看看。總之後來跟幾位朋友一起創業做 APP，因為是開發自己的產品了，多年來心中的任性就一湧而上。
這個時期的設計文件有點 UIUX 傻傻分不清的味道，雖然我們有請設計師朋友最後幫我們重新設計視覺，但像是 APP icon、介面修改等情況還是自己動手來。
我開始將所有的畫面都列出在 Wireframe 上，並且試著寫一些功能上的註解。但因為工程師是創業夥伴，每天坐在一起工作，所以各種流程的備註與說明還是沒有文件化，只有最終對於介面的變動有 Wireframe 來落實。
後來在創業期間我們跟某個健身品牌合作，協助幫他們打造後台營運系統以及會員服務APP，這個時候我第一次要跨多方合作，為了要忠實記錄規格的現況以及跟利害關係人取得共識，我開始在設計文件上面增加許多說明與備註，也是在這個時期我開始把文字版的需求大綱轉換為 Sitemap。
過去在處理產品開發的時候，我所面對的溝通對象都是同一個公司、同一個專案團隊的成員，因此許多開發文件我們省略，用嘴巴跟白板溝通完就進行開發。
但在這次跟品牌企業合作的案子中，至少要整合四個不同的團隊與人力參與專案，我才迫切感覺到完整的文件記錄能確保溝通完成的規格，大家的想像是落在差不多的範圍，也減少翻盤的意外（雖然還是有）。
後來雖然離開了創業團隊，去擔任其他公司的產品經理，但我變得更重視前期溝通時將規劃文件落實，這段時期 UX 相關工作方法論也開始在國內外流行了起來。
設計接案時期
近幾年我不再擔任產品經理，以自由工作者的身分從事產品設計的UX工作。
比起打開軟體做設計文件的時間，我現在更重視花很多時間先跟業主、需求方、利害關係人聊天。
畢竟很努力的做了錯誤的事情，還不如什麼都不做。
因為大部分的時間採取遠端工作，我們跟接案的合作夥伴更需要詳細符合現況的開發文件，大家可以依據設計文件施工，業主驗收也以此作為依據。因此設計文件的品質影響了結案。
有了這個體認，我們每次設計專案之後會再檢討這次設計文件的流程與架構有沒有可以改進的方向。
我們對設計文件的改進體現在資訊架構階段，這個階段產出的代表性文件就是 Sitemap，我們開始在這邊包含頁面命名、主要功能、共用 UI、UI FLOW、使用路徑、用戶權限等要素，盡量包含在早期的 Sitemap中。
後來我們 UI 設計師抱怨，有時候在專案頁面一多，會發生UI 設計進行中但客戶從流程開始做需求變更以至於要調整頁面架構，UX 如果跟客戶調整完頁面架構，UI 會不知道該怎麼跟 UX 新的頁面架構對應。
這個問題是因為我們的頁面編號規則沒有跟 UI 一致，因此後來的 Sitemap 要求先定義頁面主編號的規則，然後進入 Wireframe 之後，將頁面狀態變化、分頁、彈出視窗等編號列出。
此後在我們家的合作模式中， UI 設計師要實作的畫面數量，在 Wireframe 上都應該要可以查詢到對應的規劃。盡量在UX規劃階段消除專案的不確定性，以及辨別需求凍結之後產生的變更。
目前來說，我們固定產出的設計規格文件包括：
1. 專案需求書：大約3~5頁描述專案範圍以及主要的使用情境（有時會當做簽約時約定專案範圍的文件）
2. Sitemap：做完必要的訪談跟研究之後產出資訊架構，用來定義核心功能以及專案範圍。
3. Wireframe：包含 UI FLOW、資料串接的描述、行為路徑、頁面狀態變化、系統文案。此文件用來凍結需求。
Prototype 大多數只做局部流程，用來跟客戶討論風險比較高的頁面互動。至於其他的 UX 工具，則是視客戶情況搭配使用（例如簡化的用戶旅程地圖）。
結語
為了整理這篇文章去翻出自己的黑歷史實在是有點害羞，但一面整理一面回顧了建立設計規格文件觀念的過程。
最近在看一個線上課程，是 游舒帆-gipi 老師在 YOTTA 的「 專案管理入門、打造高效團隊 — 專業經理人養成計劃」，在討論專案管理盲點時，Gipi老師講了一個震撼到我的論點。
他說：「很多人以為專案做不好都是溝通問題，所以就把人這個要素放的很大，以為什麼都可以靠對人溝通的方式去解決。但這樣的觀念忽略了文件、資訊透明化、好的流程一樣可以幫助溝通。」
這段話貫穿了我在專案過程中逐漸重視文件價值的過程。過去從草草了事亂做文件，一直到沒結案就沒收入，所以開始在意在製作文件的過程消除不確定性。
文件在溝通上的價值有了定位，我對於花許多時間在前置規劃的不安也終於放下了。
我常看到有人疑惑問說，世上真的有開發團隊能把 UX 設計流程都走完嗎？老實說我也沒見過，甚至我沒有在同一個專案採用過太多的 UX 流程，大多數情況還是根據合作狀況來調整配套。
每個 UX 方法論都有它原始要解決的問題。更多時候我在風險高的專案不敢引入很少嘗試的方法論，只能在壓力與風險較低的專案時趁機實作，或者平日自己想模擬情境來測試。
所以說，各種不熟悉的 UX 工具找時間練習真的很重要，避免到了專案要用上時沒有自信跟團隊引入。
如果你希望獲得 Soking 的課程、讀書會以及 UX 講座訊息，歡迎留下你的 Email，訂閱最新的 UX 活動通知：https://subscribe.soking.cc/相關文章
- 入門資訊架構的思考方式（二）事前準備、資訊流分析、內容提供者
- 入門資訊架構並學習UX設計師的思考方式（一）觀察與練習的方法
- 【工作坊記錄】以角色扮演與親和圖卡片分類法體驗專案需求
- 【UX筆記】原型設計與易用性測試的工作坊記錄
- 我的用戶訪談故事與工作效益評估
查看獸群之心的 UX 文章目錄
