复盘:一块去周边游APP的迭代历程

目录 产品, 工作感悟

2016年4月,我加入新公司,作为移动端产品经理开始接手一块去周边游APP的产品迭代工作。到2017年我离开时,一块去周边游APP的激活量由原来的7万增长至12万,增长了71%。与巨头竞品的百万用户体量相比,这个数字可谓不足挂齿。然而,如何通过产品迭代服务好这12万用户,却是我职业生涯中的一个充满挑战且宝贵的经验。在此复盘一块去周边游APP的产品迭代历程,重点总结在产品设计上未能解决的问题和缺陷,以吸取经验教训。

项目介绍

一块去周边游是专注于周边游领域的OTA产品,为用户推荐周边旅游目的地的酒店、门票、团购等产品信息,并提供完整的在线预订功能。移动客户端APP是官方产品售卖的主要渠道之一。
项目所切入的周边游市场,作为大旅游领域中的利基市场,充满了机遇与挑战。从需求上看,周边游并非刚需,却是一个衡量生活质量的重要消费行为,是一个消费升级类的产品。越来越多的人选择在周末或者小长假进行周边旅游,其需求频次也比传统跟团游、长途游更高。

用户是谁?用户需要什么?

目标用户是20~50岁的中青年人群,喜欢利用周末等小型假期在周边游玩,出行方式倾向于自驾游或自由行,对于传统跟团长途游的方式诉求不大。
周边游用户有一个明显的特征,即决策时间很短。有别于传统长途游需要提前一定时间了解、准备、预订,周边游的消费决策时间往往只提前一到两个工作日。典型的场景是用户在周五的晚上打开APP,挑选周末准备与家人自驾出行的目的地,并预订产品。有的用户甚至是即时决策,到了游玩目的地后才打开APP购买相应的产品。
结合以上分析,可以描绘出典型的用户画像如:

  1. 王先生。42岁,二线城市某民营企业老板,收入较高,拥有一辆越野车。与妻子育有一儿一女,儿女上小学。平时工作比较忙,陪伴家人时间少,喜欢在周末开车带领全家出游。偏好于亲子游,如游乐场、植物园、农家乐、科技博物馆等等。
  2. 郑白领。女,28岁,一线城市外企白领,收入中等,无房无车。未婚,喜爱周末与男朋友一起出游,享受二人世界。偶尔会与朋友数人结伴出游。出游方式多为租车自驾。偏好于登山、远足、温泉等项目。
  3. 颜同学。女,20岁,一线城市某大学在读本科生,热爱旅游,性格外向,喜欢与同学多人结伴周边游。出游方式多为公共交通(高铁、大巴等),对旅游产品强调性价比。偏好较广,游乐园、山水风光、民俗风情等都在可选择的范围。

这些用户的主要需求是:

  1. 获知周边有哪些好玩的地方。
  2. 获知其他用户对游玩地的口碑和评价,以辅助决策。
  3. 可以方便地完成在线预订。

我所负责迭代的功能

我是在中期接手的APP的迭代工作,未参与初期的立项和设计开发。此时整体的产品结构已经定型,并已上线运营了一段时间。因此我主要负责立足于用户体验对产品进行完善,补充缺乏的功能,优化存在问题的功能。刨去小的功能优化和bug修复,主要迭代的功能复盘如下:

    • 订单中心原生化。

订单中心是我负责的第一个需求。在此之前,为了快速上线运营,APP的订单中心是通过webview链接到网页版来简单实现功能的。这个方式虽然实现成本低,但存在几个问题:一、操作流畅度低,用户体验较差;二、界面风格缺乏一致性,不利于视觉传达;三、不利于功能的拓展性。客户端订单中心的开发,主要就是为了解决以上问题,发挥客户端的优势,使功能符合安卓与iOS的原生规范,并提升用户体验。在这个过程中面临的主要困难,一个是刚到公司,对业务还不够熟悉,另一个是由于公司缺乏必要的文档管理,已没有订单流程的历史文档可以查阅。因此我做的第一步工作是和负责各类别业务的采销人员请教,了解用户在现实业务中的消费流程;同时拉上后台产品和开发,通过整理现有资料和代码,理清了不同业务类型的订单状态和订单流转逻辑。在此基础上,我结合了实际的用户消费流程,将复杂的后台订单状态名“翻译”为容易理解的前台订单状态名,并将部分细分的状态合并为一个总状态,降低用户的理解成本,形成一个新的前台订单状态流转图并写入文档。

