如何从“点子”落地到“执行”？—完整解析1个手游传播类mini项目的进化

本文来自网易云社区

作者：林玮园

从点子到落地，是不确定到确定的过程，是从模糊概念到具体现实的实现过程。无论什么点子，在落地变现的过程中都会有很多疑问产生。

首先，不确定点子本身是否成立。点子的背后是无数因果推论而做的决策，互相微妙的牵动着，牵一发而动全身，可能落地后发现用户对这一套完全不感冒，无法达到预期效果。

甚至，在落地过程中我们会有很多自我怀疑、自我推翻，把一切重来，我们会浪费大量资源和人力成本，但是不重来，项目的变现又如何实现呢？毕竟，做一个用户完全不care的页面绝不是我们的初衷。

Mini项目就是基于这些令人纠结的“痛点”而设立，先行提炼创意方案核心，快速搭建demo，实现方案框架。后续如需变现，再把mini项目的demo进行细化，事半功倍，团队战斗力也能更好凝聚。

从0到1不容易，那从0到0.5就容易些了吧？从0.5到1也会容易不少吧？

第一阶段：点子/创意的产生

2017年6月，雷火网站组计划做第二期的mini创意项目，由3-4名不同岗位的人员组成一个小组，完成mini项目的demo。第二期mini项目的重点在：创意方案 +具备较大的变现可能性。

针对这个总要求，我对我们小组提出了要求的加成版：创新方案（创新太笼统，准确说是微创新能落地，方案能贴合雷火的某几款游戏）、变现可能性（能变现还不够，期望在今年内就能从demo过渡到上线传播，并为游戏吸引用户&导流）。此外，作为网站内容编辑，我关注的重心在传播：网页是否具备自发传播性、网页如何引导用户传播。

方向既已明确，要求也十分清晰，我们就进入了头脑风暴确认核心方案的环节。作为落地方案的先行版，mini项目整体对技术的要求不算太高，基本能跑通实现即可（先不考虑动画卡不卡、网络延迟多少之类的问题），但创意模式和传播能力，是在最初就需要考虑并做预估的。最终我们选定“你画我猜”进行加工和微创新，作为本次mini项目的发展雏形。选定的原因基于这几点考虑：

1、 简单易上手，几乎不需要新手引导：节约用户学习成本，便于扩大参与群体的数量；

2、 受众面广泛，极受欢迎：以1.8亿美元现金收购这款游戏开发商OMGPOP的Zynga称，Draw Something在发行后，只用了50天就达到了5000万的下载量，日活跃用户的数量达到了2400万，上升趋势持续半年以上。

3、 参与感强：用户亲手画图，画与猜者互动，画图可保存并分享到朋友圈，增加成就感。

第二阶段：mini项目demo完成（组员4人，总计5天完成demo）

讨论demo方案时，我们对传统的你画我猜做了一些玩法上的改动。传统你画我猜游戏是一个即时制的“游戏”，一方绘画、一方猜答案，猜对加分，所有人都未猜对则画主也不得分。

我们认为H5页面会对即时制造成很大限制（网页不像APP，退出关闭的成本更低），需要做改良，创造一个非即时制的、依然能保障用户参与和分享心理的玩法。要做到这一点，只需要巧妙地将“猜”与“画”流程分离。此外，传统的你画我猜游戏，主要满足的是画手的参与感，结束回合后画手可以将作品秀到朋友圈，满足虚荣心和被围观的荣誉感。因此，这一机制我们做了保留。

最后，考虑到自发传播性，我们设置了游戏与手游中礼包挂钩的奖励机制，只要分享到朋友圈，有3个人为你点赞，就能领取一个游戏称号。这一点作为伏笔，预期了未来的分享量和传播量。

图1：你画我猜mini项目的纸上原型（放大看）

图2：你画我猜mini项目的设计定稿（放大看）

Demo原型完成后，就进入平面设计/交互设计环节。因为前期流程讨论的比较透彻，设计与开发过程都比较顺利，说说过程中遇到的一些小坑吧：

1、前端：页面需要微信授权登陆获取信息，调试只能在微信浏览器上进行，但微信浏览器上无法输出日志。

     原因：写假数据跳过微信浏览器授权步骤以及服务端code验证过程，即可在其他浏览器内打开页面调试，授权验证过程的只能通过alert输出调试。

2、前端：canvas无法直接通过css调整宽高，会导致拉伸。

    原因：在canvas外包裹一个容器，在css内定义容器的宽高后，在JS内修改canvas的宽高属性。

3、后台：微信认证流程

     由于是第一次做微信认证功能，在技术调研上花费了一些时间。技术同学在做本地测试时，由于授权中转页面的限制，前端页面需绑定.163.com或.netease.com域名，并且必须开启80端口。手机上测试需要使用fiddler作代理解决需要绑定host的问题，或者可以在PC上使用微信桌面版进行调试。

4、后台：图片数据提交

     由于画的图形不会很复杂，图片存储没有使用nos服务，而是直接提交到后台保存。因此需要使用post提交，jsonp无法满足要求，只好通过后台配置Access-Control-Allow-Origin响应头来解决跨域的问题。

第三阶段：第一期传播，落地变现

