5W1H：聊聊弹幕功能的逻辑闭环

前一段时间一直在研究弹幕，虽然已经不是新鲜玩意，但当真去分析的时候，感觉即便是在这么小的一个功能上实现逻辑闭环，也是件见功底的事情。而产品设计初期的逻辑闭环，绝对能帮你在后续的工作中省掉不少麻烦。研究弹幕时，发觉从5W1H开始梳理思路，或许是个不错的办法，遂整理成文，希望其他人也用得着。

01匹配

5W1H（WWWWWH）分析法也叫六何分析法，是一种思考方法，也可以说是一种创造技法。在企业管理、日常工作生活和学习中得到广泛的应用。5W1H是对选定的项目、工序或操作，都要从原因（何因Why）、对象（何事What）、地点（何地Where）、时间（何时When）、人员（何人Who）、方法（何法How）等六个方面提出问题进行思考。——“百度百科”

还是先科普一下。虽然对于管理学出身的娃，5W1H应该早就被玩坏了吧……

以弹幕为例。逻辑梳理的第一步，还是从匹配开始。

Why——为什么做弹幕？

我所研究的并不是视频弹幕，而是页面弹幕，目前周伯通和节操精选已经实现。为什么要做？对于用户来说，在用户群体的年龄层与弹幕相匹配的前提下，弹幕就是一种易于接受又能带来强互动的功能。而对于产品本身，当然是要提高用户参与感和产品互动性，对于社交基因不太好的产品是一种新鲜玩法。

What——弹幕是什么？

把传统的评论转化成以弹幕的形式呈现，增强场景感和参与感，这也是目前周伯通和节操精选的实现逻辑。具体说来，弹幕应当包括发言人的头像、用户名、评论内容。

Where——弹幕在哪儿？

目标实现所有页面飘弹幕，而所有页面又要区分为两种场景：一种是没有具体评论对象的评价场景，一种是有具体评论对象的评论场景。在周伯通的网站里，前者就是以首页为代表的页面，后者就是独立的招聘信息页。

When——什么时候发弹幕？

什么时候都能发射弹幕！这需要把发射弹幕的功能键做到跨页面，所以最好的实现方式是跨页面的功能栏浮层。

Who——谁来发弹幕？

这时候有两种考量。假设一：你希望弹幕越多越好，那就要区分已登录用户和未登录用户，对于已登录用户给予充分的身份标识，对于未登录用户做好匿名弹幕的准备，如用户名的显示、用户头像的初始设置等等。假设二：你希望登陆用户越多越好，那就引导用户在发射弹幕前主动登陆，如点击弹幕输入框时就提示用户需要登陆，并提供快速登录入口，提供第三方账户导入等等，帮助提高你的登陆率。

How——用户&产品

对用户来说，how是如何使用这个功能。不能简单地只考虑“发射”这一瞬间动作，而是要从头开始分析这个功能的不同场景：①要登陆；②要看到弹幕的展示，对自己发射的弹幕有一个心理预期；③能够快速找到和学会使用发射框；④发射弹幕；⑤看到自己的弹幕，获得反馈；⑥看到别人的弹幕，实现回复；⑦看到自己的回复。

对产品来说，how是如何实现这个功能。根据以上用户的使用场景一一对应：①要设置登录提示和快速登录入口；②确定弹幕的展示位置和展示时长，弹幕要包含用户所关心的元素，如评论内容、用户头像、用户名等；③功能键要可见且易理解，降低功能的学习成本；④支持基本的弹幕输入、编辑和发射；⑤确定最新弹幕的出现时机、展示位置和展示方式；⑥提供回复功能，给予应有的功能键和提示；⑦回复性质的弹幕的出现时机、展示位置和展示方式

02错误预估

用户会按照你的想法使用你的功能吗？功能运转的过程中会出现bug吗？……我相信这两个问题的答案都是共识吧——肯定和你想的不一样；也肯定会出现bug 。

好！既然明知他们会如此待我（泪），不如先自虐一把！

Why——为什么非要弹幕？

万一没人玩儿怎么办，傻了吧， 我就不用弹幕你拿我怎样？……唔，其实即便用户不是和你对着干的心理，也可能因为种种原因不愿意参与。

What——我发什么弹幕？

what总是和内容联系在一起的，即便用户想要参与，但也可能因为种种原因卡在了内容这一环，不知道说些什么好，不知道该怎么去评价。

Where——找不到哪里发弹幕？

你做的再醒目，也有可能有人找不到哪里发射弹幕。

When——什么时候发不了弹幕？