一块去周边游-订单中心

新版订单中心

    • 常用旅客信息的保存与快速选取。

对于同一个用户而言,出游人往往是固定的。常用旅客信息功能减少了用户每次下单时对旅客信息的重复输入,提升下单流程的用户体验。用户可将常用旅客的姓名、证件、手机号等信息保存在个人账户中,在下单时可以通过常用旅客列表直接点选出游人(如果需要临时添加常用旅客也可以在列表直接操作)。此外,我们还提供了默认出游人的设置,程序将自动填充默认出游人信息,最大可能地简化了用户在常规状态下的操作。

一块去周边游APP-常用旅客

常用旅客信息

    • 房型/门票产品详情页。

旧的详情页的层级只到了酒店、景区详情页,每个产品的信息聚合在酒店\景区详情页下,无法支持某些特定场景下单独展示某个产品的需要。比如运营在首页推荐了某一个单品,点击跳转的是景区或酒店的聚合页面,会增加用户定位该单品的成本,也影响运营推荐效果。因此增加了一个单产品的详情页面,用于展示特定产品的信息。同时特别增加了该产品详情页对限时促销运营活动的支持,被配置为限时抢购的产品将会显示活动倒计时,对于预热期和已结束的活动也会有不同的时间状态展示,从而帮助营造一种稀缺感。

一块去周比游APP-单品详情页

单产品详情页

    • 用户点评功能。

点评功能是解决用户获知产品口碑需求的一个重要方面,作为电商类APP中的一个非常重要的功能模块,一方面,其他买家的点评可以在用户的购买决策中提供重要的参考;另一方面,将点评融入订单流程中,可以增加用户参与感,形成内容沉淀,增强订单闭环。补充点评功能一直是用户和公司内部呼声较高的功能需求。点评这个功能可大可小,首要的是确定功能范围:对于点评的展示,需要的考虑的问题有:用户需要哪些参考的内容?通过什么方式让用户更加快速地获得有效的参考信息?在最后的方案中,除了基础的点评文字和图片外,我们增加了一些功能,一个是显示用户所购买的产品信息和出游类型,以提供更多参考;一个是“有用”功能,对于有帮助的点评用户可以点赞;一个是“精华点评”,由运营人员在后台筛选设置;另外我们将用户评分划分为差评/中评/好评三个层级,并将平均分和好评率统计了出来;此外还提供了便捷的筛选功能,用户可以将好评、中评、差评或者带图的评论独立筛选出来。
对于用户写点评的流程,要考虑的问题比如:是否是开放式的点评?如果不是,哪些订单状态之后才可以点评?点评的入口在哪里?需要多少页面完成点评?哪些是必填信息?如何把控点评质量?等等,在对这些问题的思考中逐步细化功能点。
最后,还要解决一个冷启动的问题:功能刚上线时如何获取第一批点评内容?这是一个需要产品部门和运营部门配合的事情,在这一块我做的不够充分。由于事先没有和运营部门沟通好资源,导致无法抽调人员负责点评内容的拉新运营,最后只能通过抓取友商的点评数据完成冷启动(打了知识产权的擦边球,实际上是不倡导的)。如果事先能和运营部沟通好方案,给予部分利益诱导用户参与点评(如优惠券),解决冷启动问题可能会更加优雅。

一块去周边游APP-点评

点评体系

    • 频道列表页的优化。

