时间: 2021-07-30 09:41:19 人气: 5 评论: 0
回顾2019年做的事情，收获了很多，我把它提炼成16条经验，希望在工作中能够给你带来启发。
第一直觉是我们接触产品时的第一感受，也被称为“用户感受”，比如看到一个功能玩法，我们的第一直觉是没什么意思，这其实在暗示这个功能缺乏玩的动机。
不要因为这个功能玩法做的很辛苦、不要因为急着上线、不要因为这是领导提的就忽略这样的暗示，试图说服自己，甚至给自己洗脑。
洗脑后的效果是我们不再具备同理心，听不得别人的建议，离用户越来越远。长期以往，给我们带来的危害有两方面：
我们在设计过程中**遇到很多设计细节决策：是放在左边还是放在右边？这个高度是顶到导航栏还是状态栏？这个地方要蒙上一层黑色遮罩吗？等等。
当你无法确定的时候，首要办法是去收集竞品，但竞品可能在这个细节上有多样处理方式，有些放左边、有些竞品又放在右边，导致你陷入纠结，我到底该怎么放。
这里有个参考原则：优先选择大厂的产品，因为用户量大，遵循它就是遵循大部分用户习惯；如果没有大厂的，你就选择竞品使用最多的。
看到太多因为缺失评审环节或评审环节草草了事，导致项目后期失控的案例了。前期大家不吭声，等后面做完了，意见、想法全都来了，这个需求点不行、那个设计细节不行，然后改需求、改设计、改代码。改完，这时有个人又抛出一个想法，然后再改，不断循环这样的过程。项目上线遥遥无期，所有干事的人还得背上项目延期的锅。
怎么办？
这锅当然不能背！重视每一次需求评审、交互评审、视觉评审，把可能有争议的细节全都暴露出来，目的是与所有项目利益相关成员达成共识，并做成**议纪要，抄送给所有人。一遍**议还没达成共识的，就继续开**，直到达成共识为止。
最终交付给开发的东西一定是确定的东西，就跟建造大楼一样，都已经结顶了，你说不对，这大楼的感觉不对，还得拆了改改，这样的工程永远是失控的。我曾听到一句非常直击内心的话，开发向产品哭诉着：“你们对你们产品到底要做成什么样子，到底有没有一个预期，都是我们做好的原型，你们再来试！”
（1）为了避免项目失控，在与开发配合过程中，一定要对自己的细节高度掌控，知道每个细节的具体规则。
（2）通过Excel将所有细节按照所属功能、所属页面、触发的前置条件和具体的规则描述这四个维度去整理成一份协作文档，方便团队之间共同管理细节。
（3）落地比想法重要的潜台词是：要走出自己的工位，熟悉自己业务的上下游，只有知道自己有什么家底，才能决定打什么样的仗，这远比纸上谈兵要更重要。
1）给用户提供的核心价值是什么？不清楚的，主动询问自己的需求上级；如果没有核心价值，就需要我们自己去找，可以扪心自问一下，什么东西**让用户每天都**来用两下，这个东西就是需要找的核心价值。
2）找到能够量化核心价值的北极星指标：产品前期的增长指标？产品中期的留存指标？产品稳定期的变现指标？
如果没有目标或目标根本无从执行，就需要结合自己团队的属性与擅长，依据公司（部门）北极星指标往下拆解。
记住，相比于北极星指标，团队目标一定是可落地、可执行的，比如实现日活1千万这样目标就无从执行，但每个月带来1000个新增用户有很多办法可以尝试。
定位自己在团队中的角色，围绕团队目标，把有限精力集中在能够大概率产出结果的事情上。比如在团队中承担产品设计的角色，围绕每个月带来1000个新增用户这样的团队目标，通过优化核心功能的原分享路径，预期每天带来50个新增用户。
（1）不做老好人，表面上的人际融洽，不一定是好事，反倒**让人情这玩意儿影响自己的标准。
（2）不要碍于谁的面子，不好意思在工作小组暴露问题。
（3）不要单打独干，擅做决策。因为在开发阶段、测试阶段以及上线后，很可能因为无法达成共识还要改方案。
（4）沟通过程中不要嘴比心快，不要情绪化。
（1）先提升自己标准，严谨的文档产出、高效的协作方式，这些**无形影响团队、改变团队。
（2）有问题就要暴露，暴露的目的是促进大家共同提高标准。
（3）重视评审，评审的目的是在开发之前，把问题暴露出来，并对解决方案达成共识，避免已经快提测了，还在因为共识问题修改方案。
（4）对问题发表观点前，先把问题搞清楚，同理别人的场景，给出有效的建议，而不是自以为是，抛出一些没有任何建设性的大道理。
原型就是用来把文字版的想法、思路、概念落地为可交互的产品形态。
对于核心流程绝对不可以，因为这样**很容易陷入细节的海洋里，方案产出效率低，并且很容易做错方向。
让我们在聚焦细节前，对方案整体轮廓有清晰的认识。虽然多了这一步，但却可以大大提升方案的产出效率，并且能一招制胜。
（1）足够低保真，因此不要出现任何影响我们判断的颜色与图案。这样做的好处是让我们足够聚焦于核心内容，不被无关细节干扰。
（2）足够灵活，便于我们还原真实场景与交互，所以建议大家多用纸质原型，你可以把Axure的电子原型打印下来，你也可以直接绘制纸质原型。纸质原型的优势是：可以充分调动我们的手、眼、大脑，更能感知实际场景、发现潜在的交互问题；此外这种灵活、有趣的方式，也非常有利于产品小组人员的参与。
加！但我要尽可能让这个入口加的合适。
为什么我**发起每天设计细节打卡，虽然分析方法是一样的，看上去好像在重复一件很傻的事情，但好的细节积累多了，**潜移默化地提升自己，更容易产出好方案。与一个星期前相比，积累设计细节给我做方案带来一个明显的变化就是，思路比之前开阔多了。
需求设计前，你或者给你提需求的人需要搞清楚的4个问题：
（1）做这个需求的目的是什么？
（2）上线后怎么看这个目的有没有达到？可以通过哪个关键指标体现？
（3）现状是什么？存在哪些问题？哪些问题仅是自己感觉的问题？哪些问题确实是用户反馈的？在哪里反馈的？反馈的人多吗？哪些问题已经被验证了？哪些问题还只是假设？
（4）解决方案是什么？
竞品怎么做的？哪些地方可以参考？
因为数据就是目标，没有目标做设计**很迷茫，你不知道什么是好、什么是不好，功能上线后，也不知道下个迭代怎么优化，工作实践很难闭环，对产品和个人都是挺有害的。
所以，在开始设计前，最好先确定目标，我们希望通过设计去提升哪个数据指标，这个数据指标和我们业务上的北极星指标有没有关系？
比如希望通过某个设计迭代提升某音乐平台的人均收藏歌曲数量，因为通过对照分析发现人均收藏量和产品次日留存、周留存存在着明显的正相关关系，即收藏量越多，留存数据（业务上的北极星指标）表现越好。
数据对应问题，需要我们主动积极地去了解所做的业务，洞察业务的问题是什么，再假设这个问题解决了，**提升哪个关键数据指标。
能够找到反应业务问题的关键数据指标其实不是那么简单，刚开始过程中，经常容易找错，这就**比较尴尬，到底是设计方案没达到效果还是关键数据没找对。遇到这个情况很正常，可能是由于我们对业务问题的理解还不够，导致定义的指标比较浅显，或者问题定义环节就出了问题，但不要灰心，反复蛰伏，一定可以找出来的～
我们日常工作中埋点有两种思路：
建议不太熟悉时，采用第一种，避免因为关键指标找错了，遗漏了重要埋点。
主线一定要明确，这是看简历的人希望看到的信息：现状是什么？问题是啥？你是怎么解决的？为什么这么做可以？结果怎么样？
不要试图扮演某个角色，展现最真实的自己即可：不要套书上的方法，什么用户体验地图、GSM原则，如果你对这些没有深刻的理解，只是照葫芦画瓢，就不要放了，非常影响文档可读性；比较期待的是看到是你自己的方法，你能根据自己的业务情况，抽象出对于解决当前一些问题比较有帮助的一些方法；
把作品集当成自己的交互作品来做，你的用户是看简历的人，他们想要看到什么？你如何保证他们能够轻松地理解你的表达？不要沉浸自己表达，带着同理心去做你每一页的内容；
除了专业上的产出，还可以呈现一些帮助团队提升产出质量与效率的工具或方法建设以及体现自己特色的兴趣爱好。
不要嘴比脑子快，说之前，先明确自己到底要表达什么，然后围绕观点去细说，避免你自己也不知道在讲什么。
别人提问时，一定要理解清楚别人想问什么，你可以跟他确认，明确没理解错的情况下，再回答，不要自以为理解了，实际误解了。
回答别人问题时，先思考一下，可以从哪些方面回答，然后先说观点，再说原因。
一般这种场合陈述只有10分钟，最好提前设计一下，控制好节奏，点到为止，不要发散，传达重要信息。
语速要慢，保证说出去的内容，别人能很容易听懂；切忌为了赶时间，一下说完了。
最后一点，也是最重要一点，表达的内容最好提前设计一下，听的人想听什么，这些是你表达的重点！
提升学习效率与质量的关键在于我们是否敢于舍弃不好的内容：
（1）不是所有内容都得消化，这**导致我们学习效率很低，更严重的是，**影响我们的学习兴趣。因此得对学啥内容有所筛选。
（2）如何筛选好的内容？
UE小牛犊，微信公共号：交互实验狮，人人都是产品经理专栏作家。关注产品思考、用户体验分析、交互研究，致力于UX方法论的探索和实践。
本文原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Unsplash，基于 CC0 协议
