作為產品經理最頭疼的一部分就是——需求了。需求說大可大，說小可小，除了真偽，還有一些東西讓我們困惑。所以本期天天問整理了天天問小伙伴對需求的疑問以及精選回答，希望可以幫助各位產品大大應對需求的問題，enjoy~

問題清單：

1. 都說在產品設計中要“少就是多”，可具體怎么做？
2. 每個人都可能在你的方案上插兩嘴，導致最后自己都迷糊這個需求是不是自己提的了。大家是怎么處理這種事的？
3. 如何面對小需求變大需求的問題？
4. 需求評審時哪些話不該說？

————————————————— 我是分割線 —————————————————

問題1

都說在產品設計中要“少就是多”，可具體怎么做？@瓜小皮

描述如下

1. 做的時候總是想說的更多，對用戶解釋的更清楚。然后頁面內容就被添加的各種多！
2. 怕用戶不知道這個東西在這里，怕用戶要用的時候不能做方便的找到，然后功能這里放一個，那里也放一個，各種放！
3. 我還要給用戶更多，嗯？這個用戶提了這個需求？好的我加上??！越來越多??！
4. ……

然后被說，要做減法，而不是做加法?？墒钦娴牟恢缿撛趺慈p。減了吧，總是反饋，這個不知道，那個不顯眼！每天都被問，這個功能在哪里，用戶不知道！那個功能不顯眼，用戶每次都來問！

麻煩說說看，應該怎么做才好呢！

精選回復@追夢人?

說說自己對這句話的理解：在產品設計中要“少就是多”。

為什么要講究只做非要不可的功能？

C端產品有個特點：用戶是根據習慣來使用我們的產品，基本是0操作培訓。這時就帶來一個問題：我們的產品定位是解決什么用戶的什么需求？

用戶在打開我們產品時，內心就已經錨定了這個產品能用來做什么？

那么在進去的頁面，我們就最好讓用戶看到他們希望看到的內容，以一個電商APP為例：

1. 如果我們是做生鮮電商的，那么大部分用戶常買品類可能是水果、蔬菜、肉禽蛋、海鮮等。那么應該先展示出這些品類，讓用戶一下子就找到自己想要的東西。
2. 考慮用戶的最短操作路徑：查商品-選商品-加入購物車-完成付款-查詢訂單狀態。那么在用戶的每一步操作都根據用戶的心智模型，展示下一步要操作的按鈕。
3. 做好了第2點，再來考慮用戶的一些其他操作下，系統又要如何處理？比如：用戶可能尚未注冊、登錄，那么在加入購物車進行下單時要友好地提示登錄，登錄完成后直接進入訂單結算界面等。

下面說說問題中3個點如何處理？

1. 第1點，總是想去做解釋，可以看看《用戶體驗要素》，產品可以考慮參考大部分用戶常用的其他產品，適應用戶的操作習慣，這樣就沒有太多解釋的必要。
2. 第2點，怕用戶不知道功能放那，多個地方放同個功能，參照我上面的第2點，應該可以有效解決。
3. 第3點，不同用戶提出越來越多需求，這里就有個取舍問題——一個需求做與不做的標準是什么？對于關鍵路徑外的需求，評估后如何認為有價值要做，那么這個功能可以在上線的前一階段，在主頁上有個提醒，通過一段時間的觀察，來看這個新增需求是否有真實的用戶需求，通過類似方式系統最終沉淀的功能都是實用的。

精選回復@鯨魚我是陳靖宇?

用戶不需要思考嗎？這是我懷疑的地方。

容易得到的東西，不容易獲得的快感，在生活中也是如此。比如：教了孩子好久，孩子終于學會喊媽媽了，第一聲會讓你無比感動，如果孩子天生就會喊媽媽，那么這個刺激就會降低很多。

就像是微信，他的很多操作都是比較高級和復雜的，一般人并不會發現這個功能。比如：長按小相機可以發純文字朋友圈，發消息長按可以撤回、收藏消息等等。這些功能沒有做的很容易觸達，但是還是做成了很高的認知度和傳播度。

