从电梯设计问题，窥探产品需求的另类处理思路

我想，这也是一个产品应该努力的方向吧—-不为思维束缚。

简单一句话描述场景：

怎么设计100层大楼的电梯方案？

在述说我自己的想法前。我先扯点题外话，说些其他人的想法。

看了很多人的想法。都是在想，如何将这个电梯分区，这个电梯管这些个楼层，那几个电梯管那些个楼层。然后人们迈着小脚丫子，在楼梯电梯间切切换换，走过来走过去…

恕我直言，只要这电梯能直达，人们只会老老实实地坐在电梯里，咒骂着设计师脑子进水，然后老老实实地待在电梯里等电梯到达自己想要的楼层，脾气不好点的，还会将外面焦急地按着下行键的人们数说一顿。

若是叫人们下了电梯走个几个楼层去换电梯？

放心，只要吃瓜群众们知道你的住址他们一定会给你寄刀片的。

So，我换了一个角度。

先举一个简单点的极端案例，这个100层大楼里，只有一座电梯。而现在是午饭时间，大家都急着去一层吃饭….

嗯…

没啥好的解决方案，老老实实地，从一百层开始，电梯开了进人，关了就别停，一口气到一层。然后升到100层，继续。等没人按100层了，直接升到99层，重复循环即可。

你别指望100层的人给你爬到1楼，他们绝对会把电梯间塞得满满的，就跟塞沙丁鱼一样。所以，你中间完全可以不停，直接到1层即可。

然后

我发现了我设定的场景中发生了一件可怕的事情—-

电梯中间没有停！

我们都知道，电梯难以到达底层的原因即是因为电梯的频繁暂停。但是这一次，电梯为啥没停呢？

因为电梯的运力已满，达到满载，这电梯就没必要停了。

所以，个人私以为这才是让电梯迅速运转的核心所在—-

让电梯迅速满载，以达到不必要停的目的。

这点在下班和去吃饭的时候，最好实现。

试想，在饭点的时候，你最可能到几层？

是不是除了一层，美食城所在的那层，你都基本无路可去了呢？

所以，我们只要确保电梯已满，然后悠哉悠哉地把这个电梯人送到美室层和一层就好了。

那么，如何确保电梯已满呢？

第一个保障：

电梯门打开的时候后，在外面有有人等待的情况下电梯上的人没有增添，或者电梯直接发出了满载警报，这就可以说明这个电梯人数已满，可以不用再停了。

而这两点都可以很好的通过检测电梯重量来获取。

第二点措施稍后再讲。

目前暂且认为饭点下去吃饭和下班这件事情已经有了解决框架了，待会再添肉细化。

接下来，我们再解决上班和吃完饭回的问题。

这个问题有点复杂。

吃饭的时候，大家都有一个目标，百江汇海，意图很好猜。

但倒回去，海回百江，比较麻烦。

但是解决的办法，的确也就是海归百江。把人比作水分子，将大江比作电梯，将小河比作楼层。这个电梯前往一批特定的动态楼层，那个电梯前往另一批动态楼层楼层。这个问题即可解决。

下面，我开始介绍这个电梯系统的核心—按楼层的方案优化。

一般来讲，现有的楼层按键方式只有两种：

• 我在等待时，告诉电梯我要上还是下，然后等顺风电梯，进去后再按楼层。

• 我等待时，告诉电梯我要去几层，然后等电梯过来，把我带走。

第一种方案我没有太好的解决办法，我准备在第二种方案上做优化。

我们要让电梯大概知道，准备从n层到m层的人，大概有几人，然后电梯和自己的估算载量一比较做个算法即可。

首先，在此先发表一条愚见：

对于个体来讲，常去楼层包括自己工作所在楼层，公共设施层（饮食，购物，洗浴等），1层（通往地面层）和地下层（停车层）。

而站在建筑物角度，常去楼层包括公共设施层（饮食，购物，洗浴等），1层（通往地面层）和地下层（停车层）。前往各工作区层的概率基本一致。

