邀请好友功能设计

Glip 介绍

Glip（现已更名为 RingCentral ），一站式企业协作平台，致力于团队沟通和效率提升，17年获得 Stevie Award 金奖。

我的角色

这个项目启动于 Glip V3.1, 我们刚刚完成了 Glip 从 V2.0 到 V3.0 的改版。我作为唯一的 UX/UI 设计师和 PM 协作完成这个项目。

面临的挑战 

如图所示，当前的设计具有非常大的改进空间：

1，用户记不住邮箱，也不知道可以同时输入多个邮箱做邀请，到了邀请页面时，很多用户都放弃了；

2，一大段文字解释 “同事” 和 “客人” 的细微区别点根本没有人会去阅读；

3，邀请结束后，用户将遗忘刚刚那个邀请的人；

......

我们不断思考这些问题：

1，对于 Glip 这个极其需要新用户的阶段而言，批量邀请的价值巨大，但是用户怎么能知道他们可以同时输入并邀请多个邮箱？文字提醒？有没有其他更加简单的邀请方式？

2，如何能让用户轻易理解 “同事” 和 “客人” 的细微区别点？这点其实很重要，因为两种身份有不同的权限。

3，除了用邮箱邀请，是否有其他的方法？很明显，用户很难记住好友的邮箱。

4，如何让用户邀请完后，再做点什么，让被邀请的人使用 Glip？

我们进行了无数次的讨论，也做了无数个版本的设计，始终觉得不完美。以下是最终的定稿，我们知道，这个方案还有改进的空间，也许，这需要通过数据分析来逐步完善。

我们的方案

我们朝着这些方向做这版设计：

1，用户可以通过输入邮箱或者从本地联系人中批量邀请好友；

2，和用户有同样域名的邮箱会被默认为 “同事”，并且，为了简化流程，用户必须在一个页面内完成分类工作；

3，可以有一个邀请链接，用户通过短信或者其他 IM 分享链接，邀请好友；

4，用户邀请完后，可以引导用户到对话框，让他和被邀请人通过 Glip 产生联系，增加被邀请人使用 Glip 的几率；

趁这个机会，我们希望能同时改进当前其实不太合理的联系人页面，使其信息架构更加易于理解；

我花了很多时间思考如何能让用户在一个页面内完成对 “同事” 和 “客人” 的分类，从而最小化邀请好友这个流程的复杂性。我想出了几个方案，最后我们在以下两个方案内做选择。

我们进行了分析，在方案二中，用户不需要离开这个页面就可以完成归类。但是，根据可用性测试得到的结果，这些不同状态的按钮难以理解。在方案一中，用户需要两步（点击出现弹框，再选择身份）去完成每一个人的归类，但我们最后选择了这个方案，理由如下：

1，同样域名的邮箱已经被默认归类为 “同事”，切换用户类别的动作是相对少数的

2，方案一的 UI 看起来更加人性化，较方案二更容易理解 （这是最重要的，用户比较能理解）

3，开发实现角度上来说，方案一用是的已有的页面结构，相对简单

另外一个很重要的点就是如何让用户在做完邀请后，和被邀请者通过 Glip 再次产生联系。最简单的办法就是：如果用户只邀请一个人，那么在结束邀请后，他会被引导到对话框。

由于 Glip 的账号体系是建立在邮箱的基础上，因此，如果用户在对话框内发送消息，Glip 可以通过邮件的方式向被邀请者发送消息。我们尽量的提供用户和 Glip 交互的机会，尤其是对话框。