07
7月 20

工作界面管理

这周开周会时,给团队讲了一个职场理念:工作界面管理。

所谓「工作界面」,是类比的用户界面(user interface),即产品底层功能和用户发生交互的部分。

假如我们把自己看做一个产品,这个产品的目标是为公司提供一种专业服务,那么我们与这家公司里的同事发生交互的部分,就是工作界面。比如你的交付物、分享、汇报、会议、微信群沟通,都是构成工作界面的一部分。

就像用户界面应该简洁、美观、高可用、值得用户信赖和尊敬一样,你在公司里的工作界面亦如是。通过工作界面,你和同事、领导、上游需求方、下游设计/技术团队产生交互,用户不会直接访问产品数据库,对C端用户来说,界面即产品。同理,你的同事和领导,也无法直接评估你的专业水平,只能通过工作界面形成对你的印象和评价。

因此,我们可以带着做产品的视角,主动管理自己的工作界面。

首先,最基础的要求是,保证书面交付物的质量。比如产品经理的主要交付物——原型、流程图、产品文档、操作说明书、项目规划等,应面向对应的不同受众,做到简洁易懂,重点突出,用户体验良好。

然后,更重要的是,关注一切和同事沟通的场景,包括但不限于会议、微信、邮件沟通。

先说会议。

如果你是一个会议的组织者,你的使命之一是保证会议高效进行。

  • 提前搞定投影、通知与会各方按时到场。
  • 有重要参会方迟到时,最好要在会议群里cue人或是电话提醒,而不是私聊发消息,因为对于其他已经到场的参会人员而言,他们需要感受到你在行动
  • 会议主题应清晰聚焦
  • 会议结束前总结结论和to-do
  • 会后及时发出会议纪要

如果你是参会方,在参会前为每一个会议设定明确的目标,并做好准备

比如,参加隔级领导组织的大部门例会,提前准备好一切可能被提及的发言内容,把握每一次与隔级领导、上级领导同事的沟通机会,体现出自己的专业水平。

功利一点说,你永远不知道下一次晋升述职的评委是谁。也许某一次优秀的表达,就能让你在ta心中留下好印象。

微信工作群,也是一个特别值得重视的工作界面。

我们都知道,有时候在群里文字沟通是很容易撕逼的,当你意识到文字沟通逐渐情绪升级,最好停止继续文字沟通,群里约对方电话沟通或当面沟通。

在群里留下一堆充满负面情绪的聊天记录是最蠢的行为之一。一是完全无助于问题解决,二是会给群里一大批人留下负面印象,吵架双方都很不专业。

邮件是最常用的沟通方式之一,有太多地方教人怎么写好邮件,此处不再赘述了。

最后,根据用户画像和场景,有意识的调整和优化你的工作界面。

在强调执行效率的公司,老板发出的任何指令,应该及时响应或有行动;执行过程中,随时和老板同步进展,给出完成时间点预期。

你可以把你自己想象成为一个app。

  • 你的同事、领导就是你的用户,他们的每一次输入,你是否都给出了即时的输出?
  • 从最轻量的toast到模态的弹窗,总归是要先对操作给出即时反馈吧?
  • 如果当时不能取得结果,要有一个loading进度条吧?最好能给出剩余时间和完成百分比,这样能降低用户的焦虑感;
  • 最终呈现信息,采用清晰精炼的文本,加生动的图片或动效,这就是PPT或者邮件了,形式不重要,能表达清楚信息最重要;
  • 如果你无法提供给对方需要的东西,要给出「报错提示」,话术也应尽量友好,并且尽你所能给出替代方案。
  • 避免出现一连串生硬的报错,对你的用户形成一系列暴击。

熟练运用工作界面思维,还可以改善工作效率。

  • 如果对接方很多,需要用在线表格收集信息时,给出填写样例;
  • 思考你的下游需要怎样的格式,面向最终结果设计表头字段,减少加工工作量;
  • 提供简单易懂的背景介绍,帮助你的用户快速掌握事情背景信息,让双方在同一个信息背景下更有效的沟通。