以下方案全部基于上面假设：

• 电梯控制台设计

左侧的0-9号键为十位数字，右侧为各位上的数字。按完两个数字后，界面切换为左侧数字，输入楼层样式后控制台变为图中2图。点击确认键（具体交互位置需要具体设计，反正我感觉在这绝对别扭）后，控制台变为3图，同时本层等待人数加1。

同时，我们也需要在电梯间中部位置用液晶屏大字显示当前本层等待人数。通过双重激励与反馈机制来让用户知道我们这电梯是按人头计算，你不按电梯没你人头待会没你地你上不去，从而养成用户使用电梯按电梯的习惯。

通过叠加计算计算得到某部电梯能够快速获得一个能够快速将自己填满并去往少数几个楼层的具体楼层名单，并以此作为自己此次循环的运作路径。

但是为了避免极端情况出现，单个楼梯允许被指派的楼层数目最多不能超过10个（具体数目需要大数据支撑）。若所有楼梯全部的楼梯名单已满，提示稍后再试。

而当一个用户进入电梯时，电梯重量变化，本层等待人数自动减1（双人同时进入的解决方案暂时没有想好，目前想搞的替代方案只有通过监控摄像头自动识别方案），当电梯到达指定楼层时，电梯人出去，电梯内人数-1,。到达底层时，人员清空，电梯重量恢复初始值，电梯内人数自动归零。

脑洞大开之APP（公众号）设计—蹭蹭物联网概念又不会死系列…….

• low逼设计法

在手机上按好楼层，然后电梯控制台边上NFC刷一下（更low的就是二维码扫一下）。然后等电梯来，假如电梯来了没上，用户自己选择重新选梯，然后自动刷新要坐的电梯代号。

• 高大上设计法

在手机上按好楼层，客户端直接告知电梯有客人要来准备迎客，然后用户就在该电梯边等着。

等到了后电梯开始后台验证用户身份，WiFi测距。若检测到用户距离太远，客户端询问用户是否需要重新选梯。若用户选择了是，那么自动刷新要坐的电梯代号。

是的，此即为保障楼梯快速爆满的第二个保障。

这样，我们就解决了电梯问题。

在思考这个问题的过程中，我有一些自己的感想，说出来和大家分享。

首先，相比较于如何使用最短的时间或者最短的次数将用户运送至目的楼层的常规方案来说，我的突破点放在了如何将电梯快速填满这件事情上。

是的，需求是这样的：如何使用最短的时间或者最短的次数将用户运送至目的楼层。我们都会被这个需求纠缠，企图找出更好的解决方案来。

但是，背后的真正的需求呢？

是的，缩短电梯停留次数即是解决电梯问题的关键，但是，限制电梯是否能停的真正限制在哪？

是人们设下的楼梯层数，还是电梯自身的容量？

如果我们追打着楼梯层数的事没完没了，这和我们在找一匹更快的马又有何区别呢？

生活中处处都有颠覆式思维和真实需求的挖掘，产品之路任重而道远。

所以，我又尝试了一种更为颠覆的方式。

我们再次回到最初的场景来。

一个一百层的大厦，只有一个电梯，大家要在饭点去吃饭。

不够用，绝对不够用。

为什么呢？

因为这个电梯上，只有一个电梯间啊！

等等。

为什么这么长的电梯轨道上，只有一个电梯？

我们每天，每个人都看到，一个电梯轨道上，只有一个电梯间。

但是，谁又有说过，一个电梯轨道上，只能有一个电梯间？

长长的铁轨上，难道只有火车在疾驰么？

So，我们需要那么多电梯轨道么？

我们本来只需要跟地铁一样，只要两条轨道就可以了呀。

是的，地心引力，轨道设计……都是这种设计方式的难点。

但是，那是实现问题啊，我们该知道有这样一个方案，只是因为技术问题暂时无法使用，而不是连这个方案都不曾在脑海中飘起。

我想，这也是一个产品应该努力的方向吧—-不为思维束缚。