這過程中包括：咦，為什么你的微信公眾號可以回復鏈接我的不行，我去百度找找教程，為什么你可以發純文字朋友圈，我問問你是怎么弄的。甚至有揭秘《你不知道的微信20個操作技巧》的文章都能10W加。

所以我覺得不需要考慮太多，基本上按照用戶普遍認知的交互邏輯走，滿足基本功能，一些進階操作，可以加入后續用戶間的影響學習。

精選回復@破宇?@獅子魚??Gavin?

建議看看簡約設計這本書，核心思想是為主流用戶提供產品，里面有一個很經典的例子，早先的電視遙控上經常幾十上百個按鍵，每個按鍵都有單獨的功能，操作只有一步。但是對主流用戶來說，常用的只是開關機，快慢進，其余的按鈕只增加了理解成本。而現在的遙控器通常只有6個按鍵，更多的操作通過隱藏、刪除、不同操作端的方式解決。

大部分產品，是為了滿足用戶群體絕大多數人的需求。只要多數人提了，就應該引起重視。少數人提的，一般不是大家都要用到的。每個需求是自己去分辨，還要根據當前條件，排序，哪些優先。要學會擋需求，說服大家為什么做，為什么不做。

首頁設置兩個通道可以切換，一個專業人士；一個入門人士。默認為受眾多的。

精選回復@無奈的我0000?

首先你要知道，你所關注的用戶是主流用戶嗎？是經常來你們平臺的還是只是偶爾來一兩次的。

聽用戶需求并不一定要全盤照做，而是要揣摩用戶所說的話后面真正的東西，如果用戶說一個 你做一個，那么你永遠都做不完他們所想要的需求。

1. 如果用戶看不懂的功能，那么功能基本上是不合理的，如果一個功能出來，需要用戶費腦子去理解，那么就應該想想如何讓用戶一目了然的去使用這個功能，而不是添加更多的東西來輔助。
2. 針對第二個問題，可能你可以事先埋點 ，先看看用戶實際行為，找出他們用得不爽的地方，然后針對這些地方設計出合理的功能，而不是你說的怕這個怕那個。
3. 用戶提的需求需要匯總，然后再觀察他們所有人的需求背后是否有共性，最終設計出一個大致符合他們所期望功能出來，說得不好的地方歡迎大家繼續回答?。?！

精選回復@Placeless?

現在互聯網中常說的less is more 是來自于現代主義建筑大師密斯·凡· 德羅的，出自現代建筑設計。

Less意味著明確的目標；Less意味著去除不必要的東西；Less意味著專注，把有限的精力集中在最重要的事情上；Less意味著節制的態度。

• Less，不是單調，而是簡潔
• More，不是繁復，而是豐富

“Less is More”，意味著高效，這和現代社會的精神是一致的。

少即是多 在互聯產品設計中更顯得重要，因為每個人接受的信息太多了，處理這些信息就需要效率，如果做到少即是多，都是根據具體情況具體分析的，不能一概而論，也不能根據個例去影響整體。

很多人常會說用戶是小白，這里可能看不懂那里可能看不懂，并舉例1.2.3.4.5。而互聯網發展的這幾年，已經有越來越多的用戶適應了使用互聯網，12345只是反饋的個例，那么自然不能為這12345去改80%的用戶了。

（1）比如：曾經設計的一個產品中有一個榜單功能，這個產品的用戶群體集中在青年和中年，產品就想試在頁面中用大篇幅像用戶解釋這個榜單是怎么來的，因此具有xxx公信力，能更吸引用戶。但是實際中，用戶至關心排名前幾名是否好壞。

在大部分用戶的心理模型中，你怎么定的排名和我沒時間去研究，我要看的是排前幾名的是不是我正好需要的。因此大篇幅的關于榜單介紹的內容就是冗余的，對用戶達成目標是有干擾的，就要去掉。

（2）任何產品都是存在學習和認知成本的，降低這些成本有很多方式，不是簡單地放在用戶眼前就行了， 給用戶的選擇越多效率越低，一個頁面讓用戶做一件事，一些相對低頻的操作放到二級收起來，用戶想找的時候能夠相應地去找到，也沒什么。

