【2006】说说“UGC模式”

导语

说“UGC”之前,首先要搞清楚什么是“UGC”、“PGC”和“OGC”。

名词解释

[infobox title=”UGC”]UGC(User-generated Content,用户生产内容,也称UCC,User-created Content)也就是用户生成内容的意思。[/infobox]

[infobox title=”PGC”]PGC(Professionally-generated Content,专业生产内容,也称PPC,Professionally-produced Content)指专业生产内容(视频网站)、专家生产内容(微博)。用来泛指内容个性化、视角多元化、传播民主化、社会关系虚拟化。[/infobox]

[infobox title=”OGC”]OGC(Occupationally-generated Content,职业生产内容)视频、新闻等网站中,以提供相应内容为职业(职务),如媒体平台的记者、编辑,既有新闻的专业背景,也以写稿为职业领取报酬。[/infobox]

 这三者之间既有密切联系又有明显的区别。一个平台(网站)的PGC和UGC有交集,表明部分专业内容生产者,既是该平台的用户,也以专业身份(专家)贡献具有一定水平和质量的内容,如微博平台的意见领袖、科普作者和政务微博。PGC和OGC也有交集,表明一部分专业内容生产者既有专业身份(资质、学识),也以提供相应内容为职业(职务),如媒体平台的记者、编辑,既有新闻的专业背景,也以写稿为职业领取报酬。

——文章《浅析UGC、PGC和OGC》

消费理念的变迁

这个说法有点像《马斯洛需求层次理论》,一个新的东西出现,功能实现就好。就如手表,时间对就好,但逐渐的就会追求品牌,让人觉得此品牌有质量保障。又如超市的牛奶区,以前都是认品牌的,各种品牌推销活动,现在一到周末,则是各种试吃试喝体验,通过品质吸引客户。又如微博,旅游KOL这些,重新定义资讯,让资讯不再是只有OGC这种新闻平台。在UGC这类产品中,前文说的旅游KOL、微博大V这些用户就是产品的内容。

互联网思维核心是口碑为王,口碑的本质是用户思维,要把UGC产品做好,就要让用户有参与感。

构建参与感,就是吧做产品做服务做品牌做销售的过程开放,让用户参与进来,简历一个可以触碰和拥有,与用户共同成长的品牌。才会形成三三法则这个概念。

UGC型产品其实还有两个比较常见的呈现形态“平台型的产品运营”和“新媒体型的产品运营”。

  • 平台型的产品运营模式:最经典各种论坛、微信的朋友圈,还有知乎和微博这种,都属于平台型的UGC产品;
  • 新媒体型的产品运营模式:例如微信的公众号,今日头条和喜马拉雅这种,都属于新媒体型的UGC产品。

可能这时候,会有人觉得PGC和UGC有点混淆,用罗胖子逻辑思维举例,他本身是一个KOL,属于PGC范围,但如果基于微信公众号里,他就是一个UGC的内容提供者。

小结

今天就先说到这里了,互联网发展日新月异,搞不好哪天,这些东西又被彻底颠覆了,我们能做的就是不断的更新自己的知识库,保持自身的竞争力而已。

【2005】移动端启动的“黄金七秒”

导语

一个移动端应用,在系统层点击ICON到真正进入应用第一个可操作页面,这几秒十分重要。心理学中有个“七秒钟理论”,就是说人与人见面的时候,产生好恶决定于见面的头七秒,对一件商品的认识,可以在七秒钟之内以色彩的形态留在人们的印象里。

根据国外相关机构的研究表明:能被消费者瞬间进入视野并留下印象的产品,其时间是0.67秒,第一印象占决定购买过程的60%,而这60%是色彩带来的。

启动过程中有可能出现什么页面?

  • 启动页
  • 过场页
  • 登录页
  • 注册页
  • 应用首页
  • 信息采集页

启动页

进入应用第一个看到的页面,一般是应用LOGO加应用名称,或许还有公司相关信息。主要是突出品牌/应用的色系色调,没有太多的内容,核心目的是品牌认知。

过场页

  1. 走马灯图片:一般出现于初次进入(如:新安装,更新版本进入),一般用于对应用的核心功能进行介绍;
  2. 几秒钟广告:有可能是视频,有可能是几秒钟广告图,一般用于活动宣传。

登录页/注册页

这个可以一起说,部分应用强制登录后进入,主要出现于未登录或登录状态失效。

应用首页/信息采集页

这个和上面相反,非强制登录的应用在启动后出现,展示第一个希望给用户看到的内容或希望收集的信息。

启动过程怎么设计最好?

