演示 Demo 在工作中的价值
在站酷看到了一段不错的话，对于近期正处在话中描述的水深火热中的我有所感悟，摘抄至此
此篇原文链接：https://www.zcool.com.cn/work/ZNjI1MTAzNDg
作者主页：https://feizai.zcool.com.cn
分享铺垫：https://www.zcool.com.cn/article/ZMTI5OTM2NA
成长之路：https://www.zcool.com.cn/article/ZMTM0MjUzNg
这是三鱼在快手两年多以来对体验设计侧工作成果(不含可视化)的总结，如果有的朋友从中看到了关于设计师一些不一样的价值阐释，也许会对我接下来要聊的观点有兴趣。
什么是“程序员思维”
先来聊一个轻松且看起来和设计关联不大的话题: 我认为机器和程序是由严谨的逻辑驱动的，它们会忠实地执行指令却不知变通，倘若输入的指令出现问题，机器就会朝着一个背离初衷的方向去执行。因而要想让机器乖乖执行我们所希望它做的就必须学会用它们的形式、它们的语言去与之沟通，这是一套注重逻辑的沟通方式，使得那些长期与机器打交道的技术人员，不知不觉会被训练成逻辑思维很强的一批人。这本不是坏事，但长期处于这样的环境下，身边也全是与自己类似的人时，就很容易让人误把这套被训练过的思维当成正常人的思维，这就导致了这些技术人员会认为这个世界上所有人都是讲说辑、且应该去讲逻辑的，却忽略了事实上人是感性的，驱动人们思考和行动的往往是感受和经验，进而导致了他们设计产品或服务的理念往往更注重逻辑闭环而非是否易于理解且高效。这便是我所理解的“程序员思维”，这种思维并非只存在于程员中。我所形容这种技术人员画像，很可能就是我们的业务方、产品经理甚至公司创始人，这在以技术为导向的 B 端领域非常常见。而体验设计师的价值就是去弥补这样的认知偏差，我们更侧重解决产品的“可用性”这部分工作。所以作为体验设计师的我们，恰恰应该是那个真正能理解“人”感性的一面、并帮助其构建起与机器/程序沟通桥梁的角色
体验设计的困境
事实上，很多设计师并不知道除了美术之外，自己还能提供什么样的价值，而他们所服务的对象也不太可能知道或者很难表述清楚，于是在长期的合作中，这些设计师的权限会被划定在“仅提供美术支持”的范畴内，对方也只愿意为这部分价值支付酬劳，这又会导致设计师们反过来去迎合这样的权限设定从而限定自己的能力范围。事实上，无论是“设计师”还是“美工”，头衔并不能代表什么，所得到的薪酬才能真实地反映你在整个流程中的价值。据我所知仅提供美术支持的价值往往回报低廉且没有尊严，但这却又是绝大部分设计师所面临的困境。当这种困境成为普遍现象，设计师们就不太可能意识到其中存在的问题，而是认为它理所应当是这样
技法很重要，但并非解药
三鱼曾说过“技法是制约想象力”的瓶颈，这个观点我至今仍认为它是对的，但我担心它会对某些设计师造成误导，所以我想把它描述得再准确一些:“技法是我们表达设计观点的核心手段”。因此我们必须确保一件事，即我们得先存在值得表达的观点，然后再去思考如何用技法表达它。而我所担心的，是很多设计师会误将技法学习当成专业提升的解药，却忽视了设计观点的重要性，也就舍本逐末了。
技法很重要，但提升它需要技巧
传统的技法学习方式是“学软件-做案例-应用到工作”，这种学习模式其实存在很大的风险，因为实际工作中往往要考虑成本和收益，且成本往往很有限比如时间，而新技法的应用，由于熟练度的原因前期往往是高成本低收益的，这就与工作应形成矛盾。所以是时候放弃过去那种百科全书式的学习方法了，那种照本宣科逐一介绍软件功能的教学方式，只会进一步打高应用到工作中的门槛，未来我会详细讲聊聊我所提倡的“轻学习、重应用”的思路
尝试交付“方案”
我分享一个自己认为比较有效的能同时提升专业和技法的工作方式，即在工作中确保自己交付的是“方案”而非某种效果在一个方案中，我需要去思考所服务的对象究竟面临什么问题，该如何帮助他们解决问题，我们之间是否存在认知的偏差又该如何让他们为我的观点买单。通过交付一个方案，我能更有效地管理我所服务对象的预期，进而为自己创造一个可以发挥创造力的空间，使得自己的认知和技法不断提升，这又会反过来帮助我更有效地管理预期，形成良性循环。是的，“预期管理”其实是设计师工作内容的重要环节，然而却被很多人忽视了....不展开了快说不完了
虽然我没有办法让别人仅靠一篇文章就形成设计观点、提升设计技法，但至少在我分享出来的作品中，你们能看到技法与观点相结合所带来的设计价值的体现与说服力。如果它能帮助一部分人打开一扇窗户的作用，让他们知道自己不知道什么，我的目的也算是达到了。
Q&A
Q:太棒了，也看得出三鱼一直在努力改变设计师的生存生态，关注三鱼五年了，受益良多。其实我最近也一直在思考技术成本收益的问题，能不能讲讲你是怎么大胆应用的呢？因为后续因为排期，技术，以及设计思路的有效传达都可能出现时间上 hold 不住的风险，比如你的视觉中这么多动画和视频，如果跟不上项目的节奏怎么处理？
A:说一下我的现状，目前我做项目会给我充足的时间做演示动画，但并非是他们觉悟高，事实上一开始他对演示动画是没有预期的，看不到它的价值，也并不愿意为此付出更多的成本(时间)。但我发现传统的项目研发流程中，项目成员们对同一个目标有不同的理解，这些理解会在执行过程中逐步产生偏差，项目负责人只能在项目进行过程中不断对齐、不断碰撞，并且始终会对项目最终的方向心里没底。我会去想倘若能通过一个 demo，将产品五年之后应该是什么样子演示出来，就可以把所有人基于不同理解所产生的不同可能性坍缩为只有一种可能性，大家围绕一个一个切实存在的产品去讨论它的流程合理与否、技术实现难度如何，而不是像过去那样仅仅停留在概念上的对齐，这样将极大地降低后续项目实施过程中的沟通成本，带来的收益是巨大的。所以我一开始会花额外的时间尽可能去做到这一点，并让项目负责人见识到 demo 的价值，逐步管理起他的预期，直到现在我已经可以有时间、有空间、有尊严的执行我的任何观点了。
我还是希望设计师们不要习惯于等待条件满足，而是要主动去创造有利的条件。我过往的作品基本上都是商业落地的案例，但很多都包含了一些前瞻和独创的观点在其中，但真实情况绝对不是产品经理凑过来：“三鱼，我们要做一个行业创新的产品，我们的原型图里已经为设计师想好了创新点，请尽情发挥吧！”要知道永远不可能出现这样的情况，不要以为大厂的平台就有多好，大厂体验设计师那么多，拿得出作品的有几个？所以真实的情况往往是业务方带着平庸的点子或预期，希望我们做一个类似 XXX 产品的东西，一期只需要做几个功能点，不用追求体验和功能闭环，最好赶在下周就上线，真实的需求往往就是这样，这就是业务方对设计师的普遍预期，想改变这一切只能自己先跨出那一步，否则永远是这样
对了，再多说一个点吧，很多朋友会觉得将一个方案做成这种 demo 演示成本太高。事实上，这种方式是三鱼实测下来用于说服权力远大于自己的人 (如业务负责人) 成本最小的方式。当然前提是能说服对方，如果不能说服都谈不上可比性。我们工作中最难的一件事就是说服别人放弃自己的观点去接受你的，这件事真的极难，在我没有使用这种 demo 演示的方法前，我很难真正有效地说服任何一个人接受自己的观点，我与他人之间的争辩最终会演变为摆烂直到其中一方失去耐心而妥协。这种说服别人的成本在我这里被定义为 “无限大”，这种方式在同职级中或许还行，但如果你想将观点推销至权力大于你的人脑袋里，恐怕就不奏效了。所以很多时候我们往往会因为这个“无限大”的说服成本，只好放弃掉说服别人后带来的收益。但反过来想想，如果你嫌演示 demo 的成本够高，可能是因为你还没有体会过说服了 CEO 能带来的收益
回过头来回答你的问题哈，本次项目业务方给的时间是基于他当下的预期，你所做的努力，是去改变下一次项目业务方的预期。所以知道怎么做了吧