仔细想想，有没有什么场景下，你的用户是无法发射弹幕的？比如说发射上一条弹幕的过程中？或者想要回复自己之前发射的弹幕？

Who——谁发不了弹幕？

如上文所说的，有可能根据你的预期，非登陆用户是无法发射弹幕的。那么你要如何温柔地对待TA？反之，如果已登录用户因为各种原因发射不了弹幕怎么办？

How——每个环节都可能出现错误

最好还是从用户和产品两个逻辑链条来分析，最后对应起来。但弹幕毕竟是个小功能，我就放一起写了。还是按之前的逻辑思路：①登陆：无法正常登陆时怎么破？②弹幕显示：图片加载不完整怎么办？用户就是不想看见弹幕怎么办？③用户就是不知道该怎么用发射框怎么办？④发射表情、图片要支持吗？发射了不和谐言论怎么破？⑤用户没看见自己发射的弹幕，于是又发了N多条，结果造成同一条刷屏就惨了；⑥回复功能不好用或者不会用怎么办？⑦同5，还要考虑万一用户想要在同一条多次回复怎么办？连续对话性质的回复如何展示？

03解决方案

梳理出有可能出现的各种情况，接下来就要做出对应的解决方案，预防发生以上问题：

Why——为什么不想参与？

两种处理措施：一是做出足够简单粗暴的引导，比如很多手机游戏都把引导做到你只差一个button就真正触发操作；二是事先设定官方NPC，给用户做出参与的榜样，同时营造社区氛围。

What——不知道说什么？

这种情况就可以降低内容制造的门槛，比如说设定好一些万能的弹幕金句（“duangduangduang我是一条小弹幕”），随机出现在弹幕发射框内，无需编辑内容就能发安设自己的弹幕，先让用户体验参与的过程，产生兴趣。

Where——哪里可以发射弹幕？

除了可以在整体引导时重点强调发射操作，还可以使用交互的手段提醒用户。

When——时间控制？

可以基本设定所有时间都可以发射弹幕。但在刚刚发射上一条弹幕时，要封闭发射框（使用进度条、转圈圈等）避免用户重复点击发射按钮。同时，不允许回复自己的弹幕。

Who——谁发不出弹幕？

对于未登录用户，TA的权限是可浏览弹幕但不可参与，所以应该是触发弹幕功能键的时候给予友好的登录提示；对于已登录用户因不明原因无法发射弹幕的情况，应当提示用户检测网络或浏览器，并同时报警后台自行检查。

How——给每个环节做预警

还是按之前的逻辑思路给予解决方案：①登陆：正常登陆时给用户正向的交互反馈，无法正常登陆时要给用户提示及修正建议；②弹幕显示：对于有图片的弹幕（如用户头像），在加载不完全时可以展示初始图案，并允许用户选择显示或者隐藏所有弹幕；③不会使用功能的情况，可以和前文中讲过的问题一起做引导；④对于弹幕的内容本身做初始限制：不支持内容的图片展示，限制性支持表情，对于违禁词汇做出市面上通行的屏蔽处理，次数多的账户可考虑封禁；⑤预防用户重复发布弹幕的话，一方面做事前控制，比如发布弹幕到新弹幕出现在屏幕上的时间不能超过3秒，相对地发布弹幕后3秒内不能发布新弹幕；另一方面可以考虑设置删除功能，可对自己的弹幕进行删除；⑥针对回复功能，做引导示范的同时，可以允许用户使用“@”直接输入想对话的用户名，实现回复的效果；⑦对同一条发言连续回复或两人多次对话，可设置私信模式，所对话的弹幕只有双方可以看到，既能保证弹幕的交互形式，又不会影响整体的弹幕展示。

04汇总修订

根据以上所有分析，把弹幕功能的实现逻辑与方案汇总成表，你就实现了对该功能较为全面的评估。但事实上，可能因为实现成本、上级安排、资源储备等等的原因，你所设计的方案并不能够完全实现，这时候就需要按照优先级，对所涉及的功能点进行合并、删减，最后实现一个最为经济的版本，既能保证用户体验，又能保证快速上线。

05原型测试

最后一步，找两三个“小白鼠”聊聊你的方案，从第三方的角度审视下方案里还有没有漏洞，有哪些可以优化的点，到这一步，所做的功能基本可以实现简单的逻辑闭环了。当然，只有相对的闭环，没有绝对的闭环，功能上线涉及到多方合作，除了产品本身的逻辑，其他环节也可能出现纰漏。总之，想要上线后没有Bug……