冷靜下來重新思考小程序

本文作者Kiki醬，三節課3.3計劃第三期學員，現任滴滴出行產品經理。

她的自白——

「來帝都2年，畢業時拒絕阿里選擇了滴滴，成為第一個滴滴的校招產品經理。愛旅遊，愛Elon Musk，夢想是成為一個不物質，精神富足的小網紅 ；)」

話說，各位返工快樂。感嘆下，2017年的小目標還沒有開始實現，就已經默默過去了1/6。

春節期間，面對面紅包在我的「鵝廠」朋友圈中火得一塌糊塗，但是似乎它對我家鄉人民的影響力遠遠小於16年的搖一搖紅包。儘管有小龍哥親自上陣演示，然而面對面紅包在這個春節的熱鬧還是止步於鵝廠內部。

在繁花似錦的微信派產品中，我對小程序尤為感興趣。到今天，小程序已經正式開閘差不多1個月左右，或許正好是可以冷靜下來再重新去思考小程序的最好時間。

我花了不少時間閱讀小程序的開發設計文檔，以及使用和體驗了第一批問世的小程序，希望從中窺見小龍哥的一些觀點，以及看看小程序未來是不是能夠不僅僅止步於騰訊內部。

相信每個優秀的產品經理的夢想都是創造一個產品帝國，在自己的帝國內能夠有完整的自閉環和生態。於是小龍哥創建了微信帝國，其主要的價值觀是「連接一切」。

他還說很多程序員包括自己的夢想就是：

「除了自己去寫一個程序，再去寫一個能運行程序的程序」。

所以仔細分析和觀察小程序，發現這就是現階段一個凝聚了小龍哥「運行程序的程序」和微信「連接一切」夢想的集合體。但是從已經被開發出來的小程序來說，大部分的產品經理和開發者顯然並沒有參透小龍哥的苦心。

於是，筆者從1月9號首發上線的小程序中隨機挑選了50+款小程序去認真進行了體驗，並試圖去思考它們在微信小程序體系下新增的用戶價值是怎樣的。然後，就有了你現在正在閱讀的這篇文章。

本文大約會結合我的思考分以下3個方面來展開——

一、闡述微信小程序平台的開發、產品優勢；

二、剖析首發陣容的小程序是否很好地利用到了這種優勢來實現「能運行程序的程序」和「連接一切」的野心；

三、挑選出幾個典型小程序，來思考是否有更好的產品表現形式，以及接下來產品經理可以怎麼玩。

此外，本文也會基於開發者和產品經理的角度來談一些我的觀點。下面我逐次來說。

一、小程序平台的優勢到底在哪裡？

我在1月9日內測前就在滴滴內部得到了公司內部小程序的體驗機會，當時的第一感覺是：這不就是一個載入速度快、體驗更加接近原生的H5嘛？大家的期望未免也有點兒太高了。

但，我仔細研究下來過後，才發現遠不如自己想像的簡單。

小程序無論是從獲取微信介面的能力還是體驗上，比嵌入微信的h5網頁都超出一個level。

1. 開發層

小程序開發框架的目標是通過儘可能簡單、高效的方式讓開發者可以在微信中開發具有原生 APP 體驗的服務。這是小程序框架介紹中的第一句話，其實不止是開發框架，整個小程序的思路都是圍繞它的。重點是，微信像是一個操作系統，結構化地提供了很多原生解決方案。

小程序框架上具有的四個特性為：響應的數據綁定、頁面管理、基礎組件、豐富的 API。

前兩個屬於較為底層的技術實現框架，不充分展開，簡而言之就是通過微信自有的框架，讓小程序天生具有頁面切換無縫，數據響應速度更快的能力。

基礎組件也只是一種技術實現形式，微信包裝出來的組件在自有的框架下相信是兼容得最好的，並且大大的節省了開發者人力碼代碼的時間，至於有技術大牛一定要自己實現，就先收下我的膝蓋不多說了。

豐富的API，在效果上可以說完勝微信公眾號的介面。我們以「獲取用戶地理位置」這一需求為例在二者間進行一個簡單的對比：

公眾號：用戶同意上報地理位置後，每次進入公眾號會話時，都會在進入時上報地理位置，但離開會話後，介面不可繼續被調用。

小程序：自動獲取當前的地理位置、速度。當用戶離開小程序後，原則上此介面無法調用；但當用戶點擊了「顯示在聊天頂部」時，則此介面在用戶離開後可繼續調用。

可見在小程序下，微信通過某種方式讓能力升級了。從單純的地理位置，到「速度」這樣的移動情況特徵，以及不在當前頁面時也能持續的獲取。可以想像的是，小程序的應用場景將會得到極大的擴充。舉個最簡單的例子：

