關于去玩高爾夫APP的總結思考

6 評論 6068 瀏覽 24 收藏 10 分鐘

互聯網產品:互聯網產品的產生必然依托于用戶需求或對應的線下實體資源。本質是通過互聯網的手段解決用戶的痛點。

根據公司開展高爾夫業務的需要,在去玩嗎APP中添加高爾夫功能子模塊。

初期調研結論:高爾夫互聯網產品實際上是根據實體高爾夫球并對其相關服務而產生的產品。

初始階段提供的內容主要為瀏覽和打球記分。產品盈利點為通過活動報名收取費用或預定球場。

產品定位

根據公司所能提供的線下資源來定位未來發展方向。同時在產品不同階段去推動對應功能。首先由于產品初創,構建從零到一的框架。目前通過線下活動結合線上高爾夫,從而打入線下用戶圈子,讓用戶能夠進行有效傳播互動。

?slogan未單獨提出

由于去玩高爾夫還屬于內嵌在去玩嗎APP中沒有獨立,所以并沒有對slogan做過多的討論。

按照預期去玩高爾夫會在未來單獨作為APP運營,屆時目前已經想好的slogan是“去玩高爾夫,你貼心的高球伙伴”。希望用戶在使用去玩高爾夫時,通過打開去玩高爾夫感受到我們營造的貼心感覺。

設計原則

目標用戶定位高端群體,設計原則以簡潔明了為主。

交互主要以滑動為主,打球記分部分較特殊,在進入此功能時有提示說明。

目標用戶分析

高爾夫球在國內依然還是屬于有門檻的小眾運動,用戶需要具備一定的經濟基礎。高爾夫面向的對象屬于高端人群。根據業務部門提供的信息,用戶群體大致分為下列三種:

  • 老板和土豪(通過高爾夫球娛樂)
  • 一、二線城市的高層白領(融入不同圈子的工具及娛樂)
  • 家庭環境較好的青少年(從小培養高爾夫球興趣)

使用場景分析

目前只涉及移動端,目標:用戶隨時隨地通過移動端查看去玩高爾夫提供的服務。

在球場使用時,使用打球記分功能。

在休息時,在家或者在工作之余,查看球隊、球場、活動和培訓等內容。打球記分的流程相對完整,通過和好友一起打球記分,可以查看自己的高爾夫差點和打球記錄。

產品框架

需求來源:公司業務部門。所有功能依托于業務部門提供的需求,并在綜合分析后確定。

基礎功能:

根據業務部門提出的功能要點,主要圍繞活動、球場、球隊、打球記分和高球培訓幾個模塊展開。以展示為主,展示主要為線下合作伙伴和江浙滬地區高爾夫球場地為主。主要以列表形式展示,列表點擊進入詳情。

特色功能

打球記分為單獨的功能點。

由于目標用戶群體的特殊性和小眾性質,用戶想用更少的操作來完成自己的目的。因此對于頁面設計和交互設計需要用更簡潔的邏輯來完成,減少趣味性和探索性,更簡潔明了的為用戶體現出頁面的元素,以及用戶可以查看哪些內容。用戶通過查看怎樣的內容來解決自己的痛點。

框架除了獨特的打球記分功能,其他都采用列表查看的方式。前后交互邏輯統一。即用戶通過點擊和滑動的操作便可以查看所有內容。

用戶體系

高爾夫作為新功能,與原來功能都沒有直接聯系。并且高爾夫帶有一定社交屬性,原有的功能不能滿足,所以重新規劃了只屬于高爾夫的用戶體系。

交互設計

打球記分頁面。通過點擊不同用戶從而查看用戶當前的桿數和推桿數。對比其他交互設計,在同一個頁面顯示一組用戶的桿數和推桿數。原有頁面的設計理念參考云高高爾夫,每個球洞為一個頁面,一個用戶或一組用戶都能在同一個頁面內記錄。

  • 優點:讓每個用戶在每個球洞都能明確看到自己的桿數和推桿數。掌握后長期使用能更清晰明了的查看自己的桿數和推桿數。
  • 缺點:頁面增加了交互,用戶學習成本增加。第一次使用需要學習之后才能對此有了解,對于目標用戶群體的友好度較低。

