实例分析拆解:如何设计一个运营活动类H5?

2018-10-05 19:33 作者:产品案例 来源:www.d88.com

  本篇可以满足以下需求:想知道产品从0到1的详细设计思路?想知道运营提出的活动类H5该怎么实现?解构一个真实的案例?原型之前PRD之前有哪些工作?

  最近,做运营的朋友要跟进公司的一个活动H5,第一次跟产品对接,因为希望能够沟通顺利,要我推荐学习产品的资料。

  关于产品方法论跟设计的资料是有许多,但考虑到她也只是短期任务,我很遗憾地表示,没有多少合适的。是的,iOS人机交互指南、启示录、用户体验要素、dont make me think、梁宁产品思维三十讲等经典材料并不能让人渡过初学期的手忙慌乱。

  即使是在线课程,当年学习为期三个月的腾讯课堂的BAT导师阵容的产品经理入门实战班时,同期学员问的最多的,一直是同一句话,有没有案例。案例可以参考别人解题思路,从而纠正自己的思考方向。但完整的案例很少,往往不全,既然如此,那不妨我直接来写一篇来说明。

  作为运营的高频需求,活动类需求有明确的策划目的,完整的生命周期,独立的逻辑,灵活多变的形态,设计的时候接近于一个小产品,还适合用于拿来当案例。

  本文就以实际的活动,来展示一个活动类H5,如何几经波折地从一纸方案到产品成型的。

  运营QQ传了个word文档,说要做一个H5。打开文档一看,是一个活动的策划方案,如下图所示。重点是,这并不是个简单的活动方案。

  简单的活动方案,运营直接用一张海报自己也能解决;但是涉及到限定条件报名、展示个性化用户信息、数据收集、线上计分、数据实时更新、活动状态随时间变更、用户互动、多页面条件判断切换的,尤其是越多要素重叠的,这种综合性考虑的工作就果断交给产品经理吧。

  主流程上,无论是靠自己想还是靠借鉴,细心一点,确实是可以做出八九不离十的东西。但是随之而产生的异常流程、支线流程和反向流程,未经训练的人不要说考虑,甚至都没有这方面的意识。专业的事情交给专业的人。

  这个文档跟实际的差不多,只删减了一些跟产品无关的要素。对于这种确定的需求,可以省点真假需求的功夫,将重点落在需求的产品化上。

  至少知道这是一个以活跃主播的比赛类活动,有观众攒票、投票环节;有主播争夺榜单排名、选择奖品、鱼豆加成环节。

  在讲怎么跟运营进一步沟通细节之前,先简单介绍下当时背景,关于行业、用户、产品、功能模块,有个整体的认识。

  我们的产品是细分领域的平台型APP,用户人群是休闲垂钓爱好者,男性用户为主,是C端用户的场景化服务类平台(类似悦跑圈、GOSIK),有直播的模块做社交,试水商城做商业变现。

  跟素人直播的不一样,我们的直播是限定垂钓主题的,偏户外,业余时间较活跃。所以直播间的设计,也并不会特别花哨,有所侧重地配置常规的互动,如:红包发放和礼物打赏。直播强调实时性跟互动,日常活动都要主播跟用户双端配合。

  鱼豆是虚拟币,主播收到礼物会根据价值折算成鱼豆,鱼豆可以提现为人民币,是主播的商业线。

  了解完背景,回到当前,现在,运营将活动方案交到你手中了,你接下来该怎么做呢?

  不,别傻,你在这个节点上立刻画出来的原型,只是意淫的原型。你得意地交付文档时,收获的不过是运营跟技术的深深的鄙视。

  该锱铢必较地了解事情的全貌。没有人能一次性地传递所有的信息,即使能,也没有人能一次性地接收到所有的信息。

  关于沟通过程的损耗,可以看上一篇文章【从底层逻辑到实践应用,产品经理应该拥有怎样的沟通能力?】

  活动方案提到的不过是必要的信息,你最多能得到些基础的认识,是现象。现象背后的考虑,你一无所知。所以此时要打铁趁热,跟运营通盘了解活动方案产生的来龙去脉、步骤节点、注意事项、角色行为

  了解事情的全貌应该从宏观到微观,第一步先了解大方向和主流程,细节点都可以放在后面慢慢来。因为沟通也不是一次两次,将会完全贯穿整个设计和开发流程。

  本活动目的是以活跃主播为主线程,以提高福利为驱动点,在这个过程中拉动用户活跃(攒票 、投票),做商业试水(主播礼包、直播间礼包)。

  所以,主流程是:主播报名-观众攒票-比赛日PK-Top10主播入围-选礼包-挂礼包-主播攒分-达标有奖。

  主流程是个很粗略的认识而已,进一步跟运营梳理主流程的细分流程、支线流程,流程能够推进,都是靠角色,所以要确定角色的关键步骤。

  角色之间的配合和互动,用图形来显示会更直观清晰,一图解千愁,下方的主播-用户的任务流程图,将含混不清的主流程理成不同的角色线。

  从图中你可以看出,主播线是主线,用户线是辅线,在设计上考虑零散辅线如何拼合到主线里。

  业务流程可复杂可简单,画出来之后,可以知道该活动的比赛落在前半段,后半段是主播挣钱之路。稍微以场景一推演,就会发现有不合理的点在。

  主播可以始终靠利益驱动,比赛入围有奖品,入围之后还可以持续挣高提成。但是用户端呢,基于荣誉感,将主播合理推上榜入围之后,他们就不再有理由做后续的支持了。毕竟,看直播本身是个娱乐消遣行为,谈到挣钱就很违背初衷了。

  于是,当时我建议将活动改为二段赛制,入围之后的主播还会进行同台竞技,并且为了营造紧凑感,实时反馈,榜单设为周榜,鱼豆也该按周加成。

  需求是可以更改的,但的为了更有效的结果,最好有理有据,有解决方案。作为需求产品化的负责人,一切都是用户体验,你是有义务替运营完善方案的。

  在场景推演阶段,可如图般用思维导图来做梳理和分析,不重不漏记录想法。用角色视角想象他们的关注点,有利于安排信息架构。

  方案给定,需求、业务流程、场景确定,此时可以跟运营暂告一段落,将注意力放在将想法转化为方案上。

  不同公司有不同的文档规范,而不同的产品经理也有不同的工作习惯。产品无定法,民房突发大火房顶崩塌 扎兰屯消,基本上能完成地具现化你的构思和设计的,就是成功的文档。

  将想法转为具体功能点,可用全局功能结构图表达,时刻留意用MECE法则来梳理,保证逻辑和完整。

  从图中可以看出:客户端的功能是分别由H5端跟APP端分别承担的,APP稍微调整,借用已有的直播间互动功能。而H5端是从零设计的页面,展示现实活动信息和进度明细,后台配合客户端的修改,增加礼包管理和数据导出的功能。

  一般来讲,运营有要求的话,交给产品前,活动方案应该定好一切能确定的部分。但因为本人文案是团队最好的,所以运营很放心将创意、文案部分交给了我(方案里活动主题一直都是空的),我在做产品方案的时候才确定下来,但是为了文档的一致性,这里采取最终版。

  产品方案以原型的方式确立之后,产业生态”是什么?ag88环亚国际娱,可以找运营跟技术过一遍。在确定需求满足,技术上可行,成本精简后,就交付给设计、测试和开发,如果这个过程中发现有问题,还得来回修改到基本无异议。之后还需补全其他文档。

  原型是产品文档中最为关键的部分,因产品形态、复杂度、开发进度,其他类的产品文档也许有所取舍,但是原型是必不可少的,它展示产品的最终形态和功能,是所有人沟通的共识,尤其在小团队。

  在此次的设计中,活动有效动作是APP直播间互动,而活动信息是在H5端,设计时注意两端信息的联动。相关的后台功能,在此处省略不提。

  首页banner获取用户信息,而直播间H5页面,获取的是当前直播间主播的参赛信息。无论是主播还是用户,在直播间切H5,都会中断当前的进程。

  所以呢,H5设计的时候信息要高度集中在主版面展示,削减层级,做到信息都在手边,缩短查找时间和步骤。一些强调实时性的信息,也会在直播间的评论区以消息的形式播报,减少用户和主播的频繁切换页面查看。

  H5的活动页的整体框架扁平,按照常规的做法降低学习成本,将相对低频的信息,奖励跟规则放在第二层级,高频的榜单跟主播进度放在第一层级。

  主播信息栏承担比榜单更多功能,是用户和主播第一关心的信息。实际上理解到二段赛程、多状态、多项分值统计、鱼豆比例加成,就知道主播处的设计必定要更复杂,但是这些复杂尽量留给设计人员跟后台程序,任何时候用户能感知的遵循简单和必要原则。

  分阶段来说明主播的状态信息栏的设计,先放第一阶段,下图显示的顺序依次是:未报名—启航期-非比赛日—启航期-比赛日-Top10—启航期-比赛日-非Top10。(报名成功与否,失败理由并不在此展示)

  第二阶段的图片顺序为:远航期-用户版—远航期-主播版-明细收起—远航期-主播版-明细展开—活动结束。

  鱼豆加成是个最终结果,基于我们的用户非常较真的性格,减少可预见解释性的工作,此处的转换关系要明白地表达出来,从起点到终点:周分值-分值鱼豆换算比例-基础鱼豆乘以比例-奖励鱼豆;

  可以使用图表说明的地方,尽量都用图表,一图解千愁,注意视觉线索清晰,数据点多就分区表示;

  在用户会迷惑的地方加上规则的跳转,此处鱼豆开矿指南是原规则说明的一部分。

  3)主播全流程即使是用来说明主播栏的一个状态,上面的截取的原型图也只是部分,完整流程可以见下方的主播栏页面流程图-主播版,将没有在上图显示的支线流程和异常流程补全。

  主播信息栏流程相对复杂,信息量大,分角色视角,拥有完整的生命周期。以原型和页面流程图加设计思路讲解,看到这里,其实你已经知晓一个小产品是怎样成型了。

  但是设计过程有时候并不总能这样一气呵成,即使在前期充分沟通,也免不了在过原型的时候,需求方变更或者补充需求。接下来部分借票选启航榜的设计顺道介绍改需求这件事。

  主播信息栏采取了双榜单的形式,因为榜单是不跟主播的时间线的,启航跟远航是有两个月的并行重叠,不能假定用户只关注一个主播,所以排版上是双榜单并列。

  第一个榜单-票选启航榜的设计会比较特殊,原本是常规的本周榜跟上周榜,垂直列表。但是过原型的时候,运营希望可以弱化竞争。理由是上次冲榜竞争造成主播的不愉快,在核心用户群也有反馈。

  还记得我们的此次活动的目的么,其实并不在于选出最具人气的主播,所以是可以更改的。

  本质上就是在一个必须呈现榜单和实时排名的地方,要求弱化排名,是不是有点像五彩斑斓的黑?

  最终的方案是,将主播跟粉丝关心的排名差距,分到主播状态信息栏去;而榜单从全部主播的垂直排位,改为将Top10独立区分作横向的滚动专区。因为竞争最激烈的正好是在头部。对于平台和主播而言,进入Top10就足够了,名次是无所谓的。

  为了给Top10横向滚动区出师有名,结合我们的用户群和产品特性,将第一赛段的在创意上定为每周所有主播争夺十张船票(弱化排名),滚动区定义为起航席位争夺区,UI设计上以船载形象来强化认知,比赛结束还待在十个席位里的主播就为胜,可以成功启航。进入第二赛段,开船出海,远航寻宝,开采鱼豆宝矿。

  比赛分值统计是在周六12点截止,周日凌晨即开始新赛周,所以除了本周榜之外还需上周榜,上周榜只需要显示成功启航的主播即可;

  本周榜又分为启航席位争夺区,和普通垂直列表区,直观地拉开准Top10和其他选手的差距;

  所有直播中选手,以直播标识标记出来,用户可以快速加入并将手头选票投出;

  Top10最直观的就只有自己的排位(此处没显示),其他Top10的不会一目了然,弱化了排位竞争;

  Top10因为有500票的门槛设置,实际人数可能少于10,所以垂直列表区的No.11的数值需要服务端可控。

  实际上设计思路处处体现在功能结构、流程、页面原型上,在输出文档的时候就已经包括在内,并不真的都需要写下来。但是设计要合情合理,自己心中有数,在其他同事要求说明的时候能答出来能写出来。

  APP都是利用好已有的直播间功能,因为活动是阶段性的,尽量减少对原有APP的逻辑的影响,在满足需求的情况下,考虑技术成本,复用已有模块。

  在APP端要注意做好往H5活动导流,在赛前、赛中和赛后在评论区和礼物打赏区做引导和提醒,其中注意兼顾平衡对潜在参与用户的动员,和不感兴趣用户的防打扰。

  APP端部分原型图如下,整体的文案图案跟主题风格一致,在礼物区指定礼物的点击和不点击里,体现活动进程和做好引导。

  产品方案的其他部分也按照相似的流程形成,不再一一列出。如果有需要的话,后续会将整理后的原型的链接附上。

  原型和相关文档跟运营确定之后,跟技术沟通过之后,就可以交付到下一个环节:开发。

  上线是检验一款产品的试金石,上线之后小问题大状况都可能有,至于多少,取决很多因素,看团队。当然,如果你有追求,至少要减少在自己负责和交接环节上的坑,提升实力任何时候都是一个人的基本面。

  无论是从一个想法还是一份活动方案作为项目起点,无论你前期是否参与讨论,作为产品,在开始产品设计之前,必需先巨细无遗地向需求方理解需求,再梳理业务流程,将需求转化为具体功能点,全局排布分配功能,绘制原型,跟需求方确认方案满足需求,然后向技术交付最终版的原型、流程图、脑图、文字、表格等产品文档。之后跟进产品实现和上线,到最终实施的效果跟预期一致,才算暂告一段落。

  关于改动和需求变更,越早提越好,问题越早发现越好。一个基本节点是,项目进入了开发环节,就不能随意改动了,越到开发末期越是如此,除非关键逻辑和大问题。

  笔者为什么不去提炼一下,全程把自己的项目记录了一遍,好像在做项目复盘,没有提炼出什么东西

  这篇文章有需求在的,就是给像我朋友一样的对产品设计流程不清楚的读者了解情况。至于提炼,其实已经有许多文章在做这样的事情,提炼不是难题,后续会有别的文章做这个事情,难的是系统性的思考。

  这个活动本身并不简单,所以实现起来没有多少可简化的环节,对新手来说是有些难度的。

  小白一开始不会交给你整个模块的,是从小的功能点,部分的界面入手的,做到本文的水平还是需要时间的。

  相对独立简单又通用的案例,就是登录注册设计了,你可以自己做一个,再找对应的文章对比下。我之前也写过一篇关于登录注册设计的,也可以看下。

  为什么游戏等级会设置得很高,动辄100级,而其他的产品最高等级就比较低,比如网易云,最高10级。这是因为什么呢?

  【中秋福利】又是一年中秋节,今年中秋,有没有奇特的新鲜玩法?(获奖名单公布)

  人人都是产品经理(是以产品经理、运营为核心的学习、交流、分享平台,集媒体、培训、招聘、社群为一体,全方位服务产品人和运营人,成立8年举办在线+期,线+场,产品经理大会、运营大会20+场,覆盖北上海广深杭成都等15个城市,在行业有较高的影响力和知名度。平台聚集了众多BAT美团京东滴滴360小米网易等知名互联网公司产品总监和运营总监,他们在这里分享知识、招聘人才,与你一起成长。