在微信共享實時位置的時候任何一方都不能離開會話窗口，否則將會退出位置共享（見下圖），但是假如有一個共享實時位置的小程序被置頂「顯示在聊天頂部」，你就可以同時跟其他的朋友一邊聊天一邊共享實時位置了。

2. 交互體驗層

在設計規範上，微信使用了簡潔、貼近於原生的樣式，並且在載入、導航、反饋，甚至按鈕的排布上都有統一的規範，所以市面可見的小程序，在交互形態上都能夠保證最為基本的流暢和簡潔。例如：典型的程序進入載入等待體驗優於魚龍混雜的h5體驗。

微信小程序的設計規範，被我老闆認為是非常簡潔的不錯的產品交互設計模板，確實很值得產品經理和交互設計師學習揣摩。

基於以上的開發框架和設計原則，微信小程序與其說是小程序，更不如說是一個能夠快速孵化、創造無數小程序的生態系統。也就是小龍哥所說的「能夠運行程序的程序」。

二、首發選手們的表現怎樣？

張小龍在微信公開課上描述了這樣一個場景：

在移動互聯網之後會是什麼樣的一種形態？有可能是一種類似於眼鏡這樣的設備，它會成為我們主流的一個設備。當眼鏡變得非常非常的智能化的時候，可能整個PC或者電腦的系統會藏在一個眼鏡裡面。

我更加希望的是眼鏡裡面不要再給我一些安裝應用程序這樣的過程，因為那個是很不自然、很不方便的，我更加希望我的眼鏡看到哪裡，相關的應用程序就到哪裡。

在現在看來這是一個相當理想化的生活場景，依賴於硬體之間的相互打通，但是小程序這種精妙的設計將這個場景脫離硬體的升級，準確的還原出來了。

我們把手機的攝像頭掃描的二維碼的動作看成眼鏡視線所及的過程，小程序無需下載快速的載入，即消滅了應用安裝的過程，相當於「眼鏡看到哪裡，相關的應用程序就到哪裡」。接下來要做的事情便是大量的開發者設計大量的小程序將它們的二維碼印在所有物品上。小龍哥所描述的場景就鮮活的呈現了。

真正實現了即用即走，所見即所得，連接一切，這便是小龍哥腦海中的下一個互聯網形態，他寄希望於「小程序」可以實現這些。

下面我們再來看看最先一批小程序的開發者們是怎麼來對小龍哥想像中的這個世界進行響應的。

筆者先說自己觀察過後的結論：大部分的小程序開發者是不合格的，缺乏應用場景的生搬硬套，僅僅把小程序當成了升級版的h5，生產出來的產品簡直是食之無味、棄之可惜，甚至導致了用戶在使用小程序的同時卸載自家產品的危機。

於是，在小程序出來後，不少產品都面臨著「用戶把原有APP卸載了」的尷尬。

比如，在小程序上線的當天晚上，我們的一個早期用戶群眾就有用戶展開了議論：

下面我再來逐一進行分析。

1. 為什麼首發陣容慘遭滑鐵盧？

我在試用的50+個小程序中，挑選出了幾個好壞不一的小程序為例，試著說明下為什麼當前的小程序大多數都是不合格的。

根據筆者的觀察，這些表現不佳的小程序基本可以分為兩類，一類是純線上服務，另一類是完全複製原生App的小程序。下面我們結合實際例子來分析一下為什麼這兩類的小程序註定難以出彩。

我覺得，這些實際上都不是特別適合做成小程序。從小程序開發規範中也可以發現，遊戲、直播、虛擬物品購買等功能均未開放，由此可見端倪：至少第一個階段的「小程序」天然不是為了支持純線上功能的。

我們以一個叫做匯率e的小程序來舉例吧。由於基於小龍哥腦洞中的場景，微信沒有給小程序入口，在搜索獲取上也做得非常的嚴格。所以獲取它需要由發現—小程序入口，輸入「匯率e」這個不是很大眾的名字精準查找到。

此外，如果在微信中純線上進入匯率e小程序，用戶路徑是很長的——用戶需要先搜索找到小程序，再打開，再進入操作使用。但是如果在手機任何一個瀏覽器（百度首頁）中輸入「匯率」二字，均會自動會出現匯率查詢功能異形卡片。

兩者PK，在一年可能只用到一次的旅行前觸發查詢匯率的場景下，百度首頁完勝小程序，輕量且易於觸達。

雖然在小程序在界面上比搜索異形卡片用戶友好（見下圖），但是匯率e這個小程序給用戶帶來的新增價值幾乎為零，同時有非常高的使用門檻，所以這個小程序註定是一個雞肋。

