UX 設計師應該要問 PM 的五個問題
以前在學校的時候，一個完整的設計專案總是從使用者研究開始的。了解使用者需求、尋找洞見、針對痛點想出解決方法，然後開始設計實踐想法。然而在現實世界中（尤其是B2B的世界），需求往往是PM一句：「欸，我想要加個什麼什麼功能，工程師下個sprint就要開始做了，你可以下禮拜二前給我嗎？」你抬頭看了一眼桌曆，今天已經是禮拜四，只剩下兩天可以做設計。
業界的設計需求，常常是PM權衡公司產品發展、行銷、使用者回饋（尤其是特別重要的客戶的回饋）之後而提出的。比較幸運的話，也許公司有資源已經在半年前做過使用者調查，而PM終於有機會把這個新功能加進這個版本。總之，我們UX設計師常常和想出解決方案有段距離。我們還是得和使用者站在一起，盡可能為他們著想，設計出最好的使用流程和最流暢的體驗。
因為無法直接接觸使用者，我們得抓住PM提出需求的機會問個徹底。如果連PM也不太清楚一些細節，通常客服會有答案。他們是最接近用戶的人，我們得藉由他們的嘴巴問出使用者的背景資料，來協助我們的設計和取捨。
誰是使用者？
首先，我們得請PM定義「誰是使用者」？他們是某種職業的人？或是任何人都能使用？他們多麼熟悉這個功能？專業的使用者佔比多少？新手佔比多少？
了解誰是使用者，可以明白我們在設計時要考慮的是什麼樣的使用者，還有佔比多少這個問題可以幫助我們取捨。例如，如果都是新手的話，可能需要多一點說明和引導。老手佔比較高的話，需要考慮需不需要讓他們可以做更進一步的設定，同時也要考慮不能讓新手太難上手。
他們現在是如何解決這個問題的？
這個問題可以反映出使用者目前的使用行為，還有痛點。新的設計可以針對他們目前解決問題的方法提出更好的解決方案。同時也要考慮新的設計是否符合他們目前的使用習慣，這樣新功能上線的時候，才不會在銜接上太過困難。
例如，如果公司需要一個新的庫存管理系統，而目前的管理方式是使用excel表回報。雖然excel表在網頁上的呈現可能並不理想，在設計的時候可以考慮使用和excel相近的輸入方式、表格排版、固定左方或上方行列、篩選工具⋯⋯等等，這樣這些excel的使用者在轉移到線上平台的時候就會比較熟悉這些介面和互動方式，更有自信去操作新的系統。
這個功能如何解決他們的問題？
了解他們現在的痛點之後，接下來要問提出解法的PM：「所以這個功能會怎麼解決使用者的痛點？」
這個問題可以挖出很多PM關於這個功能該長什麼樣子的想像，還可以挖出更多使用者需求，並且確保這個解法可以解決使用者的痛點。有時候其實PM根本也沒有好好想過這個問題，UX可以幫助他們思考。
接續之前的例子，PM可能只是想：喔～我要做一個庫存管理系統。接下來我們進一步問：「這個功能如何解決他們的問題？」
他可能會說：「這是為了要讓Sales Lead更清楚看到各個店鋪的庫存狀況，才能比夠比較銷售情形，和評估進貨數量、時間。」
那麼，我們就會知道，其實這個功能要解決的問題並不是輸入庫存管理的人的問題，而是上面管理者的問題。光是讓使用者可以輸入庫存、看到庫存狀況是不夠的。我們可能還會需要產出報表給Sales Lead和供應鍊管理部門，讓他們看到目前的庫存情形，甚至預測庫存狀況。同時為了要讓key報表的人心甘情願地定期回報庫存狀況，並且系統不會複雜到想要捏造數字，我們還是得好好設計key in的使用者經驗。
他們會多常使用這個功能？
這個問題主要是為了幫助我們在取捨一些設計和開發的時候會有一個評估的依據。除了單看這個功能之外，也要看這個功能在整個系統平台上的重要性如何。如果是個非常非常少使用的功能，在資源有限的情況下，我們就以工程師能做到的程度為主，不要花太多時間和資源在上面。如果是使用者每天都會使用的功能，那我們就得多花點時間在上面了。在和工程師溝通的時候，我們也有立場說：「這個功能很重要，使用者天天都會用，設計不能妥協！」
好的使用者體驗，也會影響使用者對於公司的看法，甚至是會不會續約的重要關鍵。在他們天天都會用到的功能上，當然得多花點功夫。尤其對於B2B產品而言，這個系統就是他們吃飯的工具，而且還不能因為不好用就換別的產品，因為轉移平台的成本很高。如果重要的功能做得不好，他們每天都得痛苦一次，每痛苦一次就會罵一次設計師。身為設計師當然得要極力避免這種狀況。至於不常用的功能，痛苦過一次也就算了。
這個專案的時程？
最後一個問題就是：「你什麼時候要？」
這個問題擺在最後，是為了讓我們在通盤了解PM的需求之後，可以評估需要花多少時間設計，然後開始和PM談判。如果scope不大，時間又很趕，我們可能可以稍微趕一趕。如果了解完之後，發現這是個大專案，而PM給的時間依然很趕，我們就得理性地push back。
一般來說，任何功能，再小的更動我都會跟PM要至少兩週的時間。確保有足夠的時間和其他設計師進行design crtique，得到回饋之後再進行iteration。如果是大功能的話，還得從work flow開始確認這個user flow有解決到PM於user story中提出的問題，再開始設計。無論你評估的時間是多久，記得要多預留個幾天時間給自己，避免開始做了才發現跟自己評估的不一樣，或是中間多了幾次沒有預估到的iteration。
其他關於使用者的問題
除了上面提到的這五個問題之外，根據產品不同，你可能也需要考慮不同的使用裝置、使用情境。以及在使用這個功能的時候，他們需要做哪些前置作業的準備？這些問題本來是要在使用者研究或是觀察中來了解的，然而在無法接觸到使用者的狀況下，我們只能找PM、Customer support或是其他接觸的到使用者的人來問個清楚了。
同樣拿庫存系統來當例子。跟店頭最熟的人可能不是PM也不是客服，而是業務。那我們就可以去問業務，平常店頭是怎麼點庫存的？我們可能會知道，店頭要先騰出一個人力去倉庫數庫存，再把各項產品的庫存數用紙筆抄下來，然後回到座位上輸入。倉庫的環境可能很悶熱、不舒服，他們不想久待。也許用平板可以讓他們在現場就輸入數字，用手寫輸入的方式以符合他們平常的使用習慣，這樣都們就不用回到座位上又再打一次。
這篇文章其實也是幫助我自己筆記一下和PM開會時不能漏掉的問題，大家下次也可以用這個問題清單來和PM釐清需求。這些問題都對於我們的設計非常有幫助，在和PM、工程師講解我們的設計的時候也會更有底氣，說：「對，因為這就是使用者要的。」
