产品经理在文档、数据、工具的常规知识

                                                KEVIN在工作之余，也在学习关于产品的一些软硬件技能。让自己时刻保持在一个不松懈的状态，作为各位产品朋友来说，你们呢？会不会太忙，没时间学习啦？

数据报表与交互设计中的问题
产品数据分析的一些特殊报表
一款产品的数据报表不少产品朋友用的是友盟或者自己家的平台（BAT），这里KEVIN主要分享一下关于数据报表中比较特殊的报表形式，在平常大家常用的：柱形图、扇形图等，还有什么？
特殊之一：桑基图

桑基图
主要是表现的每个页面到达页面的情况，以流线的方式表明用户在页面之间的路径。可以看到用户进入页面主要的流动情况。
特殊之二：关于常见的折线图

折线图的数量多少问题也是困扰PM数据分析的一个难点，到底要多少条折线图才能尽可能直观表现想要展现的趋势和结果？
采取大量PM经验后，每组数据建议最多不超过5个点；数据常表现趋势，波动。
在这个基础下能够良好的展现一些数据的情况，并且可以结合漏斗图进行优化。对于漏斗图是怎么样的？可以参考页面优化案例（实战）里面可以针对如何利用数据进行漏斗设计来进行产品优化的案例。
交互设计的落地思考常识
昨天KEVIN分享了一篇关于交互设计的科普，没想到转发的朋友量还是比较多。可以知道目前大众对产品经理与交互的工作内容分界还是比较模糊的。那么今天再分享一下关于交互的一些落地常识。

APP页面的基本布局
那么对于一个交互设计，需要通过在需求分享中获取用户的核心内容，在整个内容区域里面，因为用户是从左到右，从上到下的关注度逐渐降低。合适的将相应的核心内容或按钮放在相应的关注度高的地方。区分内容区的不同关注级别。
通讯产品中消息列表的产品设计常规
既然说一些产品经理工作的常规，KEVIN就先以通讯产品的常规为例，来进行罗列。
首先在通讯产品中，最重要的是消息列表，消息列表的设计原则到底有什么基本的共同点？
[ol]

即时性（快速获取，阅读以及处理）

避免产生骚扰（避免消息过于频繁给用户带来骚扰）

私密性（防止信息泄露）
[/ol]
以上是KEVIN整理后的3点。这就是消息列表中的3大点。最具代表作品的就是微信啦。
微信在红包的功能中，在消息列表是允许看到转账或红包的数额的，这就是私密性；另外消息列表的红点提示，就是让用户能够马上知道相关的消息变化，这也就是即时性；最后微信消息列表可以屏蔽或静音，防止对用户的骚扰。
另外在通讯产品，更应该考虑的是：
[ol]

有独立消息主tab（使用软件的核心流程）

消息的获取，以即时性为最高要求，越快越好

消息组织类型为以通信对象为单位，内部包含行为信息（@，红包、语音、小视频）

系统通知消息优先级低于用户消息

用户敏感信息进行保护处理
[/ol]
产品工具中的卡顿常规知识
对于PM最常用的就是AXURE等工具，那么在AXURE工具中，如何避免在大量的原型完成后，出现卡顿的问题呢？这里KEVIN收集了以下的解决办法，可以有效的帮助解决卡顿问题
1. 在Axure 单个页面内不要有太多的 Group，尤其是嵌套的 Group，有次设计师在 Axure7 中的一个页面打开和操作都巨慢无比，打开文件要花5分钟，操作就假死三分钟，经过排查发现就是因为一个模块中适用的 Group 太多了，而且是嵌套 Group过多导致，耐着性子 Ungroup 后操作慢的问题得以解决。
2. Axure 中高清大图不要太多，大图太吃内存，尤其单个页面不要太多，如果真的需要放很多高清大图

建议一：分散在不同页面

建议二：对图片进行预先压缩，让图片大小减小。因为太多大图会导致最后生成时候内存报错

3. Axure 中中继器的使用注意复杂度，虽然它的功能是提升效率利器，但是单个页面内太多且复杂的使用Repeat 功能，也会让页面变的很慢，容易出错。
产品经理在文档的常规知识
文档的分类
文档分为：PRD、MRD、技术专业文档
1、PRD
须了解各个产品的使用，很多时候PRD不仅仅是一个产品的文档，更多的是一个更新项，或者一个模块、甚至最新的一个交互或UI效果，都是需要文档来说明。
PRD的意义不仅仅是给予开发，还是PM用来作为留底，并且可以作为及时更新的功能模块，最后文档也是用来时刻与开发作为验证的证据。
很多时候，PM在除了版本更新以外，在其他模块或者小功能增加的时候没有文档，其实KEVIN的习惯是每次都有文档的更新。
这样的好处有3点：

需要出UI的话，UI能够很快知道你的原型相关的描述。

测试能够通过文档更快的了解具体的功能是什么

最后可以在开发后，发现没有做到自己期望的样子，可以说“我文档是这么写的”

2、MRD
其实MRD的形式有很多，有PPT、EXCEL、WORD，但KEVIN还是以公司的具体需求，比如这个MRD是用来给予客户或者BOSS看的，那么这个时候PPT的形式，会更有说服力。
如果这个MRD是用来给予对方审核或保底的，那么EXCEL或WORD的形式会更加适合。
MRD在产品上线前是比较常用的，能够让公司的内部员工或者客户或投资伙伴知道目前产品的定位和并且能够知道相关的市场情况。
3、技术申请
以申请当地政府创新指标、或者申请国家技术创新奖等等，都需要文档。那么作为某一个产品负责的PM就需要来写相关的文档材料。这个因不同的奖项申请有不同的表格形式，因此这个KEVIN认为就是仁者见仁，智者见智了。
文档中的一些小TIPS
在产品文档中，KEVIN比较习惯的方式以WORD 标题1、标题2、标题3….等等来进行区分，将功能的方式，来进行梳理。当然有流程图的，就不仅仅用文字了。
可以用以功能划分大板块，大板块标题醒目；把大板块简单拆分，并用小标题区分；用小序号罗列观点，不要写成一大段。
统一关键词，注意那些是全局的、那些是局部的。全局的内容，KEVIN习惯是以单独的标题或大纲来进行罗列，方便测试进行校对
某一项需求功能进行描述，描述清楚功能的使用者、使用场景、使用动作与步骤、使用结果。
如：登录需求：该需求满足了用户在未登录的情况下，触发相关条件，输入用户id及密码即可完成用户登录。
文档中的交互效果，可以通过交互结果的形式来描写。例如视频上传按钮默认为橙色，鼠标划过时变为橙黄色，鼠标点下时变为橙红色；再或者搜索框默认显示灰色文字“请输入关键词”，获取焦点后，提示文字消失，输入的文字为黑色。

PRD文档大纲
PRD的需求类型分类

产品性能需求

测试环境需求

产品数据统计需求

安全性需求

产品兼容性需求

其中，性能需求可以是指的是目前APP的相应速度、打开相应的按钮的速度。
测试环境可以如词意来表示ANDRIOD和IOS。
产品数据统计需求可以指的是埋点、PV、CPC等。
安全性需求指的是产品逻辑中是否有短信验证，或短信验证的方式是什么？是语音提示还是什么？
产品兼容性需求指的是在安卓版本比较多，安卓的版本层次不齐在国内，因此需要支持多少的安卓版本，另外IOS是否要支持最新的IOS等等。