本文目錄結構
一 收集用戶反饋的好處
二 用戶反饋的收集和分類
三 用戶需求的處理
一.收集用戶反饋的好處
? ?作為對線上產品用戶滿意度的了解，收集用戶反饋肯定是重要渠道之一。對于用戶反饋合理的收集并總結有利于了解當前線上產品的不足，了解用戶對線上產品的想法，驗證新功能點對用戶需求把握得準不準確等用途。對于用戶反饋的生命周期，簡單說從用戶反饋的收集、用戶反饋的整理分類（提取關鍵字和用戶主要想表達的想法）、對用戶反饋的分析分類和總結、最后進行相對應的處理的一套閉環流程。
下面我們根據上面的流程對“嗶哩嗶哩”進行用戶反饋的處理。
收集反饋的目的：收集問題，發現新需求，建立與用戶反饋的正向作用，
收集反饋內容類別：
用戶反饋評價的內容大致分為如下幾種：
1.表揚類別：獲得肯定（幾個字或者一段話），對某個新增功能的評價（驗證某個需求功能點是否抓的準）等。
?2.bug類別：對產品中一些bug進行反饋（注意用戶反饋的時間，版本號，驗證是否目前版本還有該bug）
?3.用戶疑問類別:找不到某些已知更新的功能，某些功能怎么使用等（分析用戶疑問類型，是對功能使用，還是某個流程操作存在疑問，來反思是否存在用戶使用成本過高的問題，流程復雜等）。
?4.功能建議類別：用戶希望能添加什么功能，什么功能怎么設計比較好等。
?5.吐槽類別：簡單幾個字，對產品的差評等。
?6運營類問題。
收集渠道：微博，貼吧，豆瓣，各大第三方安卓市場（應用寶、小米應用市場等），app
store（酷傳、七脈數據等）。
二. 用戶反饋收集和分類
下面我們對嗶哩嗶哩的最近30天（ios平臺）的用戶評價進行收集和分類。有效評論為64條，主要出現的關鍵字“ios12閃退”，“2倍速播放在哪里”，“投屏功能”。
通過對反饋的篩選，用戶反饋進行主要的分類發現主要是“bug類別”，“功能建議類別”，“用戶疑問類別”和“吐槽類別”。四個類別。
（稍后更新補充：這里還需要體現數據的比例，什么模塊用戶反饋用量大，用戶吐槽點最多的）。
1.bug類別
? ? 我們可以發現問題主要集中在“ios12的適配”上出現問題，出現很多閃退現象、Iphone max上全屏播放視頻會卡死、手機投屏不好使等現象。可以發現這種bug都是嚴重影響用戶體驗的。
?? 對于bug類別的反饋，我們的處理方式：
? ?首先需要判斷是否是已知bug：
? ? ①對于已知bug，確認是否在將要迭代的版本上已修復。同時如果具備反饋條件（微博、貼吧等）可以給用戶留言評論“已經收到您的反饋，程序猿老鐵正在積極修復中，感謝您的建議”等，促進用戶反饋的作用。用戶反饋越多，對產品的細節打磨越有用途。
? ? ②對于未知bug，判斷問題出現的概率（及是否能夠復現）和嚴重程度及block程度-是否在將要迭代的版本上解決。（主要思想就是已知高概率bug盡快修復，低概率bug內部測試復測，同時通過線下qq群微信群等進行溝通回訪問題產生的條件等）
2.用戶疑問類別：
? ? ?對于用戶疑問類別的反饋，我們發現主要針對的是“二倍速功能”，用戶找不到二倍速功能。我們可以發現在11月11號的版本更新記錄中，已經明顯的添加“二倍速”功能，但是有非常大的比例用戶反饋沒有找到。?我們從官方客服了解到，二倍速是不支持iphone7以下機型的。對于滿懷欣喜看見更新日志而更新的用戶，是否會造成一些誤解。從而出現較多的1星2星差評。同時對于學習者而言還需要考慮，為什么用戶這么喜歡“二倍速”功能，其他倍速不能滿足用戶的需求嗎？二倍速主要會解決什么場景下的用戶需求呢？
? ? 對于用戶疑問類別的問題，我們主要的思路是從用戶角度出發，分析是什么原因造成的用戶用不明白。是否出現讓用戶用不明白的設計，主路徑是否岔路太多等問題。
3.功能的建議類別：
??? 功能建議類反饋，一般都是用戶從自身出發的期望性需求。我們需要從用戶使用場景出發，明確需求的目的，是否需要開發和開發優先級別。
? 這里面的反饋主要是增加“2倍速”（對于老機型），畫中畫功能（pad端），增加字體大小調節功能。?
? 用戶提出的建議類別反饋往往是從自身出發，提出的觀點和行為。我們需要具體分析用戶在什么樣的場景下遇到什么樣子的問題，希望通過什么樣的方法解決。提煉出用戶的目的和背后的動機。從而設計出與之匹配的產品功能。
? ?對于功能類別的建議還需要思考：當前存在哪些問題-導入這個需求之后會達到什么樣子效果，對現有狀態有什么影響-判斷功能的使用場景及使用頻率-導入這個需求是否增加成本，現有功能元素點是否能滿足等。
舉例：
當前存在的問題：字體太小，希望增加字體大小調節功能
對現有現狀的影響：可能會影響界面的布局效果
用戶使用場景及使用頻率：需要了解用戶對“彈幕”字體可以調節還是app里面的文字需要調節。了解后才能判斷使用場景。
現有元素是否支持：不支持，調節系統字體大小，應用字體不會改變。
優先級：低。
4.表揚類別：
? ? 對于表揚類別，我們可以觀察到用戶對新增功能的肯定，對一些設計的肯定。可以從用戶反饋角度驗證，需求抓的準不準，符不符合預期期望等。
? ? 例如5.31版本上線的彈幕防擋臉功能
三．用戶需求的處理
? ? ?對于分類總結后的用戶反饋，我們需要做進一步的處理。Bug類別的我們需要輸出buglist，并拉通測試研發人員處理。這里我們重點對功能建議類問題和用戶疑問類問題和吐槽問題進行處理。通過分析用戶對功能的建議和觀點，以及對用戶疑問項的梳理。分析用戶使用路徑（誰，在什么情境下，做了什么操作）、總結現在出現的問題、以及現在解決問題的方法以便從用戶需求中提取出產品需求。
? ? 首先我們需了解目前的版本迭代的方向和重點，了解當前階段的“產品目標”，這樣以便我們知道在當前階段什么樣的功能上線比較重要，什么需求優先級比較高，避免上線的功能對某些主線重點迭代功能的數據造成影響。同時不至于在開發資源有限的情況下，做胡子眉毛一把抓的決定。
通過我們對全年（2018年）的嗶哩嗶哩的版本迭代分析總結發現，
①頻道方面:（5.27/5.34版本中有迭代優化操作）
②動態方面：（5.19.3/5.25/5.26/5.27/5.31版本中有迭代優化操作）
③視頻的播放方面（二倍速、投屏等）：（5.19.3/5.25/5.27/5.34版本中有迭代優化操作）
④彈幕的體驗優化方面：（5.22/5.31/5.31.2版本中有迭代優化操作）
⑤手機投稿方面：（5.28/5.29/5.33/5.34版本中有迭代優化操作）
?? 綜上通過對功能的更新迭代次數以及迭代目的（提高用戶基礎體驗，改善用戶生產內容體驗等方面）的總結，我們發現其目前的重點優化方面還是在“頻道”“動態”兩個模塊上。細節的打磨上“視頻的播放方面（二倍速、投屏等）”、彈幕的體驗優化方面、手機投稿方面為重點。所以與之相關的需求優先級先對都較高。
? ? 同時根據時間上我們發現目前（12月9日）距離上次的版本更新（11月11日）有一個月的時間。在5.34版本上重點對“頻道”主線功能上有優化，可見這部分的功能相關的用戶反饋級別比較高，需要重點關注。
1.??對用戶反饋的整理：
這里我們需要利用“金字塔模型”思考，沿著用戶任務的閉環路徑走一遍，起點由具體的場景出發，后面一系列的動機，終點指向問題的完結（解決方案）。
2.總結歸納產品需求
?? 對于用戶反饋的觀點和行為分析，需要總結出其目標和動機后來制定我們對應的產品功能來解決用戶的問題。因為篇幅問題我們就不展開了，我們得到下面8個產品需求。
3.產品需求處理流程
? ? ?通過上面的流程，我們把還沒有在需求池內的需求進行需求優先級的排序。
4根據影響面確定用戶需求的優先級
? 我們需要根據影響面因素對各個功能進行優先級的評定，最后綜合出一個與功能相匹配的優先級別。
① 用戶量和發生頻率
? ?登錄帳號的發生頻率比較高，“記住上次登錄帳號”，“記住上次登錄帳號形式”可以降低用戶的登錄門檻，可以方便用戶體驗更好的登錄模式。發生頻率和用戶量都比較大，見效也比較快。對于“緩存關鍵字搜索功能”發生頻率比較高，很對用戶都會選擇緩存喜愛的視頻，在沒有wifi的情況下查看，所以關鍵字搜索功能可以更加便捷的方便用戶查看緩存，贏得更好的口碑。
②開發難度和效果
? 從開發難度上來講，因為需要考慮功能的閉環和流程的閉環兩點。對于“短信登錄登錄、第三登錄”來說還需要增加綁定手機號的功能，第三方快捷登錄與帳號的綁定功能，流程上還有同一個手機號和三方帳號綁定唯一的流程判斷等。所以其開發難度最高。
③看產品價值
? ?迫切程度：記住上次登錄帳號>記住上次登錄帳號形式>緩存關鍵字搜索>hd版本投稿功能>倍速滑動選擇功能>字體大小調節>短信登錄，第三方快捷登錄
優先級排序：
5.總結錄入需求池:
