设计师在学校学了一肚子理论，柯布萨摩耶，安腾棕熊，色剂马……
设计师满怀理想冲进设计院，连续加班5年，被甲方爸爸连虐5年，柯布萨摩耶，安腾棕熊，色剂马的建筑梦想都还给学校了，
只想着尽量满足甲方提出的所有要求。
要偷面积是吧？我们能弄出除了卧室全是阳台的房型；要做紧凑型是吧？我们50平米能干出三房来；要托斯卡纳风格是吧？……等等，你们是高层建筑……恩，高层托斯卡纳也能做！
So what？
甲方提出了1，2，3，4，5……18个要求，你加班加点，绞尽脑汁，拼了老命终于把这18个要求都满足了，你以为甲方老爷就满意了？
有大概率，甲方老爷一看，这是什么鬼？这家设计院不行，换一家……
真的是设计师不行？
还是甲方不行？
其实都不是，如果硬要说，那就是人不行。人，都不知道自己要什么。
得到梁宁的产品思维课，有个最典型的案例是这么说的：
有家做智能家居的公司要研发一款新的智能音箱，于是找了一批潜在用户来参与用户调查。研讨会上，厂商问潜在用户，我们有两个选择，黑色的和橙色的，你们喜欢哪一款？大家都表示喜欢橙色的。研讨会结束后，组织者说，为了感谢大家参与，这里有些样品，你们自己带一个回去吧。潜在用户们都挑了黑色音箱带回去了。
用户说喜欢橙色音箱的时候，是真心的。用户带走黑色音箱的时候也是真心的。
这就是典型的用户思维。
建筑系设计系都不教用户思维。灌输给设计师们的都是柯布萨摩耶，安腾棕熊，色剂马……
我不是说他们不好，他们参与设计的出发点跟我们遇到的绝大多数项目不一样。我又想起了之前看过的一部纪录片，讲流水别墅的。访谈中，流水别墅的女主人回忆起赖特给他们家设计别墅时的经历。老太太说当时电冰箱刚开始进入家庭，她跟赖特说他们想要在厨房里面放一台电冰箱。赖特思考了很多天，最后告诉她，我允许你们在厨房里有台电冰箱。
当我们从建筑师转行做了产品设计，也是在不断的教训中明白了一些道理，再回头看建筑设计，有了不一样的认识。
我们在学校的时候就被这种设计观点给带偏了。被现实打得鼻青脸肿之后，又会跳转到满足甲方老爷一切要求上。这又掉进另个一个坑。
甲方老爷在提那18个要求的时候，是按照18个点的方式提出来的，而从来没有想过把这18个点连成片，会是个什么样子。说得再清楚一点，这18个点可能本身就是矛盾的。
就像这张著名的图片里，甲方那18个要求里面很可能在红黄蓝三个圆里面都出现了，你看他们三者的交集上就写着 不存在 三个字。
互联网产品开发的原则是，问用户要什么，都只能听听而已，用户说什么不太重要，重要的是要看用户怎么做。前面智能音箱的案例就充分说明了这个方法，他们肯定将颜色定为黑色啊。有时候，这个用户行为反馈可以通过在用户界面埋入数据检测点而达成，通过数据分析，看用户更倾向于点击哪一个按钮。
我们现在做SaaS开发也是一样的，我们聆听会听用户的意见，但也会仔细分析用户的意见。例如，曾经有家景观设计公司的老板说，工时填报只精确到小时是不够的，应该精确到分钟，例如给甲方老爷打了10分钟电话，就要能够记录下10分钟。我们想了半天，不对啊，他是老板啊，他不会来填工时的，这根本不是用户需求。所以，我们并没将填报单位精确到分钟。
事实上，就算是让员工以小时为单位，将工时填报到项目上，很多员工都不愿意。鉴于很多设计公司在分配方式上都是采用提成制，我们就开发了工时制-提成制的切换功能，让公司管理者在无需员工填报工时(无需员工参与)的情况下，也能获得项目和公司运营的实时数据，这就大大降低了Time-cost的使用门槛。现在已经有设计公司在员工不参与的情况下，开启了Time-cost的数据化运营管理，并且看到了实时的效果。
反观设计师的设计工作其实也是一样的，甲方提出的要求，一定要过滤之后发现他们的要求背后的真实需求，再动手，才能做到事半功倍，否则，就像西西弗斯悲剧一样，不停地循环改图。
我们还得清楚，用户提的要求，并不一定是需求，重要的是要满足需求而不是要求。另一个著名的段子是这么说的：
客人来买电钻，他要的是墙上有洞，而不是电钻。
电钻是要求，而墙上的洞，才是需求。
说到建筑设计满足用户需求，我倒觉得库哈斯设计的的Maison Bordeaux是个正面案例，这才是真正从用户需求出发的设计。使用者行动不便，那就让地板动起来吧。
图片来源 archdaily.com
忍不住还是要给个反面案例，哈哈，范斯沃斯住宅。心疼女主10秒钟。这事儿估计双方都有责任。
洞悉用户需求，才是产品以及建筑设计的终极大法。
这很难，但Time-cost会持之以恒，为设计公司运营管理提供数据支持，为设计公司管理增效减负。
在探寻过程中的心得，我们也会持续分享，希望能够对设计师们有所帮助。
Powered by Time-cost