Mini项目演示会上，倩女手游营销们对这个demo非常感兴趣。恰好配合倩女手游大版本更新（赛马/马会系统，斗魂坛开放），于是在沟通需求后，我们在9月完成了你画我猜第一期的上线和大推传播。

第一期正式项目与demo相比，变化在以下几点：

1、延长画者绘画时间，增加竞猜趣味：画1张变成画3张不同主题，猜的人要猜3次；

2、引入猜者竞争模式：增加斗猜对题数和猜题用时的排行榜，让猜题者可以刷榜；

3、引导用户积极分享：分享并获≥10个鲜花，才能领取灵魂画手称号。

营销的介入补足了demo中的一些弱项，即对用户心理的把握。在第二阶段，我们已经以最低的成本去搭建起来一个真实的用户应用场景，在第三阶段就是要验证在这个场景下，用户是否会真的产生我们所预期的行为。

图3：你画我猜.第一期的精细原型图（放大看）

到了变现阶段，创意已经明确，那么页面设计风格、用户体验是否流畅、后台数据存储与数据埋点监测，重要性又再次浮现。第一期我们配合宣传主题，采用倩女手游游戏主角Q版造型作为主视觉，页面整体调性略萌化，色彩鲜艳明快。引导用户分享和排行榜斗快的环节，也做了一些视觉上的“逗”点，以激发参与者的好感。

图4：你画我猜.第一期的设计定稿（放大看）

第四阶段：分析数据，复盘总结

第一期上线后，在游戏官博、微信公众号等做了渠道宣传，1个月后我们进行了页面数据整理与分析，期望复盘一下活动，看看传播转化效果。复盘时，可以从数据看到这个项目自身存在的一些问题很显著：

1、 页面PV和UV数据还不错，但未达到高热度的预期效果，与以往传播H5差不多；

2、 分享量较高，但最终环节的奖励领取数据非常低，领奖/分享率远低于10%。

小组就这2个数据做了讨论复盘，第2条引起的原因极有可能是领奖门槛太高了。在第一期，我们为了引导用户分享朋友圈，规定要攒到10个鲜花才能获奖，这个门槛设置过高。并且从页面获奖到游戏中领奖，依然是呈漏斗形锐减的，这个奖励可以说近乎虚设了。

另外，虽然是在大推期推出的页面，但你画我猜与此次大版本更新的主题相差挺远，没达到“蹭热点”目的，更多是作为一个博用户一乐的小型传播页面存在。

第五阶段：第二期再发力，配合主题，浏览/分享量激增

复盘第一期经验，在2017年12月我们又上线了优化版的你画我猜第二期。第二期上线前，我们又一次开会分析了一遍：这次能否有大幅进步？答案是：有！

因为在12月上线第二期的时机并非空穴来风，这一次大版本推出了新职业男女画魂，画魂职业特色：画物成活，这就给你画我猜创造了很好的传播空间，不再是生搬硬套，而是以完美契合的形态加入了推广大军中。

第一期在整个流程上已经很成熟，第二期我们重点优化了传播吸引点、降低获奖门槛。1、将页面常规标题和slogan都做了调整：

你画我猜（第一期大标题）→画魂转职资格考试（第二期大标题）

2、鬼畜的分享图案，分享随机展示一张灵魂画手图，在朋友圈展示效果极醒目：

图5：你画我猜.第二期朋友圈分享图

3、领奖门槛降低了，只要分享到朋友圈，就能获得灵魂画手称号。网页上确认，一键领奖，游戏中对应角色直接收到奖励邮件，无需网页、手游反复切换操作。

 整个主题的设计也配合画魂主题，从Q版改为了画魂略带中国水墨的质感。与本次大推达到风格上的协调统一：

图6：你画我猜.第二期的设计定稿（放大看）

      第二期上线后，在朋友圈看到很多分享量，心里基本有底会比第一期的数据要好不少。等到真正复盘，查看数据时还是很开心的。

1、 上线7日监测，页面PV和UV数据很好，峰值日在第一期的2.5倍左右，上升一个数量级。日均值也达到第一期的2倍以上；

2、 分享与获奖量在第一期的50倍以上。

写在最后，大家捧个场呗：

我觉得有个接地气的比喻能形容出从点子落地到执行的过程，它像是烧个菜。

当我们有创意有想法的时候，只是到了“拿到一个菜谱，觉得x食记里面推送的一道菜看起来很好吃的样子”这么一个阶段。接下来你需要根据你能买到什么食材，你有多少把控油盐和生熟的水平，你的品尝者更喜欢什么口味等等因素，去决定这道菜到底要怎么做。

过程中你会遇到各种困难，比如菜谱里用的南方的瓜果材料在北方味道不一样啦，油盐品牌不同导致组合口感有微妙差别啦，品尝者特别嗜甜嗜辣口味很奇怪啦，等等。

最后的最后，你端上桌的菜可能从色泽、装盘、口味上都和美食博主的不一样了，不过，

“唔，烧的也很好吃哦！”

网易云大礼包：https://www.163yun.com/gift

本文来自网易云社区，经作者林玮园授权发布

相关文章：
【推荐】 传统业务上云：跨AZ容灾架构解析