剛入門的產品經理經常會聽到前輩們說應該懂點技術，卻不明白為什么。本文作者分享了幾個被迫妥協的產品設計的例子，希望能讓不是技術出身的產品經理了解到“產品經理應該懂點技術”在產品設計中有什么指導意義，一起來看一下吧。

剛入門的產品經理經常聽前輩們或者網上的產品“專家”們說應該懂點技術，這個說要懂點前端技術，那個說要懂點后端技術，有的說要懂點數據庫，也有的說要了解服務器，搞得他們覺得在成為產品經理之前，應該先成為一個全棧工程師。

現在產品經理的門檻越來越低，一方面，市場上的產品越來越多，同質化也越來越嚴重，有時候產品經理只要稍加借鑒就可以做出不錯的交互設計，雖然有時候他們未必清楚為什么要這么設計；另一方面，產品經理在設計上對技術不友好的地方往往會在技術評審中被指出，并按研發工程師的要求進行調整，所以有些即使完全不懂技術的產品經理，一樣能夠很好地完成工作。

下文分享的幾個小案例，希望能夠讓不是技術出身的產品經理了解到“產品經理應該懂點技術”到底在產品設計中有什么指導意義。

我們日常使用軟件產品的時候，其實都是在跟服務器資源進行交互，大致的過程是這樣的：

當我們在訪問載體（瀏覽器、APP或者小程序中）進行某個操作（如點擊按鈕），這個時候會向服務器發送請求（請求的內容由具體的操作所決定），服務器在收到后，將請求對應的內容“響應”回來，這時訪問載體再將響應的內容“渲染”出來，就完成了一次資源交互。

你可以把服務器想象成一個虛擬的商家，經營著各種商品，而我們請求的過程，就是告訴商家我們需要的商品，商家根據我們的需求給我們提供商品。

上面的過程你可以這么理解：你告訴（發送請求）商家（服務器），說你需要一個蘋果（請求信息），商家接到信息后，把蘋果給你（響應）。

下文的案例需要你先能夠理解上述的原理。

一、分頁

分頁設計在軟件產品中隨處可見，下圖是一個最基礎的分頁器，支持上一頁、下一頁以及跳轉到指定頁的操作。

分頁本身是一個妥協的設計，如果數據少，沒有必要分頁，如果數據多，分頁也沒有用，基本靠搜索，你可以想想平時在分頁器上用得最多的，是不是就是“下一頁”？

有些信息流的頁面對分頁的功能做了調整，如下圖一樣，只剩下一個“下一頁”（加載更多）的操作，每次點擊加載一頁數據，之前已經加載的數據仍保留在頁面上，這種技術，叫做“懶加載”。

后來，為了方便用戶，“懶加載”又演變出一種新的交互形式，就是當列表快翻到頁尾的時候，頁面就自動進行“懶加載”，在用戶看來，就好像沒有了翻頁的操作。

即使是“懶加載”，本質上還是需要翻頁，只是弱化了用戶對分頁操作的感知，為什么不直接將全部內容顯示出來？分頁的意義在哪里？

你可以想象，如果你跟商家購買1噸的蘋果，并要求商家將這噸蘋果一次性放入你的倉庫，商家裝箱需要時間，運輸需要時間，到達目的地卸貨也需要時間，而因為貨物太多，這幾個時間加起來都非常長，其中任何一個環節出現問題都有可能導致你收到的蘋果貨不對板，比如商家裝箱工人不足，處理不了這么多蘋果的裝箱工作；比如運輸時間太長，過程中蘋果腐爛或遺失；比如到達目的地發現倉庫太小，容納不了這么多蘋果入庫。

從技術上來講，就是當你發送請求時，如果請求到的數據量很大，服務器處理大量數據可能會“超時”，數據傳輸過程中“失真”風險增加，訪問載體加載大量數據時可能出現“假死”甚至“崩潰”的現象，這些都可能導致你無法獲取到完整的信息。

分頁，就能解決這樣的問題。

