文章目录[隐藏]
四、产品经理修练之信息结构篇
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页面生成还有很大部分缺失（如果要写的话，有可以写一篇文章了，哈哈）
来自简书天天阿凡达
