冷静下来重新思考小程序

话说，各位返工快乐。感叹下，2017年的小目标还没有开始实现，就已经默默过去了1/6。

春节期间，面对面红包在我的“鹅厂”朋友圈中火得一塌糊涂，但是似乎它对我家乡人民的影响力远远小于16年的摇一摇红包。尽管有小龙哥亲自上阵演示，然而面对面红包在这个春节的热闹还是止步于鹅厂内部。

在繁花似锦的微信派产品中，我对小程序尤为感兴趣。到今天，小程序已经正式开闸差不多1个月左右，或许正好是可以冷静下来再重新去思考小程序的最好时间。

我花了不少时间阅读小程序的开发设计文档，以及使用和体验了第一批问世的小程序，希望从中窥见小龙哥的一些观点，以及看看小程序未来是不是能够不仅仅止步于腾讯内部。

相信每个优秀的产品经理的梦想都是创造一个产品帝国，在自己的帝国内能够有完整的自闭环和生态。于是小龙哥创建了微信帝国，其主要的价值观是“连接一切”。

他还说很多程序员包括自己的梦想就是：

“除了自己去写一个程序，再去写一个能运行程序的程序”。

所以仔细分析和观察小程序，发现这就是现阶段一个凝聚了小龙哥“运行程序的程序”和微信“连接一切”梦想的集合体。但是从已经被开发出来的小程序来说，大部分的产品经理和开发者显然并没有参透小龙哥的苦心。

于是，笔者从1月9号首发上线的小程序中随机挑选了50+款小程序去认真进行了体验，并试图去思考它们在微信小程序体系下新增的用户价值是怎样的。然后，就有了你现在正在阅读的这篇文章。

本文大约会结合我的思考分以下3个方面来展开——

一、阐述微信小程序平台的开发、产品优势；

二、剖析首发阵容的小程序是否很好地利用到了这种优势来实现“能运行程序的程序”和“连接一切”的野心；

三、挑选出几个典型小程序，来思考是否有更好的产品表现形式，以及接下来产品经理可以怎么玩。

此外，本文也会基于开发者和产品经理的角度来谈一些我的观点。下面我逐次来说。

我在1月9日内测前就在滴滴内部得到了公司内部小程序的体验机会，当时的第一感觉是：这不就是一个加载速度快、体验更加接近原生的H5嘛？大家的期望未免也有点儿太高了。

但，我仔细研究下来过后，才发现远不如自己想象的简单。

小程序无论是从获取微信接口的能力还是体验上，比嵌入微信的h5网页都超出一个level。

小程序开发框架的目标是通过尽可能简单、高效的方式让开发者可以在微信中开发具有原生 APP 体验的服务。这是小程序框架介绍中的第一句话，其实不止是开发框架，整个小程序的思路都是围绕它的。重点是，微信像是一个操作系统，结构化地提供了很多原生解决方案。

小程序框架上具有的四个特性为：响应的数据绑定、页面管理、基础组件、丰富的 API。

前两个属于较为底层的技术实现框架，不充分展开，简而言之就是通过微信自有的框架，让小程序天生具有页面切换无缝，数据响应速度更快的能力。

基础组件也只是一种技术实现形式，微信包装出来的组件在自有的框架下相信是兼容得最好的，并且大大的节省了开发者人力码代码的时间，至于有技术大牛一定要自己实现，就先收下我的膝盖不多说了。

丰富的API，在效果上可以说完胜微信公众号的接口。我们以“获取用户地理位置”这一需求为例在二者间进行一个简单的对比：

可见在小程序下，微信通过某种方式让能力升级了。从单纯的地理位置，到“速度”这样的移动情况特征，以及不在当前页面时也能持续的获取。可以想象的是，小程序的应用场景将会得到极大的扩充。举个最简单的例子：

在设计规范上，微信使用了简洁、贴近于原生的样式，并且在加载、导航、反馈，甚至按钮的排布上都有统一的规范，所以市面可见的小程序，在交互形态上都能够保证最为基本的流畅和简洁。例如：典型的程序进入加载等待体验优于鱼龙混杂的h5体验。

