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

項目背景

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

使用場景

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

按當(dāng)前客戶工作習(xí)慣推演，領(lǐng)導(dǎo)會看到下屬的目前數(shù)據(jù)，并會基于此郵件，直接轉(zhuǎn)發(fā)郵件至對應(yīng)下屬，進行工作督促。

郵件計劃

可行性評估

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

當(dāng)然，這個需求本身也是合理的，BI產(chǎn)品大多有的功能，但對于產(chǎn)品設(shè)計來說，要100%的滿足需求存在一系列難度。

• 系統(tǒng)中的BI可以查看多種視圖（表格、銷售漏斗、地圖等），并且視圖及其看板上有其對應(yīng)的交互操作，把這些圖形及其操作移植到郵件里，難度極大。
• BI報表進行郵件推送的時候，采用的是模型分享（不同人不同權(quán)限）的方式。這也就意味著：有可能會出現(xiàn)一張看板12個視圖同一時間，按照權(quán)限的不同，發(fā)給500個人，后臺相當(dāng)于要處理500*12次數(shù)據(jù)，對服務(wù)器的壓力極大，會出現(xiàn)大規(guī)模發(fā)送失敗的概率。

在與客戶的項目對接人反復(fù)溝通后，就上面問題達成一致。

• 郵件正文允許全部為表格，可以以看板為單位發(fā)送郵件，一封郵件等于一個看板。
• 客戶手動將定時發(fā)郵件的頻率拉長，我們這邊設(shè)定性能資源的使用限制。
• 客戶允許收到郵件的時間不一致。
• 允許數(shù)據(jù)不包含當(dāng)天的。

資源占用的推導(dǎo)過程：

第一步：初始按1單位=1人1視圖計算，1看板最多可放12視圖，因此給1個人推送一封郵件即為最多占用12個單位的資源。

第二步：考慮到設(shè)置為郵件訂閱任務(wù)之后，用戶又去看板里添加了更多的視圖，因此，調(diào)整統(tǒng)計單位，1單位=1人1看板。

第三步：客戶目前的銷售人員數(shù)量大概在500上下（考慮到新入職、離職情況），因此一封日報按占用1*500=500。

第四步：假設(shè)日報、周報、雙周報、月報、季報、年報同時在一天爆發(fā)的話，將會超出服務(wù)器能夠處理的上限。與客戶協(xié)商、并具體為其分析了報表之后，最終客戶決定只發(fā)送日報、周報、月報，并且周報、月報只發(fā)送管理層。

第五步：除開系統(tǒng)日常處理數(shù)據(jù)所占用的性能之外，給客戶開出了1500個單位的資源。

第六步：統(tǒng)計系統(tǒng)BI的用戶24小時的訪問情況，發(fā)現(xiàn)0-7點為空閑時段。最終決定，日報內(nèi)容每天0點后臺開始跑數(shù)據(jù)，周報、月報預(yù)設(shè)置時間的當(dāng)天0點開始跑數(shù)據(jù)。

交互設(shè)計

當(dāng)需求和技術(shù)邊界都清楚了之后，開始進行設(shè)計。

這個需求設(shè)計難度不大，很多用的還都是系統(tǒng)的標(biāo)準(zhǔn)組件，一筆帶過。

此外，還有一些設(shè)計小細(xì)節(jié)需要注意：

1）發(fā)送測試郵件要注意發(fā)送狀態(tài)的變化，以及郵箱服務(wù)器的狀態(tài)返回。

發(fā)送測試郵件時的狀態(tài)變化

2）發(fā)送周期根據(jù)維度不同，下拉界面不一樣，但是選完之后值的顯示卻要有一個統(tǒng)一的規(guī)范，

遍歷發(fā)送周期

發(fā)送周期顯示值的規(guī)范

組件截圖示意（系統(tǒng)組件，無需單獨設(shè)計）

3）有幾個時間點的叫法是需要明確的，數(shù)據(jù)同步時間、數(shù)據(jù)查詢時間、郵件發(fā)送時間、郵件到達時間。

• 數(shù)據(jù)同步時間：系統(tǒng)獲取報表數(shù)據(jù)的時間。
• 數(shù)據(jù)查詢時間：郵件任務(wù)建立之后，去查詢BI數(shù)據(jù)的時間。
• 郵件發(fā)送時間：系統(tǒng)開始向郵箱服務(wù)器發(fā)送的時間。
• 郵件到達時間：用戶成功收到郵件的時間。

這幾個時間點存在有先后順序，用戶在配置界面設(shè)置的是郵件到達時間。因此，需要研發(fā)估算出一個大概的時間段，在用戶設(shè)置的時間基礎(chǔ)上向后倒推時間點，來估算出不同階段大概耗時多久。在這之中，還需要避開系統(tǒng)集群的訪問高峰期。

以上基本就是全部的產(chǎn)品設(shè)計過程，接下來就是技術(shù)實現(xiàn)。

目前，功能已上線，在技術(shù)實現(xiàn)過程中，并沒有出現(xiàn)大的偏差。

功能后續(xù)展望

目前該功能只支持客戶和本公司使用，但需求是硬需求，之后是有機會推廣到所有租戶的，適合做成單獨收費功能，畢竟租賃服務(wù)器、使用第三方郵件都是需要花錢的。

本文由 @瓶子 原創(chuàng)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)許可，禁止轉(zhuǎn)載。

題圖來自Unsplash，基于CC0協(xié)議。