酒店/景区/团购/客栈/活动各个频道页的优化,主要是两部分内容:一是对原有列表的布局、交互、UI进行优化;二是引入新的信息元素,并对筛选功能进行拓展完善。旧的列表页的问题在于:1、使用pageview聚合五个业务列表,使得页面布局和交互方式被框架化。而随着业务的发展每个业务频道都会有越来越多的特殊的、独立的功能需求,这两者之间产生了矛盾;2、原有的信息展示缺乏主次,页面布局不合理,UI效果较差,导致用户获取信息的成本变大;3、筛选功能较弱,对酒店/景区等的筛选仅支持价格和级别,对于消费决策中的一些重要内容,比如位置区域信息、其他用户评价等信息没有展现,也不支持筛选。

一块去周边游APP-旧频道列表

旧的频道列表页

针对以上问题,我最终提出了这样的方案:首先,将每个频道拆分开来,形成独立的列表页,然后针对不同的频道设计不同的页面布局和筛选功能,同时去掉部分优先级不高的信息元素,引入新的对用户更有参考意义的信息元素。比如酒店频道,原来会显示该酒店是否有泳池、停车场、SPA等信息,然而我认为在用户初步筛选酒店的场景下,这些信息是次要的,所以在列表页我去掉了这些信息,引入了用户评分、点评数量、临近的商圈等优先级更高的信息;在布局上,调整了图片和文字的比例,使得视觉焦点更多落在文字区域,并结合UI的字体颜色、大小变化使信息形成主次对比。针对筛选功能,新增了对行政区、临近的商圈、地铁线路等地理位置特点的筛选。此外,对一些细节我也做了充分的考虑,比如地理位置筛选项数据是同步加载还是异步加载、列表数据不同加载状态的交互、空列表状态、筛选结果为空时如何处理等等。像筛选结果为空时,除了文案提示用户之外,还会列出用户所选择的所有筛选条件,用户可以通过点击快速删除某个筛选条件。

一块去周边游

新的频道列表页

    • 统一交互控件标准

由于公司没有专职的交互设计师,平日的工作里我还需要负责产品的交互设计。在这个过程中我发现了一个问题,即各个常用的交互控件没有统一的标准,产品方案多经手一个人,就可能多设计出一个版本来,各个控件的使用场景也没有做明确约束,增加了设计和开发的成本。于是我提出了规范APP的控件使用标准,比如规定了在轻提示的场景下使用toast提示,在需要用户明确知情的重提示场景下,使用Alert对话框进行提示。同时和设计师合作确立了控件的样式标准,比如toast弹层,在安卓上可以使用系统默认控件,在iOS上由于没有toast控件,需要自定义一个toast的样式。再比如,我们设计了几个加载动画并规定了其应用场景,比如在首次加载某个页面时使用加载占位背景图,在页面已存在内容但内容发生变化时使用浮层加载动画,在列表底部上拉加载更多内容时使用底部加载动画等,都做了明确的规定。规范了之后,控件管理起来更加方便,设计和开发的成本也相应降低。

一块去周边游APP-加载类控件

加载类控件示例

    • 首次在APP中引入数据埋点

在我的产品观中,我非常重视产品数据的作用,数据在需求分析中能反映出很多用户没有直接反馈的问题,在验证产品方案的有效性上数据也起了重要的作用。但是由于种种客观原因,公司此前缺乏对用户行为数据的积累,产品决策中多依赖定性分析。为了尝试改变这个现状,我首次在APP中引入了数据埋点。由于我和开发团队此前都没有这方面的经验,所以我第一步工作是查阅了资料,弄清楚了在APP内获取用户行为数据的不同方式及其技术原理,对比不同方案之后我们选择了使用友盟的SDK来进行埋点统计。然后我又将友盟的官方文档详细阅读了一遍,并根据要求梳理需要埋点的控件位置和对应地键值对提交给开发。在点评这个功能之后的所有功能需求中,我都加入了数据埋点,小范围地试验了埋点统计功能。比如在点评功能中利用漏斗模型监听提交点评流程的转化率,还有在频道列表页的筛选功能中记录不同城市的用户使用筛选功能时所选择的筛选项。以上两个例子带给我们的变化是,我们更加清晰的知道用户在app内的操作细节,运营同事也可以对不同城市用户的关注点有清晰的认知,便于调整运营策略,可以说影响是非常大的,更加深化了我对数据重要性的认识。后来我还做了一个APP内全局的埋点方案,希望能全面量化用户行为,可惜没能跟到上线。
扯一句题外话,我认为互联网产品的设计专业化是个大趋势,只有专业的理论和方法指导才能做出深入人心的产品。在具备流量红利的窗口期,仅凭一个idea和几张原型图快速制作出来的产品也能收获不少用户。但在C端市场已经饱和的今天,重视用户体验和数据反馈,用科学的方法和工具(用户研究、A/B测试、灰度发布等等)制作出来的产品才能走的更远。接下来如果有机会和平台,我希望可以更深入地接触这些科学的方法论。

