拒絕不合理需求的4個方法
阿新 • • 發佈：2019-01-17
昨晚刷知乎的時候看到一篇特別有意思的虛構故事，其中的案例讓人哭笑不得。大概是說一個產品經理不顧產品資訊結構的優先順序，希望把一個”幫助入口” 做在首頁中間。而且產品經理說服設計師時候以邏輯漏洞的方式進攻，提出諸如 “我作為使用者就有訴求，你沒有訴求也不能代表大家都沒有訴求” 之類的理由。 因為爭論無果最後PM提出要 ABtest，上線之後那個幫助入口點選率竟然還挺高的，讓設計師非常的鬱悶。我之前就經常遇到 “難以拒絕的需求”，他們之間往往都會有一些共性：
1）設計師可以明顯的感覺到需求有問題；
2）產品經理無法給出客觀的需求支撐，但是給出很多”難以拒絕的” 主觀理由；
3）爭論無果後PM會要求做出來試試，但是上線後資料看起來是有利於那個需求的；
所以當遇到這個問題這麼辦呢？我分享一下我自己思考的解法：
1，接到需求的時候，不要討論設計解決方案，而應該討論需求本身
案例中設計師的最大問題就是一直在和PM糾結一個設計解決方案，而不是需求本身。設計解決方案是設計師需要考慮的專業問題，和PM爭論有個毛用，所以之前產品經理無論拿來多麼精密的原型和文件的時候我都會忽視掉解決方案的那部分，從他的言語中定位出問題：
1）這個需求根本是達成什麼目的？
2）這個需求需要的優先程度是怎樣的？
3）這個需求需要的衡量標準是什麼？
很顯然這裡的需求就是『提供一個幫助入口』，並且希望可以『儘量幫助有問題的使用者』。
2，要追問需求背後的目標和背景
在這場溝通案例中設計師一直都在說沒必要做的這麼強，但是他沒有向 PM 瞭解為什麼要做的這麼強，忽略了挖掘需求背後的背景和原因：
1）比如是產品最近有出現重大問題需要緊急修復並且告知使用者嗎？如果這樣的話可以直接針對這個問題給使用者彈出問題卡片，並且告知事故現象和解決方案，而不是模糊的幫助入口；
2）如果是產品業務流程比較複雜，使用者的完成度低所以需要幫助？那幫助的入口是否可以直接引入到場景中，比如在輸入密碼錯誤的時候彈出找回密碼方式，在首次進行某項操作的時候進行新手引導？
需求的背景和目標是一個完整的整體，只有全面瞭解了之後設計師才可能給出ABCD等不同的解決方案，並且在這些解決方案中分析出優劣找出最優解。
3，設計效果不能只看單一的某個維度
案例中 PM 把方案上線測試，但是拿回來的資料設計師就看傻眼了，那個幫助入口的點選率挺高看起來需求很旺盛啊。但是設計師也能看出漏洞，放那麼明顯點選率能不高嗎，可是被產品經理當證據的時候也不知如何反駁，需求和設計方案的效果真的只看點選率嗎？拿獵豹清理大師來說一天有十幾億流量，但是卻也有十幾個大大小小的子功能，如果我是老大我應該把入口給誰呢？衡量指標有三個維度：誰的功能量級大，誰的功能質量好，誰的功能對產品整體帶來的收益高。所以雖然這個幫助入口點選率高，可能使用者進去了之後轉化率和留存會很低（沒需求的使用者好奇點進去就走了），另外也許功能上線後用戶的負面反饋會增多，其他功能的流量也會受到此影響，而這個功能的根本目標（幫助使用者解決問題 – 看問題的修復率）並不會改善很多。所以設計師衡量效果不能只看點選率這麼一個指標，轉化率、留存和使用者反饋等都很重要。
4，設計師要更主動的去獲取資訊
案例裡的設計師還有一個很大的毛病就是完全被PM牽著鼻子走，通過有限的資訊去判斷需求和方案的好壞，其實設計師可以自己主動做到對資訊的全面掌握：
1）比如我們經常鼓勵設計師去參加產品經理的週會、需求評審會、需求討論會，多觀察老大們對產品戰略的宣講，儘量做到設計師本身就可以掂量哪些是重要的哪些是不重要的。
2）設計師可以儘量去開通資料管理後臺學會自己查資料，或者直接進反饋平臺、AppStore、微博、貼吧去看使用者反饋。如果實在不行大公司套路深，可以讓產品和運營把相關的週報抄送給你。
3）設計師要經常學會向上溝通而不是點對點溝通，遇到這個問題的時候可以拉很多人來討論，拉領導來討論，拉牽扯到相關的產品經理來討論，由大家一起發表看法。比如案例中如果設計師拉來負責首頁的產品經理說”他要搶你流量”，你看他們不得先PK一遍？或者如果這個產品經理的需求真的不靠譜的話，適當的和老大提一提那個產品經理很可能就被噴。不必要怕溝通，作為設計師願意去認真對待一個需求一定是會收到刮目相看的。
最後，我看到 唐碩的王閱微 同學的評論也簡單精煉，經過授權給大家分享一下：
必須直接指出，故事中的設計師的立場和溝通方向是錯誤的。
在這個故事裡，事實是：
1. 產品經理提出了一個不完善的方案；
2. 產品經理提出了一個有需求的模糊的場景；
3. 產品經理提出了不適當的追蹤反饋的方式。
設計師的問題有幾點：
1. 沒有開放地去理解『產品需求』背後的『使用者需求』，進行評估很分析（例如使用者角色、可能涉及的場景及任務）；
2. 想通過『否決需求』來『否決方案』；
3. 沒有在理解和分析的基礎上『提出解決方案』（產品經理在嘗試）；
4. 沒有提供研究反饋的思路，任由產品經理以不合理的方式進行評估；
5. 沒有能從使用者任務的角度分析獲得的資料，提出合理假設與進一步分析需求。
在這個故事裡，最大的問題不是不夠專業的能力或方案，而是設計師將自己放在了一個被動的，期望合作伙伴提升的立場。
本文來自優設網，作者@可風f
1）設計師可以明顯的感覺到需求有問題；
2）產品經理無法給出客觀的需求支撐，但是給出很多”難以拒絕的” 主觀理由；
3）爭論無果後PM會要求做出來試試，但是上線後資料看起來是有利於那個需求的；
所以當遇到這個問題這麼辦呢？我分享一下我自己思考的解法：
1，接到需求的時候，不要討論設計解決方案，而應該討論需求本身
案例中設計師的最大問題就是一直在和PM糾結一個設計解決方案，而不是需求本身。設計解決方案是設計師需要考慮的專業問題，和PM爭論有個毛用，所以之前產品經理無論拿來多麼精密的原型和文件的時候我都會忽視掉解決方案的那部分，從他的言語中定位出問題：
1）這個需求根本是達成什麼目的？
2）這個需求需要的優先程度是怎樣的？
3）這個需求需要的衡量標準是什麼？
很顯然這裡的需求就是『提供一個幫助入口』，並且希望可以『儘量幫助有問題的使用者』。
2，要追問需求背後的目標和背景
在這場溝通案例中設計師一直都在說沒必要做的這麼強，但是他沒有向 PM 瞭解為什麼要做的這麼強，忽略了挖掘需求背後的背景和原因：
1）比如是產品最近有出現重大問題需要緊急修復並且告知使用者嗎？如果這樣的話可以直接針對這個問題給使用者彈出問題卡片，並且告知事故現象和解決方案，而不是模糊的幫助入口；
2）如果是產品業務流程比較複雜，使用者的完成度低所以需要幫助？那幫助的入口是否可以直接引入到場景中，比如在輸入密碼錯誤的時候彈出找回密碼方式，在首次進行某項操作的時候進行新手引導？
需求的背景和目標是一個完整的整體，只有全面瞭解了之後設計師才可能給出ABCD等不同的解決方案，並且在這些解決方案中分析出優劣找出最優解。
3，設計效果不能只看單一的某個維度
案例中 PM 把方案上線測試，但是拿回來的資料設計師就看傻眼了，那個幫助入口的點選率挺高看起來需求很旺盛啊。但是設計師也能看出漏洞，放那麼明顯點選率能不高嗎，可是被產品經理當證據的時候也不知如何反駁，需求和設計方案的效果真的只看點選率嗎？拿獵豹清理大師來說一天有十幾億流量，但是卻也有十幾個大大小小的子功能，如果我是老大我應該把入口給誰呢？衡量指標有三個維度：誰的功能量級大，誰的功能質量好，誰的功能對產品整體帶來的收益高。所以雖然這個幫助入口點選率高，可能使用者進去了之後轉化率和留存會很低（沒需求的使用者好奇點進去就走了），另外也許功能上線後用戶的負面反饋會增多，其他功能的流量也會受到此影響，而這個功能的根本目標（幫助使用者解決問題 – 看問題的修復率）並不會改善很多。所以設計師衡量效果不能只看點選率這麼一個指標，轉化率、留存和使用者反饋等都很重要。
4，設計師要更主動的去獲取資訊
案例裡的設計師還有一個很大的毛病就是完全被PM牽著鼻子走，通過有限的資訊去判斷需求和方案的好壞，其實設計師可以自己主動做到對資訊的全面掌握：
1）比如我們經常鼓勵設計師去參加產品經理的週會、需求評審會、需求討論會，多觀察老大們對產品戰略的宣講，儘量做到設計師本身就可以掂量哪些是重要的哪些是不重要的。
2）設計師可以儘量去開通資料管理後臺學會自己查資料，或者直接進反饋平臺、AppStore、微博、貼吧去看使用者反饋。如果實在不行大公司套路深，可以讓產品和運營把相關的週報抄送給你。
3）設計師要經常學會向上溝通而不是點對點溝通，遇到這個問題的時候可以拉很多人來討論，拉領導來討論，拉牽扯到相關的產品經理來討論，由大家一起發表看法。比如案例中如果設計師拉來負責首頁的產品經理說”他要搶你流量”，你看他們不得先PK一遍？或者如果這個產品經理的需求真的不靠譜的話，適當的和老大提一提那個產品經理很可能就被噴。不必要怕溝通，作為設計師願意去認真對待一個需求一定是會收到刮目相看的。
最後，我看到 唐碩的王閱微 同學的評論也簡單精煉，經過授權給大家分享一下：
必須直接指出，故事中的設計師的立場和溝通方向是錯誤的。
在這個故事裡，事實是：
1. 產品經理提出了一個不完善的方案；
2. 產品經理提出了一個有需求的模糊的場景；
3. 產品經理提出了不適當的追蹤反饋的方式。
設計師的問題有幾點：
1. 沒有開放地去理解『產品需求』背後的『使用者需求』，進行評估很分析（例如使用者角色、可能涉及的場景及任務）；
2. 想通過『否決需求』來『否決方案』；
3. 沒有在理解和分析的基礎上『提出解決方案』（產品經理在嘗試）；
4. 沒有提供研究反饋的思路，任由產品經理以不合理的方式進行評估；
5. 沒有能從使用者任務的角度分析獲得的資料，提出合理假設與進一步分析需求。
在這個故事裡，最大的問題不是不夠專業的能力或方案，而是設計師將自己放在了一個被動的，期望合作伙伴提升的立場。
本文來自優設網，作者@可風f