微信小程序的设计规范，被我老板认为是非常简洁的不错的产品交互设计模板，确实很值得产品经理和交互设计师学习揣摩。

基于以上的开发框架和设计原则，微信小程序与其说是小程序，更不如说是一个能够快速孵化、创造无数小程序的生态系统。也就是小龙哥所说的“能够运行程序的程序”。

张小龙在微信公开课上描述了这样一个场景：

在移动互联网之后会是什么样的一种形态？有可能是一种类似于眼镜这样的设备，它会成为我们主流的一个设备。当眼镜变得非常非常的智能化的时候，可能整个PC或者电脑的系统会藏在一个眼镜里面。

我更加希望的是眼镜里面不要再给我一些安装应用程序这样的过程，因为那个是很不自然、很不方便的，我更加希望我的眼镜看到哪里，相关的应用程序就到哪里。

在现在看来这是一个相当理想化的生活场景，依赖于硬件之间的相互打通，但是小程序这种精妙的设计将这个场景脱离硬件的升级，准确的还原出来了。

我们把手机的摄像头扫描的二维码的动作看成眼镜视线所及的过程，小程序无需下载快速的加载，即消灭了应用安装的过程，相当于“眼镜看到哪里，相关的应用程序就到哪里”。接下来要做的事情便是大量的开发者设计大量的小程序将它们的二维码印在所有物品上。小龙哥所描述的场景就鲜活的呈现了。

真正实现了即用即走，所见即所得，连接一切，这便是小龙哥脑海中的下一个互联网形态，他寄希望于“小程序”可以实现这些。

下面我们再来看看最先一批小程序的开发者们是怎么来对小龙哥想象中的这个世界进行响应的。

笔者先说自己观察过后的结论：大部分的小程序开发者是不合格的，缺乏应用场景的生搬硬套，仅仅把小程序当成了升级版的h5，生产出来的产品简直是食之无味、弃之可惜，甚至导致了用户在使用小程序的同时卸载自家产品的危机。

于是，在小程序出来后，不少产品都面临着“用户把原有APP卸载了”的尴尬。

比如，在小程序上线的当天晚上，我们的一个早期用户群众就有用户展开了议论：

下面我再来逐一进行分析。

我在试用的50+个小程序中，挑选出了几个好坏不一的小程序为例，试着说明下为什么当前的小程序大多数都是不合格的。

根据笔者的观察，这些表现不佳的小程序基本可以分为两类，一类是纯线上服务，另一类是完全复制原生App的小程序。下面我们结合实际例子来分析一下为什么这两类的小程序注定难以出彩。

我觉得，这些实际上都不是特别适合做成小程序。从小程序开发规范中也可以发现，游戏、直播、虚拟物品购买等功能均未开放，由此可见端倪：至少第一个阶段的“小程序”天然不是为了支持纯线上功能的。

我们以一个叫做汇率e的小程序来举例吧。由于基于小龙哥脑洞中的场景，微信没有给小程序入口，在搜索获取上也做得非常的严格。所以获取它需要由发现—小程序入口，输入“汇率e”这个不是很大众的名字精准查找到。

此外，如果在微信中纯线上进入汇率e小程序，用户路径是很长的——用户需要先搜索找到小程序，再打开，再进入操作使用。但是如果在手机任何一个浏览器（百度首页）中输入“汇率”二字，均会自动会出现汇率查询功能异形卡片。

两者PK，在一年可能只用到一次的旅行前触发查询汇率的场景下，百度首页完胜小程序，轻量且易于触达。

虽然在小程序在界面上比搜索异形卡片用户友好（见下图），但是汇率e这个小程序给用户带来的新增价值几乎为零，同时有非常高的使用门槛，所以这个小程序注定是一个鸡肋。

但同样是“查询”类的小程序，类似飞常准查航班、滴滴公交查询等小程序虽然在线上可能很难有出路，但这一类的小程序却很容易结合线下场景。

