從來沒有公司像現在這樣收到如此多的使用者反饋。拿手機應用程式來說：我們通過蘋果應用商店獲取資料，通過分析系統得到應用程式內部的運轉狀態，而且特別是通過蘋果應用商店的真實使用者中獲取評論和評級，在這個資料海洋裡隱藏著許多價值連城的資訊。

每天都有成千上萬的使用者在蘋果應用商店評論裡分享他們的想法。他們通過評論表達他們對於應用程式憤怒或者令人激動的地方，這樣做通常是希望能夠促進應用程式的改進。

許多設計和開發團隊利用這些資訊來查詢和修復bug，有些團隊甚至會回覆使用者且和他們的使用者緊密聯絡。然而，他們卻很少用一種結構式的方法來分析應用程式評論。

所以，結構式的這種分析方法在使用者體驗的設計週期中並沒有一席之地，而且他們也不被認為是使用者研究的一部分。

在這篇文章裡，我分享了一個簡單並且有效的方法，通過從成千上萬的應用程式評論中得到可執行的反饋。

首先，我將通過一個案例研究：我的公司， flexponsive，做過一個航空公司的應用程式的評論的分析，那時候我就進行了深入的挖掘並且為設計師和產品所有者，分析他們自己的應用程式列出了易於遵循的步驟。

KLM航空公司的應用程式的案例研究

flexponsive對航空公司的電子商務非常關注，並且我們可以看到許多航空公司因為他們的移動應用程式和移動網站的質量而飽受批評（ mobile website quality）。最近，應用程式的質量開始提高（ app quality is starting to improve）。

當我們看到荷蘭國旗的承運商荷蘭航空公司推出了一個全新的、耗資的，但最終不成功的應用程序升級時，我們決定進行調查研究。

我們發現：該航空公司已經從一個行業的最佳跌到了使用者滿意度排名表的底部！雖然在這個案例研究中。我們分析的是一個寵物專案的評論，但是我們也對使用者使用了這個流程，並且發現它既能有深刻的見解又很有成效。

荷蘭航空公司，以前是航空類應用程式質量最佳，以一個糟糕的結果升級了他們的應用程式。

為了找到KLM的應用程式發生了什麼，我們詳細分析了去年App Store中用英文寫的所有的評論。我們確定了八個最重要的應用程式功能，並根據評論分析了使用者對每個功能的意見。然後，我們在兩個圖上總結出了關於舊的和新的應用程式的使用者意見和使用者評論的頻率的對比。

圖表顯示了舊版本KLM應用程式的主要缺陷，關鍵優勢，其他缺陷和其他優勢。

在圖示中，右邊的位置代表正面評價，例如：“很好使用，而且掃描你的護照是個非常好的選項！！！”頻率軸上的特徵越高，評論中提到的頻率越高。

從圖表中可以很清楚的看出：KLM舊版本應用程式有非常強的設計，45%的使用者提到了外觀或者導航並給與了充分的肯定，還提到了幾個關鍵的特徵——預訂、記錄和航班資訊。

這個應用程式最大的問題是效能問題，超過30%的使用者抱怨關於app的速度和不穩定。從App的評價來看，看起來效能應該是應用更新的重點。

圖表顯示了修改過的KLM應用程式的優勢和缺陷。

不幸的是，根據應用程序升級後的圖表，幾乎所有的功能都變糟糕了。升級後，沒有一個功能被列為強項，儘管效能不再是最大的問題，但我們無法判斷速度和穩定性是否有所提高，或者其他功能是否變糟糕了。

如果設計師們在設計升級之前檢視過這些數百位使用者給出的反饋，他們可能會保留正面的功能，並且專注於提高效能。

分析資料

這個分析可以應用於其他任何應用程式。

以下是進行類似分析的四個簡單步驟：

1. 下載評論

第一步，顯而易見的是下載評論，應用程式的所有者，可以通過他們的開發者賬戶獲得該應用程式的評論。這是一個重要的，容易獲得的，並且不能被過度使用的資訊來源。

評論可以從iTunes商店的部落格訂閱（RSS feed）和谷歌商店（Google Play）非官方的API下載。示例程式碼（sample code）和更多的應用程式評論下載的細節，可以在rpubs部落格（on the rpubs blog.）裡找到。

團隊還可以與競爭對手的應用程式的反饋進行比對，但是要牢記，很大一部分評論是由對新的升級失望的使用者來編寫的。這是非常難做的，而這恰恰是改進我們的應用程式所需要的。

在失敗的升級之後，即便是長期的使用者評級很差，也不意味著負面反饋比競爭對手的應用更糟糕。

2. 確定主要功能

一旦下載了評論，就要準備一份已經確定好了5~8個特徵的應用需求的列表，其中一些將涵蓋行業或應用程式具體的功能（“我想要查到我的航班資訊”）和另外一些關注應用程式易用性的（“應用程式應該快速執行”，“應用程式不應該崩潰”）。

對於每一個主要的分類，我建議在分析過程中分析具體的功能，這樣的好處是清晰可見的。這會使得未來的評估更加容易,而且我們能夠從評論中獲得更多的資訊。

