作為用戶、客戶與 Agency 間的夾心餅乾，UXD 如何與內部進行專案溝通?(上)
UXD 是什麼？我們可以提供什麼專案價值？
UXD (User Experience Designer) 是近幾年臺灣突起的職業之一，但實際上作為用戶體驗設計師在專案內可以提供什麼價值與協助，相信對很多人來說還是陌生的。
我認為好的用戶體驗設計師的職責就是確保在任何條件或設計限制下，用戶都能獲得相對舒適的體驗或服務。以我們公司為例，從專案的開始到結束，一路上所經歷專案的需求單位溝通、用戶需求探索、專案範圍定義、用戶體驗規劃、UI 設計、程式開發和最後的全域測試，我們都需要同時站在用戶的角度與多方的利害關係人溝通，確保用戶的權益不被其他因素所犧牲。
設計一個好的產品，我們不再只是需要面對用戶與客戶，與內部利害關係人溝通是否順暢更是決定一個產品時程與品質的一大要素。在經歷許多大大小小的案子後，發現「用戶體驗」雖然逐漸被重視，但絕對還是比不過建置利益、建置成本、建置資源等條件對專案決策的影響力，因此我希望藉由此篇文章與大家分享在 Agency 內 UXD 的工作職責與溝通技巧，提供其他可能也在內部創業的 UXDs 一些經驗分享。
商業目標 vs. UX，誰說一定要取捨
策略顧問：我在乎商業利益的達成與客戶是否會對我們的提案買單以我們公司為例，會碰到的第一個利害關係人就是策略顧問，策略顧問在專案初期時會需要引導客戶定義建置目標與建置範圍，然而不可避免的，定義出來的目標與功能可能會與用戶使用產品時的體驗產生衝突，由於專案目標與利益並不會直接影響用戶體驗，而是因為目標與利益所建置的功能與用戶產生了互動，因此我們的角色即是幫助策略顧問將這些建置目的變成產品裡「必須」與「貼心」的產品功能。
首先我會先將所有需求打散，解析每個建置目標的必要性、遞進關係或功能需求，討論出對客戶而言最有價值的建置利益，嘗試將其轉換為產品核心功能，在此階段可以透過 HMW ( How Might We ) 等設計方法轉換痛點，以下針對經常遇到的衝突點舉例：
當用戶體驗痛點被轉換成機會點後，可以藉此與策略顧問討論落實辦法，其中解法當然就不限於產品功能，而是可以從行銷策略、產品內容等角度發想，創造滿足客戶的商業目標又能讓用戶有意願使用的產品，是我們能發揮的第一個價值。
Tip 1：知己知彼，同理客戶的需求，將商業目標包裝成專案核心功能，可以更容易說服客戶開發用戶需要與想要使用的產品。
敏捷開發的時代，哪些才是 MVP 開發項目
專案經理：我的責任是規劃與降低專案開發的風險，確保專案的品質與進程當用戶體驗設計師做完專案的用戶研究、競業分析、創意發想等後，一般會提出許多「必須建置」、「可以建置」與「想要建置」的產品功能，但專案的時程與成本就是有限，排除掉「必須建置」的產品功能後，如何選擇這些「可以建置」與「想要建置」的功能就成了用戶體驗設計師與專案經理的第一次交鋒了XDD
站在專案經理的角度，往往會希望進行風險較低的項目進行開發以確保對專案掌握度，但作為用戶體驗設計師的我們，則會希望開發具有市場區隔的產品，如何保有產品的個性又同時能在時間內完成最小可行性開發，即是我們與內部利害關係人溝通的第二項課題。
以我個人的習慣，針對每個小功能，我都會依照產品的性質進行一連串的自問自答：
- 沒有這個功能，是否可以透過現有功能或動線取代 ?
- 沒有這個功能是否會影響用戶的使用動線，如果會影響程度有多深 ?
- 提供這個功能是否可以讓用戶感到新奇、有趣或貼心等正面情緒 ?
當我們對於這些功能在腦中建置完整的關係網時，就是時候與 PM 討論實際要落實的項目了：
- Round 1：透過Sitemap提出完整的產品架構，並標示期望開發的項目
- Round 2：如果超出預算與時程，依照期望程度由低到高排序逐一排除，排除期間我們需要不斷喚出腦中的關係網，提供交換的 Plan B、C、D，逐漸遞減
- Round 3：與客戶定案專案架構與開發項目前，事先溝通出 2–3 款候補方案，加速討論的速度
Tip 2：事先擬好討論策略與後路，提高雙方效率，也同時爭取產品的最高品質、最小損失。
遇到專案變更需求，「Why」 比 「How」更重要
專案經理：我需要為專案的成敗負責，我在乎的是專案是否能如期開發完成。在專案開發的過程中，我們一定會遇到許多大大小小的修改需求，小至內容文案的修改，大至專案範圍的調整，有時候對於專案經理而言，為了加速專案的進程，可能會依照修改的幅度直接與用戶體驗設計師們說：「客戶說要…修改」、「你就幫客戶加上…就好了」，這一類直接要求的設計師怎麼修改的做法，而用戶體驗設計師們在無法確認需求的過程中，只能專注於當前單元的進行修改。
然而一個完善的產品內許多功能必定是相互關連的，因此再小的變更都可能巨大的影響著用戶的體驗，既使是一段文案的變更，都有可能影響整體品牌的調性與服務動線，因此我們在接受到需求變更的通知時應該立即做出判斷，告知專案經理可能影響範圍的評估，再共同討論出在現行限制下可調整的空間或做法，才不會不小心衍伸產品內架構錯亂或內容零碎的情況發生。
為了避免此情況，我們可以透過合作訓練專案經理們與客戶溝通方式，協助我們收集最核心的資訊，最基礎的方式為對客戶的提問以「Why」 取代 「How」：
- 修改內容為何 ? -> 需要修改的原因是什麼 ?
- 你想要怎麼做 ? -> 為什麼會想要這麼修改 ?
後續用戶體驗設計師們則需要嘗試將現有的架構解析，站在整體規劃的角度最小化的調整產品動線與功能，避免因為需求變更而產品發展越來越偏的情況。畢竟我們的用戶們在看到產品時，並不會理解開發的過程或變更，他們只會評斷正在使用的工具或服務。
Tip 3：被修改的東西一定不會只有當下功能或頁面，所以第一時間收集修改原因而非做法，才能為更全面的評估做準備。
下期預告
寫到這邊，相信很多人會發現用戶體驗設計師們為了綜觀產品全貌，而經常在「自問自答」、「自我質疑」與「拆掉重組」過程中往返，下期將繼續討論專案中、後期的溝通技巧，
希望這篇文章對耐心看完上期的你能有所幫助喔！下期內容預告：
UI 設計驗證，你是否確實表明了資訊的重要性與流程
與工程師的協作，「What」比 「How」更重要
全域體驗驗證，產品最後的調整與提交
