本文筆者將對一個郵件訂閱功能設計的項目的需求進行可行性評估，再對交互設計的過程進行展示以及指出相關的值得注意的交互細節。

項目背景

• 戰略級客戶提出的需求。
• 客戶的工作模式是重報表、重郵件，客戶內部開發及使用的報表系統都有郵件訂閱功能。
• 產品先在客戶銷管部使用，方式為通過每天給銷售及其領導發郵件的方式，督促他們的銷售人員在系統中即時錄入銷售數據，并進行后續跟蹤。
• 客戶希望通過發郵件的方式做到歷史數據的留存（起到快照的作用），同時由于數據具有敏感性，希望通過發郵件的方式能弱化工作人員在系統中使用數據導出的操作習慣。

使用場景

銷管部為一線銷售、中層及中高層定制報告（日報、周報、雙周報、月報），并按周期訂閱發送郵件。

按當前客戶工作習慣推演，領導會看到下屬的目前數據，并會基于此郵件，直接轉發郵件至對應下屬，進行工作督促。

郵件計劃

可行性評估

這是大客戶爸爸提過來的需求，因此不存在評估需求合不合理，直接討論如何實現。

當然，這個需求本身也是合理的，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協議。