对于产品经理,一切皆产品,一切皆可设计并优化。

带着产品思维做事,会让你在职业上取得更大进步,从而最终获得升职加薪。而这个优化工作界面的过程,反过来也能帮助你理解用户、理解人性,从而成为一个更优秀的产品经理。

题图:端午节爬了一个密云的小山,叫云峰山(不是六峰山hhhh)。远处能看到不老屯天文台,再远处是密云水库。


30
6月 20

做投资的人,可能做不好产品。

诈尸,开一个新的职场脑洞系列,慢慢记录一些在大公司随笔。计划是一些很短的内容开始,逐渐恢复码字的哪几块脑细胞。

计划分成几个标签类别:产品,金融模式,经济学。想到哪儿写到哪儿。以「复健」为主要目的。

今天是观察公司里面一个之前做战投,后来转岗业务的同事,隐隐有个猜想,做投资的人,可能做不好产品。

投资是一个快速试错的模式,不用想得清楚,只要方向对了,就快速试,不成立就换,多投必中,中了就是百倍千倍万倍回报。资本相信概率。资本是浮躁的。

但做产品不是这样。首先你的资源是有限的,老板给的机会、研发团队给的信任、市场时间窗口期,都有限,逼迫你想清楚产品关键增长路径。

做出好产品的人,需要见微知著,针对目标用户的核心痛点,想清楚,打出差异化的产品属性,解决用户的关键问题。


02
1月 18

《同世界和解》一篇旧草稿

多年之后,在一个同样晴冷的早上,她想起那个下定决心同世界和解的早晨。第一场秋雨刚刚下完,彻夜雷声不断,仿佛万千妖魔渡劫,雨后天气晴朗,阴影里很凉。

她想起曾经想要收藏的乙一的小说,《ZOO》、《我所创造的怪物》、《GOTH·断掌之谜》,哦,当然还有那本最初的惊艳《夏天·烟火·我的尸体》。这个直到今天依然不是特别红的日本作家,可能是大学时代的男友推荐的,她只记得一口气读完那么多本惊悚又神奇的文字,使她对于「孤独」这件事脑洞大开。

不止乙一,她肯定她还会收藏一套卡尔维诺,尤其是宇宙奇趣全集。那本书尤其适合在深夜窗台仰望星空,或是放在台灯下床头边,作为给小朋友作为睡前读物。

这一切需要一个大书柜,以及一个温暖的小房间。那会是一个可以收藏灵魂、休养繁衍的地方。就像是一个终于解决生存挑战的单细胞生物。区别在于,人还可以通过代际传递某些精神层面的东西,比如想法、气质、世界观。

而这,可能是她第一次对「结婚」产生美好而具体的期待。

——原文最后编辑于2016年9月11日上午10:57


27
2月 16

Everglow



15
1月 16

2015年终总结·工作篇

2015年,工作方面发生了许多的变化。

首先是年初从用户研究员转岗成为产品经理。

做了2年用研,我也不知道自己算不算一个好用研。或许是因为从毕业进入互联网行业开始,就一直想做产品,不知不觉中我努力的方式就是做一个产品经理眼中的好用研。用dota来比喻的话,类似于辅助位,插眼(市场分析、用户访谈)、反眼(体验走查)、游走gank(提供研究证据、推动产品改进)。而我老大带领用研团队努力的方向是在更大范围内发挥研究的力量。用dota比喻的话,就算不是一号位至少也是二号位,经常来个宙斯大招全屏闪电(用户体验考核),再NB一点儿的直接开启大局观、飞鞋全场带节奏(市场调研、向公司决策层输出战略决策)。

我一直觉得,我老大是一个非常牛逼的用研,更是一个非常牛逼的老大。当年整个团队学习氛围非常浓厚,经常组织内部专业分享,跟他的2年里收获很多。

