编辑导语：在负责的一个组队活动的交互设计工作中，作者发现前期在跟客户沟通需求时进展不是很顺利，为了减少信息不对等，便开始根据客户提到的一些想法来搭建初版交互流程。本文是对这次活动的总结与分享，一起来看一下吧。
前段时间负责了一个组队活动的交互设计工作，前期在跟客户沟通需求的时候进展不是很顺利，主要原因有两点：
基于这两点，为了减少大家的信息不对等，我开始根据客户提到的一些想法来搭建初版的交互流程，目的是让客户可以具象地看到用户在整个活动的操作路径是否符合预期，同时也可以通过页面与流程的展示进一步的完善需求。
以下，就是我针对这次活动的总结与分享。
虽然客户的需求比较简单，仅仅提到了以组队的形式，但是在与客户几次的沟通中我们得知，客户是希望用户每组队成功就给一个奖励，以达到活动的不断裂变，吸引更多的用户参与活动。所以我们首先需要确定的就是组队的规则。
根据以往参与组队活动的经验，我们或许都知道，组队的交互流程，其实就是将活动分享到微信等社交平台，被邀请人完成某项指定的任务后，就算加入队伍，当达到人数要求时，组队成功，获得对应奖励。但是不同的组队规则所对应的奖励形式有所不同，这里我们列举常见的两种组队形式。
1）无人数限制的组队
这种形式的组队就是用户不管邀请多少人加入队伍都可以，人数越多，队伍获得的奖励越大，奖励一般以瓜分奖池的形式，队伍中的每个人都可以瓜分到对应的奖励；另外一种形式是分阶段给奖励，比如设置每邀请3、6、9….给对应的奖励，这样的好处就是能将大目标拆解成小目标，让用户一直都有马上就要获得奖励的感觉，从而刺激用户继续邀请好友完成裂变。
2）有人数限制的组队
这种形式的组队就是设定队伍人数，用户邀请到对应的人数加入战队即组队成功，可以获得对应的奖励。为了让用户可以持续的分享，当一个队伍组建成功后，可以继续发起组队。这种形式的优势在于，每次用户重新组队的时候，自己都会占队伍的一个名额，这样就会让队伍每次都有种快组建成功的感觉，刺激用户分享。
通过以上的分析，我们结合客户的需求不难看出，第二种组队规则更适合本次活动的玩法跟预期。我们在确定了组队的基本规则后，就可以开始构建组队的整个交互流程了。
不同的运营目的所对应的组队活动的页面信息都有所不同，我们可以抛开其他的流程不谈，只单单来分析下“组队”这个功能模块的交互流程。
可能大家在参与组队活动的时候会发现，这个流程其实并不复杂，通过点击邀请按钮，分享到目标位置，被邀请用户通过邀请即成功加入该战队。但是往往简单的交互流程都会“暗藏杀机”，不提前规划好就开始流程的绘制，只会给自己挖坑导致交互流程不断的被修改。所以我们来看看都有哪些信息需要被考虑到。
交互设计师在日常工作中，最容易陷入“我以为”的思维模式中，觉得参考了几家竞品就明白了其中的奥秘。分享到哪里，我们需要结合业务跟技术可行性来考虑这个问题。
业务而言，并不是分享的途径越多带来的转化越大，过多的途径反而会让用户产生选择焦虑，需要考虑哪里的用户最有可能参与活动。比如QQ我们都知道现在的用户都是以00后为主，考虑到00后目前的属性，一个投资的活动可能不一定适合，所以在选择分享途径的时候可以不用考虑上去。
技术而言，分享到哪里需要考虑的是如何打通两个产品，并且能支持数据互通。举个例子，当你在微信给你的好友“砍一刀”时，交互流程是复制口令-打开拼多多-砍一刀。但是如果没有下载产品，用户就必须要去下载，这个就是用户完成任务的一个阻力，如果用户能在微信直接助力，app也能获取到用户信息，那参与活动的门槛就会降低很多。而这些，都是要在设计前需要技术评估的。
一般我们分享出去的都是以链接的形式，但是也有可能会被识别成“非法链接”而遭到禁用，所以我们在考虑分享形式的时候要知道都有哪些可做选择。
一般我们常用的除了链接还有口令跟生成海报，我们需要权衡每个形式的利弊。比如口令，虽然可能不会被禁用但是需要去活动主体应用打开，增加了用户的操作路径；而生成海报虽然增加了活动信息的透出与冲击力，但是也是需要用户通过识别二维码打开，没有直接打开链接方便。所以，不同的形式各有利弊，我们需要根据具体情况作出选择。
为了避免一个用户多次加入同一战队，我们需要在用户加入战队前获取用户身份来判断是否符合参与活动的条件。金融产品一般除了用户需要注册账户以外，还需要一系列的身份认证来判别用户的真实性，但是往往这个流程过于繁琐。所以我们在考虑被邀请者如何参与活动的时候，就需要考虑参与活动的条件是注册用户还是实名用户，显然用户操作路径越少，用户参与活动的可能性越大。
如上我们分析了组队活动的一些基础交互流程与注意事项，但是除此以外，我们需要考虑还有哪些功能或者流程可以进一步完善，用来提升业务目标。接下来我们进一步分析。
“组队”实际是一种熟人社交，通过不断在好友间传播达到裂变。但是我们在前期调研中发现，由于目前产品的体量小，没有多少注册用户，这样就会导致大部分用户在加入战队的时候，都需要去app注册甚至是下载产品，这无疑加大了组队的难度，那该如何提升组队的成功率来提升整个活动的运营数据呢？
按照参与活动必须注册登录的逻辑，那每个能发起组队的用户都是成功登录的状态，是否可以换一种思路，我们可以在页面中加入别人的战队，队伍如果组队成功也可以分得奖励，这样就降低了获得奖励的难度。我们将这个想法加入到交互流程并与客户沟通确认，也得到了客户的认可。
“加入战队“确实提升了用户获得组队成功奖励的概率，但是如果一味的加入别人的战队而不发起战队，就无法达到裂变的运营目标。该如何平衡呢？我们除了限制单次加入战队的数量以外，还希望提升发起战队的权重，所以增加了组队排行榜的功能，根据所有用户发起组队的成功数进行排行，对于前几名的用户，我们给予额外的奖励，从而提升用户发起组队的意愿。
组队成功了什么时候反馈？以何种形式反馈？这个是我们需要考虑的两个问题。
针对什么时候反馈，我们要知道这个不像一般的分享活动，分享出去用户返回活动就算分享成功，组队是需要被邀请者进行身份验证以后加入组队才算成功，而且还需要达到组队的人数，所以我们在考虑什么时候反馈组队成功的流程时，需要跟技术确认什么时候刷新页面数据，能获取到当前被邀请人是否接受邀请以及接受邀请的人数，再在合适的时机反馈给用户；
针对如何反馈，大致可分为两种形式：Toast或者弹窗，Toast虽然可以告诉用户组队成功的结果以及获得的奖励，但是权重太低，不足以凸显组队成功的获得感。所以我们选择弹窗的形式反馈，一方面告诉用户组队成功获得奖励，另一方面也可以引导用户继续组队。
以上，就是笔者根据过往的工作经验，分享的一篇关于构建组队活动交互流程的文章，后续也会继续分享自己在实际工作中的一些产品与交互心得与感想，经验有限，欢迎大家批评指正与交流。
本文由 @背包流浪 原创发布于人人都是产品经理，未经许可，禁止转载。
题图来自 Unsplash，基于 CC0 协议。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。