首先，服務器收到請求后，只響應1頁數據（具體1頁多少條數據由分頁邏輯決定），這個時候傳輸的數據量很小，如果用戶想要看更多內容，就可以通過分頁器來選擇下一頁或跳轉到指定頁，當用戶通過分頁器發送指令之后，服務器再根據指令返回對應頁的數據，這樣，從“全量供應”變成了“按需供應”，減少了每次傳輸的數據量，不僅從等待的時間上改善了用戶體驗，也減輕了服務器的負擔。

分頁就好比你跟商家說要1噸蘋果，商家說沒問題，但每次只給你100斤，等你需要更多的時候，你再跟商家說，商家再給你100斤，直到1噸蘋果全部給完為止，這樣可以減輕商家的負擔，縮短運輸時間，降低運輸風險，也可以給倉庫留夠余量。

現在很多分頁器會提供每頁顯示多少條數據的操作，這就好比你可以告訴商家每次給你提供多少斤蘋果，這種方式方便了用戶自定義單次請求的數據量，又同時將單次請求的最大數據量控制在系統能夠穩定處理的范圍內。但說到底，它始終都是被迫妥協做出來的產品設計。

二、實時搜索

實時搜索并不是被迫妥協的設計，相反，它是一個對用戶非常友好，體驗極佳的設計。

實時搜索是什么，是當我們提供搜索條件的時候，系統根據搜索條件實時匹配內容。如上圖所示，當我們輸入關鍵詞時，系統就自動查詢出匹配的結果。

可是這個設計，卻并非在產品設計中隨處可見，在系統設計中，更多的是像下圖所示這樣輸入關鍵詞之后手動觸發查詢。為什么實時搜索不能在產品設計中普及，而被迫妥協采用這樣的設計呢。

首先我們要知道，實時搜索的每一次請求都可能是一次關鍵詞不精準或不完整的查詢，最終的結果可能是經過多輪查詢后得到的，而手動觸發搜索在關鍵詞足夠準確的情況下，只需要通過一輪查詢就能得到最終結果。

還是那個蘋果的例子，實時查詢等于你先告訴商家你需要蘋果，這個時候商家馬上要給你做出回應，但是“蘋果”這個詞太籠統了，你到底是要蘋果手機還是可以吃的蘋果，商家也不清楚，所以只能將所有符合條件的商品都給你；這個時候你又向商家追加了關鍵詞“新疆”，商家猜測，你應該是想要購買產地是新疆的蘋果；最后你又追加了關鍵詞“包郵”，此時商家重新在所有產地為新疆的蘋果中找出支持包郵的。而手動觸發搜索等于你直接告訴商家“蘋果新疆包郵”，商家直接根據你的要求給你找出符合條件的結果。

從上述的例子我們可以看到，實時搜索查詢請求次數更多，對服務器的資源消耗也更大，除了服務端的壓力，前端訪問載體需要在短時間內多次渲染查詢結果，一邊查詢一邊渲染，可能會造成頁面卡頓等體驗不好的結果。

相比之下，要完成相同關鍵詞的搜索，手動觸發查詢只需要進行一次查詢和一次渲染就完成了，對服務器和訪問載體更加友好。

你可能會以為手動觸發搜索是為了避免實時搜索帶來的頻繁請求而造成服務器和訪問端的壓力，被迫妥協而誕生，而實際上，查詢最早就是以手動觸發查詢的形式存在的，而實時搜索因為體驗更加優秀而誕生，并在特定的場景下被使用。

什么情況下可以采用實時搜索設計呢？

1）數據體量小且增長可控或不會增長

比如國家的行政區劃數據，數量級不會很大，且不會動不動就增加幾十個省份或幾百個城市的數據。

2）查詢條件相對單一

現在有很多平臺有聚合搜索的功能，一個輸入框可以查詢數據庫的 N 個字段，這種如果做實時搜索服務器壓力將非常大。

3）前端二次查詢

