關于微信投票,設計產品前你想好了嗎?(后臺篇)
本片文章是繼微信投票產品設計前臺篇而寫的,主要分享后臺設計該如何進行以及其中的注意點。
前幾天發了一篇關于微信投票的前臺篇,今天把后臺篇也一起發上來,這樣才算完整,看前臺篇的文章請移步到這里:關于微信投票,設計產品前你想好了嗎?(前臺篇)。
關于微信投票的前臺邏輯正如上面文章中說的這樣,但這些內容的呈現都需要在后臺進行設置,所以關于后臺方面我也按照相關邏輯與開發進行了溝通,并形成了如下的思維導圖。
思維導圖:
產品設計方面,我更關注的是產品的復用性。要知道,任何一個被設計出來的產品,不單單只是為了某一活動或者任務,個人感覺產品經理設計出來的產品更像是自己的孩子,它不但“好看“、“聽話”同時還會“長大“,“長大“就是產品的復用性,如果可以把復用性作為一個權衡項來設計,將來如果再次遇到同樣的問題,就不至于讓我們手忙腳亂了。
關于后臺的產品設計方面,大體我分為了以下幾個項目:
活動配置:
關于活動配置的相關功能延伸主要如上圖所述,但需要著重說明的是以下幾點:
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臺,老板還不找你聊人生?。克孕枰卣f明的就是關于抽獎的算法,你可以不懂,但是一定要設計明白。我在這里只設置了相應的每天最多中獎數,也就是將獎項平均分在每天,如果你的獎項無法按照每天來分配,這里就需要著重與開發進行交流,確定好相關算法,多聽取意見與建議。
2.實體獎與虛擬獎的區別除了需要郵寄以外,更重要的區別就是虛擬獎即中即提,也就是現場發放,所以需要預先將相關中獎碼導入至獎品的中獎池中,所以虛擬獎品與實體獎品的庫存管理是不一樣的,這里需要特別注意。
3.中獎提示語,預先設計是為了方便在中獎時進行展示,效果大概類似于“恭喜您,獲得XXX激活碼1個。”。
表單收集:
抽獎活動的數據記錄中心:
- 表單收集中除了有投票人中獎的記錄之外,還有選手的得票情況與參與投票人的投票情況,這里是所有抽獎活動的數據匯總中心,可按照圖上的搜索條件進行搜索與查看,必要時需要支持數據導出功能方便運營派發獎品及獎品統計。
關于需要提醒的一些小細節:
- 萬能錯誤頁,這個一定要設計,以應對突發情況。
- 針對微信對第三方投票的和諧,應有2手方案,可做到快速切換。
- 測試!測試!測試!第一是對投票環節的功能性驗證,第二則是對抽獎環節的算法進行驗證,避免“老板找你聊人生”情況的出現。
- 投票關閉(但頁面仍舊顯示)時,投票按鈕的交互功能,按鈕置灰或點擊后的提示語設計。
- 對投票數據、流量、抽獎情況的實時查看。作者:淘玩家,個人微信:memenn。
#相關閱讀#
本文由 @淘玩家 原創發布于人人都是產品經理。未經許可,禁止轉載。
多半是需求方或上面給的要求,總得折騰點事情
需求總是變,也是沒準了,用第三方做,分分鐘被自己玩死啊。 ??
功能的設計來源于需求,但當需求特殊時,站在結果的角度上看,就必須做出正確選擇。
跟現有的第三方平臺上的差不多。為何還要費精力開發?
做這個功能的出發點何在?微信內容那么開放,H5應用就搞的定啊。官方也沒出發點搞這個投票。
同問
偽命題,為了產品而產品