2015年,老大去做了B2B产品。希望有朝一日能以PM的身份再次相逢。

然后的变化就是9月份换了一家公司。

在前东家做产品的半年时间里,一大半时间是在用SQL跑数,分析数据做调研,一小半时间是在开会、撕逼。真正做设计和推动方案落地的机会并不多,几个月下来除了把老大们交付的几件事按部就班的做完,别的就啥也没做了。有自身的原因,比如产品经验不足,心态不够自信等等。更多是组织层面的因素:开发资源比较少并且效率略低下,设计部门较为强势、规范已经相当成熟、留给PM发挥主观能动性的地方已经很少了。

新东家的情况完全不同,产品尚处在快速发展期,PM对产品管控权力很大,从需求发起、交互设计乃至视觉设计,都是PM说了算,开发也都非常给力,有时还会自己做个方案出来找我们PK(笑)。前些日子写试用转正总结才发现2个多月做过的项目比之前半年的还多,现在再想起当初那些撕逼也好、纠结也好,根本不算啥,心态上也自信了许多。

不知该不该感到庆幸,如果不是因为情变,说不定就会如同温水煮青蛙一样沉沦下去了。等到某一天互联网严冬的大锅盖盖下来、才发现自己弱小得根本跳不出去。

最后就是从社交领域到电商/金融领域的转换。

领域上的转换,感受到最大的差异是每个人的卷入度。社交领域里,用户和产品都没有特别强的卷入度,能玩就玩、不能玩拉倒,用户反馈每周整理一次,但其实只有高管投诉会得到重视,普通用户根本没人管。电商行业不一样,用户反馈每天整理一次,不管什么用户投诉,会要求第一时间响应到位,一些特殊问题产品会直接打电话给用户询问情况。另外每年三次电商节如同打仗,不拼个你死我活誓不罢休,竞争颇为激烈。

这种高卷入度也会渗透进产品设计中。转化率成了一个特别现实的问题。由于漏斗模型几乎是个不可挑战的铁律,每一步多余操作、每一步新增操作,都会受到设计上的质疑。 那么最后就来说说转岗之后都踩过哪些坑、收获了哪些经验吧。

1、产品设计方面

做过2个非常业余的烂设计。

第一个是白条收银台的分期选择和优惠券的交互设计。分期选择是原先就有的,新增了优惠券。优惠券有可能会限定适用分期,当用户分期不适用时,有些优惠券是不可用的。二者存在着联动关系。但分期和优惠各自都折叠在二级页面里,并且因为沿用了老版本的设计入口离得比较远,用户很难在二者之间建立起联系。

新功能上线后,负责运营的同学试用了一下,跑过来猛烈吐槽。我一边给她用美图秀秀当场做简易教程,一边很沮丧很心塞:卧槽我特么做了个需要看说明才能用的设计。。于是下决心之后一定要重构。

新版本在交互逻辑上重新做了设计:1)分拆了下单页和支付弹层,减少接口反复调用;2)分期和优惠统一放到支付弹层里解决,并且在一个操作闭环里解决分期和优惠冲突的问题,当用户选择了有限制分期的优惠,就紧接着引导用户再选分期。

经验:

1)设计要遵循就近原则。如果两个选项之间有依赖关系,那么它们要么得在空间上离得很近,要么得在时间上前后衔接。

2)最好设计前期拉运营同学一起review方案。运营、市场同学的『大脑结构』和用户更为接近,PM的大脑有时候太跳跃了。

第二个比较业余的设计是优惠的初始化状态。电商结算页初始化的时候如果没有默认优惠,这个位置就会是『未选择』。我当时觉得应该有一个状态区别于用户自主确认过的『未选择』,于是将初始化的状态设计为『请选择』,当用户手动确定『不使用优惠』时,这个才会变成『不使用优惠』。其实这种小细节的区分是没有什么必要的,却让代码逻辑变得很复杂。

经验:

