關于微信投票,設計產品前你想好了嗎?(后臺篇)

7 評論 15895 瀏覽 81 收藏 9 分鐘

本片文章是繼微信投票產品設計前臺篇而寫的,主要分享后臺設計該如何進行以及其中的注意點。

前幾天發了一篇關于微信投票的前臺篇,今天把后臺篇也一起發上來,這樣才算完整,看前臺篇的文章請移步到這里:關于微信投票,設計產品前你想好了嗎?(前臺篇)。

關于微信投票的前臺邏輯正如上面文章中說的這樣,但這些內容的呈現都需要在后臺進行設置,所以關于后臺方面我也按照相關邏輯與開發進行了溝通,并形成了如下的思維導圖。

思維導圖:

產品設計方面,我更關注的是產品的復用性。要知道,任何一個被設計出來的產品,不單單只是為了某一活動或者任務,個人感覺產品經理設計出來的產品更像是自己的孩子,它不但“好看“、“聽話”同時還會“長大“,“長大“就是產品的復用性,如果可以把復用性作為一個權衡項來設計,將來如果再次遇到同樣的問題,就不至于讓我們手忙腳亂了。

關于后臺的產品設計方面,大體我分為了以下幾個項目:

活動配置:

關于活動配置的相關功能延伸主要如上圖所述,但需要著重說明的是以下幾點:

1.投票活動起止時間與頁面展示截止時間,起初設計的活動頁面只有活動起止時間。也就是說當活動結束時,我們就無法再次進入頁面進行訪問,但我們通常會遇到這樣的情況,投票活動已經結束,但我們仍需正常訪問頁面查看選手名次及將排名對外界進行展示。所以此時頁面展示截止時間就顯得尤為重要了,投票活動的起止時間只代表了投票的時間范圍,但頁面展示時間仍舊可以繼續延長至某一個時間。

2.由于本次投票活動是借助于微信進行的,所以我們限制了每個ID每天的投票數,這里的ID指的是微信的openID,比較好控制,可以一定程度上面避免刷票情況的發生,如果是在其他應用場景里的投票,那這里的ID另當別論。

3.是否限制每天為同一選手投票,這里我建議是限制的,因為每ID每天有3票,但只可以投給1個選手1天1票,這樣可以減少單個選手刷票對投票公平性的沖擊,同時也可以帶動其他選手的得票數,這樣相對公平公正。

4.活動期間每個ID最大投票數量。關于這個配置項,我是想了很久才加上的,按常理說活動期間每個ID最大投票數量應當是“活動天數*每ID每天可投票數”。但這里加上的這個配置項是為了應對一些突發的情況,也可以理解為更大程度上給了產品了更多的靈活性。

5.每天活動抽獎次數,這里不做過多解釋,在前臺篇當中有相關的業務邏輯。

選手配置:

選手配置頁大多都是關于選手的相關信息配置,但仍舊有一些細小的功能設計:

1.初始票數,這里也許很多人有疑問,為什么要設置一個初始的票數,難道每個選手的初始票數都不一樣嗎?答案當然是假的,這么設計只是為了給票數上加上一個基數,說的簡單點就是為了讓數據好看,默認為0,可自行設置從1000或10000開始,但你要是在某位選手上多打了1個0的話,這下就不好說了。。。

2.參賽狀態,這里是需要說的,萬一萬一萬一有選手中途退賽,需要將她從投票列表中刪除,這個按鈕就起了大作用了,如果沒有設計,動動手改代碼也是可以的,但最好要考慮,不管你是設計為退賽還是刪除都可以,但這里的退賽,只是在投票頁面上隱藏,選手相應的數據保留,這樣就比較好了,萬一萬一萬一萬一那個奇葩的選手要回歸的話。。。你就懂了吧?

獎品配置:

這里可以說是投票活動中較為重要的部分,因為稍有疏忽就夠喝一壺的:

1.抽獎的原則我個人認為是“只能少不能多”。也就是獎項最好都都抽走,但是不能被多抽,萬一公司準備的5臺大蘋果被你設計的抽走了6臺,老板還不找你聊人生???所以需要著重說明的就是關于抽獎的算法,你可以不懂,但是一定要設計明白。我在這里只設置了相應的每天最多中獎數,也就是將獎項平均分在每天,如果你的獎項無法按照每天來分配,這里就需要著重與開發進行交流,確定好相關算法,多聽取意見與建議。

2.實體獎與虛擬獎的區別除了需要郵寄以外,更重要的區別就是虛擬獎即中即提,也就是現場發放,所以需要預先將相關中獎碼導入至獎品的中獎池中,所以虛擬獎品與實體獎品的庫存管理是不一樣的,這里需要特別注意。

3.中獎提示語,預先設計是為了方便在中獎時進行展示,效果大概類似于“恭喜您,獲得XXX激活碼1個?!?。

表單收集:

抽獎活動的數據記錄中心:

  1. 表單收集中除了有投票人中獎的記錄之外,還有選手的得票情況與參與投票人的投票情況,這里是所有抽獎活動的數據匯總中心,可按照圖上的搜索條件進行搜索與查看,必要時需要支持數據導出功能方便運營派發獎品及獎品統計。

關于需要提醒的一些小細節:

  • 萬能錯誤頁,這個一定要設計,以應對突發情況。
  • 針對微信對第三方投票的和諧,應有2手方案,可做到快速切換。
  • 測試!測試!測試!第一是對投票環節的功能性驗證,第二則是對抽獎環節的算法進行驗證,避免“老板找你聊人生”情況的出現。
  • 投票關閉(但頁面仍舊顯示)時,投票按鈕的交互功能,按鈕置灰或點擊后的提示語設計。
  • 對投票數據、流量、抽獎情況的實時查看。作者:淘玩家,個人微信:memenn。

#相關閱讀#

關于微信投票,設計產品前你想好了嗎?(前臺篇)

 

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 多半是需求方或上面給的要求,總得折騰點事情

    來自上海 回復
    1. 需求總是變,也是沒準了,用第三方做,分分鐘被自己玩死啊。 ??

      來自北京 回復
  2. 功能的設計來源于需求,但當需求特殊時,站在結果的角度上看,就必須做出正確選擇。

    來自中國 回復
  3. 跟現有的第三方平臺上的差不多。為何還要費精力開發?

    來自福建 回復
  4. 做這個功能的出發點何在?微信內容那么開放,H5應用就搞的定啊。官方也沒出發點搞這個投票。

    來自安徽 回復
    1. 同問

      來自福建 回復
    2. 偽命題,為了產品而產品

      來自安徽 回復