當初步清單列好了，現在就是該閱讀前100篇的評論了，要確保使用者對於列表中出現的功能進行的是真實的評論。然後根據使用者的言論修正清單，新增新的功能以及更新功能的名稱。

根據荷蘭航空應用的案例我們確定了以下功能：

（1）個性化

• 個人資訊

• 儲存就餐或座位的偏好

（2）預定管理

• 航班選擇

• 付款

• 額外服務/特殊要求

• 航班更改

• 座位選擇/座位更換

（3）登機

• QR碼（Quick Response Code 快速響應矩陣碼）

• 登機牌

（4）航班資訊和航班跟蹤

最初，我們把這個功能放在“賬戶管理”中，但是在使用者評論中特別強調了航班資訊，所以我們將他作為一個獨立功能展示出來。

（5）賬戶管理

常用飛行計劃

• 狀態里程

• 網站的相容性

• 預訂記錄

（6）相容性

• 日曆

• Passbook（Passbook是iOS中的一個應用程式，讓使用者可以在手機中儲存商店優惠券、登機證、活動門票、會員卡或其他型別的移動支付票卡等。

• Apple Watch, etc

（7）效能

• 速度

• 穩定

（8）設計

• 導航

• 圖形

一旦清單完成，就要召集一組研究人員開始進行評估。理想情況下，研究人員應該熟悉應用程式，但不涉及開發過程，這樣才不會帶有偏見。

這是一個很長的流程，需要花費很多工時去完成。這使不禁我們產生這樣的疑問：這個流程是否能自動化進行？

因此出現越來越多提供自動化評論分析的服務（包括Appplause和AppAnnie）。這些服務所使用的演算法，只對穩定性或導航之類的通用應用程式特性進行評估。能夠識別應用程式個性特徵的演算法還沒有達到商業化的程度，目前還無法超過人類專家級評估標準的50%。所以，現在我們只能祈禱未來的電腦科學家們能有所突破，並能人工進行評論分析。

3. 建立電子表格

下一步是獲取每一個評論，並把它轉化為數值評級。這有許多方法來完成，但我建議建立一個電子表格來記錄分值。如果一個評論給產品特性給予肯定評價，研究者就應該給該產品特性一個肯定的分值+1。

如果是否定的評價，則給分-1，如果是中立的評價，則給分0。如果沒有提到該產品功能，則空著不填分值。電子表格完成後，隨應用程式版本和時間的推移而產生的意見看法的改變情況，將很容易集中展現出來。

舉個例子，下面的是在iTunes商店找到的荷蘭皇家航空公司 APP的評論。

第一位評論者對最新的改動感到滿意，但她的評論不是很具體。她提到：“座位變更後的正確資訊”，我們不能確定她是指正確的航班資訊還是正確的個人資料。

因此，我們只給包含了座位變更參考的“預定管理”類目部分判定+1分。同樣，基於評論標題裡的“沒有用！！”和“沒有航班”，我們給個性化、預約、登記和設計記下-1分。

找到正確的類目來記錄使用者的看法感受通常並不容易，為了獲得高準確的結果，我們至少有兩位分析師評定一組評論。取其平均值來獲得更高精確度。

4. 視覺化&分析

一旦資料在電子表格中，我們就可以總結出結論，並計算和量化出關鍵的統計資料。為了使資訊更容易解析，這樣有助於將其呈現在圖表中。

該圖表一目瞭然地顯示了需要改進的功能，以及app是否符合或超過預期。如果分析擴大到競爭對手的app，該圖表也可以識別驅動使用者滿意度的特性，這可以作為未來升級的靈感來源。

我建議使用一個二維矩陣，X軸為“情緒”分數，Y軸為在訪問中提到該專案的“頻率”。

為了使分析更具有可操作性，將平面分成四個象限，每個象限以特定的行為對齊。需要注意的是：在rpubs部落格上可以找到像我們的團隊設計一樣建立圖表的程式碼。

• 主要優勢：這些是使用者喜愛的功能，並且經常被提到，同時給與了充分的肯定。 我們應該為這些功能而自豪，維護它們，並且提升它們- -只要它們還能滿足商業目標！

• 其他優勢：這些是得到積極情緒的功能，但頻率較低。值得調查一下這個app的分析，看看這個功能多久被使用一次。如果它的利用率不足，則這是一個促進極好的功能的機會。

• 其他缺陷：這些專案收到的消極情緒，但只有少數。這些評論會有點不尋常- -當用戶得到他們所期望的功能時，他們通常會說出一個隨機功能，並建議它可以進一步改進。

• 關鍵缺陷：這些是問題所在區域，如果一個功能屬於“關鍵缺陷”這個區域，那就意味著幾乎所有寫評論的人都會抱怨它，應該儘快實施改進。

文章來源於: 人人都是產品經理社群，版權歸原作者所有，如有侵權，請聯絡 [email protected] 刪除。

網易有數：企業級大資料視覺化分析平臺，具有全面的安全保障、強大的大資料計算效能、先進的智慧分析、便捷的協作分享等特性，點選可免費試用。

相關文章：
【推薦】 Omad群組部署、依賴部署一鍵解決
【推薦】 MySQL不帶where條件的UPDATE和DELETE限制操作說明
【推薦】 基於Kafka的服務端使用者行為日誌採集