來人人都是産品經理【起點學院】，BAT實戰派産品總監手把手系統帶你學産品、學運營。

第一次動筆寫這類型的分析，不到位的地方歡迎大家指正。在此之前我覺得如果不能對團購模式有一個基本的見解，是無法看懂美團，糯米的優劣勢的。接下來我将通過多篇文章依次介紹我的理解。

首先，判斷功能點的位置，按照我之前的分類：一進入APP，用戶本身就有不同的訴求，已經在店裡的看到二維碼要掃的；搜索去哪裡玩的和人已經在商圈想找個确定的店吃飯的。

那麼最開始的4個點就已經确定了，用戶打開APP就需要用到這幾個點：二維碼掃描，搜索功能，地圖檢索，APP内推薦以及優惠券。

在讨論具體功能之前，個人覺得有一個大前提，就是這類型的APP是跟地理位置高度相關的，所以，在城市的自适應選擇上也應該是優先的，也就是說用戶第一次進入APP之後，APP提示是否使用當時用戶的地理位置以提供更準确的附近商店信息。之後每次打開監聽地理位置并在異常的情況下（所在地和選擇的所在地不一緻）提示用戶是否更改地理位置。（因為用戶短期内的位移并不大，所以假設在進入APP到浏覽完畢關閉APP，地理位置不變）

下面開始具體描述上述的幾個具體功能。

掃碼

使用場景相對單一，用戶到店看到吧台的相應APP二維碼（提示用戶使用APP内嵌掃碼功能）——>打開APP，點擊掃碼功能。

這個功能本身相對簡單，具體流程如下，點擊掃碼按鈕——彈出是否可以訪問相機進行掃碼——調用相機程序并解析二維碼——返回結果

如圖：

我增加了一個圖片反饋，讓用戶在誤觸的前提下将異常狀态糾正的體驗更友好（我覺得在使用場景的前提下，大部分用戶都會給予掃碼相機權限，所以我把誤觸或者沒有注意否定權限歸到異常）

搜索

設計搜索跟數據庫本身的設計有着密切的聯系，先不考慮這部分性能如何優化結果的問題。

首先我們先考慮具體的用戶行為，我個人将他們分為兩種：

• 喜歡自己輸入搜索内容後逐級篩選.
• 喜歡用定義好的備選項去挑選。

但我覺得不論這兩種行為，都可以将搜索内容本身固化成對應維度的值同時返回結果，舉個例子，我在搜索框内輸入鐘樓，點擊搜索後，結果返回搜索的内容，同時清空搜索框并把鐘樓固化到位置維度裡。（我個人的想法是，因為維度取值本身就是确定的，那麼，搜索的内容去遍曆維度取值，有相同值就返回，沒有就不固化，異常值就不考慮固化，搜索本身是需要首字母比對加快速率，同時需要二次确認文字）

之後考慮下具體的邏輯步驟，首先，一般的想法是，用戶使用搜索功能是在他确定了一個大概範圍的前提下他才會使用這個功能，但是，我認為還有另一種可能就是他認為搜索可以解決他的需求（具體需要數據做支撐，用戶在非常模糊的目标下所填寫的搜索内容是一個籠統的範圍），所以，我的想法是，在搜索框添加焦點事件，當搜索框獲得焦點時，轉換成一個展示以下幾個維度的頁面（一個娛樂項目的幾個屬性分别是：類别本身，地理位置，性價比，人氣，評分），用戶面對這個頁面的行為也分為兩類1.無視篩選直接輸入搜索内容，2篩選一部分籠統的類别地點信息後直接點擊搜索。

第一種情況就用我之前描述的行為解決方案，根據他搜索的内容直接固化成維度值。但是，手動輸入有一個很重要的問題，就是用戶會不會自主考慮篩選的關系，也就是說他搜索的内容是不是以層級逐層遞進的，對這個問題，我的直覺是，不可能，因為太難了。那麼，對于交互本身，我們需要判斷的是當前搜索的細化内容跟之前的細化内容是否是包含關系，比如，優先搜索地點，之後品類，這就存在包含關系，但是還存在，先搜索火鍋，後搜索燒烤，這就是同一維度的不同類别，需要做判斷來分辨是否需要遞進，或者重新在原有搜索内容前提 下更改某一個類别的取值。