没有最好的设计,只有最合适的设计。可能在甲产品中设计A会显得很傻,但有可能在乙产品中,设计A又显得非常合理了,这是要根据产品特性决定的。

来看一个近年流行的启动流程(非强制登录类应用,例如新闻类产品):

常规套路.jpg

非常常见的一个启动流程,固定位置的品宣,5秒左右的广告,进入首页。完成整个启动过程。看似简单,整个流程是经过多番考虑的。

有何巧妙?

  • “净色底+品宣”的固定显示,哪怕广告加载不出来,也不违和;
  • 广告不挡“品宣”,感觉整个启动就在一个页面进行,相对缓和;
  • “跳过”按钮带倒数,就等于有“进度条”概念,让用户清晰知道等待时长,选择是否跳过显示。
  • 广告的加载方法,这个是看团队功力的地方。例如:打开时检测最新广告进行加载;检测是否有广告更新列队,提前下载在本地,到日期直接显示;发现新广告,下次显示等方法,这里就不详细说了。

好在哪里?

说说过去,还是“品宣”和“广告”,但不同在于以前的“广告”是满屏的,有可以跳过的,也有不可以跳过的。“跳过”按钮是个感受加分项,但不是加分最多的,关键还是页面切换。

以前的启动过程:

老流程.png

上述介绍的启动流程:

新流程.png

我解释下,同样的时间内,老流程跳了几下,让人感觉距离很远。新流程的视觉感受一直保留在一个页面内,让人觉得下个页面就到终点了。这个细小感受上的差异,极有可能决定了用户对产品的印象。当然了,我上文所说的内容并不是绝对的,只是一个举例,任何事情抛开了前提条件讨论都是耍流氓。

在这里,说的只是原理,哪怕同一个应用的不同时期阶段,启动过程要考虑的事情可能也不相同,会导致设计理念和效果对后续造成的影响也会不同,所以一切要按实际出发就好。

启动过程的设计技巧

  • 清晰,直接明了的品牌宣传,让用户一想做这个事情就想起你;
  • 使用整齐,简洁,干净的界面,舒缓用户的急躁心情;
  • 使用场景化,情怀化的氛围,让用户身同感受;
  • 使用触动情感的语句或画面,让用户产生共鸣。

启动过程设计好坏的蝴蝶效应

  • 新用户的登录转化率
  • 用户留存率
  • 活动宣传效果
  • 同类型产品的印象值

……

小结

本文只是很浅的说了一下启动过程需要注意的点,并未深入去分析各行各业启动过程的侧重点和他们迭代过程碰到的问题及解决想法。

总的来说,启动就是应用的门面,里面包含非常多的处理逻辑及设计思路。肉眼上看家家应用都差不多,但实际背后的逻辑才是见真军的地方。例如首选项配置,用户数据采集,加载逻辑等。日后有时间,再逐个分析分享。

【2004】需求文档需要详细到什么程度?

导语

相信很多产品经理都有这样的一个经历,需求写的太简单吧,开发同学嫌弃没细节。花大力气写个长需求吧,需求评审的时候又发现,大部分人压根没怎么细读过文档。在这里,要抛出个问题

需求文档是干什么用的?

一般来说也就两个用处:1、用来沟通;2、用来存档。

内容够用就好

很多人可能喜欢在这个时候抛出《用户体验要素》中的五个层次(注:用户体验的五个层面分别是:战略层、范围层、结构层、框架层和表现层。),将一个需求拆分成好几个不同的层面进行说明,写完一副这需求写的完美了,人人都能看懂了,什么信息都包含了。对,这确实没错,但这会消耗大量的时间在编辑文档上啊,若非关键大版本的需求,清楚明白就行了,毕竟实际工作场景中,太多的快速迭代版本,什么都一五一十的写出来,在时间分配上也是一门学问。很多时候,画个原型,加一些辅助的说明,远比文字直观。

给谁看

一个需求的立项,也有调研,分析,评审,排期等不同的阶段,不同的需求也有可能会碰上不同的会议,不同的主题,所以这时候给谁看很重要。最关键的是,TA想知道什么。

  • PPT:一般都是包装华丽,文字精简,突出中心,主要靠的是会议的演讲,并不是文件的本身。针对对象:大老板,发工资给你的那个人;
  • word | excel:一般都是条理清晰,层级清晰,列清楚一二三四五。针对对象:开发同学,一般他们喜欢一是一,二是二,不带歧义的描述;
  • xmind | axure:结构化思维,图形化思维,直观容易理解。针对对象:评审会议上的各路人马,大部分人容易理解这是干什么的,方便看图提问,发现问题;
  • 图片 | 交互流程 | 清单:清楚列出该需求涉及页面数量,交互逻辑是怎样的。针对对象:UI和UE设计师同学,解决设计上的布局问题和体验问题。