總結

業務流程

對于高爾夫本身除了打球記分需要了解對應的業務流程外,其他流程屬于展示,并沒有過多涉及專業的業務流程?;径家哉故卷撁鏋橹?,單純從列表出發,受制于無法判斷線下資源的數量以及用戶對于分類的有哪些判斷,所以并沒有在開始就在列表的基礎上添加篩選功能,所有列表看起來單薄。業務部門也沒有明確說明頁面需要展示哪些字段,只能借鑒現在已有的競品。

線下資源的重要性

高爾夫的相關展示還是依托于線下資源的獲取,如果沒有線下資源的配合,線上展示資源則較少。目前目標是立足于上海地區,將江浙滬地區的球場羅列出來。其次展示有合作的球隊、教練和培訓基地。用戶可以直接通過APP查看相關信息,直接找到有興趣了解的資源去合作。

業務梳理

對于高爾夫業務的不了解,由于高爾夫運動的門檻相對還是高一些。所以了解高爾夫無法從實際直觀出發,導致在做的過程中無法通過對于高爾夫的直接認知來推導業務流程。只能通過業務部門同事和其他高爾夫產品去感知要做的功能和流程?;舜罅繒r間梳理高爾夫相關知識,花費大量時間做高爾夫產品的分析和再整合。

業務人員對于自身需求的迷茫

此次高爾夫產品策劃由高爾夫業務部門提出,但是由于高爾夫部門對于互聯網產品缺少相關認知,并且對于低保真原型工具無法做出判斷的情況下。導致了只能是在UI稿完成后或者進入到產品測試階段,才能結合自身高爾夫經驗提出問題。增加了產品開發測試的滯后性。

以2C的內容為主

由于高爾夫用戶基本以個人或球隊的方式打球,所以用戶群體不涉及2B。目前C端用戶已經形成了線下高爾夫業務的固定模式,對于線上高爾夫的流程接受程度需要時間培養。能否抓住用戶的痛點也可能是產品經理自己的臆想和猜測。

獨立完成

由于公司規模并且只有本人獨自完成所有產品規劃的原因,IOS和安卓的頁面設計和交互基本都采用同一套,沒有針對不同客戶端做區分對待。

部門配合

前期高爾夫知識都是通過業務部門培訓得來,開發和測試人員流于形式。并且開發過程中不查看需求文檔,對于之前講過的細節問題反復溝通,增加了溝通成本。

 

作者:格拉德,一個正在路上的產品經理。

本文由 @格拉德 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖由作者提供

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. PRD能否分享下

    來自湖北 回復
  2. 看完之后的體會:
    1 圖片做的相當精致,應該是出到了UI級別,非常適合宣講,也就是和業務討論,這種圖估計也是boss最愿意看的,印象分會很高
    2 針對開發團隊而言,本文中的資料難以滿足開發要求,需要更細化的功能說明原型,也就是所謂的PRD文檔
    3 作者的一句體驗我感同身受:業務部門難以針對低保真原型進行討論和理解,需要到UI或者高保真級別才會進入實質討論階段,這其實增加了相當程度的返工和溝通成本。作為踏過同一個坑的同行,握個手:)

    來自上海 回復
    1. 非常感謝你的評論、
      1.圖是UI小哥后期畫的,正好都想做個總結。宣講的時候直接用UI圖講的。直接用這種圖宣講太耗設計,同時也不利于現階段開發的整體時間安排。
      2.PRD文檔我沒有分享,本文就是總結,分享出來就是希望能對大家有所幫助。
      3.無奈啊。用盡辦法就是看不懂。

      來自上海 回復
  3. 想知道樓主這個圖是用什么做的呀?

    來自北京 回復
    1. sketch。UI小哥做的圖

      來自上海 回復