本文笔者将对一个邮件订阅功能设计的项目的需求进行可行性评估，再对交互设计的过程进行展示以及指出相关的值得注意的交互细节。

项目背景

• 战略级客户提出的需求。
• 客户的工作模式是重报表、重邮件，客户内部开发及使用的报表系统都有邮件订阅功能。
• 产品先在客户销管部使用，方式为通过每天给销售及其领导发邮件的方式，督促他们的销售人员在系统中即时录入销售数据，并进行后续跟踪。
• 客户希望通过发邮件的方式做到历史数据的留存（起到快照的作用），同时由于数据具有敏感性，希望通过发邮件的方式能弱化工作人员在系统中使用数据导出的操作习惯。

使用场景

销管部为一线销售、中层及中高层定制报告（日报、周报、双周报、月报），并按周期订阅发送邮件。

按当前客户工作习惯推演，领导会看到下属的目前数据，并会基于此邮件，直接转发邮件至对应下属，进行工作督促。

邮件计划

可行性评估

这是大客户爸爸提过来的需求，因此不存在评估需求合不合理，直接讨论如何实现。

当然，这个需求本身也是合理的，BI产品大多有的功能，但对于产品设计来说，要100%的满足需求存在一系列难度。

• 系统中的BI可以查看多种视图（表格、销售漏斗、地图等），并且视图及其看板上有其对应的交互操作，把这些图形及其操作移植到邮件里，难度极大。
• BI报表进行邮件推送的时候，采用的是模型分享（不同人不同权限）的方式。这也就意味着：有可能会出现一张看板12个视图同一时间，按照权限的不同，发给500个人，后台相当于要处理500*12次数据，对服务器的压力极大，会出现大规模发送失败的概率。

在与客户的项目对接人反复沟通后，就上面问题达成一致。

• 邮件正文允许全部为表格，可以以看板为单位发送邮件，一封邮件等于一个看板。
• 客户手动将定时发邮件的频率拉长，我们这边设定性能资源的使用限制。
• 客户允许收到邮件的时间不一致。
• 允许数据不包含当天的。

资源占用的推导过程：

第一步：初始按1单位=1人1视图计算，1看板最多可放12视图，因此给1个人推送一封邮件即为最多占用12个单位的资源。

第二步：考虑到设置为邮件订阅任务之后，用户又去看板里添加了更多的视图，因此，调整统计单位，1单位=1人1看板。

第三步：客户目前的销售人员数量大概在500上下（考虑到新入职、离职情况），因此一封日报按占用1*500=500。

第四步：假设日报、周报、双周报、月报、季报、年报同时在一天爆发的话，将会超出服务器能够处理的上限。与客户协商、并具体为其分析了报表之后，最终客户决定只发送日报、周报、月报，并且周报、月报只发送管理层。

第五步：除开系统日常处理数据所占用的性能之外，给客户开出了1500个单位的资源。

第六步：统计系统BI的用户24小时的访问情况，发现0-7点为空闲时段。最终决定，日报内容每天0点后台开始跑数据，周报、月报预设置时间的当天0点开始跑数据。

交互设计

当需求和技术边界都清楚了之后，开始进行设计。

这个需求设计难度不大，很多用的还都是系统的标准组件，一笔带过。

此外，还有一些设计小细节需要注意：

1）发送测试邮件要注意发送状态的变化，以及邮箱服务器的状态返回。

发送测试邮件时的状态变化

2）发送周期根据维度不同，下拉界面不一样，但是选完之后值的显示却要有一个统一的规范，

遍历发送周期

发送周期显示值的规范

组件截图示意（系统组件，无需单独设计）

3）有几个时间点的叫法是需要明确的，数据同步时间、数据查询时间、邮件发送时间、邮件到达时间。

• 数据同步时间：系统获取报表数据的时间。
• 数据查询时间：邮件任务建立之后，去查询BI数据的时间。
• 邮件发送时间：系统开始向邮箱服务器发送的时间。
• 邮件到达时间：用户成功收到邮件的时间。

这几个时间点存在有先后顺序，用户在配置界面设置的是邮件到达时间。因此，需要研发估算出一个大概的时间段，在用户设置的时间基础上向后倒推时间点，来估算出不同阶段大概耗时多久。在这之中，还需要避开系统集群的访问高峰期。

以上基本就是全部的产品设计过程，接下来就是技术实现。

目前，功能已上线，在技术实现过程中，并没有出现大的偏差。

功能后续展望

目前该功能只支持客户和本公司使用，但需求是硬需求，之后是有机会推广到所有租户的，适合做成单独收费功能，毕竟租赁服务器、使用第三方邮件都是需要花钱的。

本文由 @瓶子 原创发布于人人都是产品经理，未经许可，禁止转载。

题图来自Unsplash，基于CC0协议。