還有的功能，雖然不明顯，但用戶操作一次后，能夠知道，那就ok，實在擔心就在用戶第一次進入的時候給個氣泡提示也行。

一些功能，用戶第一次操作存在學習成本，但后續操作是方便的，是沒什么問題的。

（3）克制，克制，克制，用戶的需求和產品的目標不一致，加嗎？不加！ 用戶的需求只是代表了他個人的想法，加嗎？不加！用戶的需求會破壞其他80%人的體驗，加嗎？不加！不是目標用戶提出的需求，加嗎？不加！

復雜也是有個守恒定律的， 一個產品包含的功能實在太多，面對的人群太廣，不管怎么刪除組織隱藏轉移這個產品還是會顯得復雜，可以考慮針對各項路徑，在任務路徑中增強主任務和其他任務的對比（就像城市中的馬路，主干道總是又寬又大的，司機一看就知道），滿足大部分人在大部分場景下操作是方便的，這樣就好。

另外在產品設計的美學上，后現代建筑設計也提出了less is bore，純粹地為了追求簡潔而做減法也是不可取的。

精選回復@夜雨?

我很少回答問題，因為很多提問我覺得缺乏必要的場景、數據支持，不能就具體情況作出符合實際的解決方案。例如：題目的問題，沒有明確是什么類型的產品，是C端還是B端？在哪些頁面場景？具體用戶反饋的數據是什么樣的？反饋比例如何？

由于沒有實際場景、數據支撐，如果一味強調用戶是傻子，照搬“少就是多“的設計理念，可能是錯的。

為什么這樣說？

如果是復雜的后臺產品，本身就是要效率最大化，如果把一些關鍵的操作隱藏、關鍵的說明文案隱藏，這樣去追求界面的簡潔性，有什么意義？

所以，要落實到具體場景分析，用戶反饋的核心點在哪里？有沒有對反饋的用戶做過調研？后臺數據反饋比例是多少，再來回到“少就是多”的問題。

問題詳情：https://wen.woshipm.com/question/detail/gdjfar.html

問題2

每個人都可能會在你的方案上插兩嘴，最后導致自己都迷糊這個需求是不是自己提的了，大家是怎么處理這種事的？@康熙是老大?

描述如下

一個需求會經過好幾次改版才定下一個終稿。但是這個過程是很零散的一個過程，也許老板吃著泡面，突然一拍大腿，嗨，這里加個柱子。亦或是總監喝著湯，突然腳一跺，嗨，這里加個坑。再或者，你的UI告訴你，這里不能這么設計。

每一個人都在打亂著你本來的思路，記得清的，是正兒八經開會確定的改稿方向，時?；煜?，是冷不丁的一條QQ消息。

我現在的方法就是不管是誰，我都記在小本本上，然后晚上做個總結，把方案相關文檔整理一下，每日更新。

但是這樣有個壞處，就是記得太清晰。比如：今天這個某人提了一個改進意見，你吭哧吭哧記錄下來了，并且又總結又更新文檔，記得可清楚了，但是過了兩天，換了個邏輯，好了，你又記錄下來，然后晚上總結，更新文檔，記得可清楚了。

時隔半月，別人問你這個功能的邏輯，臥槽，腦子里兩個邏輯在打架。趕緊翻文檔看看，看完之后明了了。但是，心里空空的，感覺這樣下去不是辦法。對自己的產品把控居然要靠需求文檔提醒，難道自己的產品不應該是身上的肉，咋長的，自己心里最清楚嗎？還要看文檔？！

所以，我想問問大家對這樣個問題的解決方案，希望能得到一些啟發。

精選回復@sooboo?

那你做好需求記錄表呀，把所有需求都羅列下來，誰提的，提的時候是什么時候，為何會提這種需求，需要解決什么問題，需求屬于哪種類別，需求評估（重要程度、緊急程度、商業價值、開發成本、難易度、開發周期等），需求對接人負責人事誰，后期的跟蹤記錄，你都做好了就不會產生這問題

精選回復@破宇 @焰陌?

（1）首先自己要清楚為什么提這個需求，老板的要求？競品的參考？自己的靈感？