产品设计上遗留的问题

这部分重点思考我认为在一块去周边游APP的产品设计上,遗留的几个最为紧要的问题。

  1. 产品架构存在不合理之处,“首页”和“在当地”的模块设计有悖用户习惯。
  2. 在APP立项时的设计理念中,首页的场景是根据用户定位所在城市推荐该城市的周边游产品,用户无法手动修改城市;在当地页的场景是用户去到了旅游地之后,进入该频道可以获取关于当地玩乐的信息,相当于一个当地的黄页,概念看上去是合理的。
    但我们设想另一种用户场景,居住在杭州的用户A计划在接下来的假期里去广州自助游,打开APP想查找一下广州周边的旅游信息,却发现首页推荐的是杭州周边的产品,并且找不到切换到广州的方法;于是用户打开了“在当地”页,发现仍然显示的是杭州的信息。虽然最后用户可以在“在当地”的城市列表中切换到广州市,但用户的心理预期和操作习惯没有被满足,操作成本也比较大,用户体验会大打折扣。
    我们永远无法准确的预估用户的操作目的和行为模式。这里最大的问题其实是预设了一种“周边游”的概念和操作模式,即在出发前浏览首页,在到达后浏览在当地页,并希望用户按照这种模式去进行操作。
    随着业务的拓展,周边游的概念已经拓展为“泛周边游”,存在两种模式,一种是传统的居住地周边游,另一种是目的地的周边游。事实上所有的OTA友商都在面临着一种用户旅游行为的融合:随着交通工具的发达(汽车、高铁、飞机的普及化),空间转移的时间越来越短,越来越多的旅游者会先选择一个目标城市,在到达目标城市后开展自助性质的城市及周边游玩活动。传统的长途/短途(周边)分类已经无法准确描述这种旅游行为。
    因此,我们更加无法要求用户按照预设的概念来操作APP,而是应该适应用户行为模式的变化。
    对于不存在明确的出发地/目的地要素的游记类、玩乐信息类旅游产品而言,可以弱化切换地点这一功能。但对于售卖旅游产品的APP来讲,这样的设计并不符合用户操作习惯。
    如果我来修改的话,首页需要加上比如“杭州出发”这样的提示文字,明确告知用户以下内容是依据当前城市而推荐的,并且暗示用户可以修改出发地。同时保留自动定位功能以减少用户的操作,并考虑一些异常情况,比如用户未开启定位时,需要手工选择城市,并尽量引导用户开启定位;比如用户所在城市与缓存不同时需要提示用户是否切换城市等。为了与首页“出发地”的概念做区分,“在当地”页可以改为目的地页,摒弃原有使用地理定位获取城市的方式,改为提供一个目的地列表供用户选择,避免首页和在当地页共同使用定位城市而出现的部分信息重叠而引起用户疑惑的问题。
    这个问题我曾向老板反映,希望抽调研发资源优化,很可惜没能得到同意。一方面,老板认为这种推荐模式是我们的特色,需要继续保留;像我所描述的那类用户并不是我们的目标用户,对于他们的特殊需求我们可以不必考虑。另一方面,这个改动涉及的功能模块较多,需要占用较长时间的开发资源。因此最后没能落地。
    如果当时能有资源做一场用户研究,或者对两种方案做一次A/B Test,或许数据可以更有利地说明哪个方案更好。

  3. 功能以展示、促销商品为主,对于用户“找到好玩的地方”这一痛点解决不够彻底。
  4. 在“用户是谁?用户需要什么?”一节中提到,用户发生购买行为前,最主要的需求是“找到好玩的地方”,这其中既包括了由官方推荐的目的地和产品,也包括了其他用户的口碑和推荐。
    在目前的APP中,主要的功能模块都用来单纯展示产品。这种橱窗式的设计太过单薄,既不利于彻底解决用户“找到好玩的地方”的痛点,也不利于用户活跃数据的提高。用户行为将只是单纯的访问与浏览,无法在APP中留下更多有趣的痕迹和互动。
    解决这一问题,我想有两个方面。一是,官方推荐的内容需要更加丰富立体,运营方式需要跳出“订单驱动”型思维,提供更丰富的信息,比如旅行攻略、排行榜、旅游新闻、精选专题等等不同维度的资讯类内容,帮助用户勾勒对目的地和游玩项目的立体印象,从而促进购买行为的产生。产品方面的设计也应以支撑上述信息的展示为思路。
    另一方面则是从增强用户与用户之间的互动着手。近年有一个观点是“消费升级时代要‘以人为本’”,用户不再满足于机械地“被推荐”产品,而会参考他人的消费评价与消费感受,甚至好奇他人的消费过程。直播与电商的结合正是这种趋势的产物。在一块去周边游APP未来的设计中,比如引入游记撰写、查看、评论的功能模块;或者引入可以发布文字/图片、可以互动的feed流广场;或者引入旅行问答的模块;更结合潮流的比如与短视频/直播的结合,用户与用户之间的互动带来的产品粘性和购买行为的转化,虽然我没有数据可以举证,但这里面一定有无限的想象空间。

  5. 其他细节:部分功能模块流程不合理;新旧版本兼容性问题。
    • 部分功能模块流程需优化。举个典型例子,预订酒店时,更符合用户习惯的流程是:选择入住城市和入住时间->搜索酒店->挑选酒店->查看酒店详情->选择房型->进入下单流程。由于产品结构的限制,现在用户进入“在当地”页时已确定了城市,再进入“酒店”频道时,展示的是该城市下的酒店列表。用户需要在下单时选择入住和离店的日期。这个流程一方面比较长,另一方面也不符合用户查找酒店的习惯,是需要优化的点。
    • 新旧版本兼容问题。主要表现在首页运营模块的接口对接上。由于立项时的设计原因,变化频繁的首页各大运营某块采用了纯图片的数据存储形式(包括了需要用到文字的地方比如icon下的label文字也使用了图片),设计和运营同事每期运营活动变更时在后台上传活动图片,客户端由数据接口获取图片并渲染布局。众所周知图片在适配性上表现较差,不同设备展现的图片宽高比、清晰度都会有不同,很难保证普遍的显示效果。此外,纯图片的数据格式,使得首页在改版和功能拓展上非常困难,布局变化或者引入新的信息元素都会使得未更新的旧版本APP布局错乱甚至无法使用。这是一个设计失误,给后期维护带来较大的成本。解决的方法是增加一套合理的首页新接口并判断版本使用不同接口,并行运行一段时间,待旧版本使用率尽可能下降后再废除旧接口,以减轻影响。另外一个可能的解决方式,是对频繁变更的首页使用webview渲染,将内容更新工作在网页上完成并保持不同终端效果的统一性。虽然解决兼容性问题的开发成本、维护成本和过渡时间成本都比较高,但是尽早处理将会对未来的产品设计和用户体验提升更加有利。

至于更多细节性的功能改进和功能缺失问题,这里就不在展开赘述了。
祝一块去可以越来越好!

2 条评论

  • robbertcai
    2017-05-10

    maple老师牛逼 能有一些项目核心竞争点 产品规划 和数据验证就更好了

    • Maple
      2017-05-11

      谢谢斧正!我会再斟酌斟酌!

发表评论

电子邮件地址不会被公开。