第二種情況就需要考慮維度本身的值如何定義，類别來看，吃和玩本身就大不同，分類做遞進效果更好（其他類目暫時不讨論，邏輯上也一緻，把所有業務覆蓋的點歸類，可以合并的歸成父類，然後點擊展示具體子類，樹形結構），舉個例子，火鍋跟燒烤就應該劃歸在美食這個父類别下，密室逃脫就放在消遣娛樂這類父類下。之後的問題就變成了，子類是否應該支持多選，我個人不覺得多選是一個好點子，雖然這麼做很符合理性假設，但是，大部分人并不習慣去遍曆全部後挑選，或者說他們不考慮自己所可能做的全部活動，之後全部篩選，而是選擇一個，發現選的不好，再換一個，這個邏輯更符合實際（當然，需要數據進一步驗證），但是體驗上需要最後一步頁面的保留，也就是說，用戶選擇某一個子類之後，看了一圈發現沒有自己想要的，他點擊同樣篩選位置應該返回的是跟這個子類同級别的菜單欄，而不是從頭來過，比如，美食父類的火鍋子類，用戶沒有滿意的火鍋美食，他就會想說有沒有燒烤，那麼點擊類别篩選的時候應該在父類項已經選中美食，同時子類選中火鍋。（當然，你也可以認為用戶想去玩了，這個邏輯相比我的邏輯更需要數據的證明，不是麼）

現在讨論下位置這個維度，對于位置來說，地标是不是優于政府劃分的行政區域本身（對于用戶來說，他們隻能通過他們知道的地點或者地标來搜索，對于現在的二級遞進設置，我以個人的經曆為例，找了半天小寨，不知道小寨在哪個區....最後就是一個個試，後來反應過來，試了試直接搜索小寨，結果還挺好的，但是我們做交互的時候為什麼不能直接在篩選欄的上面置頂的提示一下用戶，“找不到想要的地标？試試直接搜索吧”效果應該會更好，你說呢

至于好評，客單價，距離，人氣，開店時間，這類型的篩選，選擇按什麼排序即可，額外說下好評，評價這個東西，我個人還是覺得是不是可以防止刷單，對有圖片的好評單獨列出來，同時，刷單需要的獨立IP，同時，刷單人并不會真正到店體驗，而是通過網絡傳播圖片，所以圖片的雷同性很高，針對這個，可以通過數字圖像處理做反刷單算法，同時恢複真實好評的占比。

考慮完維度的如何取值定義，流程圖如下：

第三個主要功能，地圖檢索，這作為一個獨立的功能有他特有的使用場景，日常吃飯，飯後就近的娛樂需求，這類型需求對地點的要求相對苛刻，所以以地圖展示更符合交互結果（個人觀點，需要運營數據驗證），一般人走路10-20分鐘也就600-1200米的半徑，地圖本身比例尺應該以這個為界限，（按照30分鐘，2公裡計算，展示給用戶的也是徒步的時間而不是距離，這個我上一篇文章已經提到了，大部分人對時間的概念性大于距離，展示給他們時間更優于距離，至少我是這麼認為的），方向确定了，那麼開始解決實際展示的邏輯，首先，用戶點擊入口按鈕，之後顯示一個以4公裡為直徑的圓并幾乎沾滿整個屏幕，當然，這個根據具體地圖設計定，但是最好的結果是4公裡，同時标注主要周圍的商圈，同時地圖最上角顯示篩選的維度，這裡的維度就僅僅隻有類别跟如何排序，因為距離已經是一個限定條件，就不需要再篩選了，同時,頁面所最大能顯示的數量需要跟美工讨論下，對這個的分析我并不是很在行....就不亂給意見了，設置好分辨率本身所對應的頁面展示數量，就開始嘗試展示搜索結果，結果以所在的地理位置對應的圖标展示，但是這樣就有一個問題，沒有辦法對圖标進行排序，這個方面我的想法是，排序的展示方式以圖标顔色的深淺區分，（現在的評分體系一般是5分，那就把顔色基本分成5個标志性顔色，展示出來），綠色以深色為高，紅色以淺色為高，具體需要跟美工人員商議，畢竟我隻是個外行=。=

