【天天問每週精選】第51期：關於需求的那些事，我們可不是隻嘮真偽
零基礎學產品，BAT產品總監帶，2天線下集訓+1年線上課程，全面掌握優秀產品經理必備技能。 ofollow,noindex">瞭解詳情
釋放雙眼，帶上耳機，聽聽看~！
00:00
00:00
作為產品經理最頭疼的一部分就是——需求了。需求說大可大，說小可小，除了真偽，還有一些東西讓我們困惑。所以本期天天問整理了天天問小夥伴對需求的疑問以及精選回答，希望可以幫助各位產品大大應對需求的問題，enjoy~
問題清單：
- 都說在產品設計中要“少就是多”，可具體怎麼做？
- 每個人都可能在你的方案上插兩嘴，導致最後自己都迷糊這個需求是不是自己提的了。大家是怎麼處理這種事的？
- 如何面對小需求變大需求的問題？
- 需求評審時哪些話不該說？
————————————————— 我是分割線 —————————————————
問題1
都說在產品設計中要“少就是多”，可具體怎麼做？@瓜小皮
描述如下
- 做的時候總是想說的更多，對使用者解釋的更清楚。然後頁面內容就被新增的各種多！
- 怕使用者不知道這個東西在這裡，怕使用者要用的時候不能做方便的找到，然後功能這裡放一個，那裡也放一個，各種放！
- 我還要給使用者更多，嗯？這個使用者提了這個需求？好的我加上！！越來越多！！
- ……
然後被說，要做減法，而不是做加法。可是真的不知道應該怎麼去減。減了吧，總是反饋，這個不知道，那個不顯眼！每天都被問，這個功能在哪裡，使用者不知道！那個功能不顯眼，使用者每次都來問！
麻煩說說看，應該怎麼做才好呢！
精選回覆@追夢人
說說自己對這句話的理解：在產品設計中要“少就是多”。
為什麼要講究只做非要不可的功能？
C端產品有個特點：使用者是根據習慣來使用我們的產品，基本是0操作培訓。這時就帶來一個問題：我們的產品定位是解決什麼使用者的什麼需求？
使用者在開啟我們產品時，內心就已經錨定了這個產品能用來做什麼？
那麼在進去的頁面，我們就最好讓使用者看到他們希望看到的內容，以一個電商APP為例：
- 如果我們是做生鮮電商的，那麼大部分使用者常買品類可能是水果、蔬菜、肉禽蛋、海鮮等。那麼應該先展示出這些品類，讓使用者一下子就找到自己想要的東西。
- 考慮使用者的最短操作路徑：查商品-選商品-加入購物車-完成付款-查詢訂單狀態。那麼在使用者的每一步操作都根據使用者的心智模型，展示下一步要操作的按鈕。
- 做好了第2點，再來考慮使用者的一些其他操作下，系統又要如何處理？比如：使用者可能尚未註冊、登入，那麼在加入購物車進行下單時要友好地提示登入，登入完成後直接進入訂單結算介面等。
下面說說問題中3個點如何處理？
- 第1點，總是想去做解釋，可以看看《使用者體驗要素》，產品可以考慮參考大部分使用者常用的其他產品，適應使用者的操作習慣，這樣就沒有太多解釋的必要。
- 第2點，怕使用者不知道功能放那，多個地方放同個功能，參照我上面的第2點，應該可以有效解決。
- 第3點，不同使用者提出越來越多需求，這裡就有個取捨問題——一個需求做與不做的標準是什麼？對於關鍵路徑外的需求，評估後如何認為有價值要做，那麼這個功能可以在上線的前一階段，在主頁上有個提醒，通過一段時間的觀察，來看這個新增需求是否有真實的使用者需求，通過類似方式系統最終沉澱的功能都是實用的。
精選回覆@鯨魚我是陳靖宇
使用者不需要思考嗎？這是我懷疑的地方。
容易得到的東西，不容易獲得的快感，在生活中也是如此。比如：教了孩子好久，孩子終於學會喊媽媽了，第一聲會讓你無比感動，如果孩子天生就會喊媽媽，那麼這個刺激就會降低很多。
就像是微信，他的很多操作都是比較高階和複雜的，一般人並不會發現這個功能。比如：長按小相機可以發純文字朋友圈，發訊息長按可以撤回、收藏訊息等等。這些功能沒有做的很容易觸達，但是還是做成了很高的認知度和傳播度。
這過程中包括：咦，為什麼你的微信公眾號可以回覆連結我的不行，我去百度找找教程，為什麼你可以發純文字朋友圈，我問問你是怎麼弄的。甚至有揭祕《你不知道的微信20個操作技巧》的文章都能10W加。
所以我覺得不需要考慮太多，基本上按照使用者普遍認知的互動邏輯走，滿足基本功能，一些進階操作，可以加入後續使用者間的影響學習。
精選回覆@破宇 @ 獅子魚 Gavin
建議看看簡約設計這本書，核心思想是為主流使用者提供產品，裡面有一個很經典的例子，早先的電視遙控上經常幾十上百個按鍵，每個按鍵都有單獨的功能，操作只有一步。但是對主流使用者來說，常用的只是開關機，快慢進，其餘的按鈕只增加了理解成本。而現在的遙控器通常只有6個按鍵，更多的操作通過隱藏、刪除、不同操作端的方式解決。
大部分產品，是為了滿足使用者群體絕大多數人的需求。只要多數人提了，就應該引起重視。少數人提的，一般不是大家都要用到的。每個需求是自己去分辨，還要根據當前條件，排序，哪些優先。要學會擋需求，說服大家為什麼做，為什麼不做。
首頁設定兩個通道可以切換，一個專業人士；一個入門人士。預設為受眾多的。
精選回覆@無奈的我0000
首先你要知道，你所關注的使用者是主流使用者嗎？是經常來你們平臺的還是隻是偶爾來一兩次的。
聽使用者需求並不一定要全盤照做，而是要揣摩使用者所說的話後面真正的東西，如果使用者說一個 你做一個，那麼你永遠都做不完他們所想要的需求。
- 如果使用者看不懂的功能，那麼功能基本上是不合理的，如果一個功能出來，需要使用者費腦子去理解，那麼就應該想想如何讓使用者一目瞭然的去使用這個功能，而不是新增更多的東西來輔助。
- 針對第二個問題，可能你可以事先埋點 ，先看看使用者實際行為，找出他們用得不爽的地方，然後針對這些地方設計出合理的功能，而不是你說的怕這個怕那個。
- 使用者提的需求需要彙總，然後再觀察他們所有人的需求背後是否有共性，最終設計出一個大致符合他們所期望功能出來，說得不好的地方歡迎大家繼續回答！！！
精選回覆@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）這個需求看起來很容易理解吧，於是我便輸出解決方案：
- 客服A轉接給客服B時，允許客服B看到顧客X的訂單資訊；
- 考慮到看到訂單資訊和績效統計這兩點可能有聯絡，便強調只是允許看到訂單資訊，不能把績效算進客服B。
（4）我把這個方案提給產品總監
產品總監看了看，搖了搖頭說：“得改”
“為何”
“沒有考慮客服B的績效問題”
“這個系統之前設計就是這樣的，不會算入B的績效，而且需求不是關於客服B的績效問題”
“不，你得考慮各種情況”
“但客服B的績效問題一直都是，而且跟客服溝通過，沒客服覺得有這個有問題，都運作了這麼久沒人提這個問題，我們產品不好意淫吧，萬一弄出其他問題怎麼辦”
“不，不要只聽客服說的”
我再強調說“需求不是這個，只是客服B的訂單顯示問題”
總監說“還是得改，不合理”，然後轉身去開會了。
（5）此刻我的心想：我的天啊，我真的想不通我的解決方案有什麼問題，竟然被駁回了。需求明確擺在那，我覺得自己的方案能解決該需求的啊，怎麼突然給我扯到了其他需求，這不是要我延期完成任務嗎！
求各位大神告訴我，問題出在哪裡？是做事方式還是解決方案？應該怎麼辦？
精選回覆@追夢人
初看這個問題，我從一般公司的層級角度給你提供一個思考方向：
我之前在甲方做軟體規劃分析時，產品接到某個使用者的需求時，一般要初步判斷下，這個需求是屬於普通的操作優化還是對公司業務、KPI等有影響？
如果屬於後者，那這個需求就不是一般的業務單位的一個基層可以決定怎麼樣是合適的。從公司組織結構來看，客服中心如有經理、總監，那麼客服人員提出的這個需求應該通過其經理、總監同意（你們可以做個需求申請表及稽核流程來解決這類問題，如果中小公司，就可以直接內部討論下）。
建議需求人填寫：目前遇到的問題是什麼？希望實現的效果是什麼？
經過客服的大佬們同意後，再流向產品，產品來回復解決方案，產品的解決方案再流向產品大佬稽核，稽核通過後在流程客服大佬稽核，最終才進入開發階段。（上述流程主要是中大型企業，如果中小企業就直接找個會議室溝通清楚）
我來看，你的問題可能是把一個涉及公司KPI考核的問題，簡單地當成了一個客服人員的操作優化，所以你們總監不認同.
精選回覆 @阿呂 @ 追求卓越
（1）我問一個問題啊，B處理A轉接的訂單的時候，如果瞎幾把處理，弄砸了，這個時候你扣誰的績效？
（2）在職場領導永遠都是對的。即便領導的決策是錯的，你也需要先執行了再說。針對你這個問題了，你就把如果只是解決訂單顯示的問題需要的工作量和解決績效問題需要的工作量一一做詳細的分析後讓領導決策。
而且涉及到績效的問題就牽扯到很深的業務了，各種情況都要考慮到，比如：現在的考核體系是否支援一個訂單相關的績效同屬兩個客服人員，若是屬於需要按什麼規則拆分，若是不屬於那B的績效如何算。而且績效考核問題牽涉到很深的業務層面，那就得部門或是CEO來決策了。
總之一句話你詳細分析各種情況需要的資源，包括業務部門簽字確認，人員調配等等。
精選回覆@horace
感謝大家意見，我這裡也說下後續。
- 需求重新更改，輸出商家和公司內部都認為更好的績效方案設計，通過產品內審。（耗時4天）
- 技術評估，發覺改動很大，出問題風險高，向老闆彙報。（耗時1.5天）
- 老闆綜合多方意見，決定不做。（耗時0.5天）
這個大需求，後來不做，共耗時6天（假如要開發，還不含實際開發量）。
後來迴歸採用原來的小方案，共耗時2天就能讓技術完成開發。開發完成後，各部門和商家皆大歡喜。
那就是說，一開始各部門和商家都覺得能產生價值的明確需求其實可以先做，然後再考慮大家都不在意的不明確需求（哪怕真的是有價值）。畢竟產品有迭代性，沒有產品是完美的。
問題詳情： https://wen.woshipm.com/question/detail/oc92ge.html
問題4
需求評審時哪些話不該說？@張十安
精選回覆@ 
（1）這個功能，我看XX產品做了，挺有意思，既然別人做了，就有存在的理由。
因為別人做了，我們就可以做，這句話有很大邏輯漏洞，根本站不住腳，別人做了不代表他們覺得有價值，或者使用者覺得有價值。這種話如果說出來，很容易讓人質疑你的能力。
（2）這個功能XX說了好幾次了，優先順序肯定很高，需要快點做。
別人說了好幾次的需求，不代表現在要馬上做，要確認當時提需求時，是否和特定場景相關，很可能當時很緊急的需求，到現在並不緊急了，這個得具體問題具體分析。
（3）雖然這個功能是為這個活動做的，但以後我們也可以用在其他地方。
具體講解時，需要考慮全面了再說，也就是要明確“其他地方”都有哪些，是否一定要用這個功能實現，投入產出比如何？其他方案是否也能滿足需求，如果長期考慮用途不大，只是為了一次性活動，那就要根據開發成本考慮最簡實現方案。
（4）這個功能做了，可以拿來售賣啊……
一個功能是否值得做，需要先考慮其在特定場景下的使用者價值，然後再提商業價值。有些功能的商業屬性是很弱的，單純拿出來作為理由站不住腳，還是要結合場景來說。
精選回覆@ sssDamian @ Kevin.H.S @ 文二水 @ 夢想家
- 我覺得，我認為，可能是，或許吧。
- 做好自己分內的事，不評價產品工作外的事情，比如：不評論技術框架的好壞和設計元素上的優劣，這些都是由開發團隊和設計團隊該考慮的事情。
- 這個功能很簡單啊， 兩天夠了吧……說了肯定能被研發砍死。
- 這個功能，我看XX產品做了，挺有意思，既然別人做了，就有存在的理由。
問題詳情： https://wen.woshipm.com/question/detail/2et698.html
總結
你在“需求”中有什麼疑問和見解嗎？歡迎來天天問和小夥伴們一起分享討論哦~
相關閱讀
【天天問每週精選】第49期：傳統行業如何合理利用網際網路思維
【天天問每週精選】第48期：各位產品大大，來腦洞大開玩點子吧
【天天問每週精選】第47期：秋招季到了，來看點有意思的面試題吧
【天天問每週精選】第46期：QQ和微信之間不得不說的那些事
精選問題每週有，歡迎食用~配合回覆味道更佳(∩_∩)
本欄目由天天問小編@Tracy 編輯，歡迎大家踴躍提問，一起交流。
題圖來自 Unsplash ，基於 CC0 協議
