設計協作與設計文檔的結合

Ladies that UX Taipei

Published in

Ladies that UX Taipei

12 min readSep 1, 2020

2019/09/24@三創

這個月的月會邀請到 Sophie Lo 和 Tom Liou 分享他們在設計協作和製作設計文檔方面的經驗，小編覺得這個月月會的主題非常實用，應該有非常多 UI/UX 領域的朋友正在經歷或是經歷過這個課題。

接下來就是精彩的筆記，請大家開始閱讀第一篇啦～

主題一：設計協作-在不同企業文化下的設計環境觀察

第一位講者 Sophie 曾過待過金融業與軟體業，身經百戰的她要為我們分享成功與失敗的溝通經驗、以及設計作業的流程改善。

在協作工具方面：

Sophie 表示這要看公司氛圍和環境允不允許；在工具選擇多的狀態之下可以使用版控工具、任務追蹤系統；在與設計團隊或需求端溝通上，可以用 mail、或是像 Slack 等軟體輔助；但不同環境下設計團隊不一定能碰得到需求端，這時也許主動去和不同單位的人「聊聊」，想辦法間接或直接的接觸到真正的需求端，可以讓做事更有效率。

但如果在環境相對封閉的地方，如限制外連、嚴謹分工的工作環境下，礙於也許限制協作工具不能用那麼多，那麼溝通就變得極為重要；在封閉的環境下通常無法與需求端接觸、溝通傳遞複雜的狀況下，做設計的時間成本相對是高的；還有一種缺乏溝通是屬於內部的，很多工具選擇少的公司會缺少系統化的交接文件，這會讓機接品質不穩定、下一位設計很困擾之外，也會影響產品的延續性。

Sophie 強調溝通的重要，並且補充道，很多需求是主動「聊」出來的；Sophie 也鼓勵大家多多去了解同部門其他設計師工作的特性，有機會也多了解其他團隊的作業方式、操作情境、原因始末等等；同理別人的想法就能在執行設計時做出更好的產品。

Sophie 這時舉了一個例子，讓大家試著了解工程師的使用環境。

這時候也許可以用測試的方式做做看、用一起解決問題的態度來面對。Sophie 提到她的某一份工作經驗當中，同事曾經抱怨工程師都改不動某些畫面，但有時候工程師不是設計畫面的人，有些效果不知道要怎麼做，但這時其實只需耐心的找出問題點即可；心態上其實不急著找出解法給對方時間、也給自己時間，並且把改善後的成果與解法分享給大家知道，並記錄下來就好（小編聽到這裡時覺得 Sophie 頭上有天使的光環）。

當資源有限下，我該怎麼工作？

工具選擇

若用流水編號式的 Excel 設計工作單紀錄表，可再加上分類和 Tag 欄位，給未來工作查詢留一個軌跡。

Sophie 告訴我們一個故事，她也嘗試過建議工作團隊使用 task 管理工具，但剛開始大家只是先聽聽，不會有感覺，於是她試著自己使用，實驗看看在自己身上用有沒有幫助、並且展示成果，讓大家破除恐懼；過了半年後當大家在管理上遇到問題時，想到了 Sophie 提過的解決方案，終於嘗試使用（這溝通期居然要半年啊～真是不容易）。

但要考慮管理產品的穩定性，因為最後那個 Task 管理工具的公司最後被收購解散了😭

歸檔

歸檔時要做有意義的分類，不只是把東西放進資料夾；可以多方嘗試、由自己開始做分類，並分享給大家，讓別人也跟著改善自己的設計流程。

命名規則

最重要的大原則是讓「大家」都看得懂。

這邊的大家特別指不同工作崗位的人，像是產品經理檢視資料的角度和設計師不一定相同，資料排列的方式和命名規則也可能不一樣；接著名詞可能要統一，因為類似像同一個元件有可能有很多名詞，這時建議作統一並盡量避免用太難的術語；命名時要注意延伸性、穩定性並且可被理解，當命名被別人使用但被錯誤延伸時，則須考慮再做調整，當產品迭代的時候也需測試看看命名會不會有問題。

Sophie 為想嘗試歸檔與命名的同學推薦了一本書：資訊架構學

個案實例1

個案實例1 : 切割成模組化的設計檔案，再集中管理

Sophie 使用 indesign 做檔案管理，因為他有替代面板，如果要做新專案就 copy 替代面版並集合元件連結，讓大家的初始點都一樣（提供一個 sample 讓大家照做的感覺）告訴大家為什麼要做統一、管理，讓所有人認同並且共同維護以提升便利性。

彙整後的檔案會分成來源檔名和組成元件，讓設計師修改同一元件時不遺漏其他產品以達到一致與統一，並可以用彙整後的檔案去說服更多的人，讓這種共同維護與創造、分享的氛圍成為團隊的認同感、最終成為一種精神。

個案實例2

讓我們直接以命名的例子來看：

如果需要以產品去找檔案，這樣的命名就會有點問題。

調整

Sophie 所調整的方式如下圖三種，不過對於不同角色而言，可能有不同的最佳解；Sophie 覺得以這個例子而言，將日期拿掉可以避免後續大家一直用日期命名造成的困惑（在不同資料夾時的同一份檔案就得都拿出來檢視）

小結

溝通可以是漸進式的、慢慢地做修正；並且由自身做起的改進過程。