確定了為什么提，就要圍繞這個理由去想要不要改，如果違反了開始的目的，就不要聽。

舉個例子：老板說讓你加個收藏功能，你要弄明白的是老板為啥加這個功能，什么目的，什么要求，想要什么結果？這時候不管是UI跟你說這個需求影響頁面布局，還是研發跟你說這個需求影響框架穩定，都去圍繞最開始問題去考慮聽不聽，改不改，怎么改

（2）我做了一個一個Excel，誰，什么時間，提出了什么問題，問題被提出的次數，每一次是怎么解決的。

我覺得有用，你可以試試。

問題詳情：https://wen.woshipm.com/question/detail/oc92ge.html

問題3

如何面對小需求變大需求的問題？@horace?

描述如下

（1）有一個需求，我接手前情況是這樣的：

客服A在接待顧客X時，輸入顧客X的手機號綁定信息，那么以后顧客X的下單績效只會算進客服A，并且只有客服A能查看顧客X的訂單信息；然而，客服A不是24小時在線，有時需要轉接給客服B處理，但客服B在處理問題時，看不到顧客X的訂單信息，處理起來非常麻煩。

（2）因此，客服向產品提了需求：要求客服A轉接給客服B時，讓客服B能看到顧客X的訂單信息。（這個需求通過了產品內審）

（3）這個需求看起來很容易理解吧，于是我便輸出解決方案：

1. 客服A轉接給客服B時，允許客服B看到顧客X的訂單信息；
2. 考慮到看到訂單信息和績效統計這兩點可能有聯系，便強調只是允許看到訂單信息，不能把績效算進客服B。

（4）我把這個方案提給產品總監

產品總監看了看，搖了搖頭說：“得改”

“為何”

“沒有考慮客服B的績效問題”

“這個系統之前設計就是這樣的，不會算入B的績效，而且需求不是關于客服B的績效問題”

“不，你得考慮各種情況”

“但客服B的績效問題一直都是，而且跟客服溝通過，沒客服覺得有這個有問題，都運作了這么久沒人提這個問題，我們產品不好意淫吧，萬一弄出其他問題怎么辦”

“不，不要只聽客服說的”

我再強調說“需求不是這個，只是客服B的訂單顯示問題”

總監說“還是得改，不合理”，然后轉身去開會了。

（5）此刻我的心想：我的天啊，我真的想不通我的解決方案有什么問題，竟然被駁回了。需求明確擺在那，我覺得自己的方案能解決該需求的啊，怎么突然給我扯到了其他需求，這不是要我延期完成任務嗎！

求各位大神告訴我，問題出在哪里？是做事方式還是解決方案？應該怎么辦？

精選回復@追夢人?

初看這個問題，我從一般公司的層級角度給你提供一個思考方向：

我之前在甲方做軟件規劃分析時，產品接到某個用戶的需求時，一般要初步判斷下，這個需求是屬于普通的操作優化還是對公司業務、KPI等有影響？

如果屬于后者，那這個需求就不是一般的業務單位的一個基層可以決定怎么樣是合適的。從公司組織結構來看，客服中心如有經理、總監，那么客服人員提出的這個需求應該通過其經理、總監同意（你們可以做個需求申請表及審核流程來解決這類問題，如果中小公司，就可以直接內部討論下）。

建議需求人填寫：目前遇到的問題是什么？希望實現的效果是什么？

經過客服的大佬們同意后，再流向產品，產品來回復解決方案，產品的解決方案再流向產品大佬審核，審核通過后在流程客服大佬審核，最終才進入開發階段。（上述流程主要是中大型企業，如果中小企業就直接找個會議室溝通清楚）

我來看，你的問題可能是把一個涉及公司KPI考核的問題，簡單地當成了一個客服人員的操作優化，所以你們總監不認同.

精選回復 @阿呂?@追求卓越?

（1）我問一個問題啊，B處理A轉接的訂單的時候，如果瞎幾把處理，弄砸了，這個時候你扣誰的績效？

（2）在職場領導永遠都是對的。即便領導的決策是錯的，你也需要先執行了再說。針對你這個問題了，你就把如果只是解決訂單顯示的問題需要的工作量和解決績效問題需要的工作量一一做詳細的分析后讓領導決策。

