一个活动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设计以船载形象加强认知，比赛结束时仍有待解决

以上就是关于一个活动H5从0到1到100的生命周期的解析的相关介绍，更多一个活动H5从0到1到100的生命周期的解析相关内容可以咨询我们或者浏览页面上的推荐内容。我们将让你对一个活动H5从0到1到100的生命周期的解析有更深的了解和认识。