实战经验|如何找到小程序的最佳切入点?

零基础学产品,BAT产品总监带,2天线下集训+1年在线课程,全面掌握优秀产品经理必备技能。了解详情

我能做的就是,做好手头的事情确保,就算这事对公司来说又黄了,我也要通过这事有所收获。

(一)

产品定位:微信小程序是一种全新的连接用户与服务的方式,它可以在微信内被便捷地获取和传播,同时具有出色的使用体验。

这是微信小程序的官方定义,不妨一起画一画重点。我觉得有三个关键点:

  1. 被定义为一种连接方式:很显然,与微信社交的调性不谋而合,小程序是一种全新的产品能力,微信社交连接能力的二次延伸。
  2. 连接的对象是用户和服务:很清楚,微信连接的是“人与人”,而小程序连接的是“用户与服务”。这一切都基于已有的微信生态圈,是微信OS对APP生态方式的一次挑衅。
  3. 微信内获取和传播:很无奈,一切都要基于微信,从工具兼内容产品升级到平台产品,成为现有玩法的规则制定者,我的地盘、我做主!

以上三点是我个人对小程序的解读,也可以用三个字概括:很封闭、厚背景、新旧事物

近期负责公司的一款微信小程序产品,近乎涉及到了很多问题,其中有几组比较矛盾的问题

1、小程序定位

对于公司而言,小程序究竟是一个什么产品定位?以目前的大环境而言,无非就是几个关键点:

  • 蹭一波热点,吸引眼球,做小程序这件事情本身就是一个吸引眼球的事情;
  • 延伸产品线,对已有产品线做一个开辟,确保整个线的完整性;
  • 借助小程序,赶上这趟车,营销导流;
  • 跟风随大流,别人做了,我也要有。(无法忽略)

2、产品结构

相信绝大多数的产品的功能和结构体系都比较完善,即使再差,一套完整的流程还是有的。那么,面对小程序的这个新生事物,究竟该从何做起?

  • 全部业务功能,都要有;
  • 核心业务流程,必须有;
  • 专注关键要点,可以有。

3、资源投入

由于小程序的前景,以及目前对于该产品的投入产出比都相对比较保守,那么相应的资源投入都会相对比较缺乏,或者说并不是那么重视。

  • 集中投入,急速开发,先保证有;
  • 阶段投入,阶段开发,需要即用;
  • 持续迭代,增量迭代,保持机警。

(二)

公司对小程序的产品定位,直接决定产品形态的走向,也直接决定了公司的资源投入比例。事实上,小程序本身也是一个增量迭代的过程,逐渐开放能力,保持了产品应有的克制。针对以上所说的三组问题,下面将逐一回顾下我个人这段时间的实践经历。

1、如何决定小程序的产品定位?

很不巧的是,公司层面并没有明确给出小程序的定位,那么就不做呢?那肯定是不行,老板出去别人家都有小程序,我们怎么能没有?其实,这恰恰是给了产品经理充分的机会,可以尝试给小程序一个产品定位。于是,我就有了这么一次机会自己做了一回主(Leader是确认过的),给出了一个基于公司现状和行业特性的小程序产品定位。

小程序产品定位:基于知名品牌、高转化品类,以活动推单品的电商小程序。

说白了,一个基调:单品!赋予用户和平台两个能力:

  1. 能找到自己想要的商品
  2. 能展示平台想推的商品

第一个是对用户的赋能,更加依赖于用户自己的主观能动性,也吻合了小程序目前工具的定位,用完即走;第二个是对平台的赋能,是平台自身的商业属性决定的,能够曝光更多核心资源,进而吸引用户向平台转化。不管如何表达,如何定位,都必须体现产品的调性和情怀,这一点甚至远比一款小程序本身重要。

2、如何决定小程序的产品形态?

很尴尬的是,明明是小程序,领导却啥都想要?Are you kidding me ? 这让我想到之前有人说小程序会取代APP,之前我还不信;不过单纯从产品的功能上而言,确实有这个可能,而且可能性还很大。事实上,微信小程序是不可能那么快如愿的,其中的原委可就错中复杂了。

产品形态:电商平台的核心要素——商品、购物、结算。

很明朗,一个底线:购物!至少为用户提供两个要素:

  1. 商品,至少有东西可买;
  2. 购物,至少能下得了单;

第一个是为用户提供平台的绝大多数商品,至少先保证电商平台的核心——商品的完整性,即使暂且达不到多样性的效果。第二个是保证用户能够在获得商品的基础上,获得一个相对完整的购物流程。其中我们也做了妥协,1.0版本并未加入购物车的功能,只能随了电商早些年的做法——单件购买。出于产品阶段和资源的投入程度,只能选择产品的有损设计。

