实例：如何设计一个运营活动类H5？

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

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

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

真正的从零到一的系统性资料很少，有的，都去开课赚钱了，还良莠不齐。

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

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

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

项目起点

产品的日常。

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

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

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

我们来看看这份作为需求的起点的文档：

活动策划方案

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

阅读文本，你可以得到什么信息？

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

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

项目背景

我们的产品是细分领域的平台型APP，用户人群是休闲垂钓爱好者，男性用户为主，是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。（报名成功与否，失败理由并不在此展示）

设计思路：

1. 状态条显示主播当前赛程，有努力启航与远航寻宝两个状态；
2. 对于未报名的用户为奖品、规则和报名截止期限；
3. 已报名的新手关注当前任务，未到比赛日是拉票攒票，攒票规则，一周仅周六是投票比赛，其余时间都是需要靠用户看直播累积票数，此处可以同时提醒主播跟粉丝；
4. 关注自己的排名跟进度，Top10关注自己跟临近对手的差距，非Top10的关注跟第十名的差距，显示项目会有所不同；
5. 此处不需要区分主播跟用户的可见的信息。

主播信息栏-未报名到启航期

2）远航期-活动结束

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

设计思路：

1. 鱼豆的明细信息是仅主播可见的，所以在远航阶段要区分用户版跟主播版；
2. 远航赛主播的关注点都在鱼豆，所以直接地看到本周的鱼豆奖励；
3. 鱼豆加成是个最终结果，基于我们的用户非常较真的性格，减少可预见解释性的工作，此处的转换关系要明白地表达出来，从起点到终点：周分值-分值鱼豆换算比例-基础鱼豆乘以比例-奖励鱼豆；
4. 可以使用图表说明的地方，尽量都用图表，一图解千愁，注意视觉线索清晰，数据点多就分区表示；
5. 在用户会迷惑的地方加上规则的跳转，此处鱼豆开矿指南是原规则说明的一部分。

主播信息栏-远航期到活动结束

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

主播栏页面流程图-主播版

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

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

（2）票选启航榜

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

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

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

难题：

虽然需求是正确的，但是满足起来是有难度的：

1. 每周Top10+500票的规则是不变的，也就是所有人都得直观看到Top10；
2. 淡化竞争要素，表观上得弱化榜单排名；
3. 主播和粉丝必须看到实时排名，以决定自己的行动对策；
4. 榜单不是采取及格制，而是排名制，不到最后一刻都不能确定哪些参赛选手是胜利者…

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

解决思路：

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

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

（P.S.所以说这个运营上的个性化限制最后补完了活动的创意和主题）

原型定稿：

设计思路为：

1. 比赛分值统计是在周六12点截止，周日凌晨即开始新赛周，所以除了本周榜之外还需上周榜，上周榜只需要显示成功启航的主播即可；
2. 本周榜又分为启航席位争夺区，和普通垂直列表区，直观地拉开准Top10和其他选手的差距；
3. 所有直播中选手，以直播标识标记出来，用户可以快速加入并将手头选票投出；
4. Top10最直观的就只有自己的排位（此处没显示），其他Top10的不会一目了然，弱化了排位竞争；
5. 对于有主观查看意愿的用户而言，可以手动滚动席位争夺区查看明细；
6. Top10因为有500票的门槛设置，实际人数可能少于10，所以垂直列表区的No.11的数值需要服务端可控。

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

3. APP端

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

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

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

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

开发上线：

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

接下来按照以下步骤推进：

1. 开发期间保持密切的沟通，重视来自开发同学的修改意见；
2. 在上线之前，测试验收需求是否完整实现；
3. 上线运营后，在各个重要节点跟运营保持密切沟通，留意下是否行为和数据正常；
4. 活动结束之后，复盘流程，总结经验，下次改进。

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

结语

至此，一个活动H5从0到1到100的生命周期，你都已经见证完毕。

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

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

本文完整看下来，你就算是入门了，至于进阶跟提升，还有很长的路要走。