提交需求
賽事與廣告咨詢合作,請填寫需求表單,我們會在第一時間與您聯系!
這是一個已經很成熟的金融產品,且擁有龐大的用戶群體。該產品在10.0版本升級之后,要進行下一步迭代升級?!?strong>如何確定下一步迭代方向?如何解決現在存在的問題?】以此展開探索。
10.0版本更新思路及內容:http://www.1628yb.com/detail/619950.html?nopop=1
------------------------步驟1:確定產品問題及迭代方向------------------------
用戶反饋是收集問題重要來源,收集的渠道也多種多樣,此次用戶反饋收集渠道主要有:
1、公開渠道:app store、各應用商店用戶反饋信息。(https://app.diandian.com)
2、半公開渠道:千人體驗群
3、內部渠道:平臺用戶反饋、用戶投訴、客服咨詢
在問題收集過程中將多個角度的評論,進行拆分,所反饋的信息以便利貼的形式呈現。
歸類的目的:整理用戶反饋問題的方向及潛在機會點的挖掘
用戶意見收集為避免用戶提出問題的局限性,一般不會直接采用單個或多個用戶反饋,而是形成一定的比例,對產品現有問題的一個初步了解。
聚焦問題只是找到了問題方向,但缺少環境因素,還需要通過訪談對問題進一步驗證。圍繞著【什么人? 什么時間? 什么樣的目的? 做什么樣操作?得到了什么反饋?造成什么樣的感受?】為中心展開訪談。結合用戶的具體特征及使用場景,挖掘這些問題的根本原因,客觀的對問題進一步收斂和更深入的洞察。
聚焦的目的:為避免對單一反饋的局限性,從整體對現在產品的一個了解。并且聚焦的問題可以形成主題,為之后的訪談找到方向。
用戶訪談的目的:驗證已經得到的問題,并進一步發現新的問題。
整理用戶在具體使用情境下的痛點,并從多個維度確認此次需要解決的問題。并進行分析這些問題存在的根因。比如
此次問題聚焦時發現很多用戶的指向是每個功能都很重要,未做等級區分,所以造一級內容的堆積,解決思路是按照用戶對功能和內容的理解重新梳理信息架構,重新設計導航系統。
尋找根因目的:驗證已經得到的問題,尋找存在的根因,并尋找解決方法。
10.0版本迭代: 基于當前的開發模式及周期限制,在原有的基礎上進行調整。成本低、見效快,但隱藏問題依然存在。
11.0版本迭代: 時間周期長、可以把產品現有問題進行展開,重新進行邏輯梳理,適合大版本迭代。
根據時間及排期規劃,選擇適當的解決思路及方法。
--------------------步驟2:對本品和競品分析,確認原始卡片--------------------
對本品及競品的信息架構進行梳理,總結出共性及差異性,用來分析產品的優勢及劣勢,為產品功能及用戶體驗設計提供參考。
做產品規劃時,通過分析競品,可以學習對手的優勢、避免對方的短板。也可以查閱在同樣痛點的前提下,競品是提供的是怎樣的解決思路,拓寬自己產品思考維度。
對層級模塊拆解,分析產品結構及框架層的差異。梳理本品,可以分析產品潛在的問題及痛點;梳理競品,可以分析競品在面對同樣的產品痛點時,是怎樣的解決思路?
梳理本品的過程中,對本品有更清晰及準確的認知,把用戶的反饋進行可視化。帶著同樣的問題梳理競品,探索競爭品的解決思路。例如:梳理本品后,發現一級tab列表下的內容有較多的重復性。 梳理競品時,發現一級列表下盡量避免內容的重復。
通過多維度分析,對現有功能模塊進行整合及篩選,此流程由產品經理參與決定。
主要維度由數據埋點及競品分析決定。如數據不理想、競品均沒有此模塊且無其他維度優勢,對此模塊進行層級弱化。
可設多個篩選維度,進行多角度分析:例如埋點、競品分析結果、行業背景、自身產品優勢等…
重新定義卡片,卡片顆粒度根據本次迭代目的決定。此流程由產品經理與部門經理共同參與決定。
--------------------步驟3:卡片分類確定初步框架--------------------
對信息架構分類這里采用的是開放式卡片分類。
卡片式分類能夠提供非常精確、顆粒度非常細的數據結果。參與對象源于現人群包,且符合此次版本升級的主旨。(結合本次主要優化內容及競品分析定義產品模塊的顆粒度,進行卡片分類。)
參與對象主要分為兩類:偏股票投資和偏基金投資。偏股票投資用戶是現在人群包占比最多,而偏基金投資用戶是產品規劃希望能吸引更多的基金用戶,這兩種對象對調研都非常重要。
通過這種一對一的訪談和意見整理以及推理過程記錄,可以得到很多附加的有用信息,因為卡片分類整理結果只是一個固定的結果,被調研對象在整理卡片時,心理模型可能和最終結果并不完全一致,如果不進行這種追蹤記錄,可能就會錯失很多有用的輔助信息。
根據測試用戶分類的結果對原始卡片進行匯總,就形成了產品基礎框架的初步歸類,即初步信息架構。
對于暫無異議的模塊,進行收納,對存在異議的模塊,后期的過程中需進一步的驗證。
(該步驟由部門領導及產品經理共同商議決定)
--------------------步驟4:可用性測試確定最終流程--------------------
通過可用性測試結合本品桌面背景及競品分析,確認最終架構。通過可用性測試進行決定,為避免理解誤差,會結合低保真原型。此過程由部門經理、產品經理、等人員共同討論,并作為重要確認節點。
提供出幾個方案,及該方案的的依據。
通過可用性測試結合本品桌面背景及競品分析,確認最終架構。通過可用性測試進行決定,為避免理解誤差,會結合低保真原型。此過程由部門經理、產品經理、等人員共同討論,并作為重要確認節點。
Powered by Froala Editor
大牛,別默默的看了,快登錄幫我點評一下吧!:)
登錄 立即注冊