举个例子，在韩国，大多数公交车站上方都有一个显示屏，实时显示下一班次的公交车什么时候到站。

我们做个猜想——有了小程序之后，显示屏能够直接被替换成一张滴滴公交查询的二维码，用户通过微信扫码即可以获取同样的信息——这样一来，其实大大减少了政府设备和维护成本。

所以，笔者认为，更多小程序的突破口，更应该在线下。

这里我们再来看看“首发部队”里另一类典型的小程序——那些其实基本就是在复制原生APP功能和体验的小程序。

这类小程序的典型代表为大众点评+，其功能跟大众点评原生几乎没有差别，导致很多用户使用了之后首先卸载了原App，细节的差别是用户在小程序上无法看到完整的用户点评，需要在App上才能看到。

这种导流方式非常的不可取，转化率低且不说，还让使用小程序的用户在卸载了原生App之后体验不佳。

盲目复制原生的体验，带来的就是卸载装机量和用户体验的折损，我觉得大众点评要好好思考一下这个小程序的新增价值了。

我觉得其实大众点评完全可以基于点菜和共享餐费的角度去设计自家的小程序作为原生的补充。

三节课Luke老师设想的场景就更加地符合用户场景：4个人去吃海底捞，某人扫了一下桌子上的二维码，然后分享给四个人一起点，各自点自己喜欢吃的。然后下单、优惠券填写、AA付款，都可以很方便搞定哦。

如果大众点评能出具一款这样的小程序，在与线下结合上无疑是更近了一步。

并且以上类型的小程序，是和线下场景紧密结合的，也就是小龙哥预期的最大的小程序入口（另外一个是微信群分享）。

所以，还是再强调一遍：小程序的突破口，更应该在线下。

说归说，如果老板一定要让我这个产品dog来跟风做小程序怎么办呢？上面已经给出了两个使用场景，说明了其中一个大方向是通过扫码连接智能硬件（手机）解决现实生活中真实存在的问题。所以针对线下入口和使用场景，就不赘述了。

只再举一个例子：以后只要家电有二维码，所有的物理遥控器都可以被手机取代，小程序甚至能够提供近场遥控的通用方案，这点对于很多产品经理来说是可以考虑的。

接下来我们再讲另外一个大方向：微信群的分享传播。

例如：表情家园，这个小程序激发了我主动将它分享到微信群的欲望，并且也引起了朋友们的兴趣。

不知道微信后续会不会允许，在用户使用小程序制作出来的东西上带有该小程序的入口，即在我制作的表情下方增加上来源。

一旦允许，将会非常有利于“表情家园”这类病毒型小程序快速传播。

App分享出来的卡片是可自定义来源介绍的

小程序的分享更多的是希望能够带来一种新的协作的方式。

这是一个小龙哥在微信公开课上举的例子：

大家可能会做一个小程序，这个小程序是一个投票功能，当我把一个投票的小程序发到群里面的时候，意味着群里面的每个人可以立即启动这个小程序，并且利用投票，并且每个人可以看到其他人的投票。

对于一个群来说，这个小程序是带有每个人的登录状态的，大家访问的是同一个小程序的任务。基于这样群的任务，它是可以被群里面的所有人共享的，当任何一个人更新群里面小程序状态的时候，群里其他人都是可以看到的，基于这个想法你可以想象得到，可能会存在非常多的一些协作式的小程序。

其实Luke老师说的海底捞场景中也体现了用户协作的场景。

说了这么多，大家肯定猜到了，这也是小程序的另外一个重要流量入口：群分享。

关于小程序的分析就到这里了。希望能够给作为一个产品经理或者开发者的你，一些启发。（完）

PS：我有一个点子，希望做一个自己的小程序，有兴趣加入的朋友可以添加我的公众号：魔女Kiki的小世界，给我留言。俗话说，想法已经有了，产品经理也有了，就差一个全栈工程师了，会是你吗？哈哈哈。