小结

软件只是工具,模板只是方法,关键在于随心所欲,灵活变通。

【2003】说说周报

导语

相信大部分的公司每周都要写周报,除非特别忙碌,否则周报里总会掺杂一些看似华丽,实际没用的内容信息。就如以下场景:

运营活动发生变更,活动专题页需要调整文字和更换图片,内容琐碎,但存在工作量。产品经理叫技术帮忙调整下页面,虽然是手板眼见功夫,但技术人员想了几秒,还是说了句,提个需求吧。

这里涉及到几个因素:

  • 工作流上应该走需求提交流程
  • 技术人员需要写周报,这是工作证据
  • 有个记录,日后发生问题的时候有依据

今天说的是周报,就不扯远,不去纠结若出了问题这个锅谁背这些办公室问题和职能问题。更多的时候,其实就是工作证明的问题,我做了这个事情,有证据可依。

那么,周报到底要写些什么呢?怎样写周报才让周报真正有意义。

本周做了什么

描述做了什么事情,开了什么会议不重要。关键在于时间节点,进度情况,有什么决定,后续如何跟进等。

下周要做什么

原理同上,主要描述需要获得的结果成就,不是过程经历。

遇到什么问题

例如:一个可控低的需求,遇到第三方资源还没到位,需要什么人,怎样帮忙。若无法达成,是否存在后补方案。

存在什么风险

例如:一个需求的实现方法上存在多种实现方案,但有各自的优缺点,使用不同的方案分别会引致什么问题发生,这些问题是否存在重大影响。

给谁看

在写作技巧上,尽量少用“继续跟进会员中心功能细节”这种比较虚的描述,应该使用“与开发部的XX同学进行讨论后,达成共识,周4启动XX功能的需求撰写工作”。

根据不同的汇报环境,调解内容的敏感层次。若真的存在敏感内容必须汇报告知的时候,可以将公共内容进行“TO”和“CC”,将敏感内容再单独“盖楼”给对应的人员,完成汇报周报的工作流。

小结

任何工作,不是为了别人,而是为了自己,周报不是应付,而是对自己过去工作的一个小总结,定期对自己过去知识点和碰到的问题进行梳理,让自己能不断的提高。

【2002】产品经理的起源及查克拉属性

产品经理岗位的起源

自1927年,美国P&G(宝洁)公司出现第一名产品经理(Product Manager)以来,产品管理(Product Management)制度逐渐在越来越多的行业得到应用和推广,并且取得了广泛的成功。
自此,国内多家领先企业相继采用产品经理管理模式,走出了产品研发的“象牙塔”,使产品的研制开发有的放矢,快速地满足客户的需求。

有个段子分享下给大家

很久很久以前,负责给程序员提需求的人叫做老板,或者叫客户。
老板经常对程序员做出来的东西不满意,好几次都想动手,但是脑子一闪现“删库跑路”,不由得放下了紧握的拳头。
程序员也经常对老板提出的需求不满意,好几次都想动手,但是脑子一闪现“炒鱿鱼滚蛋”,也不由得放下了紧握的拳头。
在这种尴尬中生产出来的产品,结果可想而知。
时间过去了很久,有一个非常聪明的老板,他想出来一个主意:招了一个人,安排个岗位叫“产品经理”。
他对这个产品经理说,以后你就负责整理我的需求,然后传达给程序员,谁要是敢揍你,你来找我,我给你出气。
然后他又对程序员说,以后他就是负责给你们提需求的,叫产品经理,他要是敢揍你,你找我,我给你出气。
于是,老板就这样每天喝着茶、笑看产品经理和程序员撕逼打架。既不用担心被打,也不用担心程序员删库跑路了。
于是,产品经理就这么产生了!

在长辈眼中的产品经理

估计很多产品岗的同学都有同样的经历,当告诉长辈自己是产品经理时,长辈们第一反应就是挺厉害的,年纪轻轻就是个经理了。“经理”一词,在老一辈的认知当中,就是管事的,下面有一个部门的人让你使唤。

其实自己心理都清楚,大部分的产品经理并不是真正的经理,产品经理上面还有高级产品经理和产品总监等,产品经理说白了就是一个执行专员,只是名字比较好听而已。当然了,每个公司都有自己的评级标准,在岗位头衔的叫法也有略微的差异。

产品经理的属性

今天我想说的是产品经理的属性,为什么要说属性?在很多互联网公司的用人招聘时,若没看清产品经理自身的属性,会导致匹配度,吻合度的各种不符预期,导致磨合成本提高。