而且涉及到績效的問題就牽扯到很深的業務了，各種情況都要考慮到，比如：現在的考核體系是否支持一個訂單相關的績效同屬兩個客服人員，若是屬于需要按什么規則拆分，若是不屬于那B的績效如何算。而且績效考核問題牽涉到很深的業務層面，那就得部門或是CEO來決策了。

總之一句話你詳細分析各種情況需要的資源，包括業務部門簽字確認，人員調配等等。

精選回復@horace?

感謝大家意見，我這里也說下后續。

1. 需求重新更改，輸出商家和公司內部都認為更好的績效方案設計，通過產品內審。（耗時4天）
2. 技術評估，發覺改動很大，出問題風險高，向老板匯報。（耗時1.5天）
3. 老板綜合多方意見，決定不做。（耗時0.5天）

這個大需求，后來不做，共耗時6天（假如要開發，還不含實際開發量）。

后來回歸采用原來的小方案，共耗時2天就能讓技術完成開發。開發完成后，各部門和商家皆大歡喜。

那就是說，一開始各部門和商家都覺得能產生價值的明確需求其實可以先做，然后再考慮大家都不在意的不明確需求（哪怕真的是有價值）。畢竟產品有迭代性，沒有產品是完美的。

問題詳情：https://wen.woshipm.com/question/detail/oc92ge.html

問題4

需求評審時哪些話不該說？@張十安?

精選回復@張十安?

（1）這個功能，我看XX產品做了，挺有意思，既然別人做了，就有存在的理由。

因為別人做了，我們就可以做，這句話有很大邏輯漏洞，根本站不住腳，別人做了不代表他們覺得有價值，或者用戶覺得有價值。這種話如果說出來，很容易讓人質疑你的能力。

（2）這個功能XX說了好幾次了，優先級肯定很高，需要快點做。

別人說了好幾次的需求，不代表現在要馬上做，要確認當時提需求時，是否和特定場景相關，很可能當時很緊急的需求，到現在并不緊急了，這個得具體問題具體分析。

（3）雖然這個功能是為這個活動做的，但以后我們也可以用在其他地方。

具體講解時，需要考慮全面了再說，也就是要明確“其他地方”都有哪些，是否一定要用這個功能實現，投入產出比如何？其他方案是否也能滿足需求，如果長期考慮用途不大，只是為了一次性活動，那就要根據開發成本考慮最簡實現方案。

（4）這個功能做了，可以拿來售賣啊……

一個功能是否值得做，需要先考慮其在特定場景下的用戶價值，然后再提商業價值。有些功能的商業屬性是很弱的，單純拿出來作為理由站不住腳，還是要結合場景來說。

精選回復@?sssDamian?@Kevin.H.S?@文二水 @夢想家?

1. 我覺得，我認為，可能是，或許吧。
2. 做好自己分內的事，不評價產品工作外的事情，比如：不評論技術框架的好壞和設計元素上的優劣，這些都是由開發團隊和設計團隊該考慮的事情。
3. 這個功能很簡單啊， 兩天夠了吧……說了肯定能被研發砍死。
4. 這個功能，我看XX產品做了，挺有意思，既然別人做了，就有存在的理由。

問題詳情：https://wen.woshipm.com/question/detail/2et698.html

總結

你在“需求”中有什么疑問和見解嗎？歡迎來天天問和小伙伴們一起分享討論哦~

相關閱讀

【天天問每周精選】第50期：大開眼界：活動運營的新鮮玩法

【天天問每周精選】第49期：傳統行業如何合理利用互聯網思維

【天天問每周精選】第48期：各位產品大大，來腦洞大開玩點子吧

【天天問每周精選】第47期：秋招季到了，來看點有意思的面試題吧

【天天問每周精選】第46期：QQ和微信之間不得不說的那些事

精選問題每周有，歡迎食用~配合回復味道更佳(∩_∩)

本欄目由天天問小編@Tracy 編輯，歡迎大家踴躍提問，一起交流。

題圖來自 Unsplash ，基于 CC0 協議