關於溝通產品設計時的五個層次
哈囉大家好，我是產品設計師盈秀。
最近經歷了我人生的第一次轉職，加入了一個產業、組織規模、文化都與以往非常不同的團隊，真是有點砍掉重練的感覺啊！
這篇文章在我轉職初期寫了一半，雖然拖著拖著就這樣快半年了，但這半年內剛好也有一些不同的心得，所以也是挺好的。
今天來聊聊與在設計過程中與不同角色之間的溝通。
作為產品設計師的日常工作中，除了設計產出本身以外，我也花費了大量的精力和時間在「說服」與「被說服」的溝通上。
尤其是遇到邏輯強到狠甩自己幾條街的工程師與重視實際獲利的 PM 時，單純強調視覺與體驗基本上不會是能夠說服對方的重點，所以我開始嘗試將產品的不同層次盡可能有條理並且清楚地描述出來，目的除了在溝通時能夠說服對方以外，在設計時思考不同的層次也能讓自己的產出能夠包含更多面向，更有品質。
今天這篇文章內的五個層次出自於 Jesse James Garrett 的 The Elements of User Experience 一書，這本書已經是經典中的經典，相信已經相當多前輩詳細解說過，這次我會以自己的經驗再理解一次並記錄我運用在跨部門溝通與合作的心得。
用戶體驗要素
Jesse James Garrett 在書中提出的用戶體驗要素以五個層次呈現，這五個層次涵蓋了使用者在使用網站（或產品）時決策的每一個環節，以下簡單回顧一下各個層次，並且以大家最熟悉的電商網站舉例：
- 表現層（Surface）：介面的視覺元素、配色、風格、動態效果等。重點在視覺感受以及整個網站的風格與效果是否一致。
- 框架層（Skeleton）：文字、按鈕、控件在版面上的位置。重點在讓元素達到最大效用，例如： Call to action 應該擺在哪個位置，才能讓使用者在需要的時候可以馬上按下購買的按鈕。
- 結構層（Structure）：定義資訊如何分類以及各元素的排序方式，例如：使用者從當前頁面的哪個位置進入特定頁面，並在做完事情後會去什麼地方（流程）。
- 範圍層（Scope）：某個功能是否該成為產品的功能之一，以及不同功能之間是否會相互影響。例如：是否需要提供了一個保存寄送地址的功能，讓使用者在購買時直接預填好，不需再次輸入？而當使用者帳戶設定了多組地址時又該以哪一組優先？
- 戰略層（Strategy）：產品想解決什麼樣的問題，例如使用者是誰？他們能從這個產品獲得什麼？以電商網站為例：提供買方購買產品，賣方銷售產品，網站營運方則從中抽成獲取利潤。
這五個層次提供了一個基本的框架，由下往上從非常抽象到更加具體，每一個層次的內容都會受下方層次的影響，而決策的順序通常也是由下往上。
簡單描述完體驗要素的各個層次後，接下來說明由下至上在不同層次時，我的合作對象主要會是誰，以及主要溝通的重點有哪些。
戰略層（Strategy）
在戰略層，我們主要探討產品目標（Product objective）與用戶需求（User need）。
在過去的經驗中，有時候產品目標只存在於產品團隊中一小群人的腦袋當中，而在沒有明確目標的情況下進行設計，很容易像無頭蒼蠅一樣。一看到 A 競品有什麼就做什麼，看到 B 競品新功能推出了又開始在想是不是也要加入新功能，最後產品只能被東拼西湊成一個奇怪的樣子。
後來我在接手一個新的產品或是新的功能開始時，第一步會想辦法把產品目標或功能價值盡可能明確的列出來：
- 這個產品（或功能）可以讓使用者得到什麼？
- 這個產品（或功能）可以為我們帶來什麼？
列出來以後反覆地與 PM、需求方確認彼此的理解是否有出入，甚至一起訂定成功指標等。
而用戶需求就是 UXer 們的拿手好戲了，無論是量化或是質化研究，或是各種分析方法，都可以在戰略層時對決策發揮很大的效果。
在戰略層我最常溝通的對象是 PM 與需求方，但在 B2B 的世界有時候很難直接接觸到使用者，因此我會將前線們帶回的聲音當成使用者需求的參考。
範圍層（Scope）
帶著「使用者得到什麼？」與「我們想要什麼？」的明確認識，我們可以開始將產品目標與使用者需求轉化成要提供給使用者的內容和功能。在範圍層，我們溝通功能規格（Functional Specifications）。
我曾經接手過一個專案，設計被變更了 18 個版本，過程中客戶反覆塞入突發奇想的大大小小新需求。雖然有時候專案不太能跟產品相提並論，因為在專案的世界裡客戶掌握了較大的話語權，但那一次的經驗我感覺問題是出在最初沒有把範圍劃分清楚，而讓整個專案失去控制的膨脹。
在設計與開發的過程當中，很容易看到新的需求，多做了 A 功能好像會更好用，那再加上競品也有的 B 功能好了，接下來就會像雪球一樣越滾越大，專案可能一直結不了案，產品則會一直上不了線。
我團隊裡的角色是 Feature Owner，而我與 PM 作為 Product Owner 的差異是「大顆粒」的功能（Feature）由 PM 進行優先權排序來讓設計師開工。進到設計與開發階段時，大顆粒的功能裡面會包含更細的「小功能（Function）」，這部分就由我與 RD 們依照可行性與風險來判斷需求如何拆分並 PM 溝通上線時間。
在範圍層我最常溝通的對象是 PM 與 RD，而我們通常透過產品需求文件（PRD, Product Requirement Document）來溝通細節並且紀錄清楚。
透過文件我們可以詳細記錄每個小功能的細節、各版本預定要上線的範圍，和團隊對焦上線節奏，並且確保團隊內每個人都可以查看。
關於 PRD ，這邊光明正大放上以前寫過的小小心得工商一下。
結構層（Structure）
在定義好範圍並且排序好優先級別後，我們可以開始將分散的小功能組合成具體的模樣。在結構層，我們可以開始進行交互設計（Interaction Design）與資訊架構（Information Architecture）了。
在早期時，我在確定好範圍後很容易貪快，會直接進行介面設計甚至 Prototype 來和 RD 討論，但後來發現這樣的方式其實很容易讓討論內容失焦，討論時很容易就直接偏到版面與視覺效果，而等到設計後期要再補上交互邏輯雖然也不是不行，但就有點重工的感覺。
後來在 RD 的建議下，我們調整成先利用 Flow chart 與資訊架構來討論，設計、前端、後端都可以就 Flow chart 判斷需要的資訊與合理性，而且在定義清楚後後面進行介面設計也比較不會缺漏。
在結構層我主要就是與前後端 RD 溝通了，我們會盤點不同 Use Case、透過 Flow Chart 確定流程、與前端確認不同狀態的互動流程、與後端確認要跟後台要那些資訊來顯示，甚至請前後端 RD 討論串接可行性，這些都屬於在結構層要釐清的內容。
框架層（Skeleton）
在結構層確定好 Use Case，我們可以進一步將這些流程更具體的設計出來。在框架層，我們可以開始著手介面設計（Interface Design）與資訊設計（Information Design）了。
介面設計已經是設計師們的老本行，所以這邊就不會提到太多大家熟悉的設計重點了，但我想稍微提一下關於「研究」什麼時候做。
我並不是一個對介面敏感度很高的設計師，所以在進行介面時很容易進入 A 版本還是 B 版本比較好的小迴圈，而且更多的時候自己並不能代表使用者，所以就會更難抉擇。
之前的文章有提到，在和前輩討論後，我們開始嘗試在不拖慢開發節奏的前提下利用「借助內部資源」和「簡單快速的測試」來增加對自己設計的信心。
我在設計過程中越來越習慣利用「簡單快速的測試」來幫自己脫離抉擇困難的小迴圈，再將結果利用Prototype、Wireframe等更具象的方式和前端 RD 溝通可行性。
表現層（Sensory）
最後在表現層，設計師可以用最具體的方式完成前四個層面的目標，並且顧及使用者的感官感受。
除了視覺比例、配色等美感以外，在表現層我們還會考慮到一致性。而一致性又除了眼睛看到的元件以外，文案的一致性也是我經常在這個層次苦惱的部分。
有些團隊會有專門的 UX writer 顧及這一塊，但我個人過去的經驗是產品設計師會在設計時才一併考慮。
我們在定義用詞的時候除了產品內部以外，也必須確保其他團隊在對客戶推廣與溝通時的用詞是一致的，以一個例子來說：「電子簽名（Electronic Signature）」與「數位簽章(Digital Signature)」在定義上是截然不同的東西，而 Digital Signature 有時候又因為地區的不同有時候會被翻譯成數字簽名。
這些很相近的詞如果在產品內與對客戶的行銷文案、新聞稿、簡報都有不同時，客戶會很容易混淆，因此在挑選不同語系的文案時我通常會與行銷團隊一起討論，看看過去是否已經有使用過的詞用於描述同一件事情或功能，並且一步一步嘗試把詞彙表(Glossary)建立起來。
只是目前我還沒有找到適合整理 Glossary 的工具，如果大家有推薦的也歡迎跟我分享!
結論與一些心得
產品設計並不是一個單一方向的線性流程，這五個層次也是，雖然有權重的差異，但並非一定是戰略層完全解決了才開始範圍層和後面的層次這樣的單一方向。
實際在運作的時候經常五個層次是同時考慮的，所以有時候當你和 RD 討論完了實作上的問題，才會發現可能動要到原本和 PM 同步過的規格範圍，要變更規格嗎？還是要延後上線呢？還是必須再回頭討論一下。
但這也是產品設計有趣的地方(吧)！
我有一段時間一直在掙扎自己在工作上的價值。
雖然我在第一份工作就已經加入了一個有獨立的 UX 部門，設計的觀點與產出相對會被重視的團隊，但仍然一直在擔心自己的角色對產品的影響是不是只存在於無關痛癢的互動體驗與視覺。
在職場摸索一端時間後，我才突然發現當初學的這套理論其實在實務上還是有幫助的，它可以幫助我問對問題，並且和團隊內正確的角色一起找出解法。
我的新工作加入了一個還在摸索與習慣怎麼和設計師合作的團隊，我也嘗試利用這套層次在這邊找到對的人來蒐集所需要的資訊，雖然我還不知道結果會怎麼樣，祝福我吧！
Reference
Jesse James Garrett 著。范晓燕 譯（2019）。用戶體驗要素 — 以用戶為中心的產品設計。中國：機械工業出版社。
