產品思考:如何打造一個禮服租賃平臺

10 評論 9757 瀏覽 74 收藏 12 分鐘

前陣子從同事那里得到消息,有需求方想做一個租賃禮服的App,可以進行AR試穿。由于當時能拿到的消息就這么多,本來想去下載幾個租賃類App參考一下,可惜乞丐版手機沒有空間。正好目前也比較閑,便嘗試對整個事情進行分析,看看是否能較為合理的完成這個案例。

需求分析

整體平臺搭建

雖然對方初步提出只想要一個租賃類App,但實際分析下來,僅靠一個App是沒法支撐起租賃這個行為的。真正的需求是一個前、后臺齊全的租賃平臺。大致如下:

  1. 前臺App:主要提供租賃、個人信息管理等功能;(后面再展開討論)
  2. 后臺:至少需要有兩套管理臺(不考慮部署問題,僅從展現端考慮),一個向商戶提供商品信息、訂單信息相關的管理功能,另外一個是該租賃平臺方自身管理個人客戶、商戶各類信息的功能;
  3. 其他比較重要的模塊:最容易想到的就是與交易相關的支付功能,既然作為一個平臺方來運營,這里最好建設一個較為完整的支付平臺來支撐,方便對資金進行管理和調撥。

App功能分析

按照客戶要求,App端最重要的功能當然就是“租”了,即通過各種手段讓客戶來找到合適自己的禮服,比如搜索、推薦、活動等等。除此之外,本App需要用AR作為亮點,所以此功能也需要作為一級入口提供。參考一些購物類、生活類App,擬定前端主要結構如下:

后臺管理功能分析

由于需求不是很明確,這里可以分階段進行分析。

  1. 若需求方體量足夠大,可以獨家開展禮服租賃業務以及相關增值服務,那么只需要建立一個平臺側的管理端,無需考慮商戶;
  2. 反之,則需要引進商戶來擴充平臺內容,向客戶提供多樣化的租賃服務,做法跟X寶、X東類似;

需要支持的常用功能如下:

個人理解平臺方和商戶側的功能基本類似,只不過平臺方需要對商戶、平臺進行管理,再加上后續的運營需要,因此會多出相應的功能,即可以把平臺方視為一個特殊的商戶來對待。另外,相同菜單開放的權限也需要注意;這部分功能可以通過注冊成各類平臺商家進行參考、完善。

其他模塊分析

這個部分主要考慮需要與哪些外部系統有關聯。既然是做禮服租賃,不可避免的會涉及到付款、收款等行為。不論是自己單獨運營,還是引進商戶,常用的做法是作為商戶接入各類第三方支付平臺,由其進行資金清算。(直接讓對方轉賬這種“暴力”收款不考慮)選擇第三方支付平臺,主要考慮的基本就是費率以及清算頻度。

這里我們搭建的支付模塊主要包含功能如下:

簡單設計思路

App部分

按照上面的需求分析,App端暫定有5個一級選項卡,大致樣式如下:

(1)頁卡詳細說明

首先是一邊分析一邊整理在設計過程中可能涉及到的頁面和其他元素,做好分類,便于管理和制作交互稿。

接下來整理每個頁面的邏輯。

(2)首頁

首頁界面需要體現出app的主干業務,保證客戶能夠獲取自己想要的、感興趣的信息。因此,各類活動信息、垂直搜索功能不可或缺。同時為了保證客戶拿到可用的信息,定位功能也是必須的。

(3)分類

分類頁面提供明細選擇,客戶大部分的租賃行為都是通過本頁面完成,所以如何提供合適的分類,需要仔細斟酌,再參考運營一段時間后的各類數據來進行調整,不斷完善。

(4)AR

作為 App 的特色功能,設置為一級選項卡是為了保證用戶隨時都能點開使用,提升用戶活躍度。此外,本頁面不應設置太多的門檻,比如不要求客戶登錄、參數不宜太多。

(5)圈子

提供場所讓用戶與用戶、用戶與商戶互動,類似貼吧、論壇的地方,因此需要加強管理。又因為移動設備屏幕有限,所以功能不宜太復雜。

(6)我的

涉及未登錄和已登錄兩個頁面,如下:

(7)部分頁面示例

搜索類:

商品、注冊頁:

最后,不可避免的需要根據客戶方、開發人員多次溝通,調整界面功能,完成最終的設計稿。在確定主體需求的時候,前后臺已經可以同步開發了。

后臺管理部分

管理臺部分按照最初的分析,主要提供如下功能:

  1. 業務信息類:管理商品、個人、訂單、活動等信息;
  2. 報表類:提供流水、簡單分析、統計類報表;
  3. 平臺類:平臺自身參數配置,用戶管理;
  4. 自定義類:個性化首頁配置;

一般來說,后臺管理端對應的用戶量并不大,系統也不需要支持很高的并發。在設計的時候,可以不用考慮很多性能方面的問題,而且很多前后端框架本身的性能也不差,我們優先把關注點放在功能的實現上。每個功能點大致都需要圍繞輸入/輸出界面、操作流程、異常處理這三點來完善

其他部分

對于支付模塊的設計,僅就完成功能而言,主要包括:

  1. 賬戶體系:需要建立一套虛擬的賬戶體系,包括與銀行卡賬戶相對應的子賬戶、紅包賬戶、臨時賬戶(比如活動賬戶),以及每個賬戶的扣帳原則、分錄;這部分需要跟客戶信息進行掛鉤,用于評定客戶等級、贈送積分等等。
  2. 支付郵路:靈活的郵路切換原則,找到成本和效率的平衡點;
  3. 流水:支付流水的查詢以及差錯處理,設計時需要考慮到客戶的感受,畢竟支付出了問題體驗已經不好了,如果不能及時定位以及處理差錯,那么失去客戶也是分分鐘的事情;
  4. 報表:這塊主要是為了進行運營分析,所以維度要盡量多一些,每一種表樣在設計的時候需要多斟酌一下,不要產生模棱兩可的含義;

余下的事情

  1. 數據庫的設計、開發框架的選擇就丟給資深程序猿大神們了。當然,產品狗適當的參與、了解也是必要的,便于后期開展工作;
  2. 賬戶體系、支付模塊的設計應該可以通過網上找到成熟文檔,設計時可以多參考一下;

總結

第一次嘗試做app端簡單的交互設計(姑且這么叫吧),很多地方可能也不夠完善和美觀,希望能在以后多看到相關資料來提升,也希望在這里找到各類產品牛人帶我飛。

對拓展功能的思考:

  • 當客戶在看中某產品時,并不僅僅只有租賃可選,還能直接買下。如果這樣,商品頁面、購物車、付款頁面等都需要做相應的調整。
  • 根據運營方式(會員、押金)來給客戶提供更多的附加功能,例如目前比較火的開鎖共享單車,當然這些需要通過數據來驗證效果。

 

本文由 @盜不留蘅 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Pixabay,基于 CC0 協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 補充下用戶場景就更好了

    來自山東 回復
  2. 需求挺好,原型有點兒太挫

    來自上海 回復
    1. 大神,原型這塊的提升有什么好的建議嗎 ?

      來自上海 回復
  3. 很厲害,思維很廣闊?。?/p>

    回復
  4. 整個需求流程寫的太不錯,很贊

    回復
  5. 做外包都是不分析需求場景,不分析市場行業,直接開干的嗎?

    來自浙江 回復
  6. 不錯不錯,希望多謝一些行業分析

    來自新疆 回復
    1. 之后可能需要跟對方見面交流下才可以

      回復