UX答課問：Wireframe要由產品經理負責產出嗎？
今年在商業思維學院開課了一系列從需求訪談、用戶研究到資訊架構、原型設計等等的產品設計課程，在這邊記錄一下學生的提問，以及我的回答。
商業思維同學的提問
請問Wire frame一般來說都是由產品經理產出嗎？我們公司都是UX/UI一起搞定。
或是說不由產品經理產出會有什麼問題嗎？
我的回答
哈囉，每間公司對於職責分工的期待都不一樣，所以你的問題沒辦法獲得通用回答。
我過去在新創公司擔任產品經理的經驗，以及這些年與不同領域的產品經理交流，的確沒有找到什麼明確的規律，很看公司目前發展階段以及人力現況。
我先說說如果是 PM 負責產出wireframe的優缺點：
優點是，PM 通常是彙整需求變動的人，因此可以將 wireframe 作為目前規格的共識文件，只要有良好的線上發佈習慣以及搭配編碼原則，團隊夥伴只要經過一開始的共識講解，後面在開發過程就不需要一直跑回來問 PM 某些狀況怎麼辦、去哪邊找人問之類的問題
缺點也很明顯，主要有兩個原因，一來是 PM 的時間通常是團隊生產力瓶頸，二來不是每個 PM 都對於互動設計有所涉獵。
先談談第一個狀況吧，PM 的時間通常是團隊生產力瓶頸
我過去在擔任 PM 時，經常一整天有開不完的會議，要跟各色各樣的利害關係人以及合作單位溝通，協調共識。
通常有時間坐下來好好寫文件的時候，多半已經是夜深人靜的晚上。
但其實這個時間，經過一整天的認知消耗，注意力已經是匱乏狀態，不容易維持高度專注以及動用系統二的邏輯腦來進行深度思考。
也就是說，這樣狀態寫的規格文件，有大概率充滿了漏洞。
然後當犧牲了休息時間的 PM 辛辛苦苦把這樣的文件好不容易擠出來，提供給團隊夥伴之後，又因為漏洞擺出的規格描述，被團隊夥伴砲轟以及降低專業信任感。
瞧，這邊就是負面循環以及衝突的癥結點。
辛苦熬夜的 PM 沒有得到正回饋，反倒是讓網路上增添更多吐槽的文章。
第二個狀況是，不是每個 PM 都對於互動設計有所涉獵。
到了 wireframe 階段，這是資訊架構設計重要的格局規劃以及互動引導的規格文件。
有些 PM 是技術背景出身、有些是行銷出身等等，對於人類需要什麼程度的訊息量，用以完成目標的互動設計以及 UX 體驗，認知程度不一。
常見的產品領域，或許還可以上網找一些通用的模版來當範本改看看，但更常見的狀況是變成拼裝車，找了四五種不同領域產品的模版來參考，各取一點看起來像是我要的東西放上去。
這個狀況到了工程師以及後面接手的設計師手上，看起來就會像是噁心的大雜匯，因為無法辨識哪些元素是真正的想法，哪些元素是抄過來用的時候沒有拿掉的。
更糟糕的情況是，我們會愛上自己付出心力的東西，這份 wireframe 再怎麼醜，也是我辛辛苦苦熬夜的呀，怎麼你們都不認同我？
這些慘劇我也遇過，也看過許多 PM 朋友踩過坑。
但坦白說，這不是誰的錯，而是沒有正確識別每個角色的能力範疇以及團隊應該如何互相支援。
我會定義為，這是團隊人力資源沒有協調好的問題，才發生了某項工作雖然知道有人該處理，但是卻將壓力放在脆弱的環節上。
不過話又說回來，我也因此遇到很多心靈充滿創傷的 PM，一下子嚷嚷著要去寫程式（被工程師嗆），一下子嚷嚷著要多學一點設計（被設計師嫌棄）。
這也是這份職業為難以及充滿矛盾的地方，我們似乎什麼都要會，但又似乎不應該插手團隊夥伴的專業，但如果我們真的不會，又要怎麼 review 成果以及提出足夠品質的要求呢？
這就是 PM 的修煉了。
以上分享給你。
訂閱 Soking 舉辦的 UX 教學活動：
如果你希望獲得 Soking 的課程以及 UX 講座訊息，歡迎留下你的 Email，訂閱最新的 UX 活動通知：https://subscribe.soking.cc/
查看獸群之心的UX文章目錄