剛?cè)腴T的產(chǎn)品經(jīng)理經(jīng)常會聽到前輩們說應(yīng)該懂點(diǎn)技術(shù)，卻不明白為什么。本文作者分享了幾個被迫妥協(xié)的產(chǎn)品設(shè)計(jì)的例子，希望能讓不是技術(shù)出身的產(chǎn)品經(jīng)理了解到“產(chǎn)品經(jīng)理應(yīng)該懂點(diǎn)技術(shù)”在產(chǎn)品設(shè)計(jì)中有什么指導(dǎo)意義，一起來看一下吧。

剛?cè)腴T的產(chǎn)品經(jīng)理經(jīng)常聽前輩們或者網(wǎng)上的產(chǎn)品“專家”們說應(yīng)該懂點(diǎn)技術(shù)，這個說要懂點(diǎn)前端技術(shù)，那個說要懂點(diǎn)后端技術(shù)，有的說要懂點(diǎn)數(shù)據(jù)庫，也有的說要了解服務(wù)器，搞得他們覺得在成為產(chǎn)品經(jīng)理之前，應(yīng)該先成為一個全棧工程師。

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

下文分享的幾個小案例，希望能夠讓不是技術(shù)出身的產(chǎn)品經(jīng)理了解到“產(chǎn)品經(jīng)理應(yīng)該懂點(diǎn)技術(shù)”到底在產(chǎn)品設(shè)計(jì)中有什么指導(dǎo)意義。

我們?nèi)粘Ｊ褂密浖a(chǎn)品的時候，其實(shí)都是在跟服務(wù)器資源進(jìn)行交互，大致的過程是這樣的：

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

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

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

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

一、分頁

分頁設(shè)計(jì)在軟件產(chǎn)品中隨處可見，下圖是一個最基礎(chǔ)的分頁器，支持上一頁、下一頁以及跳轉(zhuǎn)到指定頁的操作。

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

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

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

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

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

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

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

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

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

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

二、實(shí)時搜索

實(shí)時搜索并不是被迫妥協(xié)的設(shè)計(jì)，相反，它是一個對用戶非常友好，體驗(yàn)極佳的設(shè)計(jì)。

實(shí)時搜索是什么，是當(dāng)我們提供搜索條件的時候，系統(tǒng)根據(jù)搜索條件實(shí)時匹配內(nèi)容。如上圖所示，當(dāng)我們輸入關(guān)鍵詞時，系統(tǒng)就自動查詢出匹配的結(jié)果。

可是這個設(shè)計(jì)，卻并非在產(chǎn)品設(shè)計(jì)中隨處可見，在系統(tǒng)設(shè)計(jì)中，更多的是像下圖所示這樣輸入關(guān)鍵詞之后手動觸發(fā)查詢。為什么實(shí)時搜索不能在產(chǎn)品設(shè)計(jì)中普及，而被迫妥協(xié)采用這樣的設(shè)計(jì)呢。

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

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

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

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

你可能會以為手動觸發(fā)搜索是為了避免實(shí)時搜索帶來的頻繁請求而造成服務(wù)器和訪問端的壓力，被迫妥協(xié)而誕生，而實(shí)際上，查詢最早就是以手動觸發(fā)查詢的形式存在的，而實(shí)時搜索因?yàn)轶w驗(yàn)更加優(yōu)秀而誕生，并在特定的場景下被使用。

什么情況下可以采用實(shí)時搜索設(shè)計(jì)呢？

1）數(shù)據(jù)體量小且增長可控或不會增長

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

2）查詢條件相對單一

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

3）前端二次查詢

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

三、進(jìn)度條 與 Loading

進(jìn)度條是偉大的設(shè)計(jì)；比進(jìn)度條更偉大的設(shè)計(jì)是進(jìn)度條百分比，這個我們在上傳時經(jīng)常看到；比進(jìn)度條百分比更偉大的設(shè)計(jì)是進(jìn)度完成剩余時間，這個我們在下載時經(jīng)?？吹健?/p>

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

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