1)要克制。合理的简化设计是很有必要的。当RD抱怨:『这块的逻辑太复杂了,我们hold不住』,也许是有道理的。请一定要想到发版前夜大家一起熬夜加班改bug、梳理逻辑的情景;

2)要去看行业通用设计。因为它有可能是比较合理的做法,至少,它会是用户最习惯的做法;

3)通过增加逻辑判断提升的用户体验可能会由于复杂而被抵消掉,或者提升压根可以忽略不计。要知道对体验影响最大的那块短板在哪儿,而不是盲目加高其他木板的长度。

2、异常情况处理

从社交转行做支付后最大的感受就是:90%的时间和精力都用在处理各种异常流程,只有不到10%的时间花在正常流程和用户界面上。很多逻辑一开始没有想通透,常常是一边开发一边遇到之前没有考虑到的异常情况,也就是『踩坑』。坑踩多了,会逐渐掌握异常情况的全集,从而得以预判哪里有坑。

47a53314jw1eynqw0mtqhj20cs0an405

经验:

1)预先准备业务流程图,或者在需求宣讲时和RD一起梳理绘制,一些复杂的前端逻辑或许用伪代码来说明会更好(不过我还没写过,不知道会不会伤害到RD的自尊233);

2)和QA一起review测试用例,好QA可以帮忙预警很多坑;

3)各种追加的处理,随时补充到文档里、随时讨论组里沟通以免RD遗漏(尤其是当团队成员有分散办公的情况);

3、降低上线风险

还遇到过两次上线失误。

一次是服务端『少上了一个依赖』(开发原话,具体啥意思我也不是很懂),代码回滚,收银台挂了34分钟;另一次是H5前端少处理了一种情况,挂了30分钟左右,和我变更过需求有关系,QA同学没有回归测试到这个用例,也是个小失误。这两次上线问题,RDQA当时都是处于多个项目同时进行的状态。

作为PM,同时跟进2-3个项目是一件很正常很合理的节奏,每天的工作非常充实饱满,工作狂倾向的我还觉得略爽。但写代码是一个要求认知资源高度卷入的活动,多个项目并行RD会有较高的失误率。

经验:

1)测试用例QA一定要写、一定要写、一定要写,写完还要一起review,这是最简单的管理风险的方法;

2)关键环节最好在业务非高峰上线(不过没人愿意熬夜加班上线,落实起来有点困难);

3)尽可能不要在开发中途变更需求,如果变更需求,尽量帮RDQA回顾逻辑依赖。

4、大局观

谁没被砍过需求呢。

需求起因是老大说要『搞搞消费』,但现在的产品框架容纳不了太多导购内容,于是需要先扩展产品架构。扩展需求列出来之后,最先跳出来反对的是客户端RD,因为安卓内存控制做得不好,架构扩展后可能会提高低端安卓机崩溃率,吵来吵去最后争论焦点回到了这个事情有没有必要做,老大想了想,拍板砍掉了(他自己提的)需求。所以你们看,其实一切都赖老大,对不?哈哈

有想法、出方案、说服开发开搞、然后搞到一半需求被砍,这是小PM比较容易遇到的情况。作为一线PM,要努力提升大局观,老大『拍脑门』的时候自己要心里有数,对于那些逻辑上不成立、不符合战略重点的需求,缓缓再搞。把宝贵的资源专注在战略重点上。

2016年计划

16年目测又是很忙的一年。战略重点涉及公司机密就不多说了,自己比较感兴趣的事目前有以下几件。

1、支付SDK:上半年希望用来了解支付类SDK的实现原理:包括支付路由、如何具有业务通用性、安全性等。

2H5设计:在承接业务需求和开发基础功能的中间,也希望能穿插着做几次运营活动,所以需要平时多看看H5案例,了解H5页面的实现原理。

3、混圈子:多走出去,参加一些产品经理论坛。如果有可能,希望可以自己组织几次内部小工作坊,和小伙伴们一起成长。

加油,2016