起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識從電梯設計問題，窺探產品需求的另類處理思路
我想，這也是一個產品應該努力的方向吧—-不為思維束縛。
簡單一句話描述場景：
怎么設計100層大樓的電梯方案？
在述說我自己的想法前。我先扯點題外話，說些其他人的想法。
看了很多人的想法。都是在想，如何將這個電梯分區，這個電梯管這些個樓層，那幾個電梯管那些個樓層。然后人們邁著小腳丫子，在樓梯電梯間切切換換，走過來走過去…
恕我直言，只要這電梯能直達，人們只會老老實實地坐在電梯里，咒罵著設計師腦子進水，然后老老實實地待在電梯里等電梯到達自己想要的樓層，脾氣不好點的，還會將外面焦急地按著下行鍵的人們數說一頓。
若是叫人們下了電梯走個幾個樓層去換電梯？
放心，只要吃瓜群眾們知道你的住址他們一定會給你寄刀片的。
So，我換了一個角度。
先舉一個簡單點的極端案例，這個100層大樓里，只有一座電梯。而現在是午飯時間，大家都急著去一層吃飯….
嗯…
沒啥好的解決方案，老老實實地，從一百層開始，電梯開了進人，關了就別停，一口氣到一層。然后升到100層，繼續。等沒人按100層了，直接升到99層，重復循環即可。
你別指望100層的人給你爬到1樓，他們絕對會把電梯間塞得滿滿的，就跟塞沙丁魚一樣。所以，你中間完全可以不停，直接到1層即可。
然后
我發現了我設定的場景中發生了一件可怕的事情—-
電梯中間沒有停！
我們都知道，電梯難以到達底層的原因即是因為電梯的頻繁暫停。但是這一次，電梯為啥沒停呢？
因為電梯的運力已滿，達到滿載，這電梯就沒必要停了。
所以，個人私以為這才是讓電梯迅速運轉的核心所在—-
讓電梯迅速滿載，以達到不必要停的目的。
這點在下班和去吃飯的時候，最好實現。
試想，在飯點的時候，你最可能到幾層？
是不是除了一層，美食城所在的那層，你都基本無路可去了呢？
所以，我們只要確保電梯已滿，然后悠哉悠哉地把這個電梯人送到美室層和一層就好了。
那么，如何確保電梯已滿呢？
第一個保障：
電梯門打開的時候后，在外面有有人等待的情況下電梯上的人沒有增添，或者電梯直接發出了滿載警報，這就可以說明這個電梯人數已滿，可以不用再停了。
而這兩點都可以很好的通過檢測電梯重量來獲取。
第二點措施稍后再講。
目前暫且認為飯點下去吃飯和下班這件事情已經有了解決框架了，待會再添肉細化。
接下來，我們再解決上班和吃完飯回的問題。
這個問題有點復雜。
吃飯的時候，大家都有一個目標，百江匯海，意圖很好猜。
但倒回去，?；匕俳?，比較麻煩。
但是解決的辦法，的確也就是海歸百江。把人比作水分子，將大江比作電梯，將小河比作樓層。這個電梯前往一批特定的動態樓層，那個電梯前往另一批動態樓層樓層。這個問題即可解決。
下面，我開始介紹這個電梯系統的核心—按樓層的方案優化。
一般來講，現有的樓層按鍵方式只有兩種：
- 我在等待時，告訴電梯我要上還是下，然后等順風電梯，進去后再按樓層。
- 我等待時，告訴電梯我要去幾層，然后等電梯過來，把我帶走。
第一種方案我沒有太好的解決辦法，我準備在第二種方案上做優化。
我們要讓電梯大概知道，準備從n層到m層的人，大概有幾人，然后電梯和自己的估算載量一比較做個算法即可。
首先，在此先發表一條愚見：
對于個體來講，常去樓層包括自己工作所在樓層，公共設施層（飲食，購物，洗浴等），1層（通往地面層）和地下層（停車層）。
而站在建筑物角度，常去樓層包括公共設施層（飲食，購物，洗浴等），1層（通往地面層）和地下層（停車層）。前往各工作區層的概率基本一致。
以下方案全部基于上面假設：
- 電梯控制臺設計
左側的0-9號鍵為十位數字，右側為各位上的數字。按完兩個數字后，界面切換為左側數字，輸入樓層樣式后控制臺變為圖中2圖。點擊確認鍵（具體交互位置需要具體設計，反正我感覺在這絕對別扭）后，控制臺變為3圖，同時本層等待人數加1。
同時，我們也需要在電梯間中部位置用液晶屏大字顯示當前本層等待人數。通過雙重激勵與反饋機制來讓用戶知道我們這電梯是按人頭計算，你不按電梯沒你人頭待會沒你地你上不去，從而養成用戶使用電梯按電梯的習慣。
通過疊加計算計算得到某部電梯能夠快速獲得一個能夠快速將自己填滿并去往少數幾個樓層的具體樓層名單，并以此作為自己此次循環的運作路徑。
但是為了避免極端情況出現，單個樓梯允許被指派的樓層數目最多不能超過10個（具體數目需要大數據支撐）。若所有樓梯全部的樓梯名單已滿，提示稍后再試。
而當一個用戶進入電梯時，電梯重量變化，本層等待人數自動減1（雙人同時進入的解決方案暫時沒有想好，目前想搞的替代方案只有通過監控攝像頭自動識別方案），當電梯到達指定樓層時，電梯人出去，電梯內人數-1,。到達底層時，人員清空，電梯重量恢復初始值，電梯內人數自動歸零。
腦洞大開之APP（公眾號）設計—蹭蹭物聯網概念又不會死系列…….
- 不高大上設計法
在手機上按好樓層，然后電梯控制臺邊上NFC刷一下（或二維碼掃一下）。然后等電梯來，假如電梯來了沒上，用戶自己選擇重新選梯，然后自動刷新要坐的電梯代號。
- 高大上設計法
在手機上按好樓層，客戶端直接告知電梯有客人要來準備迎客，然后用戶就在該電梯邊等著。
等到了后電梯開始后臺驗證用戶身份，WiFi測距。若檢測到用戶距離太遠，客戶端詢問用戶是否需要重新選梯。若用戶選擇了是，那么自動刷新要坐的電梯代號。
是的，此即為保障樓梯快速爆滿的第二個保障。
這樣，我們就解決了電梯問題。
在思考這個問題的過程中，我有一些自己的感想，說出來和大家分享。
首先，相比較于如何使用最短的時間或者最短的次數將用戶運送至目的樓層的常規方案來說，我的突破點放在了如何將電梯快速填滿這件事情上。
是的，需求是這樣的：如何使用最短的時間或者最短的次數將用戶運送至目的樓層。我們都會被這個需求糾纏，企圖找出更好的解決方案來。
但是，背后的真正的需求呢？
是的，縮短電梯停留次數即是解決電梯問題的關鍵，但是，限制電梯是否能停的真正限制在哪？
是人們設下的樓梯層數，還是電梯自身的容量？
如果我們追打著樓梯層數的事沒完沒了，這和我們在找一匹更快的馬又有何區別呢？
生活中處處都有顛覆式思維和真實需求的挖掘，產品之路任重而道遠。
所以，我又嘗試了一種更為顛覆的方式。
我們再次回到最初的場景來。
一個一百層的大廈，只有一個電梯，大家要在飯點去吃飯。
不夠用，絕對不夠用。
為什么呢？
因為這個電梯上，只有一個電梯間啊！
等等。
為什么這么長的電梯軌道上，只有一個電梯？
我們每天，每個人都看到，一個電梯軌道上，只有一個電梯間。
但是，誰又有說過，一個電梯軌道上，只能有一個電梯間？
長長的鐵軌上，難道只有火車在疾馳么？
So，我們需要那么多電梯軌道么？
我們本來只需要跟地鐵一樣，只要兩條軌道就可以了呀。
是的，地心引力，軌道設計……都是這種設計方式的難點。
但是，那是實現問題啊，我們該知道有這樣一個方案，只是因為技術問題暫時無法使用，而不是連這個方案都不曾在腦海中飄起。
我想，這也是一個產品應該努力的方向吧—-不為思維束縛。
本文由 @風催花殘掩君語 原創發布于人人都是產品經理。未經許可，禁止轉載。
是的
對對對！哈哈哈，可以有！不過哈，纜車有個毛病，慢。 ??
按人頭算是不行的……現在的人都偏胖。核載15人的電梯，通常12個就超重了
那就得調整單人體重的預估值了，比如說從60改到75神馬的。而且你直接一句現在的人都偏胖，估計站上的小姐姐們會不高興的哦 ??
就怕小姐姐一個頂你2個
泥垢了，我要的是尼爾，不要這樣的小姐姐 ??
出發點是好的，但是電梯控制臺設計存在一個致命的問題，想想中國人的習慣，除非是獨立的一個人去做電梯，否則一個公司或者部門的人去坐電梯，你認為會有幾個人去輸入號碼，放心，只會有一個人。 所有人都去輸號碼的功夫，電梯都下去了，所以是無法準確的預估出這個樓層的實際搭乘人數的
我知道這個痛點的，所以我做了一個按一次人數加一的反饋功能，讓用戶明白電梯是按人頭計數的原理，去培養人人都按電梯這個習慣。等習慣培養好，有人開始提每個人都按一次好麻煩之后，就可以用樓層*人數這個針對你那個場景的方案了。
這個習慣培養有點難 ??
就像我剛開始提的那個極端場景一樣，這個方案本來就是沒有最優解，畢竟最優解是給每人都配一部電梯啊。所以我們能夠相出一個比現在好得多的方案就好啦。其實我覺得最大的痛點時這個：飯點的時候，那個樓層按電梯的數量都極大，人數都很足，這個時候該如何處理這些請求。我想你也大概了解，一座十五層的樓，飯點高峰的時候基本走到九層電梯就滿了。這個解決起來我覺得蠻難的。
是不是可以這樣，一個人選，然后可以選擇幾人乘電梯？就和購票APP買票一樣，一個終端可以給好幾個人買票。
是的，其實就是一個調度前置的問題，但是如何讓選人這個動線簡單，是一個很考驗交互的工作