大家有看过火影忍者吗?里面有个名词叫查克拉,类似龙珠的“气”,游戏中的“魔法值”等。查克拉共有七种性质变化:火、水、风、雷、土、阴、阳。根据自身的查克拉特性进行修炼不一样的忍术,与自身属性不搭的忍术练起来困难,提升慢,与自身搭的忍术用起来顺手,提升快。

以下是我归纳的的产品经理基础属性:

  • 功能型产品经理
  • 交互型产品经理
  • 运营型产品经理
  • 技术型产品经理
  • 管理型产品经理

功能型产品经理

功能型产品经理擅长的就是设计功能,主要通过模仿和改造,对自身产品的某个版块的某个功能进行优化迭代。一般在软件上比较喜欢使用Word,Axure进行内容产出,对功能的细节比较敏感。

交互型产品经理

交互型产品经理擅长的是用户体验方向,更多考虑的是一个功能如何吸引用户点击,如何更合理的布局。一般在软件上比较喜欢使用Axure,Excel进行内容产出,对操作体验比较敏感。

运营型产品经理

运营型产品经理一般存在于非专业的互联网公司,一般思路是我要用什么功能,做什么活动,具体怎么实现有技术同学。一般在软件上比较喜欢使用Word和截图,对业务层的运作比较敏感。

技术型产品经理

技术型产品经理一般内功比较强大,了解开发同学要什么,在功能和前后交互逻辑上甚至比“功能型”和“交互型”更优,但由于是“技术型”属性,在应变能力和选择方案上会较差,一般在软件上比较喜欢Word和Execl,对一个功能如何实现和实现难度比较敏感。

管理型产品经理

管理型产品经理有点像项目管理人员,比较擅长调动资源,做时间管理。但更多拥有这个属性的产品经理都是高级的产品经理,都是通过工作积累慢慢修炼出来的。若初期单纯靠“管理型”这个属性成长比较缓慢。

小结

以上属性类型是基于产品新人在工作过程逐渐认知和感受自己所擅长的属性类型,每个人的属性都是多样的,巨头级产品经理都是多属性顶级,甚至全属性的存在。正确阅读自我,寻找属于自己合适的成长路径,能事半功倍,否则麻木的努力可能会离成功越来越远。

【2001】关于“验证码”的下发机制

今天在使用招商银行的【掌上生活】app时,碰到这样一个情况,某个业务场景,需要输入手机号,填写下发的验证码。或许是网络原因,验证码几分钟没到,作为用户,肯定会多按几次,这是非常正常的操作行为。然而,坑爹的事情发生了,试了两三次,几分钟过去了,在某次请求后,验证码来了,但输入后是错的,大概过了30秒,又来了一条,我再次输入,还是错的。使用返回再进入,又重新获取了一次,来信息了,但还是错的,瞬间心好累。

为什么会出现这个情况?因为他们的验证码下发机制没有考虑到一些特殊场景,例如网络延误,短时间内多次下发的输入等。他们的机制很简单,就是请求一次,生成一个不一样的验证码,需要输入最新的,或许有最大下发次数保护机制,这个是另外的话题,这里不发散说。然而,不知道是哪边服务器的原因,延误的验证码不是连续来,而是隔十几秒来一个,还要让人在当前页面等到最新的验证码进行输入才是正确的,想到就心好累。

这里就引出了一个问题:验证码的下发是否应该使用相同的验证码?

在一定时间内(10-30分钟),向同一个手机号下发相同的验证码会比较好,超过一定时间,下发不同的验证码。这样在短时间内,用户看到多个相同的验证码,不会出现疑虑,对需要输入的验证码非常明确,若短时间内的验证码不同,就会产生“哪个才是我需要输入的?”这个疑问烦恼,可能产生多次输入的试错成本。

那么,如果在迭代需求中,需要描述这个功能,怎么说比较好呢?

用户发起一个验证码请求时,去库里查该账号/ID最近一次下发验证码和下发时间,若在30分钟内,则把该验证码再下发一次,并进行记录(30分钟是否需要重新计时,根据各个业务的情况自行调整,没有标准答案),若是超过30分钟,则重新生成新的验证码进行下发。

小结

虽然只是一个触发验证码的动作,里面也涉及到很多小细节,这里主要是讲述的是验证码多次下发的使用场景。在整个流程当中,其实还涉及什么时候触发下发请求的相关问题,倒计时控制连续下发验证码的时间问题,每个功能都需要多思考,尽可能的严谨和人性化,这些细节不一定能让产品带来飞跃性的成功,但肯定能提高产品的下限。