---迭代说明：助教大大眼力真好，反馈意见确实没够30条，已补充完成。用户反馈的原因分析以及行动计划补充完成。
1.用户反馈收集
[图片上传失败...(image-e7d0cd-1512918738290)]
2.用户反馈分类
2.1性能类
2.1.1问题：APP耗电量大，使用中会卡；
原因分析：
软件功能庞大，体积臃肿，运行耗费资源多。
行动计划：
提炼核心功能，针对跑步记录的需求，开发微信小程序。完整的产品体验放在APP，单纯记录运动的功能由微信小程序提供。
另外，关于小程序的开发成本问题，后端代码及数据是与APP共用的（用户资料，用户数据，功能代码接口）；小程序主要是前端界面，把跑步模块单独拿出来，故此，难点在于如何定义何为跑步模块的核心功能。个人的理解，跑步模块起码要做到，记录运动数据（GPS位置移动，跑步时间），分享跑步结果，这是一种方案。
方案2：做群应用。把跑步打卡以群应用的形式实现，借助微信的社交关系链，转移用户因打开APP相对麻烦的困扰。说白了，以炫耀的驱动力覆盖掉打开APP的麻烦感。
2.2功能类
2.2.1问题：数据收集不够完整准确；
a）步数统计不准确；
b）跑步，走路，分开统计，而用户有时候是处于混合运动状态的；
c）手环/智能手表 等设备的数据收集不准确；
原因分析：
对于运动状态的判断过于单一；
由于各种设备的标准差异化较大，造成数据统计上准确度下降或不稳定；
行动计划：
运动状态（跑步/走路）以用户初始设置为初始值，根据速度变化来做切换；调优：根据用户的历史记录，逐步完善通过速度判断该用户运动状态的准确率。例如，在运动结束后，针对运动状态的统计，预留一个小入口进行意见反馈，收集用户对此功能准确度的评价。通过算法以及每次用户运动后的反馈，进行调优。
根据数据统计，筛选出用户中使用的智能设备占比较高的品牌以及型号，做有针对性的优化；
根据市面上移动设备数据传输的解决方案，做优化。
2.2.2问题：专业内容提供需要优化
a）对于特殊人群的运动需求，照顾不足；
b）根据用户的身体参数（身高/体重/年龄）匹配运动建议；
c）跑前跑后的热身运动支持不足；
d）跑步结果统计的指标单一；
原因分析：
产品早期，目的是为了保证业务流程的完整性，很多优化的地方暂时模糊掉。
行动计划：
a）挖掘特殊人群的运动需求，例如老人，小孩或生理期女性，做差异化的内容，以弱入口的方式呈现；
b）通过用户运营的手段，收集用户的身体参数，继而给出运动建议以及对应的运动计划。
c）当用户点击“GO”开始跑步，弹出提示，询问用户是否需要跳过热身，默认为可跳过。若不跳过，则进入5-10分钟的热身运动视频。当用户点击“结束运动”后，默认进入5-10分钟的拉伸放松视频，用户可以选择结束（结束的提示比较隐蔽）。理由：用户有较大的几率是自己完成了热身运动，而小概率是点击结束运动前完成拉伸放松。此功能有利于让用户建立正确的运动保健意识。
d）新增数据指标的统计维度，包括速度，距离，最大海拔，上下坡度，心率变化，配速变化；以及各种指标对应的标准，例如专业运动员/业余高手/业余进阶/入门级的数据，以作参考。标准数值的查看，可以做成弱入口的方式，理由是，有这种需求的用户，会愿意花时间去寻找，而大部分用户是不需要知道的。
2.3用户体验类
2.3.1问题：对于运动状态的判定支持不足；
a）建议增加显示“暂停时间”。默认是开启“自动暂停”的。
b）希望进一步改进训练计划中的间歇跑数据统计和语音播报。
c）很专业，我在偷懒，他好像看到似的，叫我努力，
d）咕咚内容太泛，什么都想兼容，反而什么都搞不好。
原因分析：
产品早期，目的是为了保证流程完整性，即完整记录跑步过程。而对于跑步中的提醒，跑步中的激励等需求，属于超预期需求。可逐步优化。
行动计划****：
参考2.2的方案，通过精细化的数据收集，判断用户的运动状态。优化语音提示，当用户刚开始跑步的时候，可以用较舒缓的语音提示方式，把关键数据（已跑时间，跑步配速）播报即可。当用户跑步超过半程或（3KM）后，可以改为鼓励性的语句，添加“继续加油”，“坚持就是胜利”等；另外，可以提供特色语音提示，例如明星配音，方言配音，作为增值服务提供给用户。
