第二次作業-App案例分析

本次案例分析選用的是 摩拜單車IOS５.７.５版本

測試環境為 IPhone 6s (IOS11.0.1，含有3DTOUCH功能).本次案例分析僅針對APP 而言，並不涉及到整個MOBike共享單車的其他服務體系。

第一部分 調研， 評測

1.1上手

上手體驗：簡單明了，打開APP 的第一眼就能夠配合MObike的其他其他服務使用起來，用戶的使用學習成本極低。界面UI設計以紅色為主，符合現在主流的簡約化設計風格。總體UI還是沒得挑剔的。

1.2.找BUG

使用過程中發現了如下兩個問題：

1.2.1 3DTouch快捷操作選擇掃一掃偶然出現閃退現象，直接上動圖。

預期效果：能夠正常打開掃一掃的操作界面。直接掃描單車上的二維碼

BUG現象：

1.2.2 3DTouch快捷操作選擇掃一掃進入操作界面後，並沒有直接打開二維碼掃描界面。而是進入了APP的主界面

預期效果：能夠正常打開掃一掃的操作界面。直接掃描單車上的二維碼

BUG現象：

1.3其他用戶體驗

用戶背景：非計算機專業本科在校生。

用戶需求：使用APP作為工具打開MOBike。

使用機型：IOS10，（沒有3DTouch功能）。

使用體驗：上手容易，可以支持多種方式支付押金。除了自行車的其他故障，APP上來說基本沒有什麽弊端。還能夠記錄每一次的行蹤，這個是其他同類服務可能不具備的。

用戶改進建議：能夠記錄每一次的行蹤，但是卻不能手動刪除，這可真是一個麻煩的問題。emmmm,這可能會對某些不想讓手機記錄下行動軌跡的用戶放棄選擇MOBike。

　　　　　　　關於UI設計還是比較符合大眾審美的，說不上非常炫酷華麗的UI設計，但是起碼讓人用起來不別扭

結論：一般，對比同類沒有什麽很突出的表現。

第二部分 分析

2.1功能分析

　　①：【地圖尋車->】【預約車輛->】掃碼開鎖->結束付款

②：查看歷史行蹤

　　③：應用內的商城服務

　　④：自行車報修

　　註：【】為可選項

2.2產品對比

第三部分 建議和規劃

1 如果你是項目經理，如何提高從而在競爭中勝出？

　　①優化開鎖速度，從二維碼的內容識別開始。

　　②簡化商城內容，內容越多新客戶使用的幾率就更小了，因為入手難度高，學習成本高

　　③采用獎懲制度，鼓勵用戶報修，對問題分等級處理，簡單的報修問題可以先不對自行車進行鎖定處理（設置成無法開鎖），對於會影響騎行的問題要將自行車鎖定起來。以免影響了用戶的體驗感。

2 市面上同款的APP 眾多，廈門地區主要有 OFO 、 Hallo Bike 、

3 我覺得新增一個導航是不錯的選擇

N：

目前的APP沒有導航的功能，但實際上已經是使用了高德地圖的地圖接口了。在用戶不知道路的前提下可以通過APP一站式服務，不需要再手動切換到其他導航軟件進行導航。這樣可以優化停車點的服務

A：

從新開發一個導航系統對於這種創業公司是遠不可能的，我們只能夠通過與高德地圖攜手。通過各種商業手段去獲取到高德的地圖導航接口，並嵌入到系統中。另外應用本身就有記錄行蹤，可以通過記錄下的行蹤數據對常用的路線進行優化反饋，讓騎行路線從用戶中來到用戶中去，還可以填補高德地圖不存在的路線。

B：

解決用戶取到車以後的可能存在的不知道往哪走的問題。另外采用商業合作去獲取別人現成的導航功能是可行性比較高的方案。

C:

本身APP存在的初衷是作為開鎖，租車的管理工具。很大一部分還是應該在整個服務體系中去優化產品。作為APP而言應該追求高效，功能性，實用性強。少一些花裏胡哨的東西，多一個實際我們很可能用到的功能，競爭力自然就大了。就比如我16G的手機，我裝不下那麽多軟件，那我一個MOBike既可以租車，又可以給我簡單的導航，那我不就可以少用導航的APP；

D：

誰用誰知道，用過一次以後需要導航的用戶自然會選擇該類產品

4.如果讓我來領導技術團隊：

　　MOBike的整個服務側重點應該是在其他的運營服務上，如果我是負責技術的，如同上面的優化APP是一方面，另外我會註重小程序等這一方面的開發，或者是嵌入到支付寶，QQ等其他的常用平臺。

5.如果你的團隊有5個人, 4個月的時間，你作為項目經理，應該如何配置角色（開發，測試，美工等等）？

　　這個可是一個憑空意淫的大難題。首先，美工和後端的開發是可以分離的，而且要考慮多端支持到底支持多少，比如我們要同時兼容IOS和安卓兩大陣營，還要同時兼容小程序和手機端大小的web頁面。

後端的話應該是通用的。但是後端的難點是建立在我要用誰的地圖引擎，我的後端要搭建一個支持多大規模的服務器，這個也是很難拍腦袋就想出來了。

　　五個人的團隊應該是不足以支持這麽多方向的開發的，但是如果勉強要這麽做，我會選擇兩個人做服務端提供服務，（後端後期可能工作就比較少了，那他不妨最後以一個小白的身份去做測試）。

一個寫IOS，一個寫安卓。（實際上兩個人應該要互相共享整個APP的操作邏輯）。然後一個人負責測試（可能一個人也是不夠的，但是總要有人主要負責測試一整塊）。

　　時間軸方面

　　　　①：前一周，每個人都需要參與到設計這個app中來，確定要初期的基調。服務端的人開始考慮各種需要大的技術問題，如地圖怎麽來，如何結合硬件去開鎖。前端的人開始進行原型設計。（IOS和安卓可以公用一份設計原型的，暫且先不考慮小程序等復雜的）

　　　　②：２－４周。服務端開始搭建服務器平臺。前端開始做UI的實現，期間要對方向進行微調，比如某方面的功能受制於某項法律規定，或者其他的資源無法開發等。

　　　　③：５－９周　主要代碼的編寫

　　　　④：９－１２對原型進行內測修改。服務端可以考慮優化，而美工由於功能的疊加可能需要對界面進行簡單的重構。

　　　　⑤：１３－１４　兩周時間做第一次的測試，此時的主要內容在測試方面。

　　　　⑥：１４－１５　對測試的問題進行修改

　　　　⑦：１６－１７　進行回歸測試

註：測試應該是貫穿整個開發過程的，故在這裏就不一一例舉出來了

APP案例分析-摩拜單車app