雖然我們很希望在訪問端發(fā)送請求時，能馬上得到所有信息，但是因?yàn)榉?wù)器的處理、響應(yīng)、訪問端的渲染，包括物理端的存儲（下載）等，都需要時間，為了讓這個時間可視化，所以出現(xiàn)了進(jìn)度條，那為什么還會出現(xiàn) Loading 這個設(shè)計(jì)？為什么不把所有的 loading 都換成進(jìn)度條呢？

1）懶得做

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

2）效益低

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

3）難以量化

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

雖然 Loading 是被迫妥協(xié)的設(shè)計(jì)，但每天為了用戶體驗(yàn)“殫精竭慮”的產(chǎn)品經(jīng)理們還是盡可能地讓它變得更加友好，我們可以看看 Loading 的幾個發(fā)展階段。

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

2、頁面分區(qū)域加載，只在對應(yīng)加載區(qū)域出現(xiàn) Loading 動畫，加載時不影響其他區(qū)域的操作。

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

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

四、并發(fā)

有時候我們在進(jìn)行一些操作，比如點(diǎn)擊一些按鈕時，會發(fā)現(xiàn)它有一個處理的過程，在處理完成之前，不允許我們多次點(diǎn)擊，如下圖。

還有發(fā)送短信驗(yàn)證碼的按鈕，等待時間更長，要我們等60秒。

我們有這樣一種體驗(yàn)，當(dāng)我們在飯店吃飯的時候，如果上菜時間太久，我們一般會讓服務(wù)員去后廚催一下廚師。

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

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

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

第一種場景中，可能是因?yàn)橛脩袅?xí)慣性雙擊按鈕，或者系統(tǒng)反應(yīng)不夠及時，讓用戶以為系統(tǒng)假死，用戶會習(xí)慣性多次點(diǎn)擊，或者系統(tǒng)遭遇病毒或網(wǎng)絡(luò)爬蟲的暴力請求，在這種情況下，系統(tǒng)會在短時間內(nèi)收到多次相同的請求，這個時候系統(tǒng)往往還沒有處理完前面的請求，就要介入處理新的請求，如果短時間內(nèi)請求達(dá)到一定數(shù)量，可能會直接導(dǎo)致系統(tǒng)卡死。

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

1）前端優(yōu)化

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

2）后端策略

短時間內(nèi)的多次點(diǎn)擊只處理一次，比如在1秒內(nèi)連續(xù)點(diǎn)擊一個按鈕，系統(tǒng)只當(dāng)作是點(diǎn)擊了一次處理。這種就好比你剛找服務(wù)員催菜，沒隔多久又找服務(wù)員催，服務(wù)員說了一句好的就走開了，但是其實(shí)他沒有幫你去催。

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

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

要處理這種場景的并發(fā)，首要是提升服務(wù)器的性能，支持更多并發(fā)數(shù)，這就是我們經(jīng)常看到一些大平臺，在大型節(jié)假日做活動之前，有時候會公告說在升級服務(wù)器、提升服務(wù)器性能之類的，這些手段都是為了服務(wù)器接下來在活動期間能夠更好地迎接流量沖擊。當(dāng)然，服務(wù)器升級擴(kuò)容等是有成本的，一定要根據(jù)平臺的實(shí)際情況來確定，如果平臺的最高并發(fā)數(shù)是10萬，你把服務(wù)器性能提升到可承受100萬并發(fā)數(shù)，那就大可不必。

另一方面，系統(tǒng)上也需要在一些容易產(chǎn)生高并發(fā)的操作中加入優(yōu)化策略，比如我們有時候會遇到，在秒殺的時候，系統(tǒng)提示正在排隊(duì)，其實(shí)是系統(tǒng)延遲向服務(wù)器發(fā)送你的請求，把你的請求放在一個隊(duì)列中，按順序發(fā)送請求，這樣在一定程度上可以有效防止服務(wù)器因?yàn)橐凰查g收到太多請求而承受不住。

以上便是本文的全部內(nèi)容，感謝閱讀！