一个活动H5从0到1到100的生命周期的解析

最近做运营的朋友要跟进公司的H5活动，第一次和产品对接，因为希望沟通顺畅，推荐学习产品的信息。有很多关于产品方法论和设计的信息，但考虑到她只是一项短期任务，我遗憾地说，没有多少合适的。是的，iOS人机交互指南，启示录，用户体验要素，don’tmakemethink、梁宁产品思维30讲等经典材料，不能让人在初学期匆匆忙忙。真正从零到一的系统性数据很少，有的，都去开课赚钱了，还好坏参半。即使是在线课程，当腾讯课堂BAT导师阵容的产品经理在为期三个月的时候，同期学生问的最多的是同一句话，有没有案例。案例可以参考别人解决问题的想法，从而纠正自己的思维方向。但是完整的案例很少，往往不完整。在这种情况下，我不妨直接写一篇文章来解释。作为运营的高频需求，活动需求具有明确的规划目的、完整的生命周期、独立的逻辑、灵活的形式，设计接近小产品，也适用于案例。本文以实际活动展示了活动H5如何从一纸方案到产品成型。项目起点产品的日常生活。运营QQ发了一个word文档，说要做H5。打开文档一看，是一个活动策划方案，如下图所示。重点是，这不是一个简单的活动计划。简单的活动计划，操作可以直接用海报解决；但涉及有限条件注册、显示个性化用户信息、数据收集、在线评分、数据实时更新、活动状态变化、用户互动、多页条件判断切换，特别是重叠元素越多，综合考虑工作果断给产品经理。在主流过程中，无论是靠自己的思考还是借鉴，细心一点，真的可以做出八九不离十的事情。然而，未经训练的人不应该考虑由此产生的异常流程、支线流程和反向流程，甚至没有这方面的意识。专业的东西交给专业的人。让我们来看看这个文档作为需求的起点：活动策划方案与实际文档相似，只删除了一些与产品无关的元素。对于这种确定的需求，可以节省真假需求的努力，把重点放在需求的产品化上。在阅读文本时，你能得到什么信息？至少知道这是一个活跃主播的比赛活动，包括观众存票和投票；有主播争夺榜单排名，选择奖品，鱼豆加成。在谈到如何与操作进一步沟通细节之前，简要介绍一下当时的背景，对行业、用户、产品、功能模块有一个全面的了解。项目背景我们的产品是细分领域的平台应用，用户群体是休闲钓鱼爱好者，男性用户主要是C端用户的场景服务平台(类似于悦跑圈)GOSIK），有社交直播模块，试水商城做商业实现。与业余直播不同，我们的直播限制了钓鱼的主题，偏向户外，业余时间更活跃。因此，直播间的设计不会特别花哨，而是侧重于传统的互动，如红包分发和礼品奖励。直播强调实时性和互动性，主播和用户应配合日常活动。鱼豆是虚拟货币，主播收到的礼物会根据价值转化为鱼豆，鱼豆可以提现为人民币，是主播的商业线。确定需求，了解背景，回到现在，操作会把活动计划交给你。接下来你该怎么办？很多人马上去画原型图，先给个方案。不，别傻，你在这个节点上立刻画出来的原型，只是意淫的原型。当你骄傲地交付文档时，你得到的只是对操作和技术的深刻蔑视。所以这个时候你该怎么办？要对事物的全貌有一个很好的了解。没有人能一次传递所有的信息，即使可以，也没有人能一次收到所有的信息。不信？关于沟通过程的损失，你可以看到一篇文章[从底层逻辑到实际应用，产品经理应该具备什么样的沟通能力？】活动计划中提到的只是必要的信息，你最多可以得到一些基本的理解，这是一种现象。你对现象背后的考虑一无所知。因此，在这个时候，我们应该趁热打铁，了解活动计划的来龙去脉、步骤节点、注意事项和角色行为。。。你知道多少？最理想的情况是比操作更熟悉计划。1.理清主流程，从宏观到微观了解事物的全貌。第一步是了解大方向和主流程，细节可以放在后面慢慢来。因为沟通不是一两次，它将完全贯穿整个设计和开发过程。理解目的，即把握设计中的大方向和原则。本次活动的目的是以活跃主播为主线程，以提高*为驱动点，在此过程中拉动用户活跃(存票、投票)，做商业试水(主播礼包、直播间礼包)。因此，主流程是：主播报名-观众存票-比赛日PK-Top10主播入围-选礼包-挂礼包-主播存分-达标有奖。2.梳理业务流程的主流程只是一个非常粗略的理解。进一步梳理主流程的细分流程和分支流程取决于角色。因此，有必要确定角色的关键步骤。角色之间的合作和互动将更直观、更清晰地显示图形。下面的锚-用户任务流程图将模糊的主流程理成不同的角色线。从图中可以看出，主播线是主线，用户线是辅线。在设计中，考虑如何将分散的辅线拼接到主线中。业务流程图3。场景演绎业务流程可以复杂简单。画完之后，可以知道活动的比赛落在前半段，后半段是主播赚钱的路。稍微用场景推演一下，就会发现有不合理的点。主播总能靠利益驱动，比赛入围有奖品，入围后还能继续赚高佣金。但在用户端，基于荣誉感，将主播合理推入榜单入围后，他们就没有理由做后续的支持了。毕竟看直播本身就是一种娱乐行为，说到赚钱是违背初衷的。因此，当时我建议将活动改为第二阶段，入围后主播将在同一舞台上竞争。为了创造一种紧凑感和实时反馈，名单被设置为每周名单，鱼豆也应该每周奖励一次。运营迅速接受了建议，并使用了新的解决方案。需求是可以改变的，但是为了更有效的结果，最好有理有据，有解决办法。作为需求产品化的负责人，一切都是用户体验，你有义务为操作改进计划。在场景推演阶段，思维导图可以如图梳理分析，不重不漏记录思路。从角色的角度想象他们的注意力，有利于信息架构的安排。4.功能结构方案给定，需求、业务流程和场景确定。此时，它可以暂时结束操作，并将注意力集中在将想法转化为方案上。不同的公司有不同的文件规范，不同的产品经理有不同的工作习惯。产品无法确定，基本上可以完成你的想法和设计，是成功的文档。将想法转化为具体的功能点，可以用全局的功能结构图来表达，时刻用MECE法则来梳理，保证逻辑和完整性。从图中可以看出，客户端的功能由H5端和APP端分别承担，APP稍微调整，借用现有直播间的互动功能。H5端是从零设计的页面，显示实际活动信息和进度细节，后台配合客户端修改，增加礼品包管理和数据导出功能。一些小伙伴可能会发现名词前后不一致，这是主题和创意确定后的版本。一般来说，如果操作有要求，在交付产品之前，活动计划应确定所有可确定的部分。然而，由于我的文案是团队中最好的，我可以放心地将创意和文案部分交给我（计划中的活动主题一直是空的）。我在制定产品计划时确定了它，但为了文档的一致性，我在这里采用了最终版本。这属于团队成员优势互补，各展所长。是的，很好；没有，就各司其职。通过原型和产品文档，将产品方案从抽象功能点转变为技术可执行。产品方案以原型方式确立后，可以找到操作和技术。在确定满足需求后，技术上是可行的。成本简化后，交付给设计、测试和开发。如果在此过程中发现问题，必须来回修改，直到基本无异议。之后还需要补充其他文档。原型是产品文档中最关键的部分。由于产品形式、复杂性和开发进度，其他类型的产品文档可能会被选择，但原型是必不可少的。它展示了产品的最终形式和功能，这是每个人的共识，尤其是在小团队中。1.在本次设计中，活动的有效动作是APP直播间的互动，活动信息在H5端，设计时要注意两端信息的联动。这里省略了相关的后台功能。APP与H5的连接点在直播间的广告空间，主页的banner广告空间。App端和H5端主界面主页banner获取用户信息，而直播间H5页面获取当前直播间主播的参赛信息。无论是主播还是用户，在直播间切H5都会中断当前的过程。因此，在H5设计中，信息应高度集中在主页面显示，降低层次，使信息掌握在手中，缩短搜索时间和步骤。一些强调实时性的信息也会在直播间的评论区以新闻的形式播放，减少用户和主播频繁切换页面的查看。2.H5活动页面H5活动页面整体框架扁平，按照常规做法降低学习成本，将相对低频的信息、奖励和规则放在第二级，高频列表和主播进度放在第一级。以主播信息栏和榜单为例。(1)主播信息栏设计主播信息栏承担的功能比榜单多，是用户和主播首先关心的信息。事实上，如果你了解了两个时间表、多个状态、多个分数统计和鱼豆比例奖励，你就会知道锚的设计必须更加复杂，但这些复杂性应该留给设计师和后台程序，用户可以随时感知到遵循简单和必要的原则。1)未注册-启航期分阶段说明主播状态信息栏的设计，首先放在第一阶段。下图显示的顺序是:未注册—>起航期-非比赛日—>起航期-比赛日-Top10—>起航期-比赛日-非Top10。（注册是否成功，失败原因不在此显示）设计理念：状态条显示锚当前时间表，试图启航和远程寻宝；未注册的用户为奖品、规则和注册截止日期；注册新手关注当前任务，在比赛日之前是拉票保存规则，一周只有周六是投票比赛，其余时间需要依靠用户观看现场累积投票，这里可以同时提醒主播和粉丝；关注自己的排名和进度，前10名关注自己和接近对手的差距，非前10名关注与前10名的差距，显示项目不同；没有必要区分锚和用户的可见信息。主播信息栏-未注册至启航期2)远航期-活动结束第二阶段的图片顺序为:远航期-用户版—>远航期-主播版-明细收起—>远航期-主播版-详细展开—>活动结束。设计理念：鱼豆的细节只能由主播看到，所以在远程航班阶段区分用户版本和主播版本；远程航班主播关注鱼豆，直接看到本周的鱼豆奖励；鱼豆奖金是最终结果，基于我们的用户非常严肃的个性，减少可预测的解释性工作，这里的转换关系应该清楚地表达，从起点到终点：周分值-分值鱼豆转换率-基本鱼豆乘以比例-奖励鱼豆；可以使用图表说明的地方，尽量使用图表，一张图片解释悲伤，注意清晰的视觉线索，更多的数据点表示分区；在用户会感到困惑的地方加上规则跳转，鱼豆开采指南是原规则说明的一部分。主播信息栏-从长途航行到活动结束3）即使主播的整个过程被用来解释主播栏的状态，上面截取的原型图也只是一部分。完整流程见下面的主播栏页面流程图-主播版，补充上图中未显示的支线流程和异常流程。主播信息栏-从长途航行到活动结束3）即使主播的整个过程用于解释主播栏的状态，上面截取的原型图也只是一部分。完整流程见下面的主播栏页面流程图-主播版，上图中未显示的分支流程和异常流程将得到补充。主播栏页面流程图-主播版主播信息栏流程相对复杂，信息量大，从角色角度看，生命周期完整。用原型和页面流程图加上设计思路来解释，其实你已经知道一个小产品是怎么形成的了。然而，有时设计过程并不总是一次完成。即使在早期阶段进行了充分的沟通，也不可避免地需求方在原型过程中会改变或补充需求。接下来，一些借票选择启航榜的设计顺便介绍了改变需求的问题。（2）投票启航名单主播信息栏采用双名单的形式，因为名单不符合主播的时间线，启航和远航平行重叠两个月，不能假设用户只关注一个主播，所以排版是双名单平行。第一个列表-票选启航列表的设计将更加特殊，原本是常规的本周列表和上周列表，垂直列表。但在原型之后，运营希望削弱竞争。原因是上次竞争导致主播不开心，核心用户群也有反馈。还记得我们这次活动的目的吗？其实不是选最受欢迎的主播，可以改。问题：虽然需求是正确的，但很难满足：每周前10名 500票的规则是不变的，也就是说，每个人都必须直观地看到前10名；淡化竞争要素，削弱表面排名；锚和粉丝必须看到实时排名来决定他们的行动对策；列表不是通过系统，而是排名系统，在最后一刻之前，我们无法确定哪些选手是赢家。。。本质上，它需要削弱排名，因为它必须呈现列表和实时排名。这有点像五颜六色的黑色吗？解决方案：最终解决方案是将锚与粉丝之间的排名差距分为锚状态信息栏；列表从所有锚的垂直排名改为水平滚动区。解决方案：最终解决方案是将锚与粉丝之间的排名差距分为锚状态信息栏；列表从所有锚的垂直排名改为水平滚动区。因为最激烈的竞争恰好在头部。对于平台和主播来说，进入Top10就够了，排名也没关系。为了让Top10横向滚动区出名，结合我们的用户群和产品特点，将第一阶段的创意定义为每周所有主播争夺10张票（削弱排名）。滚动区定义为起航座位竞争区。UI设计以船载形象加强认知，比赛结束时仍有待解决