這是一個已經很成熟的金融產品，且擁有龐大的用戶群體。該產品在10.0版本升級之后，要進行下一步迭代升級?！?strong>如何確定下一步迭代方向？如何解決現在存在的問題？】以此展開探索。

10.0版本更新思路及內容：http://www.1628yb.com/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