前车之鉴后事之师，聪明的人可以从别人的错误中学到经验。这次特意邀请了七位迈入职场不久的产品经理、交互设计师同学，分享那些他们踩过的坑。话不多说，收获有多少，就看你有多聪明啦。
当从象牙塔走入职场，新人们除了兴奋和憧憬以外更多的还有紧张和迷茫：对庞大业务的不熟悉、对工作模式和规范的不了解、对同事和前辈的生疏，都是新人成长的必经之路。有些坑，需要我们亲自踩过才能有深刻的体会，但是前车之鉴后事之师，聪明的人一样可以从别人的错误中学到经验。
这次特意邀请了七位迈入职场不久的产品经理、交互设计师同学，分享那些他们踩过的坑。话不多说，收获有多少，就看你有多聪明啦。
交互设计师 鸿影 from 阿里巴巴
1. 无脑闷头执行
过程描述：接到需求的时候，对方描述了一个具体的解决方案，就直接陷入这个方案里去构思细节。
原因反思：对「交互设计」的全流程认知不透彻，思考深度不够，以为出线框出界面就是工作大头，目标什么的有产品经理想就够了，而不去思考目标本身、目标和需求方描述的解决方案关联是否合理。
如何避免：开始设计前一定要和需求方进一步沟通清楚，明确业务目标和用户场景的合理性，并用自己的语言重新描述放在设计文档第一页。对需求方给出的具体解决方案，不要让它框住自己的思路，而是反推确认方案背后的目标本质，回到目标导向设计上来。
2. 缺少全局视野
过程描述：接一个需求就加一块内容，而不思考如何和之前已有的信息结构系统整合，久而久之变成了缝缝补补式的堆砌，产品的整体感、一致性、扩展性变差。
原因反思：没有从系统的角度来梳理看待问题，对内容之间的关联感知弱，只顾聚焦当前业务需求的细节，忽视了对产品整体层面的影响，或虽有意识到，但因为畏惧工作量、沟通成本等不愿意推进整体角度的优化。
如何避免：提醒自己不能老抠细节，将需求们整合起来，列举会被影响到的产品功能点，系统梳理优化信息结构，打包进一个解决方案，并在设计时考虑到未来新需求接入后的扩展性。敢于适时打破之前的框架，总是在旧方案上直接加东西，短期思考和设计的成本低了，但难以维持长久。
3. 忽视UI呈现
过程描述：觉得自己不是专业视觉设计师，交互稿不用太在意UI上的质量，随便东拼西凑一下能表达出东西就可以了。
原因反思：对交互和视觉的分工认知太狭隘，实际上，像布局、栅格、字数限制、内容重心层次这些东西都是在交互设计阶段就必须考虑和表达清楚的事情，交互设计师偷懒会导致视觉设计师受到影响(比如因为内容放不下，要完全把布局方式推翻等)。
如何避免：交互设计师必须懂得基础UI设计原则，用高标准来对待自己的交互稿，这也是专业交互设计师和会画原型的产品经理的区别;在很多公司里交互设计师直接出高保真是常见的现象，不要把自己的技能栈限死，这样不利于长期发展。
4. 逃避退让沟通
过程描述：不敢主动向合作伙伴去沟通和争取一些事情，过于站在产品经理和开发的角度着想(这个成本会不会太高了啊我还是不考虑了吧)，而缺少对产品体验底限的强势坚守。
原因反思：新人意识还在，脸皮不够厚，总觉得自己资历浅薄，在合作伙伴面前没什么话语权，所以还没开始沟通就自己把自己先吓退了。
如何避免：提醒自己已经毕业，已经是正式设计师了，要学会独当一面，不能还用实习生的心态来对待手里的事情。尝试鼓起勇气去和合作伙伴争取，尝试从对方的利益点来解读自己想做的事情能带来的帮助，给自己设一个产品体验的底线，几次沟通下来，你会发现对方根本没有自己想像中那么可怕和难说服。
交互设计师 宝玲 from eBay
我就简单说两个。我们公司设计部比较弱，是交互UI混在一起的，可能有些不太适合多数人：
1. 不追踪开发效果
过程描述：许多设计师在完成了一个模块的设计之后就进入下一个模块的设计，永远处于设计的状态，而不去追踪设计效果的开发实现。实际上，开发结果和设计效果往往会有出入，特别是设计师不管开发效果的时候，不少前端会自作主张或者错误理解设计稿，最终开发出不尽如人意的产品。
原因反思：设计师往往认为设计过程是最重要的，提交了设计稿之后自己的任务就完成了，接下来的开发环节不归自己管了，应属开发和产品经理来负责，如果开发不理解设计稿也肯定来问设计师的，设计师只管等着被问就好了。而实际上，人都有惰性，开发也会碰到问题不来问，宁愿自作主张的。产品经理也会更注重大局，而忽视交互视觉上的小瑕疵。将设计稿完美地开发出来需要设计师对后续开发的跟进和反馈。
如何避免：首先在提交设计稿时就应按照开发写代码的方式将设计稿标注好，如果标注的字太小，也可以在邮件里再写一遍，以便开发能有明确的参考。其次，将设计稿提交之后随时跟进开发进度，对于开发结果出现的诸如没对齐、没有边界线、padding大小不对等等细节进行反馈请求修改。
2. 不懂技术
在国内，不懂技术对于设计师来说似乎无可厚非，许多公司的招聘广告里丝毫不要求设计师懂技术。然而懂一点前端开发是你的设计可以被完美开发还原的基础。懂前端可以让你以开发想要的方式来标注你的设计稿，降低了设计师和前端之间的沟通成本，有时甚至可以帮前端改一些他懒得改的细节代码，以使开发作品更符合自己的设计原型。
原因反思：许多公司招聘设计师不要求设计师懂技术，面试时也不会涉及任何技术问题;设计师理所当然地认为技术属于开发的管理范畴，自己只要能设计出来的，开发一定有办法开发出来;犯难情绪，觉得技术难懂，不想学。
如何避免：我提倡设计师去接触一些前端知识，即使自己一行代码都不写，不练习写代码，但至少也要看看前端代码是如何构造而产生界面的。推荐http://w3school.com 这个网站，能系统地学到许多前端知识。
交互设计师（实习）Thor from 网易游戏
想提一点我自身感觉特别深，就是在进行讨论时，要懂得始终让讨论在同一个维度上，说白了就是讨论的是同一个问题。
说两个案例：
1、在前一份燃健身实习时，boss是大熊，前美丽说副总裁，性格非常直爽的一个人。有一种很明显的体会就是，大熊参加的会议，讨论产品的效率会提升不少。因为每次在讨论某个问题的时候，参与的人可能会从不同的角度去分析或则思考，得出的结论也会不一样。大熊往往会出来控场，每次的控场都非常的果断，只要有其他纬度的延伸，就会及时的遏制住，确保当前纬度的问题可以更好的进行下去。
2、第二个案例说一说最近的，目前在网易游戏实习，在这份实习过程中，同样经常需要参加评审以及讨论。有一次在和导师讨论我的设计方案时，导师提出了我方案中做的不好的地方，并具体说明了理由，但当时我并没有就这个角度去回应，而是自己从其他角度进行了更多的解释。不得已导师又继续重复了一遍，并顺便指出了我所提出的角度存在的问题，这才让我两的沟通更加顺畅。
分析：这两个案例都说明了讨论在一个维度上的重要性，不管是参与评审还是1对1的讨论，假如各方之间的观点并不在一个维度上，是无法达成一个共识的，因为不同的理由只能对应于不同的维度，当维度相同时，各方之间才能够正面的进行碰撞。
小菜，Flyme Research & Design Center，准交互设计师
1. 在进入产品形态发展较为成熟的公司时， 常会设计出违背设计守则的设计
(尤其在手机厂商，设计 ROM 时有着非常多的设计规范。)
踩坑过程：在入职一周后便进行了 Flyme 某应用的概念设计，在设计时我尝试了很多新颖的交互和视觉，甚至有过颠覆 Flyme 的天真想法。但由于对 ROM 设计规范了解不透彻，以及不够重视 ROM 一致性，最后被同事喷了「真‧概念」。
如何避免问题再次发生：在进入一家公司时，先不着急接手设计项目，或者利用接手项目前的时间，深度体验公司的产品，并且将规范整理和记忆。
2. 前辈的指导看作是真理
踩坑过程：刚入职场时，每次评审面对一群 boss 时都会提心吊胆，boss 也会对自己的设计稿提出各种建议。顶着压力之下和对前辈的认可，往往 boss 说什么都没经过多思考就点头认可，但回头自己一想却四处有问题。
如何避免问题再次发生：评审实际上也是一场讨论会，经验再丰富的前辈也会判断不准确，更何况他们仅仅是评审时才进入思考模式，多表达自己观点和设计时的思考。但更为重要的是，培养独立思考能力。
3. 和同事讨论关于过于激烈而最后引发争吵
踩坑过程：当时做了一项新功能，就是否需要新手引导的问题和我的导师讨论了起来。我们各自表达了加入新手引导的利弊，但又各持态度，最后谁也不让谁而引发了争吵。过后导师还向自己道了歉，我为此非常愧疚。
如何避免问题再次发生：当讨论时双方各持态度时，多一些人加入讨论会产生不一样的观点，或许能成为矛盾下的「润滑剂」，也或许会得出更好的结论。
匿名，Microsoft Research Asia，UX 设计实习生
作为职场新人，除了锤炼专业技能，工作中的「性格」表现也应当注意。
踩坑过程：刚开始工作时，常把一些学校的习惯代入到公司中，例如在工作中过多的曝露自己的私人生活与喜好。这样的行事方式容易给周边的同事留下一个在你意料之外的标签，如「爱打游戏」「宅男」「养猫人士」。我就是因此常被不熟悉的同事误认为工作不够饱和，贪玩。或许这样能给大家留下一个有趣，容易相处的好印象，但是在工作场合，让人想起你的第一件事更应该是「专业」而不是其他东西，这样才能体现出你在公司的价值和重要性。
如何避免问题再次发生：工作外的事情在工作场合以外和好友同事分享便已足够。「你有看过你的老板跟你分享他的私生活吗?」
from 卿词 聚划算 产品经理（实习）
问题点：
初入大公司陷入「螺丝钉」情绪，拘泥于产品细节和功能体验。
描述：
上一份工作是在一个创业公司兼任产品与交互设计，更多的强调快速迭代拿到结果的执行力和产品体验上的细节雕琢能力，工作效率和用户体验设计是我的核心竞争力。但是到了阿里后，我的工作职能调整成为了进口业务的产品经理。这是一个更前台化，业务化的岗位。初期在惯性下，我仍然过多的拘泥于单点的执行和前台玩法的视觉优化上，在业务层面的思考不够全面也不够深入，没有在一个大的业务方向下去进行长线的规划。一方面，我没有意识和主动承担我对业务的决策能力，另一方面，基于业务浅层的功能设计也很难给我带来提高。
而当我逐渐意识到这个问题后，我开始花更多的时间去了解行业特点，对待竞品更多的从业务上的竞争力(货品结构、销售模式、目标人群、运营策略等)而非功能设计和视觉展现去分析，积极地约运营和UED同学探讨业务的现状和未来发展，我把自己更多的放在了一个业务经理的位置，愈发的意识到产品只是业务执行中的一种工具和手段。只有基于业务层面的分析和决策才是决定业务未来发展的核心点，而产品设计和体验设计，更像是业务实现目标的一种表现形式，决定了业务达到“天花板”的速度。
结论：
在大公司不要局限于所处业务和团队，将自己束缚于“螺丝钉”的定位中。在产品执行之外，主动承担业务的思考和决策工作，积极的进行跨类目、行业、bu的沟通与合作。虽然每个人负责的业务可能很有限，但是，能够对接的业务确是无限的。
产品设计本身没有好坏，只看是否能表达这个业务的运营策略。在我看来，做的好(产品执行、问题解决)的同时，更要想清楚(对于业务核心和下阶段重点的判断)，前者是职业能力的体现和获取信任的基础，而后者才决定了能在当前位置和业务上走的高度。
产品经理是一个很大的箩筐，具体到某一公司某一行业的产品经理，其职业发展和能力修炼和方向都是非常不一样的，一定要迅速找准当前业务的重点，明晰自身定位，做到工作效能最大化。
在我的问题中其实还隐藏了一点，为什么我会拘泥于产品体验和浅层执行上，我认为，恰恰是我对自身能力的不够自信(hold住业务，说服大家)，所以才选择了一条更加封闭和短期就看得见反馈的体验优化之路。结论就是，不要用战术(产品执行、功能设计)上的勤奋来掩盖战略(业务规划、团队领导)上的懒惰。
form 宝鹏 阿里巴巴 产品经理
不要过度关注于产品本身，避免成为工具人
工具人： 消耗绝大部分精相对比较确认要做的事情中，而欠缺对于全局、业务或者对于自身的考虑，导致自己成为了公司的“螺丝钉”，可替代性强，就像工具一样，公司用你就用，不用可以随时裁掉。
在阿里巴巴等偏重业务导向的公司中，“产品”仅仅是业务或者需求落地的抽象工具，因此“产品”并不代表了业务的所有。在这种境况中“产品”实现或者是说放大了业务的价值，是业务价值的主要承载体。
我认为没有任何业务场景更准确的说没有应用场景的“产品”是没有存在必要的。即便是在因缘际会下某些“产品”进入了大众视野，我相信这类“产品”也很容易死掉。因此不要认为“产品”只要做的足够好，体验足够极致，那么就一定会有可观的用户和可观的流量。
案例：
在做无线产品的时候(支付宝-首页下拉更多-云市场)，接到一个任务是使用支付宝的扫码支付来提供一个在B2B线下扫码下单(读者请注意，这里是扫码下单并非是走直接转账哈)的功能。我认为保证用户的点击、扫码体验以及功能性是比较重要的，因而花了大量的精力在控件优化和扫码性能、功能的提升上。诚然，这些东西无论在何时何地都是十分重要的。然而在线下推广我们业务的初期，发现了一些问题：
1、不少用户连支付宝都没有用过，更不用说扫码;
2、扫码支付存在用支付宝账号免登陆到1688的逻辑，然而由于历史原因淘宝-支付宝-1688的账号并不是一一对应的，导致登陆失败;
3、下单过程实际上是一个扫码到店铺页面，并点击向档口付款来进行支付，存在用户的跳失。
因此实际上我要做的并不是一个功能，而是一个场景：用户在线下的登陆-扫码查看店铺-向店铺支付-支付宝支付成功，而并非扫码本身，并且还需要从业务角度考虑如何让没有用过支付宝的人进入到这个场景中，以及如何让用过支付宝但是只习惯扫码转账的人使用扫码下单而不再用扫码转账才是应该考虑的问题。
归纳：
产品设计和实现过程中要使用全局业务思考原则和优先级判定原则来解决上述问题。在如上的场景中，需要利用全局业务思考原则来进行“产品”的判定，我做的到底是功能还是场景，如果是做功能那需要聚焦的是哪方面，如果是要做场景则要保证怎样的业务闭环。
根据全局思考的原则，我们再回来查看以上场景中的问题。
1、用户没有用过支付宝，则需要通过线下运营的方式来考虑这个问题。因此需要向老板提出配备运营团队或者同支付宝来合作来进行共同地推装机，这个不是产品所能够解决的问题。
2、首先理清楚账号对应逻辑，能够对应的做到无感登陆;对应关系无法查到的则给予提示告诉用户你目前的账号状态，要如何操作才能够继续接下来的功能。
3、下单跳失这个问题同样不是产品能够解决的问题，因为扫码支付同直接转账的方式并没有任何的优势，反而操作多了一点点的成本，再次，即便是用户付现金也没有任何差别。那么需要通过确认使用如何的运营策略来勾住用户(比如红包、满减、积分等方式)。
从如上来看，扫码下单流程的“产品”功能本身反而是次要的了。
欢迎关注作者的微信公众号：