面向微信的WebApp产品观

自从入行以来，本人的产品经理工作一直以移动端网站为主，也就是大家常说的WebApp。接触的时间久了，对WebApp这种产品形态产生了较多的认识和感悟，在这里分享给大家。希望给在这个方向上有工作需要的同学，带来一些帮助。

WebApp与NativeApp的对比

这已经是老生常谈了，网上的分析文章一搜一大堆，我相信只要是合格的移动产品经理，对这个问题都能回答的八九不离十。所以关于WebApp与NativeApp，我只想谈其中一点，也就是它们之间差距最大的地方：NativeApp需要下载安装，而WebApp不需要。

最开始我以为这是WebApp的优势所在，后来发现自己真的是too young too simple。原来这世上，你在某些方面的优势，会成为埋藏在另一个地方的祸根。NativeApp初次使用的门槛高，但一旦下载，产品就能在用户的手机桌面获得一个稳定的入口，只要不卸载，用户和产品就有可能产生持续的连接，这是WebApp所办不到的。在实际的工作中我发现，通过手机浏览器把网站保存在桌面这个功能，90%的用户要么不会，要么不习惯。

WebApp虽然在便捷性上胜出，但在入口这件最重要的事情上却输的彻底。过去业界一直在谈论WebApp与NativeApp之争谁胜谁负，现在看来毫无疑问是NativeApp压倒了WebApp，手机浏览器也不再是移动互联网中最重要的入口。而且智能手机时代发展到现在，用户的使用习惯基本已经建立，个人认为WebApp再翻盘的机会也不大。

为什么还要做WebApp

Web端和客户端是互联网的两种最典型的产品形态，PC时代Web端更强盛，智能手机时代则是客户端更主流。在不同历史时期会出现一强一弱的格局，但谁也没有能力把另一方打垮、消灭，反而会相互融合，产生新的产品形态（Hybrid APP）。

所以，哪怕不是目前的主流，WebApp依然有它的生存空间，也能活的很好。这也是我目前依然从事WebApp产品工作的意义。那么，哪些领域和场景是适合WebApp发展的呢？我的经验是：轻体验、轻入口、重传播、重转化。

怎么理解呢？就是指那些对产品体验要求没那么高，不在意用户是否每天固定访问（相对而言），重视单个页面的传播率和转化率的领域。比如媒体、微商、官网、营销活动等等。

另外，很多互联网公司产品都是横跨多个平台的，虽然从战略意义上讲，手机web端往往只能排第三，要么PC端第一，要么APP第一。但谁不敢忽视手机web端给其他平台产品带来的传播和引流作用。

面向微信的移动网站设计

写到这里，其实一个结论已经呼之欲出：社交网络是满足WebApp特性最好不过的生长土壤。社交网络用户基数大，传播效应强，内容时效性短，天生就适合WebApp的使用场景，所以我们在微信中越来越多地看到别人分享的网站链接，以及各种花哨炫酷的H5网页活动。

相信很多细心的产品同学应该能留意到，同一款产品，在微信上和手机浏览器上会是不一样的两个版本。那么，为什么要面向微信单独设计一个产品版本？基于微信的WebApp和基于手机浏览器的WebApp有哪些差异？这也是我这篇文章要重点向大家说明的内容。

微信是目前国内移动互联网最具核心地位的一款APP，也是最大的移动流量入口。它是如此的重要，以至于创业者完全有必要单独设计出一个版本，来迎合微信的产品特性，或者说是，适应微信生态里的游戏规则。在微信内使用WebApp，实际上就是用微信内置的浏览器来打开网页，它与其他浏览器上的WebApp，有以下几个方面的不同：

1.注册登录

浏览器上的WebApp只能通过邮箱或手机号注册登录，没办法像PC站点或NativeApp那样使用第三方账号登录，相关的接口迟迟没有放开。但微信内网页可以通过授权，获得用户的微信ID、头像、名称等，从而达到免注册登录的效果。这一操作极大地降低了用户进一步使用产品功能的门槛，给WebApp获取注册用户带来方便。所以在设计微信内WebApp的注册登录时，必须要把微信登录这一因素考虑进去。

2.导航设计

NativeApp通常会采用底部一级导航，顶部二级导航的信息架构，这样做的好处是让一、二级导航在上有很好的区隔，同时底部一级导航更方便用户点击。但对于WebApp而言，浏览器窗口本身就占据了屏幕不少的空间，再把导航固定显示的话，内容展示的区域就更小了。比如淘宝WebApp在iPhone5s上就会是这样的效果：

尤其是浏览器底部操作栏，跟WebApp的一级导航放在一起，感觉非常别扭，所以WebApp采取这种导航结构的并不多见。但在应用在微信内的WebApp就不一样，它的设计可以趋同于NativeApp，因为微信内置的浏览器底部没有固定显示的工具栏，同时，把底部导航设计得和微信APP一致，会让用户以为并没有脱离微信，从而产生熟悉感和安全感。

所以我们可以经常看到，点击某些公众号的底部菜单，明明已经跳转到某个外部WebApp上了，但感觉上还是像停留在公众号里面。

3.头部设计

对于一个网站来说，头部设计是要花很大精力的，它代表了一个产品给人的第一印象。特别是网站logo，老板可能会纠结好长时间。微信内WebApp在这一点上就又不一样了，因为微信自带了一个头部，同时还会显示当前的网页名称。所以，一般的网站在微信内会出现两个头部，一个是微信的，一个是自己的，显得冗余并浪费空间。比如唯品会：

我们再来看看京东是怎么做的：

京东很巧妙地把原本属于头部的品牌logo、搜索框放在了banner图上，同时加大了banner的高度。这样既避免了双头部的美观问题，又让banner图更大更有冲击力。果然还是儿子最懂爹的心事啊。

用于微信的WebApp，采用无头部设计会在视觉上感觉更清爽。参考案例：

4.分享

从浏览器打开的WebApp，是没办法把某个页面分享到微信的。所以几乎每个NativeApp都会在内容页提供分享按钮，但在对应的WebApp上，很少有这个按钮，这也就意味着浏览器内的WebApp缺失传播功能。这一点在微信上得到了弥补，微信网页通常会提供分享操作，但这个操作并不是真的把该网页分享出去，而是出现一个弹出层提示：点击微信右上方的分享按钮。

这种曲线救国的分享方式，想必大家已经司空见惯了吧。千言万语化成一句话，都是微信给逼的啊。。

WebApp在微信和手机浏览器上的不同表现形式，很多都是Web端和客户端之间的通信不顺畅造成的，这其中既有技术层面的原因，也有公司或产品从商业利益出发，主动设置的障碍。技术上的问题，到最后肯定都不是问题。但人为的因素，就很难说了。毕竟在互联网的江湖里，什么样的竞争手段都出现过，而封锁与封杀，只是其中之一罢了。

有关微信WebApp设计的差异，就先分析归纳到这里。以上我所说的，当然不是事情的全部，等我产生新的灵感之后，再分享给大家吧。

 

作者：李翔  微信号：haoyuebinghe，电商产品经理  以梦喂马 便得自由

本文由 @haoyuebinghe 原创发布于人人都是产品经理 ，未经许可，禁止转载。