需求作為用戶獲得產(chǎn)品的最重要動機，是每一個開發(fā)者都應(yīng)該關(guān)注和重視的問題。一些開發(fā)人員在工作過程中往往在碰到不合理的需求，這些不合理需求不僅會嚴(yán)重阻礙開發(fā)人員正常工作的開展，也將影響產(chǎn)品或者項目的價值。那么，當(dāng)我們遇到不合理的需求時，應(yīng)該如何應(yīng)對呢？中培課堂《需求分析與管理最佳實踐》王教授在這里給出了自己的意見。

討論需求本身

接到需求的時候，不要討論設(shè)計解決方案，而應(yīng)該討論需求本身。設(shè)計解決方案是設(shè)計師需要考慮的專業(yè)問題，和PM爭論并不會產(chǎn)生實質(zhì)性作用，所以之前產(chǎn)品經(jīng)理無論拿來多么精密的原型和文檔的時候我都會忽視掉解決方案的那部分，有時候會出現(xiàn)以下定位出問題：

1、這個需求根本是達(dá)成什么目的？

2、這個需求需要的優(yōu)先程度是怎樣的？

3、這個需求需要的衡量標(biāo)準(zhǔn)是什么？

很顯然這里的需求就是提供一個幫助入口，并且希望可以盡量幫助有問題的用戶”。

　　要追問需求背后的目標(biāo)和背景

在這場溝通案例中設(shè)計師一直都在說沒必要做的這么強，但是他沒有向 PM 了解為什么要做的這么強，忽略了挖掘需求背后的背景和原因：

比如是產(chǎn)品最近有出現(xiàn)重大問題需要緊急修復(fù)并且告知用戶嗎？如果這樣的話可以直接針對這個問題給用戶彈出問題卡片，并且告知事故現(xiàn)象和解決方案，而不是模糊的幫助入口；

如果是產(chǎn)品業(yè)務(wù)流程比較復(fù)雜，用戶的完成度低所以需要幫助？那幫助的入口是否可以直接引入到場景中，比如在輸入密碼錯誤的時候彈出找回密碼方式，在首次進(jìn)行某項操作的時候進(jìn)行新手引導(dǎo)？

需求的背景和目標(biāo)是一個完整的整體，只有全面了解了之后設(shè)計師才可能給出ABCD等不同的解決方案，并且在這些解決方案中分析出優(yōu)劣找出最優(yōu)解。

設(shè)計效果不能只看單一的某個維度

衡量指標(biāo)有三個維度：誰的功能量級大，誰的功能質(zhì)量好，誰的功能對產(chǎn)品整體帶來的收益高。所以雖然這個幫助入口點擊率高，可能用戶進(jìn)去了之后轉(zhuǎn)化率和留存會很低（沒需求的用戶好奇點進(jìn)去就走了），另外也許功能上線后用戶的負(fù)面反饋會增多，其他功能的流量也會受到此影響，而這個功能的根本目標(biāo)（幫助用戶解決問題 – 看問題的修復(fù)率）并不會改善很多。

所以，設(shè)計師衡量效果不能只看點擊率這么一個指標(biāo)，轉(zhuǎn)化率、留存和用戶反饋等都很重要。

設(shè)計師要更主動的去獲取信息

案例里的設(shè)計師還有一個很大的毛病就是完全被PM牽著鼻子走，通過有限的信息去判斷需求和方案的好壞，其實設(shè)計師可以自己主動做到對信息的全面掌握：

設(shè)計師有機會應(yīng)該多去參加產(chǎn)品經(jīng)理的周會、需求評審會、需求討論會，多觀察老大們對產(chǎn)品戰(zhàn)略的宣講，盡量做到設(shè)計師本身就可以掂量哪些是重要的哪些是不重要的。

設(shè)計師可以盡量去開通數(shù)據(jù)管理后臺學(xué)會自己查數(shù)據(jù)，或者直接進(jìn)反饋平臺、AppStore、微博、貼吧去看用戶反饋。如果實在不行大公司套路深，可以讓產(chǎn)品和運營把相關(guān)的周報抄送給你。

設(shè)計師要經(jīng)常學(xué)會向上溝通而不是點對點溝通，遇到這個問題的時候可以拉很多人來討論，拉領(lǐng)導(dǎo)來討論，拉牽扯到相關(guān)的產(chǎn)品經(jīng)理來討論，由大家一起發(fā)表看法。比如案例中如果設(shè)計師拉來負(fù)責(zé)首頁的產(chǎn)品經(jīng)理說”他要搶你流量”，你看他們不得先PK一遍？或者如果這個產(chǎn)品經(jīng)理的需求真的不靠譜的話，適當(dāng)?shù)暮屠洗筇嵋惶崮莻€產(chǎn)品經(jīng)理很可能就被噴。不必要怕溝通，作為設(shè)計師愿意去認(rèn)真對待一個需求一定是會收到刮目相看的。