IMO 服务号的海外探索
职责
交互设计师
产品
imo
平台
移动端
时间
2020
imo 服务号可以类比于微信的订阅号，用户通过订阅账号，获得自己喜欢的内容和服务。
这个项目主要展示了我的创新能力。我通过一个契机，帮助这个业务重新启动；并使用有趣的设计方案解决了发展中遇到的问题，获得了不错的结果。
背景
服务号最初来自 imo 在印度区的增长探索。2018年，4G 网络和手机在印度快速普及，印度很快被资本视为下一个“中国”，是每一个出海公司都想去尝试的探索之地。
当时 imo 在印度有千万级别的日活，但因为 Whatsapp 的竞争，日活一直在下降。 为扭转这一局势，设计和产品多次前往印度进行实地调研。
在调研中，团队发现印度人对观看电影有较强的需求，因此决定和外部网站合作，通过提供电影资源，将用户导流到 imo 内。于是服务号作为推送电影卡片的账号出现。
拉新流程
用户通过外部的电影网站链接跳转到端内观看，从而完成闭环。
但上线后，因为拉新效率较低，此路径渐渐被废弃，服务号后续无人维护，沦为历史功能。
后续我在工作中慢慢发现，因为海外有非常成熟的广告平台，所以很难有一个拉新方案的效果会比直接买量有优势。
契机
在大概一年后，一个运营活动引起了我的注意：因为 imo 上有大量的穆斯林用户，所以运营在斋月期间上线了一个提醒祷告时间的 H5 活动。但上线后活动的留存并不理想，因此希望设计团队配合进行优化。
对于穆斯林来说，”祷告“是一个很重要的习惯。但因为祷告的时间和地理位置以及季节有关，因此每天可能都可能有所不同。
留存不好的原因其实很明显：网页活动没有固定路径。可如何提供一个“合适”的路径？这是一个宗教属性非常强的功能，并不适合对所有人开放。
在这种情况下，我想到了废弃已久的服务号。这是一个非常合适的载体，对于需要的用户，订阅后即可定时接受提醒。因此我迅速的输出了第一版的祷告提醒服务号的设计方案，很快就得到了认可并被推动开发。
Quran, Salah & more
Every Muslim is obligated to pray five times a day - Fajr, Zuhr, Asr, Maghrib, and Isha.
//
上线后，这种形式相比之前的网页版留存有了巨大提升，账号订阅人数很快就达到了百万量级。
团队也看到了服务号的潜力，希望通过服务号这一媒介，给用户提供包括内容、本地生活等多项服务。
挑战
很快，运营团队谈好了多家外部服务商，端内迅速的出现了多种类型的服务号，主要可分为“内容类”和“工具类”。
但随着业务的壮大，一些问题逐渐暴露，产品、开发和外部服务商都希望对现有的功能进行调整，且各自的需求之间存在分歧。
在这种情况下，我作为项目的设计师被委以重任，大家希望设计师能提供一个新的产品框架来解决这些问题。
思路
在设计方案前，我先做的是理清问题所在。我最常用的方法是：第一性原理。当把复杂问题拆解成基础逻辑后，就很自然的会发现解决方案。
产品对交互的分歧
首先是产品内部对于交互流程的分歧。当前服务号通过会话页关注，负责内容服务的产品希望改为通过资料页关注 ，但负责工具服务的产品不同意。
表面上看,这是一个交互流程的分歧，但实际却是因为产品各自业务重点不同。两个业务都希望用户第一时间感知到自己的特点（我是什么工具、我有哪些内容），给予用户关注动机，但目前的结构无法同时做到。
TOOL
VS
CONTENT
所以如果要解决这个问题，就需要在用户接触服务号的第一场景，能够支持展示两个业务对应的关键信息：工具和内容。
TOOL
CONTENT
B. 外部和内部的不同诉求
其次，是外部服务商和开发同事的不同需求：本地运营希望为外部服务商、更加定制化的消息类型，开发同事却希望设计尽快定好需要的消息模版。
🏏 Cricket News
图为一家印度的板球媒体，他们希望提供定制化的赛程卡片信息给到订阅者。
在对技术进行详细了解后，我发现问题其实出现在消息上。在通讯产品中，因为消息会在用户间进行流转，所以如果不提前定义好消息类型，不仅在不同场景的适配工作量大，也会导致旧版本用户频繁看到不支持的消息。
既然是消息的问题，那我思考：有关定制化的服务，能否从消息剥离，通过其他模块来实现呢？
在已知我们的页面需要同时兼顾内容和工具两个属性，且工具本身提供的就是定制化的服务，那这道题的解法就清晰起来：
NEW PAGE
模板消息
定制服务
设计方案
在设计实际方案时，如何为客户实现订制化的服务成了一个新的问题。在调研了市面上的同类产品后，我设计了第一版方案，和几乎所有主流的产品一样，在底部增加一个跳板式交互，支持配置多种入口。
但我并不满足于此：在西文字体下，这种结构的拓展性较低。因此，我又输出了下方右图这种新的跳板，类似金刚区。
底部跳板
金刚区
这个方案已经可以满足绝大部分账号的需求，不过我还是不够满意，因为这个方案还是不够定制化：对比之前的方案，目前的样式对于工具类的服务号没有任何优势，不够直观，且需要用户进行一次跳转。
那么如何在同一个客户端框架下，给予每个账号充分的自定义空间？设计工具给了我新的灵感：如果需要高度定制化，任何模板都不如直接提供一个“画布”。
Component to Pen
根据我对技术的了解，这个画布可以用 Webview 来实现。对于客户端来说，只需要定义好画布是否存在，以及尺寸即可；至于画布内的内容，通过 Web 技术实现，更加灵活，改动起来也更加便捷。
在这种情况下，普通客户可以采用模版来满足大部分的诉求，但有高度定制诉求的客户，可以根据自己的需求，自由定义 Web 区域内的内容。
Customize
这个方案整体看下来非常大胆：对用户来说，服务号从一个熟悉的会话变成了全新的主页；但因为这个结构确实能够解决当时的核心问题，方案还是很快被团队采纳。
上线后，通过这个结构，服务号既能满足各种不同角色的业务诉求，又有特别强大的定制能力。
NEW CHANNEL
新服务号框架
后记
在实验了一段时间后，新的结构整体留存稳定提升约50%，这数据得益于关注率的提升。在这种情况下，此方案顺利全量，且因为一定的独创性，我使用此方案在海外成功申请了设计专利。
但我也要说一些这个方案存在的问题：这提升是完全真实的吗？可能也有一些新鲜感带来的短暂吸引。
同时因为采用 Webview 来实现定制服务，在某些网络不好的地区功能的加载成功率不足预期，因此后续的迭代里，我又对加载策略进行了详细的优化。
在某些海外地区，因为流量资费较贵，用户会选择平时关闭数据流量，只在有需要的时候打开。
但不完美才是正常的，这才需要我们一直走在追求完美的路上。