3、如何决定小程序的资源投入?

很无奈的是,纯粹依靠产品经理是搞不定这个问题的,因为技术资源的投入非产品经理可靠范围之内,越级越权可是大忌。不过,有一点可不要忘了——这是BOSS想要的,谁敢不做?感觉有点逼宫的意味,可大家还是愿意乐此不疲。学会适当适时借力是一种智慧,对产品经理尤为重要,再也不怕没人DIAO我呢!

资源投入:一切从实际出发,增量迭代,数据驱动。

很明确,一个原则:克制!至少要为项目提供两点保障:

  1. 有人做事
  2. 有时间做

第一个是为了落实小程序需要的必要投入,没人肯定没法做事,东拼西凑的,最终出来的肯定就是残次品,坑害的是参与的一票人。第二个是团队争取的资源,因为小程序大多基于已有产品的既视感,有一种先入为主的感觉,认为不都是现成的吗?有那么难吗?可我遇到的还真不是搬运工的活,别后夹杂了太多的辛酸,因此必要的前期时间投入是为后续产品的良好更迭的打基础。

(三)

产品实例:

在整个微信小程序的产品设计过程中,最为纠结的一个点:账户登录。其实,并不是由于功能本身的纠结,而是用户体验/心理与账户信息结构的矛盾。

问题描述:小程序牵涉到微信授权的问题,就相当于APP的应用授权,比如:获取地理位置、PUSH推送通知等。

可能存在的三种纠结的解决方案:

  • 不提供微信授权,只提供已有账户体系;
  • 提供微信授权,进入小程序强制微信授权;
  • 提供微信授权,同时提供已有账户体系。

泛泛的概括下,上述三种方案可能遇到的问题:

  1. 微信账户与已有产品Passport账户合并;
  2. 用户拒绝微信授权或者直接开放微信账户购买能力;
  3. 用户既有账户登录的最短登录路径。

导致这些问题的原因大多不一,可能是已有账户的导致,可能是对用户体验的妥协,也可能是产品经理个人对方案的倾向性选择。不管为什么,问题终究要解决,综合考虑了以下三个要素:

  1. 普遍解决方案
  2. 用户心理/体验
  3. 技术壁垒/限制

下图为最终的小程序的完整产品解决方案,仅供参考:

小结

扯了这么多,到底该从何入手呢?产品经理的基本思维和技能就不再赘述了,解决上面我说的三个问题,产品基本已经上路了。实际工作中,有两点需要兼顾:

  1. 微信平台
  2. 自有产品

微信作为平台方,对小程序制定了一系列的规则(最深页面层级不超过五层,以确保消息程序的结构清晰),对小程序的产品能力进行了约束,并且保持克制持续开放。不难看出,作为平台型产品,小程序本身也在自我迭代自完善,产品能力逐渐完善,还是很有产品感、保持了良好的节奏感!

如何把握小程序和自有产品框架下的分寸,需要产品经理额外投入时间和经理,理解到位。任何的新产品线,都不能以牺牲已有产品结构为代价都是不可取的。

#专栏作家#

王伟,@简书-互联网产品小王。一个会讲故事的产品人,喜欢做菜、乐于家务、懂生活的工科男,将理想照进现实的布道者。

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

祝给予赞赏的伙伴,2017年发大财!
6人打赏