查詢是訪問端發送關鍵詞到服務端，服務端返回結果的過程，但有時候我們還會在拿到服務端的查詢結果的情況下，直接在訪問端做二次查詢。比如我向服務端查詢廣東的城市，服務端返回了廣東的所有城市名稱，這個時候如果我想查詢這些城市里面有沒有我要找的，就可以在訪問端做二次查詢，由于結果已經事先從服務端拿到，現在是對結果進行二次查詢，無需再次請求服務器，在這種情況下，也可以做實時搜索。

三、進度條 與 Loading

進度條是偉大的設計；比進度條更偉大的設計是進度條百分比，這個我們在上傳時經?？吹?；比進度條百分比更偉大的設計是進度完成剩余時間，這個我們在下載時經?？吹?。

但等待的時間并不總是以進度條的形式出現，有時候陪伴我們度過等待時光的，叫做——Loading。

如果說，進度條卡在99.9%是一個令人抓狂的時間點，那么 Loading 動畫出現時，就是另一個令人抓狂的時間點。當 Loading 動畫出現的時候，就意味著一個信息，那就是沒有任何信息，我們不知道它要持續多久，不知道它什么時候結束，加載時間太久我們甚至不知道它是還沒加載完還是已經“死掉了”，也做不了任何操作，除了等待，我們沒有任何辦法。

雖然我們很希望在訪問端發送請求時，能馬上得到所有信息，但是因為服務器的處理、響應、訪問端的渲染，包括物理端的存儲（下載）等，都需要時間，為了讓這個時間可視化，所以出現了進度條，那為什么還會出現 Loading 這個設計？為什么不把所有的 loading 都換成進度條呢？

1）懶得做

因為做進度條是需要計算總進度以及已完成和未完成進度來繪制出可視化的進度條圖形，包括百分比和剩余時間，也都需要進行計算，相比直接顯示 Loading 動畫來說，開發量更大，有時候并不一定都是開發人員懶得做，而是企業或產品經理基于時間和成本考慮，以犧牲用戶體驗為代價，用 Loading 來取代進度條的設計。

2）效益低

這種就是在一些特定的場景下選擇放棄進度條而改用 Loading 的設計，比如在上傳圖片時，系統限制了最大只能上傳2M的圖片，在5G的網速下這樣的一張圖片一瞬間就上傳完了，這樣的情況下，用戶可能還沒看到進度條出現就已經看到上傳成功的提示，那這個進度條就沒什么意義了，相反，有時候為了呈現完整的進度條動畫，圖片已經上傳完了，進度條動畫還沒播放完，對用戶來講，體驗就更加糟糕了。

3）難以量化

假如我有10個蘋果，吃了一個，你可以說我吃掉了10%，但如果我咬了一口，問你我吃了多少，這個是很難準確回答的。同理，大文件的上傳下載可以通過文件大小和網速來計算時間以及百分比，但是如果是查詢、讀取文本數據的時候，則較難量化。

雖然 Loading 是被迫妥協的設計，但每天為了用戶體驗“殫精竭慮”的產品經理們還是盡可能地讓它變得更加友好，我們可以看看 Loading 的幾個發展階段。

1、Loading 動畫出現時，整個頁面出現遮罩，什么都做不了，加載超時 Loading 動畫也不會消失，只能刷新頁面。

2、頁面分區域加載，只在對應加載區域出現 Loading 動畫，加載時不影響其他區域的操作。

3、在上一階段的基礎上，給 Loading 加一個延遲出現的時間，比如2秒，如果數據在2秒內就加載完成則不會出現 Loading 動畫；設置加載超時時間，比如加載了10秒鐘還沒有出來，可能已經加載失敗，則停止加載和 Loading 動畫，允許用戶手動點擊重新加載。

什么情況下用進度條？什么情況下用 Loading？等待時間較長，但數據可量化的情況下，用進度條，比如上傳、下載等；等待時間較短，或處理數據體量較小，或較難量化的情況下，用Loading，如提交、查詢數據等。

四、并發

