設計師與產品經理的合作指南 規劃、產出絕佳使用者經驗的有效方法
大部份的組織結構都是設計師要跟產品經理 (PMs) 緊密合作。他們對於產品裡的功能如何運作，有數不完的意見；他們有設計決策的否決權力，或是決定某個產品的流程要如何打造；他們也完全以商業需求當作考量，思考能夠符合以上需求的產品樣貌；他們在想的是使用者如何跟產品互動，然後分析是否達到設定好的使用者需求目標；他們協助安排工程師工作清單的優先順序；他們是決策者；他們協助打造產品路線，維護/定義產品的願景。
對於一個角色來說，背著非常多責任，對吧？
簡單來說，他們是在極度高壓環境下工作的超級明星。不管從哪個角度來看，他們手上總是在處理超過能夠應付的範圍。設計師的工作必須要跟產品經理的方向一致，因為到最後，這些利害關係人 (stakeholders) 都有相同的願景。
思考流程的差異
老實說，一開始我覺得跟產品經理的同步處處有阻礙。身為設計師，我重視的是體驗、流程、元件的一致性，還有如何在不同解析度的表現更好⋯等。 我們沒有投入太多心力的是：公司當前的需求、要用到的工程工作份量 (engineering efforts)、接下來幾季的產品策略、產品發展路線內容 (roadmap)，還有資源分配⋯等。
很明顯地，正是因為我們直覺上不會考量這些事情，所以在產品世界，跟產品經理合作是很基本的需求：有助於描繪更寬廣的視野。 經過跟產品經理緊密合作很長一段時間，我決定現在講些心得，寫下有助於用更有目標的態度進行設計的方法。以下是一部分我採用的步驟，沒有特別的先後順序：
- 任務的先後順序
- 更新使用者經驗債清單
- 建立使用者經驗測試計畫
- 追蹤產品活動 (tracking actions)
1. 任務的優先順序
我注意到：提出外觀不一致或強化貼圖花樣的話題，常常會讓產品經理翻白眼。我理解他們會這樣並非不想修好，或覺得不重要，只不過目前不是恰當時機。其實一定會有絕佳時機，可以提出你覺得芒刺在背的東西。
那麼，要怎麼知道好時機來了？
好吧，回答這個問題比我想像的難一點。答案在以更大的範圍了解專案的狀態。
我這時候開始做公司當前商業需求和工程工作份量 (engineering efforts) 的筆記。
**商業需求：**要如何讓價值最快傳遞出去？因為沒有賣點的話，就不是一門成功的生意，也因此無法在真實的範疇內設計可能還是前所未見的東西。
**工程需求：**要讓系統穩定下來，得要做什麼事情？而讓現有功能不會無法運作。是那些為了要傳遞更好體驗而要最佳化的事情。如果可以理解工程上的限制，在進行設計決策的時候很有用。某個更好的互動效果，可能對系統是很大的負擔。因此得要有些妥協，讓它穩定。
一組吸睛的互動但是功能卻壞掉了，那還有什麼好談的？
知道這兩個主要考量後，除了一大張的設計修改清單，我還開始排先後順序 (prioritize)。
產品裡需要大幅度變動的部分，優先順序就要往後移；而可以產出最大價值的項目就要在清單內提高。這讓我可以跟正在進行的事情和平相處。
而絕佳時機到來的時候（相信我，一定會有），我加入之前想到的重新設計 (redesign) 點子。跟產品經理互動時的摩擦就會少很多。
2. 使用者經驗債清單
幾乎所有設計師都曾經聽過產品經理這樣說：
「我們先完成 MVP*，然後就可以回來做這項。」
*MVP: Minimal Viable Product，最小可行性產品
某種程度上來說，這讓我很挫折，因為我知道對產品的改變非常微小。那不是在我內心的設計師，所想的體驗。
我害怕如果總是採取 MVP 策略，最後我們都在為了要修好所有應急方法 (workarounds) 而超時工作。這比較像是 MVP 悖論 (Paradox)。
我偶然發現工程師在用一種技術上的庫存清單 (backlog)，他們稱之為技術債 (Tech Debt)，是擱置中的技術任務目錄，會特別空出時間衝刺完成它們。我覺得這是個好方法，有點好奇正在進行中的專案，是否也可以有個使用者經驗債清單 (UX Debt)。
我跟產品經理談過之後，決定列出所有 UX 的庫存清單。我粗略訂定優先順序的排列方式，分佈在導入的影響程度 (Impact) 和實作容易程度 (Ease of implementation) 為參數的圖表上。
如你所見，總共有 4 個象限，數字代表優先程度。
**第 1 象限：**容易執行並且有高度影響的工作。這些必需先搞定，因為它們傳遞的價值最高。
**第 2 象限：**容易執行但是影響程度沒這麼高。它們是接下來要做的，因為許多小改進雪球還是可以讓我們滾出優秀的體驗。
**第 3 象限：**接下來我們著手搞定產品裡有點難導入的部分。開始處理那些比較難的東西時，先弄可以有最多影響力的，是很重要的（態度）。
**第 4 象限：**在這象限範圍的東西，優先程度很低，而且常常就放置不管。為了甩開這種持續芒刺在背的感覺，此象限的任務可以再細分成更小的次級任務，然後安排次級任務的優先順序。解決在此象限的任務很困難，而我還在嘗試有沒有更好的處理方法。
接下來要做的事情是把它存放在不會離久情疏的地方。跟我一起工作的團隊習慣使用 JIRA 當作大部份專案追蹤的工具。
為了要以更正面思考的方式看待設計優先順序，我的專案經理建議開一個 JIRA Epic，稱之為 UX 改進項目 (UX Improvements)，這是非常好的方法。現在所有成員都在同個地方看到攤在陽光下的設計改進項目，跟所有 mockup 放在一起。
不同的團隊都有各自類似的工具，我們的 UX 團隊使用 Trello 來記錄所有 UX 庫存清單。另外，我發現有些工程團隊使用 Basecamp，滿足類似的需求。
3. UX 測試計畫
我在研究所時期進行的設計流程，是設計樣貌定案前大量的使用者研究和連貫整合。也就是說，規劃和執行研究的時間很充裕。但是在敏捷環境，不會一直如此。設計功能是根據既有使用模式和對目標聽眾的理解進行假設。
大多數的假設以顧客需求驗證。從顧客對話獲取驗證時，先設定好遊戲規則很重要。為了能夠在顧客互動的 30–45 分鐘獲得最大效益，我習慣跟 PM 合作規劃與顧客的對話。
對話的的進行方式非常簡單，就是清楚表達我們想要在過程取得的。這是從顧客盡可能獲取資訊的好機會，用來修改 (iterate) 產品，符合他們的需求。大多數顧客回饋的對話都有：
- 測試的目標
- 有待證實的假設
- 介面的顧客流程
- 知道下一步他們的期待
4. 追蹤產品活動
現有產品使用者行為是很好的思考重新設計起點。如果使用某個功能的流程因為技術上的限制而得要修改，或是現有的使用者在易用性方面覺得困惑。
像是 Google Analytics 的分析工具提供很多種方法測量跳出率 (drop-out rate) 和行為的順序⋯等。不過大多數情況，產品還要更仔細的追蹤。
按下某個動作時，會發生什麼事？使用者接下來會去哪？你要如何評量一個功能成功了？這些問題可以用流程追蹤找出來。
一位想要把設計決策解釋做得更好的設計師，要分析、得知哪些要追蹤、為何要追蹤，還有最後想從追蹤獲得什麼。
如果想要用更複雜的事件追蹤和更仔細的漏斗分析 (funnel analysis)，像是 MixPanel 和 Keen，都有提供使用 API 的方法，讓我們可以用最細微的等級追蹤。如此善用各種數據，讓設計師可以下更好的決策，也更能影響利害關係人。
能夠使用資料分析幫助設計師的好朋友就是產品經理，他可以直接拿到這些資料。有些 (PM) 會親自參與這些工具的使用，也因此是以鳥瞰的方式檢視活動資料。
結語
這絕對不是一篇已經詳盡說明設計師如何與產品經理共同工作的文章，但肯定是往正確方向前進的一小步。產品經理已經幫助我不斷思考像素以外的問題、安排優先順序，還有以整體的觀點來看正在設計的東西。規劃好如何跟產品經理工作，就可以充分利用他們的強項，也就能夠打造更好的使用者經驗。
我也很有興趣知道你跟產品經理工作的流程，希望可以在以下的留言區看到 :)
這裡還有一些其他我之前寫的東西：
A simple framework to help designers with whiteboard challenges in an interview.
My journey as a designer in 2016.
我是 Adhithya，OpenDNS（舊金山）的產品設計師，如果你喜歡這篇文章，歡迎在底下按推薦鈕。☺️
你可以在 Twitter 找到我。看看我的作品，或是直接寫信給我：adhithya.ramakumar@gmail.com。