但同樣是「查詢」類的小程序，類似飛常准查航班、滴滴公交查詢等小程序雖然在線上可能很難有出路，但這一類的小程序卻很容易結合線下場景。

舉個例子，在韓國，大多數公交車站上方都有一個顯示屏，實時顯示下一班次的公交車什麼時候到站。

我們做個猜想——有了小程序之後，顯示屏能夠直接被替換成一張滴滴公交查詢的二維碼，用戶通過微信掃碼即可以獲取同樣的信息——這樣一來，其實大大減少了政府設備和維護成本。

所以，筆者認為，更多小程序的突破口，更應該在線下。

1.2 複製原生App體驗類小程序

這裡我們再來看看「首發部隊」里另一類典型的小程序——那些其實基本就是在複製原生APP功能和體驗的小程序。

這類小程序的典型代表為大眾點評+，其功能跟大眾點評原生幾乎沒有差別，導致很多用戶使用了之後首先卸載了原App，細節的差別是用戶在小程序上無法看到完整的用戶點評，需要在App上才能看到。

這種導流方式非常的不可取，轉化率低且不說，還讓使用小程序的用戶在卸載了原生App之後體驗不佳。

盲目複製原生的體驗，帶來的就是卸載裝機量和用戶體驗的折損，我覺得大眾點評要好好思考一下這個小程序的新增價值了。

我覺得其實大眾點評完全可以基於點菜和共享餐費的角度去設計自家的小程序作為原生的補充。

三節課Luke老師設想的場景就更加地符合用戶場景：4個人去吃海底撈，某人掃了一下桌子上的二維碼，然後分享給四個人一起點，各自點自己喜歡吃的。然後下單、優惠券填寫、AA付款，都可以很方便搞定哦。

如果大眾點評能出具一款這樣的小程序，在與線下結合上無疑是更近了一步。

並且以上類型的小程序，是和線下場景緊密結合的，也就是小龍哥預期的最大的小程序入口（另外一個是微信群分享）。

所以，還是再強調一遍：小程序的突破口，更應該在線下。

說歸說，如果老闆一定要讓我這個產品dog來跟風做小程序怎麼辦呢？上面已經給出了兩個使用場景，說明了其中一個大方向是通過掃碼連接智能硬體（手機）解決現實生活中真實存在的問題。所以針對線下入口和使用場景，就不贅述了。

只再舉一個例子：以後只要家電有二維碼，所有的物理遙控器都可以被手機取代，小程序甚至能夠提供近場遙控的通用方案，這點對於很多產品經理來說是可以考慮的。

接下來我們再講另外一個大方向：微信群的分享傳播。

2.1 自帶傳播類型的小程序，通過微信群建立連接

例如：表情家園，這個小程序激發了我主動將它分享到微信群的慾望，並且也引起了朋友們的興趣。

不知道微信後續會不會允許，在用戶使用小程序製作出來的東西上帶有該小程序的入口，即在我製作的表情下方增加上來源。

一旦允許，將會非常有利於「表情家園」這類病毒型小程序快速傳播。

App分享出來的卡片是可自定義來源介紹的

小程序的分享更多的是希望能夠帶來一種新的協作的方式。

這是一個小龍哥在微信公開課上舉的例子：

大家可能會做一個小程序，這個小程序是一個投票功能，當我把一個投票的小程序發到群裡面的時候，意味著群裡面的每個人可以立即啟動這個小程序，並且利用投票，並且每個人可以看到其他人的投票。

對於一個群來說，這個小程序是帶有每個人的登錄狀態的，大家訪問的是同一個小程序的任務。基於這樣群的任務，它是可以被群裡面的所有人共享的，當任何一個人更新群裡面小程序狀態的時候，群里其他人都是可以看到的，基於這個想法你可以想像得到，可能會存在非常多的一些協作式的小程序。

其實Luke老師說的海底撈場景中也體現了用戶協作的場景。

說了這麼多，大家肯定猜到了，這也是小程序的另外一個重要流量入口：群分享。

關於小程序的分析就到這裡了。希望能夠給作為一個產品經理或者開發者的你，一些啟發。（完）

PS：我有一個點子，希望做一個自己的小程序，有興趣加入的朋友可以添加我的公眾號：魔女Kiki的小世界，給我留言。俗話說，想法已經有了，產品經理也有了，就差一個全棧工程師了，會是你嗎？哈哈哈。

更多內容，請關注三節課（微信公眾號ID: sanjieke），一所互聯網人的在線大學。這裡有成體系的線上課程，有挑戰的線下實戰活動，以及有深度的產品運營觀察+評論。