充实背后的危机：应对业务需求之余还该多做些什么？

　　最近被业务需求频繁轰炸，工作日也变得非常繁忙。放在过去的话，我会觉得这是充实的体现，在不那么忙、没人提需求时反而会更加焦虑不安；后来却更多感受到了危机：所谓的充实，有些时候不过是体力劳动的重复，效率和质量都很低，在项目完结后就不再有多少价值，对业务长期发展和个人成长带不来多少帮助；永远都有新需求在插队，自己思考过程中一些灵光一闪的念头，一旦在优先级面前退让放下就很难再拾起，周期长了甚至自己也已忘记细节
　　反思现状：不偏听，不轻信，敢于质疑，主动验证
　　我接触过的一些专家级的设计师和产品经理，身上有一点特质让我很欣赏：即使是在数据节节高升，大家一片赞誉之声的时候，也依然对现状保持不满和危机感，能看出用户定位可能造成天花板，数据体现的可能只是虚假繁荣，假想产品未来可能失控甚至死亡的多种情形，不满足于现象级的惊艳，而是能看到更长远的未来。
　　在过去一年里，虽然我开始培养起了重视业务目标和用户目标的意识，但很多时候还是以和业务方、产品经理沟通确认，再转化为自己的语言重新表达、然后朝着这个方向开始设计为主，但对目标定位本身存在的问题思考却还不够透彻、质疑不够有底气，也缺少主动去调研、验证对方想法的行动。
　　我之前做一个网站首页设计的时候，在和产品经理明确了首页目标用户是谁后就匆匆开始了设计，而对网站其他用户群在首页能得到什么价值，并未多加思考。结果后来的用户调研反馈却显示，我们当初定位的那些目标用户绝大多数情况下是在移动端使用我们的产品，访问网站的频率相对要低很多；而当初被降低优先级的其他人才是网站首页的主体用户，但他们却不知道首页能带给他们什么，稍加停留就匆匆切到了其他页面。
　　还有一次做一个CRM页面的设计，涉及到表格中字段很多放不下的问题，我的做法是和业务方明确表态空间限制下不能支持字段全显示出来，要求给字段划分优先级，然后将次要的字段收纳起来不直接显示。在内部评审的时候，我和大家说明了这一点并表明业务方已经给出了优先级列表，但组里一位设计师却对此提出疑问：业务方虽然和目标用户很熟悉、本身也是目标用户一员，但主观给出的优先级不一定准确，还是要实际访谈了解更多的目标用户，才能得到更准确的结果。后来由于时间原因没有做这样的调研，先按照业务方的信息上线了一版，找用户内测的时候被反馈有个被砍的次要字段对他们很重要，于是前端那边还要再重新调整加回。由此可见，光和业务方沟通与听信一面之词是不够的，有条件的情况下还是多做做高保真原型给更多真实用户使用与获取反馈。
　　推销愿景：让大家听到你的声音，革新想法能够落地
　　这周和老板进行了绩效面谈，在聊的过程中我多次提到自己的不满意：对瀑布式的传统工作流程不满意，职能界限应该更模糊和交叉，不喜欢等到Prd评审完才开始思考接入设计；对交互与视觉合作模式不满意，不想让视觉设计师重复劳动式地堆砌组件、花了大量时间在别人眼里只是给交互稿上了个色；对项目日常优化节奏的不满意，不喜欢缝缝补补的修BUG式优化，倾向整合打包成一套设计方案再交付
　　老板对这种不满意的态度表示了肯定和鼓励保持，但也提出了一个问题：要学会将自己的愿景推销给别人，让大家理解和接受，使想法可以真正落地。之前和组里另一位设计师聊项目规划的时候，也被指出想法很多但太闷着，别人都不知道。
　　因为平时工作还是比较忙的，总会有新的需求源源不断加入，而面对新的需求我还不能太好地把控节奏，总会把自己的想法降低优先级一拖再拖，但需求是做不完的，无限拖延就会造成有时明明是自己和利益相关方都认可的方向，但拖着拖着大家就都忘了这一回事，不能落地的idea最终也会失去它本身的价值。
　　提效聚焦：用短期忙碌换长期空间
　　可能一些同学会有疑问：我也想更深度地思考业务，也有很多idea想说服大家接受，但光是应对接踵而来的需求就已经筋疲力尽了，根本没有机会做自己想做的事情。在经历了这段时间的密集需求轰炸后我也有类似的牢骚，但更坚定了做一件事的决心：宁肯让自己在短期内事情更多更忙，也要配合前端、开发一起做完组件化沉淀（有点类似设计规范，但不定义到具体视觉样式，而是基础的组件和使用场景整理）的工作。这类工作在短期内是给自己加事情，但一旦成型起来，对之后设计和开发的效率都会有大大提升，长远看来有利于未来腾出更多时间做自己想做的事情，本身也是一个专业上的沉淀。
　　之前UCAN2016大会上，也有多位设计Leader在分享上提到对建立设计中台的重视，打造中台DPL组件库和规范、创意模版化等，将设计师从重复性的体力劳动中解放，留出更多自主思考和发挥的空间。
　　如果永远只想着忙完手头的事情，在重复性工作中周而复始，可能就会陷入一直忙下去，却没有多少思考与发挥空间的怪圈，不利于长远的职业生涯成长。
　　本文由人人都是产品经理专栏作家鸿影原创发布于人人都是产品经理。未经许可，禁止转载。