有時候我們在進行一些操作，比如點擊一些按鈕時，會發現它有一個處理的過程，在處理完成之前，不允許我們多次點擊，如下圖。

還有發送短信驗證碼的按鈕，等待時間更長，要我們等60秒。

我們有這樣一種體驗，當我們在飯店吃飯的時候，如果上菜時間太久，我們一般會讓服務員去后廚催一下廚師。

我們可以設想一下這種場景，我們剛讓一個服務員去催菜，這個服務員還沒走到后廚，我們又讓另外一個服務員去催，同樣，第二個服務員還沒走到后廚，我們又讓第三個服務員去催，接下來廚師就會連續收到3個服務員的催菜要求，你想想，這個廚師會怎樣。

或者我們設想另外一種場景，我們讓服務員去催菜，這個時候，另外兩桌的客人也同時找了服務員去催菜，我們假設，如果這3個服務員剛好催的是同一個廚師，你可以想想，這個廚師會怎樣。

上面所講的例子，在技術中，叫做——“并發”。第一種場景是同一個用戶短時間內重復發送相同的請求；第二種場景是多個用戶同一時間發送相同的請求。

第一種場景中，可能是因為用戶習慣性雙擊按鈕，或者系統反應不夠及時，讓用戶以為系統假死，用戶會習慣性多次點擊，或者系統遭遇病毒或網絡爬蟲的暴力請求，在這種情況下，系統會在短時間內收到多次相同的請求，這個時候系統往往還沒有處理完前面的請求，就要介入處理新的請求，如果短時間內請求達到一定數量，可能會直接導致系統卡死。

針對這種場景的并發，一般處理方式有兩種。

1）前端優化

功能觸發后，在處理完成前禁止再次點擊。這種就好比你剛找服務員催菜，沒隔多久又找服務員催，服務員就告訴你，剛催過了，耐心等待。

2）后端策略

短時間內的多次點擊只處理一次，比如在1秒內連續點擊一個按鈕，系統只當作是點擊了一次處理。這種就好比你剛找服務員催菜，沒隔多久又找服務員催，服務員說了一句好的就走開了，但是其實他沒有幫你去催。

以上兩種方式，條件允許的情況下前后端都應該同步做，比如上文提到的短信驗證碼，有時候我們點擊發送按鈕出現倒計時之后，刷新頁面會發現發送按鈕又可以點擊了，但再次點擊時，系統又提示發送驗證碼太頻繁之類的，這就是前后端共同作用的效果，至于為什么要讓用戶等待60秒這么長的時間，除了基于系統性能原因考慮之外，另一個原因就是成本，假如平臺用戶量大，如果用戶每點擊一次就發送一條短信，那么每個用戶無意間點多幾下，平臺可能就要支付巨額的短信費用。

第二種場景常見于秒殺，或者像過年大家都在平臺上搶紅包之類的，大量的用戶涌入到平臺，幾乎同一時間都在發送相同的請求，這種場景考驗的就不只是系統的穩定性，更考驗服務器的性能，我們有時候會聽到研發說每秒多少并發，指的就是系統最多能夠處理多少個人同時發送的請求。

要處理這種場景的并發，首要是提升服務器的性能，支持更多并發數，這就是我們經?？吹揭恍┐笃脚_，在大型節假日做活動之前，有時候會公告說在升級服務器、提升服務器性能之類的，這些手段都是為了服務器接下來在活動期間能夠更好地迎接流量沖擊。當然，服務器升級擴容等是有成本的，一定要根據平臺的實際情況來確定，如果平臺的最高并發數是10萬，你把服務器性能提升到可承受100萬并發數，那就大可不必。

另一方面，系統上也需要在一些容易產生高并發的操作中加入優化策略，比如我們有時候會遇到，在秒殺的時候，系統提示正在排隊，其實是系統延遲向服務器發送你的請求，把你的請求放在一個隊列中，按順序發送請求，這樣在一定程度上可以有效防止服務器因為一瞬間收到太多請求而承受不住。

以上便是本文的全部內容，感謝閱讀！