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

項(xiàng)目背景

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

使用場景

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

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

郵件計(jì)劃

可行性評估

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

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

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

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

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

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

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

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

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

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

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

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

交互設(shè)計(jì)

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

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

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

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

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

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

遍歷發(fā)送周期

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

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

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

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

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

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

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

功能后續(xù)展望

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

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

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