本文是一個(gè)PaaS平臺(tái)設(shè)計(jì)的一個(gè)復(fù)盤，筆者結(jié)合了實(shí)際的設(shè)計(jì)過程一一分享。

一、背景

PaaS平臺(tái)，公司內(nèi)部產(chǎn)品線的名稱。PaaS平臺(tái)即服務(wù)，我的理解差不多就是“中臺(tái)”，只是在叫法上有所不同。平臺(tái)能力覆蓋范圍很廣，這個(gè)需求只是其中UI框架層部分。

批量操作功能web端已有，本次只是mobile端的能力拉平。需求來源于多個(gè)業(yè)務(wù)需求，比如，審批流程中的批量同意、批量拒絕，工單流程中的批量簽名等等。

二、開始設(shè)計(jì)

1. 批量的入口放在哪里？

最初，我的想法是將入口放于頁面右上角的更多按鈕里（下圖方案一）。

但是，這個(gè)想法很快遭到了PM的反對，因?yàn)橛疑辖堑奈恢媚壳霸诖a層面配置了普通按鈕，如果要將批量的入口選在這里，意味著技術(shù)上的改動(dòng)會(huì)很大。而且平臺(tái)型產(chǎn)品在設(shè)計(jì)上有一個(gè)普遍的原則需要遵守，那就是組件和組件在迭代時(shí)應(yīng)互相不干擾。

企業(yè)級軟件滿足客戶定制化的需求，就像是用積木去拼一個(gè)樂高城堡，不能因?yàn)樾枰嘁粋€(gè)積木，就把之前的破壞掉重新做，那產(chǎn)品就有可能在無休止的返工改舊功能。當(dāng)然這一定不是絕對的，但在批量入口的選擇上，還不足以耗費(fèi)這么大的成本。

右上角的入口不行了之后，又去調(diào)研了一些競品。本著不隱藏便于找到的初衷，又設(shè)計(jì)了多個(gè)入口方案，最后A/B測試，選了右下角的懸浮按鈕。

多種入口的設(shè)計(jì)方案

2. 全選的上限是多少？

1. WEB端可以批量處理的上限是1000條，移動(dòng)端本身“窗口唯一”的特性決定了它不具備處理這么多數(shù)據(jù)的的場景；
2. 列表頁目前采用的是分頁加載，全選的話，希望能做到選中的是所有列表?xiàng)l目，而不只有已加載出來的，這一點(diǎn)是要和研發(fā)明確確認(rèn)的，萬幸的是可以做到。

3. 數(shù)據(jù)處理量大的話該怎么辦？

數(shù)據(jù)批量處理的操作不同決定了所需耗時(shí)，批量關(guān)注和批量轉(zhuǎn)移數(shù)據(jù)耗時(shí)肯定差別很大的。

那在移動(dòng)端進(jìn)行數(shù)據(jù)的大批量處理場景是否存在呢，也許做業(yè)務(wù)線需求的時(shí)候你需要考慮，但是在做平臺(tái)需求的時(shí)候，do it，因?yàn)槟悴虏坏接脩魰?huì)怎么用這么功能。功能本身是無屬性的，但我們在設(shè)計(jì)的時(shí)候，這是一個(gè)需要考慮的異常情況，需要給出解決辦法，至少要確定用戶不會(huì)玩崩你的系統(tǒng)。

（和研發(fā)同事討論，暫定50條以上定義為大數(shù)據(jù)。小于50，數(shù)據(jù)由前端處理，走同步，大于等于50，數(shù)據(jù)由后端處理，走異步）。

那問題就來了，異步開始處理的提醒，過程中數(shù)據(jù)處理的隊(duì)列，完成后如何通知，一個(gè)異步隊(duì)列存在時(shí)是否還允許第二個(gè)隊(duì)列同時(shí)存在，隊(duì)列里數(shù)據(jù)有幾種狀態(tài)，隊(duì)列中時(shí)是否能離開、離開后回來是什么狀態(tài)……

抱著這些問題，與PM和研發(fā)多次溝通確定方案，因?yàn)榕袛嗟墓?jié)點(diǎn)過多，我做了一份流程圖：

流程圖1.0

流程圖1.0完成之后，看起來太過于復(fù)雜和繁瑣，不清晰，又優(yōu)化了流程圖2.0版本，感覺好了很多：

流程圖2.0

4. 把所有的特殊情況都考慮上，那這個(gè)流程的閉環(huán)該是什么樣？

根據(jù)已有的流程圖和組件規(guī)范，結(jié)合批量的需求，輸出了頁面的常規(guī)流程和考慮上特殊情況的全流程：

常規(guī)流程及交互說明

全流程

三、最后

至此，項(xiàng)目進(jìn)入研發(fā)階段，等待產(chǎn)品驗(yàn)證。

復(fù)盤了一下之前做業(yè)務(wù)線需求的過程，兩者在思考方式和關(guān)注點(diǎn)上還是有挺大差別的：

• 權(quán)限的考慮：業(yè)務(wù)需求基本都需要多問一句：分權(quán)限嗎，而平臺(tái)需求是不考慮權(quán)限的；
• 場景：業(yè)務(wù)需求有比較明確的使用場景，而平臺(tái)需求則需要在多種業(yè)務(wù)場景里提煉出一個(gè)流程來，更多的是要做到通用；
• 驗(yàn)證環(huán)節(jié)：業(yè)務(wù)需求設(shè)計(jì)完成之后，需要對著最開始的需求點(diǎn)一一比對，查漏補(bǔ)缺。而 平臺(tái)需求則需要把多種業(yè)務(wù)場景嵌入流程中，校驗(yàn)是否做到了通用。

以上，謝謝閱讀！

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

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