这是一个已经很成熟的金融产品，且拥有庞大的用户群体。该产品在10.0版本升级之后，要进行下一步迭代升级。【如何确定下一步迭代方向？如何解决现在存在的问题？】以此展开探索。

10.0版本更新思路及内容：https://www.ui.cn/detail/619950.html?nopop=1

------------------------步骤1：确定产品问题及迭代方向------------------------

1.1：问题收集

用户反馈是收集问题重要来源，收集的渠道也多种多样，此次用户反馈收集渠道主要有：

1、公开渠道：app store、各应用商店用户反馈信息。（https://app.diandian.com）

2、半公开渠道：千人体验群

3、内部渠道：平台用户反馈、用户投诉、客服咨询

在问题收集过程中将多个角度的评论，进行拆分，所反馈的信息以便利贴的形式呈现。

归类的目的：整理用户反馈问题的方向及潜在机会点的挖掘

1.2：用户访谈

用户意见收集为避免用户提出问题的局限性，一般不会直接采用单个或多个用户反馈，而是形成一定的比例，对产品现有问题的一个初步了解。

聚焦问题只是找到了问题方向，但缺少环境因素，还需要通过访谈对问题进一步验证。围绕着【什么人？ 什么时间？  什么样的目的？ 做什么样操作？得到了什么反馈？造成什么样的感受？】为中心展开访谈。结合用户的具体特征及使用场景，挖掘这些问题的根本原因，客观的对问题进一步收敛和更深入的洞察。

聚焦的目的：为避免对单一反馈的局限性，从整体对现在产品的一个了解。并且聚焦的问题可以形成主题，为之后的访谈找到方向。

用户访谈的目的：验证已经得到的问题，并进一步发现新的问题。

1.3：规整访谈寻找根因

整理用户在具体使用情境下的痛点，并从多个维度确认此次需要解决的问题。并进行分析这些问题存在的根因。比如

此次问题聚焦时发现很多用户的指向是每个功能都很重要，未做等级区分，所以造一级内容的堆积，解决思路是按照用户对功能和内容的理解重新梳理信息架构，重新设计导航系统。

寻找根因目的：验证已经得到的问题，寻找存在的根因，并寻找解决方法。

★明确迭代方向-迭代总结

10.0版本迭代: 基于当前的开发模式及周期限制，在原有的基础上进行调整。成本低、见效快，但隐藏问题依然存在。

11.0版本迭代: 时间周期长、可以把产品现有问题进行展开，重新进行逻辑梳理，适合大版本迭代。

根据时间及排期规划，选择适当的解决思路及方法。

--------------------步骤2：对本品和竞品分析，确认原始卡片--------------------

2.1：对产品架构进行梳理

对本品及竞品的信息架构进行梳理，总结出共性及差异性，用来分析产品的优势及劣势，为产品功能及用户体验设计提供参考。

做产品规划时，通过分析竞品，可以学习对手的优势、避免对方的短板。也可以查阅在同样痛点的前提下，竞品是提供的是怎样的解决思路，拓宽自己产品思考维度。

2.2：对竞品功能模块进行分析

对层级模块拆解，分析产品结构及框架层的差异。梳理本品，可以分析产品潜在的问题及痛点；梳理竞品，可以分析竞品在面对同样的产品痛点时，是怎样的解决思路？

梳理本品的过程中，对本品有更清晰及准确的认知，把用户的反馈进行可视化。带着同样的问题梳理竞品，探索竞争品的解决思路。例如：梳理本品后，发现一级tab列表下的内容有较多的重复性。 梳理竞品时，发现一级列表下尽量避免内容的重复。

2.3 多维度确认最终卡片

通过多维度分析，对现有功能模块进行整合及筛选，此流程由产品经理参与决定。

主要维度由数据埋点及竞品分析决定。如数据不理想、竞品均没有此模块且无其他维度优势，对此模块进行层级弱化。

可设多个筛选维度，进行多角度分析：例如埋点、竞品分析结果、行业背景、自身产品优势等…

★ 原始卡片确认

重新定义卡片，卡片颗粒度根据本次迭代目的决定。此流程由产品经理与部门经理共同参与决定。

--------------------步骤3：卡片分类确定初步框架--------------------

3.1 对产品进行信息架构梳理

对信息架构分类这里采用的是开放式卡片分类。

卡片式分类能够提供非常精确、颗粒度非常细的数据结果。参与对象源于现人群包，且符合此次版本升级的主旨。（结合本次主要优化内容及竞品分析定义产品模块的颗粒度，进行卡片分类。）

参与对象主要分为两类：偏股票投资和偏基金投资。偏股票投资用户是现在人群包占比最多，而偏基金投资用户是产品规划希望能吸引更多的基金用户，这两种对象对调研都非常重要。

3.2 对访谈结果进行整理

通过这种一对一的访谈和意见整理以及推理过程记录，可以得到很多附加的有用信息，因为卡片分类整理结果只是一个固定的结果，被调研对象在整理卡片时，心理模型可能和最终结果并不完全一致，如果不进行这种追踪记录，可能就会错失很多有用的辅助信息。

3.3 对产品进行信息架构梳理

根据测试用户分类的结果对原始卡片进行汇总，就形成了产品基础框架的初步归类，即初步信息架构。

对于暂无异议的模块，进行收纳，对存在异议的模块，后期的过程中需进一步的验证。

（该步骤由部门领导及产品经理共同商议决定）

--------------------步骤4：可用性测试确定最终流程--------------------

3.4 给出可行性方案

通过可用性测试结合本品桌面背景及竞品分析，确认最终架构。通过可用性测试进行决定，为避免理解误差，会结合低保真原型。此过程由部门经理、产品经理、等人员共同讨论，并作为重要确认节点。

提供出几个方案，及该方案的的依据。

3.5 对各方案进行对比分析

通过可用性测试结合本品桌面背景及竞品分析，确认最终架构。通过可用性测试进行决定，为避免理解误差，会结合低保真原型。此过程由部门经理、产品经理、等人员共同讨论，并作为重要确认节点。

Powered by Froala Editor