文章目录[隐藏]
四、产品经理修练之信息结构篇
1、前言:
写这该文章的目的,是想告诉刚接触产品经理的“同学”,当完成产品的商业部分分析后,不要马上就画原型,这只能说明你刚“入行”,我理解的“产品经理”就好比军队的“参谋”,他是实现军队领导意图的主要组织者,是军事工作具体的组织实施与督促检查者。它需要根据现有部队的火力配置、人员情况制定作战计划,虽然两者之间所处的领域不同,但产品经理与“参谋”有许多相似的地方,最终是为了实现战役(商业价值)目标的成功,所以我把我的一些经验整理一下,供大家参考。
2、整体思路:用户体验不能被设计
用户体验的核心不是功能的集合。事实上,用户体验的核心是用户使用该产品做什么,例如Uber的用户体验的核心就是让用户很容易在任何时间打到出租车,可能用户使用产品包括线上及线下流程,在满足用户需求的同时,能实现企业的商业价值。下图是一个描述网页和 app 设计时候谈论用户体验时候可以被分解出来的五个层次,除了用户可以直接看到和操作的裸露在水面之上的 Surface 层(视觉设计),一个好的用户体验需要从深到浅考虑一下四个层面:
1、Skeleton 页面骨架层:每个页面的线框图,基本的交互动效
2、Structure 结构层:用户的工作流,网站或者 app 的操作逻辑;
3、Scope 内容层:产品需求文档及需要展现的内容;
4、 Strategy 策略/商业层:用户和市场研究后得出的商业模式,包括目标用户、场景、赢利模式等;
3、内容层(Scope)
在完成对产品的商业层的分析后,首先应该是对产品所涉及的内容进行筛理,因为不管什么产品,通过APP或网页呈现给用户的是“信息”,信息在数据库里呈现的就是一个“二维表”,而导航的目的应该是能让用户更方便找到“信息”,而对信息操作也是类似,所以我把内容层分为三个阶段:
1、内容定义:把内容分为按核心内容及辅助内容进行分类,形成相应的标签
2、内容操作:用户对内容会如何操作,我整理一个7字口诀“增删改浏查传达”。
3、后续操作: 假设用户找到了他们要找的内容,接下来他们可以做什么、又会做什么呢?,例如引导用户进入产品的增值业务、反馈流的设计。
我定期会分析市面上的一些APP产品,下图是我对一款针对学校“社团”APP内容层的分析,内容层不涉及到任何导航,只是根据内容的重要性进行筛理,同时思考用户获取内容后如何操作及后续操作。
4、结构层(Structure)
在弄清自己移动应用的内容组织情况之后,就可以开始考虑结构层了,可能有人想结构层不就是“导航”吗?这只是其中的一部分,“结构层”的目的是让你的用户能更容易找到“内容”,我称为内部路径,路径的具体实现可以有许多的方法(如标签式导航等,这是在页面骨架层实现的),所以我建议采用GOMS模型,该方法在交互系统中用于分析用户复杂性的建模技术,主要被软件设计用于建立用户行为模型。GOMS模型是一个缩写术语,G代表Goals(目标)--就是商业层的内容、O代表Operations(操作)、M代表Methods(方法)、S代表Selection rules(选择规则)。
1、Goals(目标):就是执行任务最终想要得到信息及“内容层”。
2、Selection rules(选择规则):是用户要遵守的判定规则,以确定在特定环境下所使用的方式。
3、Methods(方法):是通过文字描述如何完成目标的整个过程。
4、Operations(操作):是任务分析到最底层的行为,是用户为了完成任务必须执行的基本动作。(注:在内容层有“内容交互”和“后续操作”就是该部分内容)
4.1 Selection rules(选择规则)
“选择规则”就是中心思想,通过“规则”如何体现核心内容的价值,让用户能快速了解产品是什么、能做什么,并快速上手。以下图给大家提供一个参考
5 页面骨架层(Skeleton)
5.1 导航部分
根据“选择规则”,我会初步整理出一级导航及比较粗的功能模块,另外,还要以信息结构为基础、建立手势交互规范,优先设计自然的手势交互,而不是点击TAB。以下截图供参考
5.2 Methods(方法)
完成一级导航及功能模块整理后,我会筛理相应的页面(这也是后续画原型的产品结构图),每个页面包括什么内容及操作大部分已经在“内容层”进行筛理,这个时候产品经理根据经验、项目情况进行“组合、排版”,包括二级导航、内容页采用卡片式、列表式、图片式等。
最后还要提醒一下各位,产品的“反馈流”部分也在该环节设计,通常产品都是一层一层返回,但对于内容多、信息结构比较复杂的产品,这块就需要好好设计了。
最后
当我按照以下思路完成后,会输出相应的产品原型(供大家进行讨论),对于简单产品会形成相应的PRD。这个时候产品经理工作并还没有完,这个时候要对产品进行“埋点”,埋点本身其实是对于自己所设计产品的一个可视化健康检查,通过逻辑和数据,贯穿产品的整个生命周期,通过产品不断迭代逐步达到最佳状态,这也是互联网产品与传统产品本质的区别,原有的传统模式是先有产品后来开拓市场,而互联网产品是完全相反,但这一切需要数据支撑,这部分我将成后续整理的数据篇进行介绍。
五、产品经理修练之数据篇
1、前言
最近看到几个群里在讨论“产品经理与运营的关系,是否要参与?”等问题,我想借用黎万强的话, “我们做营销策划的同事,全都是产品经理出身,而且一定要是好的产品经理。如果不懂产品,一定做不好营销。所以,到现在我还坚持在一线做产品和设计,就是为了保持‘温度感’。”
其实这个问题很难回答,虽然产品经理在整个产品的生命周期中,不掌握任何实际的权力(除BOSS级产品经理除外),都需要全程参与整个过程,需要对产品的具体工作组织协调与督促检查,让产品按照正确的航线进行下去。就像需要通过 “经纬度”知道船的航行轨迹,产品经理需要掌握“经纬度”,可能我们不是船长,但我们是“舵手”。
2、数据分析思路
2.1 数据核心“场景”和“用户”
传统互联网对产品的数据分析,核心围绕着“用户”,例如从用户质量分为:狂热用户、核心用户、一般用户及边缘用户;从运营角度分为:活跃用户、留存用户、流失用户、回归用户等,移动互联网也不例外。
然而,移动互联网由于“碎片化”等原因,虽然你已经明确是哪一个用户,如果没有场景支撑,用户也不会来的。例如:我如果最近不看电影,我不会去美团;我在公交车站等30分钟,公交车还没有来,我可能会打开“公交大师”查询公交情况。
所以根据我个人的看法,“用户”的指标体系发展多年应该是相当完备了,但“场景”的指标体系还不太完善,至少我还在学习及摸索中,我的初步解决思路就是尽量在产品中体现“场景元素”,这样便于统计。例如:我会让用户做选择商品内容的时候,能接近场景选择核心内容。
2.2运营三步走:获取游客、激活成员、保留用户
在“前言”中谈到“产品与运营的关系”,如果单从产品角度去分析,个人认为价值不大(运营与产品紧密相关),所以我通常会按照运营三步走“获取游客、激活成员、保留用户”进行数据建模,也便于与运营同事进行沟通。
2.2.1 获取游客
先我先声明一下,我通常把“新用户”称为“游客”,我认为这个称呼更为贴切,运营同事根据前期产品经理整理的用户画像及场景,通过各种手段(活动、软文)在各渠道去获取游客来使用产品。
从数据统计角度,首先最基础的是增长事件是什么、增长的渠道(电子市场、官网等),然后这个时候的“游客”,他们对你这个产品什么都不知道,或者他们抱着很高的希望,所以这个时候要遵循“三秒原则”,快速让用户在3秒内了解产品是什么、能做什么,并且快速上手。
对于“游客”来说,会受内容质量及交互友好方便的影响,我们先要通过排除法把交互流程、信息结构影响用户排除,例如:我会统计新用户访问路径数,与我在产品设计过程中规划的路径是否吻合。
我个人观点,产品经理会放入大部分精力在该阶段,主要是解决交互流程及信息结构对使用者的影响,以下我就举一个我前期在网上收集的例子,让大家更好的理解。
以下这个产品中东的数字音乐流app,设计者的用意很好,通过引导及定制让用户找到真正感兴趣的音乐,从而提高用户使用率和活跃度。设计者需要验证“多少人完整走完了三个步骤的引导页”?数据显示,当用户通过第一页,从第二个引导页到第三个引导页的流失率达到15%,后经过分析原因是在中东,用户听歌认脸多于认音乐的类型!。
另外,第一个引导页,也就是Personalize Anghami,并没有什么用。用作者的比喻就是,你要让用户进门去看里面的房间,还非要把门锁上再给他一把钥匙(Personalize那个按钮),说你用钥匙一开门就可以进去看啦!为什么不直接把门打开呢!
2.2.2 激活成员
获取游客就好像“相亲”,在见面之前相互之间不了解对方,通过短时间熟悉后,对双方有一定的好感,这个时候双方之间就会进行“约会”,这个时候需要通过产品让用户从“游客”变为“成员”。
这个阶段采用的手法我称为“激活”,就是让游客做些你事先已经决定,他们应该做的,进一步达到你的目标。这可能是让用户加入一个电子邮件列表、点击广告,或者创建一个帐户,甚至是购买。现在你必须激活游客变为成员,你甚至可以有多个激活,让你更能方便的跟踪,可以通过“埋点”等手段实现。
2.2.3 保留用户
当通过“激活成员”的热恋期后,是解决让“成员”变为真正的“用户”(我称为结婚),说实话把一个“游客”变成“成员”就很难了,把“成员”变成“用户”就更难了。
这个阶段的使用者对产品已经有一个整体的了解,所以交互流程及信息结构可能对用户影响不是特别大,根据我的经验大部分是核心内容能否吸引用户。就像《iOS Human Interface Guidelines》设计基础提到的“以内容为核心,UI能够更好地帮助用户理解内容并与之互动,但却不能分散用户对内容本身的注意力”。所以这就需要运营人员提高产品内容的质量,从而吸引用户。
从数据角度来看,通常有流失用户、留存用户、回归用户数、活跃用户等指标进行分析,但我认为指标都是比较粗的,因为用户许多可能的原因导致用户不想使用该产品,所以这部分我认为应该与具体业务挂钩,在这里我也是一个“学生”也在摸索,不能给大家比较有用的建议。
3、梳理数据点
产品梳理数据点为后续埋点做准备,最理想状态是在产品的每个功能分分支哪里进行“埋点”,但这个工作量太大,我个人也认没有必要。现在虽然第三方统计也提供“自定义事件布点”,但我认为缺乏灵活性,无法层层追查及分析。
通常运维、运营的同事,并不知道哪些节点是具有分析价值的,因此产品经理需要先将要添加数据点的功能和入口梳理出来。我们可以用Mindmanager等软件对产品的主要功能进行拆解。拆解当然是越细越好,需要注意的是,同一个功能模块里边往往包含多个值得记录的点,这时就需要我们先明确好研究的目的,确定到底以哪个点作为分析的基准。
例如:在第4部分的“建立指标体系”的“微观数据”的路径就是我梳理的数据点,这样可以分析出新/老用户通过什么路径达到核心内容,在结合用户在“内容页面”停留时间,大致能推断出来内容与用户兴趣的匹配度。
4、建立指标体系
一个好的指标体系,可以作为数据收集和分析的大纲,可以让我们少走很多弯路。产品经理用思维导图建立这种体系的过程中,可以让我们的思路更清楚,避免遗漏。
需要注意的是,建立指标体系并不是建立标准(标准是人为定义的,要看产品所处的阶段)。所以我把评价体系分为宏观数据和微观数据,以下图供大家参考。
【宏观数据】是指长远的,大的方面,也可以是一个大概的意思,大部分是给领导或运营人员看的。(现在第三方统计都有这个功能,比较容易实现)
【微观数据】比较细的方面,这要看你具体用在什么方面。不同的地方,具体意思不一样的,我通常会分为路径和页面两个角度,可以通过用户使用路径知道问题出在哪里,至于什么原因可以后续在进行详细分析。
5、最后
产品经理修练系列按照计划已经写完了,最初写这个文集的目的是自己整理一个思路,从最初产品只是领导idea,一步步最后实现过程,在写这个文集的时候发现有许多不足及遗漏的地方。写完这个文集,感觉自己对产品经理有更深入的了解,这是需要你不断学习的职位,因为外部环境发展太快,昨天忽然想到,根据自己的经验PC整整经历了20多年的发展才达到普及的阶段,而移动互联网只用了3年左右的时间。
最后我想对自己说,继续向前,不进则退,享受变化带来的一切。
【商业分析部分】缺少:竞品分析、调查问卷、角色分析报告、信息收集、SWOT等部分,
【信息结构部分】遗漏:当通过GOMS分析完成后,确定了大致的页面的范围及页面所包括的内容及操作等信息,但到最后通过axure页面生成还有很大部分缺失(如果要写的话,有可以写一篇文章了,哈哈)
来自简书天天阿凡达
原创文章,作者:Tinadmin,如若转载,请注明出处:https://www.iamue.com/10636/