第二次作業需求分析
以下是正文:
1 項目概述
1.1 引言
隨著共享經濟的不斷滲透到生活的各個層面,如共享單車、共享籃球、共享雨傘等,再度引發了一次資本熱潮;而針對不用出行方式,現在都市年輕人的出行主要以共享單車為主,因為自由度高,價格合理,能很便捷的解決都市人的最後1公里出行問題;所以摩拜的每次迭代需求都有特別重要的意義;
第一次作業的競品分析分別從用戶體驗、功能和交互、運營等層面對摩拜進行了下一個版本的迭代設想。本文在競品分析結論及有限地用戶調研的指導下完成,本需求分析報告主要是對摩拜下一版本迭代需求進行分析,對需求細節和實現方式進行了較為詳細的闡述。由於市場環境的易變性以及用戶本身對於需求描述的模糊性,需求往往很難做到一步到位需求分析不僅僅是屬於軟體開發生命周期早期的一項工作,而且還應該貫穿於整個生命周期中,它應該隨著項目的深入而不斷地變化。
此次摩拜的迭代不但為了提高摩拜良好的用戶體驗,還要不斷吸引新用戶,從而提高新老用戶的黏度和活躍度;
此外,為了方便後續的評審和測試等工作,需求的描述應該盡量做到:具體、詳細、可以測量和可以實現,並且基於時間。
1.2 需求的來源、背景及意義
隨著ofo、永安行、小藍單車各種優惠運營策略的不斷衝擊,目前共享單車的競爭市場依然激烈;此時摩拜急需找到一個更好的技術和運營策略去實現「以最低成本去完成讓用戶可以更好的去體驗騎行快樂」的目標,怎樣才能留住老用戶,吸引新用戶成為了摩拜最主要的任務之一;
基於競品分析中與ofo押金層面的對比,我們得出目前摩拜的高押金可能是阻礙其進一步發展新用戶的可能性之一;同時,我們通過對用戶的問卷調查,得出摩拜的功能在用戶體驗、功能與交互、運營層面還有很多痛點(經過用戶調研和競品分析,共產生27個需求),如圖所示:
基於以上27個需求,小組每個成員對所有需求進行打分,優先順序從P0到P5進行排序,高亮顯示優先順序較高的需求。下面分別對選出的11個需求進行分析與梳理。
(1)騎行體驗發表
a) 任務描述
加入騎行體驗發表環節,用戶掃碼後可顯示車輛騎行體驗。用戶A在完成騎行後可對該次騎行發表體驗(包括車輛硬體完整性、舒適性及其他);用戶B掃描車輛二維碼後,可查看用戶A對該車的評價。
b) 真偽需求分析
此需求是通過用戶調研得出的結論。借鑒滴滴出行的評價系統,思考出騎行體驗發表的需求。但是考慮車輛的同質性和用戶填寫騎行體驗的積極性,特別在掃碼用車的場景中,用戶並不會去關注騎行體驗,而以車輛能掃碼騎行為主。特別地,當用戶騎行完成之後,不會再打開APP專門對騎行體驗進行發表。因此分析本需求應該是偽需求。
(2)「已預約」標記和「故障」標記
a) 任務描述
將地圖上已被預約和故障的車輛給以特殊標記,方便用戶找車時同空閑車輛區分
b) 真偽需求分析
此需求是通過用戶調研得出的結論。用戶在掃碼用車過程中,經常出現「該車輛已預約,請換一輛車吧」的提醒。「已預約」標記涉及到產品易用性,同時用戶使用場景較為廣泛,此種情形出現次數較多。因此分析本需求應為優先度較高的真需求。
(3)客服快速轉接
a) 任務描述
增加24小時在線客服,方便用戶投訴和建議。將「個人中心>設置>關於我們>聯繫電話」的「聯繫電話」上升到較高結構層面,同時設置點擊「聯繫電話」後彈出撥號確認窗口,用戶點擊確認後進入撥號狀態。
b) 真偽需求分析
此需求是通過用戶調研得出的結論。當用戶在對用車扣費、退還押金、信用積分扣除等問題有疑惑需要致電客服時,在APP上很難找到客服;客服頁面層級較深,不利於用戶的反饋。如果客服無法快速轉接,將對用戶心理產生影響。雖然僅僅在有限場景中會使用客服,但是客服快速轉接卻是必須的。因此思考該需求為優先順序較高的真需求。
(4)「忘記關鎖」提示
a) 任務描述
增加「忘記關鎖」提醒,提醒用戶是否忘記關鎖。
b) 真偽需求分析
此需求是通過用戶調研得出的結論。用戶在用車過程中,可能出現忘記關鎖的現象,因此造成的誤扣費將給用戶和公司帶來極大不便。在這種情況下,「忘記關鎖」提醒就顯得尤為重要。因此考慮,本需求應為優先順序較高的真需求。
(5)違停換停功能
a) 任務描述
增加違停換停功能,給予用戶違停提醒,並建議用戶換停。用戶發生違停後,立即發送如「您現在停車地段為違停區域」,給以用戶重新開鎖許可權,2分鐘內換停成功不另計費。
b) 真偽需求分析
此需求是通過用戶調研得出的結論。摩拜信用積分的扣除選項之一就是違停,當用戶不知道該區域是否違停時,由APP給出提醒是必須的選擇。因此此需求為優先度較高的真需求。但是由於違停區域的劃分需要和政府部門協商,且技術上GPS的精度可能不夠,因此本次迭代並未考慮本需求點。
(6)導航與路況提醒
a) 任務描述
加入導航功能和語音提醒,智能提供便捷路徑,加入路況提醒,提醒用戶注意安全。提供線路導航和路況信息,提高用戶騎行安全屬性(建議與第三方軟體如騰訊地圖等合作)
b) 真偽需求分析
此需求是通過用戶調研得出的結論。但是考慮本產品的定位是解決最後一公里的需求,而最後一公里中需要使用導航的場景非常少;同時對於外部環境嘈雜、路況複雜的情況下,使用導航可能對用戶安全產生威脅。因此考慮本需求為偽需求。
(7)訂單發布與搶單
a) 任務描述
此需求是通過運營調研得出的想法。加入訂單發布與搶單功能,讓用戶需求在APP上顯性化。系統或用戶A發布騎車需求,被距離範圍內用戶B得知,若用戶B將車騎到需求目的地,且車輛在3分鐘內被A騎走,同時給A和B獎勵;超出3分鐘只給B獎勵;
b) 真偽需求分析
在考慮本需求時,主要側重點在於解決車輛的運營及產品的利用率。但是由於沒有摩拜內部運營數據支撐,因此本需求待定。
(8)騎行筆記與騎行心情
a) 任務描述
此需求是通過運營調研得出的想法。加入騎行筆記與騎行心情活動,以摩拜作為媒介進行社交。用戶騎行—>發表「騎行筆記」—>吃瓜群眾圍觀並評論或點贊,甚至關注作者,「筆記」採用瀑布流的方式進行展示,吃瓜群眾可以看到圖片+標題+點贊總數+評論總數;點進去是「筆記詳情」,還有轉載和三方分享功能
b) 真偽需求分析
此需求是通過運營調研得出的想法。以騎行為切入點做社交是一個非常好的想法,但是和產品本階段的定位不符。本階段應為搶佔市場份額、擴大優勢的階段,因此社交在本次迭代中不予考慮。
(9)信用積分獎勵
a) 任務描述
增加信用層級,與優惠掛鉤。對用戶按積分多少分為金銀銅等級用戶,給以不同級別用戶不同的騎行優惠或特權。
b) 真偽需求分析
此需求是通過運營調研得出的想法。從目前來看摩拜並沒有對信用積分模塊進行等級劃分,同時信用模塊是孤立的,沒有於優惠、運營活動掛鉤;僅僅思考信用分較低不能用車是不夠的,還需考慮高信用積分的用處。因此考慮,本需求是真需求。
(10)高押金解決方案
a) 任務描述
通過成本風險的分析得出一個合理的押金額度,作為新用戶註冊的最低押金門檻;原有的299作為最大額度,交納該額度的用戶可邀請一定數量的家庭用戶免押金加入並使用摩拜(即集體押金式),以此平衡老用戶已繳納高額押金的心理。
b) 真偽需求分析
此需求是通過競品分析得出的結論。在與ofo及其餘共享單車的競品分析中,摩拜的押金為最高的。高押金成為產品推廣中的一大阻礙。因此高押金解決方案應為優先順序較高的真需求。
(11)O2O騎行
a) 任務描述
將線下騎行、線上集券和線下消費結合起來。在活動中心發布定點騎行活動信息,如完成騎行任務可領取騎行卡,用戶憑騎行卡到指定商鋪兌換或折扣支付物品
b) 真偽需求分析
此需求是通過運營層面考慮得到的結論。考慮將用戶運營及車輛調度結合起來。是真需求,但本次迭代未考慮。
最終經過梳理與優先順序排列,從中得出前4個需求:
(1)「已預約」車輛顯示
(2)客服快速轉接、「忘記關鎖」提示
(3)信用積分獎勵
(4)高押金解決方案
為此,摩拜只有不斷去改進自身的劣勢,用更完美的用戶體驗,才能更好在這個共享單車激烈競爭的洪流中,保住並提高自身的市場份額;
下面對選取的四個功能點分別闡述背景及意義。
1.2.1「已預約」車輛顯示
a.背景
「預約」標記體現不夠。在目前的版本中,地圖上沒有車輛的已預約和故障標記,用戶會出現掃碼發現該車輛已被預約的情況,用戶體驗極差。
b.意義
在地圖界面可以選擇將「已預約」車輛標記過濾掉。解決用戶不知道車的情況,提高用戶的操作,避免用戶重複操作
1.2.2客服快速轉接與「忘記關鎖」提示
a.背景
(1)當前版本的摩拜客服服務只有—開不了鎖、發現車輛故障、舉報違停、其他問題四個方面,點進去之後需要掃描車輛的二維碼,有一些問題的提示和備註區域,而且掃描二維碼為必選項,操作相當的繁瑣,而且用戶有一些其他的需求和建議沒有明顯的提交入口;這樣的客服系統使得用戶不願意使用,也難以收到大量的用戶反饋。
(2)當前版本用戶騎行後忘記關鎖的話,會隨著時間的推遲繼續扣費,或者被其他的用戶騎走,直到用戶找到車子並且鎖上,才會停止扣費;或者用戶在事後發現扣掉了大量的資金找摩拜的客服申訴,過程非常繁瑣,用戶體驗感也極差。
b.意義
(1)為了方便用戶快速反饋信息,開通電話客服的功能,能夠跳過繁瑣的步驟,直接聯繫客服,方便用戶直接反饋問題和建議,提高用戶反饋信息的積極性已經方便用戶更詳細的描述問題。
(2)根據時間和GPS判斷的距離等信息提示用戶是不是忘記關鎖,避免用戶因為自己的疏忽造成不必要的損失,和事後申訴帶來的大量的工作量。
1.2.3信用積分獎勵
a.背景
(1)積分成長條件寬鬆。在6項信用加分的規則下——消費(正常騎行)、反饋(上報故障、舉報違停)、邀請(邀請好友註冊、填寫邀請碼)和分享(首次分享行程),信用分差距和兩級用戶的出現只是時間問題。
(2)激勵機制缺失。目前摩拜單車有對低信用分用戶的懲罰機制:<80分的用戶用車單價為100元/30分鐘,但還沒有高信用分用戶(≥80分)的獎勵機制,這對用戶的規範用車行為並沒有持續鼓勵作用。
b.意義
(1)用戶訴求匹配。目前摩拜尚未體現用戶分級概念,即一個信用積分300的忠誠用戶,並不會比信用分200或80的用戶獲得更多優惠和服務。對用戶進行分級管理,給予不同級別用戶差異化的優惠和特權,既可以彰顯用戶身份,也可以提高用戶粘性。
(2)利潤最大化的要求。信用積分從一定程度上反映了用戶的行為習慣和消費心理,不同信用分的用戶,在利益、體驗、情感上的訴求不盡相同。隨著用戶的大量沉澱和信用積分的廣闊分布,資源的匹配將變得格外重要。根據用戶的不同級別進行資源差異化配置,有利於商家實現利潤最大化。
1.2.4高押金解決方案
a.背景
同質化競爭慘烈,高額押金成門檻。在共享單車的競品分析過程中,已了解到摩拜新用戶註冊所需交納的押金額度最高,早期摩拜強勢布局各大城市時,因為用戶的視野里可見的無樁共享單車主要是摩拜,所以儘管押金高,也不會影響剛需用戶的註冊使用。而當該行業發展到現在有十多家品牌爭相積極布局市場時,用戶有了太多的選擇,而其他品牌的押金金額普遍大大低於摩拜,尤其是最大競爭對手ofo,押金金額僅為99元,這在一定程度上使摩拜錯失了很多單車用戶。
b.意義
既解決拉新難題,還平衡老用戶權益。一人交押金,可帶其他三人免押金,人均押金不到80元。而且這迎合了一些家庭多成員使用單車的需求和場景,70年代以前的人,他們曾經也是單車的重度使用者,更該享用到共享單車的便利。增加此功能後,子女只需將父母邀請為關聯帳號,他們便可以直接使用摩拜單車了。
1.3 目標用戶群
摩拜單車的用戶人群主要以一線城市的年輕打工一族及學生為主,這類人群出行方式主要以共享單車為主,為摩拜的核心用戶群和主流用戶;
性別:摩拜偏男性用戶居多,佔到了72.1%;
年齡:年齡階段佔比突出,主要以26-35歲為主:25歲以下為22.1%,26-35歲為55.5%,36-55歲為17.5%,55歲以上佔了極少數;
地區:主要集中在一線城市,如北京、上海、廣州、深圳;佔比可以佔到七成以上;
設備使用比例:華為佔了32.4%,三星20.5%,小米20.3%,其他26.8%
現在都市裡主要這類人群有些以下共同的特點:平時喜歡關注房產、金融、教育閱讀,並且線下消費偏好特徵突出;
由此可以看出摩拜的用戶主要以一線城市為主,喜歡關注房地產和金融這塊;用戶性別以男性居多,年齡偏年輕化上班族為主,普遍是安卓手機的用戶,注重下消費娛樂和教育閱讀;
1.4 產品預期目標和安排
目標
安排
時間
地圖可明確哪些車是可預約的
技術跟後台及時溝通調試
2天
客服電話可快速處理異常反饋
技術處理撥號功能、客服系統
3天
實現良好的信用積分系統
後台完善信用系統,並對接前台進行調試
1周
推出新押金獎勵制度,吸引更多的新用戶
後台、前台對接改進押金系統
2周
1.5 預期讀者和閱讀建議
本需求說明書供業務和科技部門人員、軟體需求提供人員、軟體的概要設計人員、軟體的開發人員、軟體的測試人員使用,並作為產品驗收確認的依據。
不同人員可挑選對應相關內容進行閱讀;
2 任務概述
2.1 「已預約」車輛顯示
2.1.1 需求簡介
2.1.2 功能結構圖
2.1.3 業務流程圖
2.2 客服快速轉接、「忘記關鎖」提醒
2.2.1 需求簡介
2.2.2 功能結構圖
2.2.3 業務流程
客服熱線流程:
「忘記關鎖」提醒流程:
2.2.4 頁面流程
客服熱線:
「忘記關鎖」提醒:
2.3 用戶激勵體系
該任務將通過用戶等級和用戶特權兩個功能實現。用戶分級適用於摩拜所有app用戶,用戶特權只覆蓋普通及以上用戶。
2.3.1 需求簡介
用戶場景需求梳理:
2.3.2 用戶等級模型
用戶等級適用於摩拜所有註冊用戶。根據騰訊科技2015年5月22日發布的關於摩拜超3400萬註冊用戶的推算,我們假定以下等級分配模型:
本項目上線後,預計各級別用戶人數將新增0.5萬(關注用戶);2000萬(普通用戶;1000萬(銅牌用戶)、300萬(銀牌用戶)、1萬(金牌用戶)。
2.3.3 用戶特權模型
用戶特權只覆蓋普通及以上用戶。
目前預期可提供的用戶特權如下:
(1)生日禮包:普通及以上用戶生日時,將會獲得生日禮包,用戶生日默認從實名認證時的身份證號碼讀取。生日禮包由系統提前向用戶發送,禮包包括騎行優惠券和紅包,有效期為7天。
(2)積分兌換:銅牌及以上用戶可以將積分兌換合作商鋪優惠券、禮品券,用戶憑騎行券享受騎行優惠,憑券享受商鋪消費優惠或免費禮品。兌換積分越多,禮品越豐厚。
(3)出行優惠:銀牌及以上用戶可以享受系統不定期贈送的騎行優惠券和免費騎行天數。用戶級別越高,優惠券的折扣越大,免費騎行天數由系統隨機決定。
(4)高端禮遇:金牌用戶可以享受摩拜不定期發送的紀念品,並且有機會受邀參加官方組織的線下體驗或交流分享活動。
本項目上線後,預計有3300萬用戶可享受到生日特權,1300萬用戶可享受積分兌換權益,300萬用戶可享受到出行優惠,1萬用戶可參與官方線下交流活動。
2.3.4 功能結構圖
2.3.5 業務流程圖
2.4 高押金解決方案
2.4.1 需求簡介
2.4.2 功能結構圖
2.4.3 業務流程圖
.2.4.4 頁面流程圖
3 性能要求
軟體運行環境:
iOS:需要ios7.0或更高版本,與iPhone、ipad和ipod touch兼容;
安卓:2.3.3以上;
非功能性需求一般包括:
(1) 性能(響應時間、交易吞吐量)
響應時間:
1)Spflash界面持續3秒結束;
2)手指拖動地圖顯示出內容時間≤1秒;
3)選項卡感應速度≤1秒;
4)界面跳轉速度≤1秒;
5)點擊刷新按鈕內容反應速度≤3秒;
6)刷新內容出現時間≤5秒;
7)搜索內容聯想內容出現時間≤1秒;
8)選擇搜索內容後點擊確認搜索反應時間≤3秒;
交易吞吐量:
1)並行用戶數:每秒1萬的並發數;
2)交易響應時間:每筆交易小於等於1秒;
3)交易執行呑吐量(trans/s): 每秒1萬筆;
(2)可修改性(新增、修改、刪除功能或特性引起的工作量)
(3)可用性(故障恢復時間,平均無故障時間,故障檢測時間等)
(4)易用性(操作習慣、操作層次等)
1)應符合人的操作習慣,並且有詳細的操作流程說明;
2)在保證操作可理解的前提下,精簡操作步驟,增強用戶體驗;
3)各功能設計跳轉要無縫結合,把整個產品各模塊功能形成有機整體;
(5)安全性(安全級別,訪問控制等)
1)當將密碼或其他的敏感數據輸人到應用程序時,其不會被儲存在設備中,同時密碼也不會被解碼;
2)在運行其軟體過程中,如果有來電、SMS、EMS、MMS、藍牙、紅外等通訊或充電時,是否能暫停程序,優先處理通信,並在處理完畢後能正常恢復軟體,繼續其原來的功能;
3)程序必須能夠處理不可預知的操作,例如頻繁的操作和同時按下多個鍵;
4 需求清單(Featurelist需求分類)
通用需求:
1.客服快速轉接
2.「忘記關鎖」提醒
3.「已預約」車輛標識
需求優先順序排序:
客服快速轉接:P0
「忘記關鎖」提醒:P0
「已預約」車輛標識:P0
用戶獎勵:P2
高押金解決方案:P1
推薦閱讀:
※Guerrilla Usability Testing 游擊測試
※交互設計師,你真正讀懂產品需求了嗎?
※產品經理如何將需求分析正確應用到工作中
※《用戶故事地圖淺析》學習小記