评论( 24

写下你的想法
  1. 测试专员

    你好!请问下流程图后半部分中”已绑定微信?”判断为“是”的情况下“重新输入”是什么意思?有点不理解 :x

    回复
    1. 回复

      不好意思,又被发现一个细节问题错误:应该是否,感谢指正! :twisted:

    2. 那这里是“否”的话,就是将授权的微信账号覆盖绑定到输入的手机号上了?然后登陆同步用户信息?

    3. 回复

      其实就是一个场景故事:该手机已经注册,并且已经已经绑定了其他微信,则提示该用户尝试绑定其他账号!可否留个微信,交流下!

    4. 再仔细看一次,应该把那个是去掉,其实就是个分支流程

    5. 1.那就相当于输入手机号后判定是已注册的账号,就直接登陆;是新手机号就绑定授权的微信再登录?
      2.如果把这里去掉,那每次登录已注册的手机号按照流程都要重新获取一下验证码才可以了?

    6. 回复

      你需要仔细了解下整个流程,不要紧盯着哪一款,那个场景有一个前置条件——必须微信收授权登录小程序! ;-)

    7. 问下,微信授权登录后,在使用手机号登录,那会将授权微信和手机号绑定在一起吗?

    8. 回复

      故事一:
      在微信上,用户第一次使用小程序,启动小程序提示用户微信授权:
      如果用户接收微信授权,则直接进入小程序首页;
      如果用户拒绝微信授权,则提示用户[使用微信小程序需要微信授权,您已经拒绝了该请求,请删除小程序重新进入],无法进入小程序;

      故事二:
      在微信上,用户第一次使用小程序,启动小程序并且用户接受微信授权:
      如果该用户是老用户并且绑定此微信账户,则不再为该用户提供手机绑定功能;
      如果该用户并不是老用户,则提供该用户账号绑定功能;

      故事三:
      在微信,用户第一次使用小程序,微信授权登录后并不是老用户,并且绑定手机号:
      如果用户的手机号已经注册,则同步该用户的账户信息;
      如果用户的手机号未注册,则将该微信与该手机绑定;

    9. 抱歉刚刚有事没来得及回,你说的故事三的第一种情景应该也有两种情况:
      1.手机号已注册且未绑定微信号,这时手机号直接绑定前面授权的微信账号(手机号绑定微信号这一步流程图上没有说明)
      2.手机号已注册且已绑定其他微信号,这时手机号绑定的微信号应该会被前面授权的微信号覆盖绑定(流程图上有这个分支不过注明的操作是“重新输入”)

    10. 回复

      你这不就明白了吗?我的图只是参考参考并不是绝对完整的图,至于第2点,我们是不允许覆盖的,是一一对应的关系,如果尝试解绑需要去客户端解绑再绑定! ;-)

    11. 回复

      你再仔细看看 ;-)

    12. 我看了看作者跟小筑的交流内容,对此我个人的理解如下:
      1 这款小程序是作者对公司已有原生产品的一个延伸,两边的数据应该是打通的,这也是流程图中可以“同步账户信息”的原因。(由此可推测用户在原生产品端是有唯一注册的手机号的)
      2 既要同步账户信息,又要避免账户体系的冗余度,所以授权微信号和手机号必须有一一对应的关系。微信号是新用户且手机号未注册是很好解决的,通过手机验证码登录的操作自动在后台注册并绑定授权的微信号即可,难点在于微信号是新用户但手机号却已注册。
      3 针对第二点的困难,我们需要考虑到用户可能是手机号没变,但需要切换微信号登录。此时可询问用户是否愿意换绑,即把注册的手机号与新微信号建立绑定,并解除旧绑定(注:此处绑定的含义并非是微信本身的绑定,而是系统后台自建的一一对用关系),用户同意后可在立即在后台换绑并同步账户信息后正常使用。 同时在老用户登陆时增加是否有绑定手机的判断,若没有则必须输入手机号并在短信验证通过后自动绑定/换绑,然后同步账户信息正常使用。 以上方案可在保证账户安全和账户一一对应关系的前提下给用户提供更灵活的登陆场景

  2. 一个会讲故事,喜欢做家务、做菜的产品人!

    可以的,原创很辛苦,也希望您能带上原文链接和作者简介,方便留个微信吗?我加一下您 ;-)

    回复
  3. 作者你好,我是一家支付公司的产品经理,最近也在构思为商户推出一个商品推荐的小程序,不知道方便加微信交流一下么,我的微信号:michaelhust

    回复
    1. 回复

      阔以的,已经加了! ;-)

  4. 需求分析员

    最后一段中“额外投入时间和经理”,“经理”应为“精力”;“都不能以牺牲已有产品结构为代价都是不可取的”应该改为“以牺牲已有产品结构为代价都是不可取的”或“都不能以牺牲已有产品结构为代价”

    回复
    1. 首先非常感谢你的细心阅读,其次不好意思,文章出现了低级错误,我已经开始修改原文,请多见谅!

    2. 恩没事

  5. 流程中有个问题,我有不同的意见,多个微信号是可以绑定同一个手机号的。是多对一的关系,并不是一对一的关系。

    回复
    1. 回复

      在技术上,确实可以多个微信绑定一个手机,如果账户建设没有足够或者一些特殊的行业,如此会存在账户安全风险,并且账户结构也会有过于冗余!

  6. 欣赏作者写的这篇关于小程序的文章,请作者允许我转载到微信公众号UI设计窝,谢谢了

    回复
    1. 回复

      阔以的!需要标注下原文链接!

推荐阅读