流程如下：

最後一個功能APP推薦：乍一看這個功能的名稱無法理解他到底想描述什麼，我對這個闆塊的定位是，以運營為核心，我上篇文章提到了，人們打開這類APP的具體需求基本已經大概确定了，有到店想要查看有沒有團購的，有打算在某個時間段出去玩的，有對地點要求特别高的，還有的就是，女性類通用需求：是否打折？是否新奇？是否有活動？（把他們歸于女性需求雖然有些偏激，但是這類需求的典型代表确實是追求新鮮感跟貪便宜的妹子群體~），同時這些也是刺激消費的重要一環，消費類需求的定義不應隻是局限在用戶已經想要什麼，而是基于盡力讓他們發現有很多東西适合他們，同時推銷給他們，就如同很多商場的促銷打折活動，他們的目标并不隻是這一個商品，而是吸引你進店然後推銷給你更多的産品。

在這個方面，推薦大家一本書昂德希爾的《[顧客為什麼購買》，閑話撤完，開始聊正事，這個功能我對他的定義是一系列闆塊，比如上一篇所描述的，用戶有小團體，情侶，家庭聚會各種不同的需求，那麼針對某一個時間點對一個類别進行活動促銷是一個很好的方式（為什麼不單獨列出來團建，我個人覺得，消費者跟付款者的不一緻，導緻這些人對于團購本身沒有太大的興趣，更多的是嘗試更貴的或者更高大上的店，畢竟，一個月才一次，還是公司掏錢，當然就~~嘿嘿~~不過，團購也可以針對這點做一些高大上的團單，滿足這些人的需求），同時，打折促銷是也是一個不錯的細分類别，當然，具體的哪些在哪段時間可以優先做活動還是由數據決定的，比如，在年底，家庭聚會普遍，那麼就可以單獨拉出來做活動，周末的情侶出遊，就可以試圖做一些促銷活動等等。

至于交互，用戶點擊相應活動頁，彈出頁面頂上應該有分欄作為提示，目的是在下拉的過程中讓用戶清楚知道自己所在的位置和還有多少類目，做一提示，同時，分欄也有篩選的作用，或者說直接在數據庫所對應的商品表增加一欄，目的是記錄當前所有的商品狀态（正價，打折，XX活動等），直接使用搜索結果即可。說到這裡，我覺得搜索功能是否可以改善一下，增加一個類目是活動項，顯示的結果是不同産品正在進行促銷或者根據當前各種活動的不同來做篩選，是不是更好呢。

同時，既然是刺激消費，應該還有一個需求是優惠券，這個更多的邏輯應該是産品需求，目的就是刺激消費，所以邏輯上應該是越易用越好，否則，如果出現，選了半天，發現券不能用（有些店的商品是不能使用券的，但是并沒有任何提示），我觀察過我幾個同學在這一步的反映，直接關閉糯米，大概2.3次之後就卸載了..優惠券成了一個搬石砸腳的行為，很奇怪他們的設計人員是如何想的，不好用的看似有利于消費者的行為都會讓他們覺得你是騙子，這樣的結果往往還不如不做。批判完了，考慮交互行為，最原始的優惠券的整個流程應該是，首先，在店面附近發給你一張優惠券，強調在哪個或者哪些店裡可以使用，使用的前提是什麼，那些不包含在優惠範圍内，之後，用戶判斷是否需要去消費，同理，APP内的優惠券也可以應延用這個邏輯，首先，領取券後在搜索欄可篩選出使用的優惠券的店鋪和商品，然後之後的流程跟搜索本身一緻。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!