Sophie精彩的經歷分享就在這裡告一段落，讓我們準備邁入下一個主題，捨不得結束的朋友們還會在Ｑ＆Ａ看到Sophie哦！

主題二：傑出的一手之設計文檔大解密

接著是 Tom Liou (www.facebook.com/tom.liou.6)的分享，Tom Liou 又名湯六，除了是 UI/UX Designer 之外，也是台灣道路體的字型設計師；湯六這次要分享他的 PRD 文件寫作之旅

PRD 的全名是 Product Requirements Document ，湯六的 PRD 寫作之旅起源於前公司的工作需求，讓這位設計師開始寫作 PRD

湯六表示在這家公司遇到了四個情境：

需要設計師兼 PM（逼上梁山不得不做）。
不同設計師寫文件風格不一樣，RD 理解成本大。
人員流動，需要統一的文件入口可以讓所有專案關係相關人查閱。
設計師常常會陷入埋頭苦幹的世界裡，寫作 PRD 其實是跳脫此狀況、能夠達到更低成本但更宏觀看待產品的效果。

菜鳥寫 PRD 的好處：

可以設想該 Feature，如何驗證他的效果好不好
以更宏觀的角度梳裡產品 MVP，看出優先順序與排程

而什麼是 PRD 呢？

湯六補充如同產品的施工藍圖，目標是將產品需求描述清楚、作為溝通用，PRD 就是將抽象或形而上的東西具體與清晰的呈現出來；寫 PRD 一定沒有口頭溝通快，但一定會比起口頭溝通來的準確，它是一種「共識」與「證據」；對於攥寫 PRD 的人而言，它是一個思考框架，能夠將產品由大到小的做梳理，由近到遠的規劃。

但湯六也提到，寫文件雖然沒有「面對面口頭溝通」的即效性，但具有保存「共識」特質，避免記憶缺漏的問題；但適當的文件產適當的效果，如果文件做得過多就會像為寫而寫（而且也未必有人要看厚厚一疊？！）。

接著湯六一步一步地教我們文件的寫作方式：

PRD 組成內容

第一部分

文件概況：如同寫企劃書的 5W1H，再加上有誰經手過文件的紀錄、版本號、平台。

BX：老闆體驗設計師

第二部分

產品簡介與目標說明：用一句話說出產品的特色、TA是誰、最主要的商業目標是什麼？

寫下來其實是提醒自己、當開發排程時去設想如果自己是 persona 會想要什麼；做PRD有點像做 Persona，從圖中也可以去推敲衡量此產品的好壞有可能是從遊玩時間去觀察；這部分也可以做成對照表形式，或是每次開會寫的便利貼、User Story 等等，也可以寫上版本號（通常是自己寫的）、上版時間；重點是附上需求來源，先釐清所有需求資訊再動筆畫圖，例如 HD 需求是重要的、老闆的也是，但不是所有需求都要吃，還需要考量是否會動到架構多少？難易度？需不需要這個版本就做等等。

第三部分

產品架構和流程：依照專案的大小和視情況去決定要畫心智圖的顆粒度大小，還有也需要附上 IA 產品信息架構圖；這個部分很有可能是工程師會問到或想了解到的技術問題，所以盡量去設想它，雖然寫再多還是會被問意想不到的問題……

也需要包含 Flowchart ，要標注出任務的起點和節點。

第四部分

圖形化流程和原型：大原則就是 PRD 越後半部就越接近圖像、更具體的描述，這邊需考慮時間成本和溝通對象去選擇要放的原型保真度。

第五部分

產品指標：進一步去了解如何判斷產品、如何衡量功能成效，從樹幹>樹枝>樹葉的去思考是開啟次數重要、還是產品使用的時長重要？

商業的指標和體驗的指標有點因果關係，因為老闆要 UX 好、商業也好，通常也是這兩者都好產品才會成功；落後指標就像我要減肥十公斤，那麼領先指標就如同作法（因），有些事雖然風馬牛不相及、但有關聯。

以產品最重要的商業目標是「使用時長」，但你今天如果優化了一個啟動產品的步驟，讓「開啟遊戲的步驟加快」。那這個「步驟」是領先指標也是UX們常常在做的事情，然而在總體商業目標上更重要的是「使用時長」。要打造一個好產品，會有不同的原因。然而那些原因有重要跟次要的，所以切記做事要分輕重。

第六部分

字串表：key value

與RD討論定義字串的Key，讓兩個平台可以共享一份字串規則

第七部分

附件：如產品切圖、甘特圖、工作記錄log、會議等等

總結：

湯六推薦了一本書：用戶體驗要素。

這是裡面的五層次圖，第一層是空泛地想法和概念，到第二層開始縮小且具體，到第三層開始思考產品的工作流程的規則或例外，接著到介面設計如圖片按鈕文字如何排列，整體的視覺如何等等；PRD 是一個溝通協定（雖然沒口頭溝通快但是比較準），是思考框架、可以降低溝通阻力並統一溝通的媒介；但 PRD 在 Scrum 中是沒有效率的，它的特色是可以保存共識，所以文件真的不要為了寫而寫，適當的文件產生適當的效果，過度的話就會變成文件產生器。

當我們可以把「抽象文字」演變到「圖形表達」。

設計師想溝通的事情，將越來越準確。