"本文是一個PaaS平臺設計的一個覆盤，筆者結合了實際的設計過程一一分享。
本文是一個PaaS平臺設計的一個覆盤，筆者結合了實際的設計過程一一分享。
一、背景
PaaS平臺，公司內部產品線的名稱。PaaS平臺即服務，我的理解差不多就是“中臺”，只是在叫法上有所不同。平臺能力覆蓋範圍很廣，這個需求只是其中UI框架層部分。
批量操作功能web端已有，本次只是mobile端的能力拉平。需求來源於多個業務需求，比如，審批流程中的批量同意、批量拒絕，工單流程中的批量簽名等等。
二、開始設計
1. 批量的入口放在哪裡？
最初，我的想法是將入口放於頁面右上角的更多按鈕裡（下圖方案一）。
但是，這個想法很快遭到了PM的反對，因為右上角的位置目前在代碼層面配置了普通按鈕，如果要將批量的入口選在這裡，意味著技術上的改動會很大。而且平臺型產品在設計上有一個普遍的原則需要遵守，那就是組件和組件在迭代時應互相不干擾。
企業級軟件滿足客戶定製化的需求，就像是用積木去拼一個樂高城堡，不能因為需要多一個積木，就把之前的破壞掉重新做，那產品就有可能在無休止的返工改舊功能。當然這一定不是絕對的，但在批量入口的選擇上，還不足以耗費這麼大的成本。
右上角的入口不行了之後，又去調研了一些競品。本著不隱藏便於找到的初衷，又設計了多個入口方案，最後A/B測試，選了右下角的懸浮按鈕。
"本文是一個PaaS平臺設計的一個覆盤，筆者結合了實際的設計過程一一分享。
一、背景
PaaS平臺，公司內部產品線的名稱。PaaS平臺即服務，我的理解差不多就是“中臺”，只是在叫法上有所不同。平臺能力覆蓋範圍很廣，這個需求只是其中UI框架層部分。
批量操作功能web端已有，本次只是mobile端的能力拉平。需求來源於多個業務需求，比如，審批流程中的批量同意、批量拒絕，工單流程中的批量簽名等等。
二、開始設計
1. 批量的入口放在哪裡？
最初，我的想法是將入口放於頁面右上角的更多按鈕裡（下圖方案一）。
但是，這個想法很快遭到了PM的反對，因為右上角的位置目前在代碼層面配置了普通按鈕，如果要將批量的入口選在這裡，意味著技術上的改動會很大。而且平臺型產品在設計上有一個普遍的原則需要遵守，那就是組件和組件在迭代時應互相不干擾。
企業級軟件滿足客戶定製化的需求，就像是用積木去拼一個樂高城堡，不能因為需要多一個積木，就把之前的破壞掉重新做，那產品就有可能在無休止的返工改舊功能。當然這一定不是絕對的，但在批量入口的選擇上，還不足以耗費這麼大的成本。
右上角的入口不行了之後，又去調研了一些競品。本著不隱藏便於找到的初衷，又設計了多個入口方案，最後A/B測試，選了右下角的懸浮按鈕。
多種入口的設計方案
2. 全選的上限是多少？
- WEB端可以批量處理的上限是1000條，移動端本身“窗口唯一”的特性決定了它不具備處理這麼多數據的的場景；
- 列表頁目前採用的是分頁加載，全選的話，希望能做到選中的是所有列表條目，而不只有已加載出來的，這一點是要和研發明確確認的，萬幸的是可以做到。
3. 數據處理量大的話該怎麼辦？
數據批量處理的操作不同決定了所需耗時，批量關注和批量轉移數據耗時肯定差別很大的。
那在移動端進行數據的大批量處理場景是否存在呢，也許做業務線需求的時候你需要考慮，但是在做平臺需求的時候，do it，因為你猜不到用戶會怎麼用這麼功能。功能本身是無屬性的，但我們在設計的時候，這是一個需要考慮的異常情況，需要給出解決辦法，至少要確定用戶不會玩崩你的系統。
（和研發同事討論，暫定50條以上定義為大數據。小於50，數據由前端處理，走同步，大於等於50，數據由後端處理，走異步）。
那問題就來了，異步開始處理的提醒，過程中數據處理的隊列，完成後如何通知，一個異步隊列存在時是否還允許第二個隊列同時存在，隊列裡數據有幾種狀態，隊列中時是否能離開、離開後回來是什麼狀態……抱著這些問題，與PM和研發多次溝通確定方案，因為判斷的節點過多，我做了一份流程圖：
"本文是一個PaaS平臺設計的一個覆盤，筆者結合了實際的設計過程一一分享。
一、背景
PaaS平臺，公司內部產品線的名稱。PaaS平臺即服務，我的理解差不多就是“中臺”，只是在叫法上有所不同。平臺能力覆蓋範圍很廣，這個需求只是其中UI框架層部分。
批量操作功能web端已有，本次只是mobile端的能力拉平。需求來源於多個業務需求，比如，審批流程中的批量同意、批量拒絕，工單流程中的批量簽名等等。
二、開始設計
1. 批量的入口放在哪裡？
最初，我的想法是將入口放於頁面右上角的更多按鈕裡（下圖方案一）。
但是，這個想法很快遭到了PM的反對，因為右上角的位置目前在代碼層面配置了普通按鈕，如果要將批量的入口選在這裡，意味著技術上的改動會很大。而且平臺型產品在設計上有一個普遍的原則需要遵守，那就是組件和組件在迭代時應互相不干擾。
企業級軟件滿足客戶定製化的需求，就像是用積木去拼一個樂高城堡，不能因為需要多一個積木，就把之前的破壞掉重新做，那產品就有可能在無休止的返工改舊功能。當然這一定不是絕對的，但在批量入口的選擇上，還不足以耗費這麼大的成本。
右上角的入口不行了之後，又去調研了一些競品。本著不隱藏便於找到的初衷，又設計了多個入口方案，最後A/B測試，選了右下角的懸浮按鈕。
多種入口的設計方案
2. 全選的上限是多少？
- WEB端可以批量處理的上限是1000條，移動端本身“窗口唯一”的特性決定了它不具備處理這麼多數據的的場景；
- 列表頁目前採用的是分頁加載，全選的話，希望能做到選中的是所有列表條目，而不只有已加載出來的，這一點是要和研發明確確認的，萬幸的是可以做到。
3. 數據處理量大的話該怎麼辦？
數據批量處理的操作不同決定了所需耗時，批量關注和批量轉移數據耗時肯定差別很大的。
那在移動端進行數據的大批量處理場景是否存在呢，也許做業務線需求的時候你需要考慮，但是在做平臺需求的時候，do it，因為你猜不到用戶會怎麼用這麼功能。功能本身是無屬性的，但我們在設計的時候，這是一個需要考慮的異常情況，需要給出解決辦法，至少要確定用戶不會玩崩你的系統。
（和研發同事討論，暫定50條以上定義為大數據。小於50，數據由前端處理，走同步，大於等於50，數據由後端處理，走異步）。
那問題就來了，異步開始處理的提醒，過程中數據處理的隊列，完成後如何通知，一個異步隊列存在時是否還允許第二個隊列同時存在，隊列裡數據有幾種狀態，隊列中時是否能離開、離開後回來是什麼狀態……抱著這些問題，與PM和研發多次溝通確定方案，因為判斷的節點過多，我做了一份流程圖：
流程圖1.0
流程圖1.0完成之後，看起來太過於複雜和繁瑣，不清晰，又優化了流程圖2.0版本，感覺好了很多：
"本文是一個PaaS平臺設計的一個覆盤，筆者結合了實際的設計過程一一分享。
一、背景
PaaS平臺，公司內部產品線的名稱。PaaS平臺即服務，我的理解差不多就是“中臺”，只是在叫法上有所不同。平臺能力覆蓋範圍很廣，這個需求只是其中UI框架層部分。
批量操作功能web端已有，本次只是mobile端的能力拉平。需求來源於多個業務需求，比如，審批流程中的批量同意、批量拒絕，工單流程中的批量簽名等等。
二、開始設計
1. 批量的入口放在哪裡？
最初，我的想法是將入口放於頁面右上角的更多按鈕裡（下圖方案一）。
但是，這個想法很快遭到了PM的反對，因為右上角的位置目前在代碼層面配置了普通按鈕，如果要將批量的入口選在這裡，意味著技術上的改動會很大。而且平臺型產品在設計上有一個普遍的原則需要遵守，那就是組件和組件在迭代時應互相不干擾。
企業級軟件滿足客戶定製化的需求，就像是用積木去拼一個樂高城堡，不能因為需要多一個積木，就把之前的破壞掉重新做，那產品就有可能在無休止的返工改舊功能。當然這一定不是絕對的，但在批量入口的選擇上，還不足以耗費這麼大的成本。
右上角的入口不行了之後，又去調研了一些競品。本著不隱藏便於找到的初衷，又設計了多個入口方案，最後A/B測試，選了右下角的懸浮按鈕。
多種入口的設計方案
2. 全選的上限是多少？
- WEB端可以批量處理的上限是1000條，移動端本身“窗口唯一”的特性決定了它不具備處理這麼多數據的的場景；
- 列表頁目前採用的是分頁加載，全選的話，希望能做到選中的是所有列表條目，而不只有已加載出來的，這一點是要和研發明確確認的，萬幸的是可以做到。
3. 數據處理量大的話該怎麼辦？
數據批量處理的操作不同決定了所需耗時，批量關注和批量轉移數據耗時肯定差別很大的。
那在移動端進行數據的大批量處理場景是否存在呢，也許做業務線需求的時候你需要考慮，但是在做平臺需求的時候，do it，因為你猜不到用戶會怎麼用這麼功能。功能本身是無屬性的，但我們在設計的時候，這是一個需要考慮的異常情況，需要給出解決辦法，至少要確定用戶不會玩崩你的系統。
（和研發同事討論，暫定50條以上定義為大數據。小於50，數據由前端處理，走同步，大於等於50，數據由後端處理，走異步）。
那問題就來了，異步開始處理的提醒，過程中數據處理的隊列，完成後如何通知，一個異步隊列存在時是否還允許第二個隊列同時存在，隊列裡數據有幾種狀態，隊列中時是否能離開、離開後回來是什麼狀態……抱著這些問題，與PM和研發多次溝通確定方案，因為判斷的節點過多，我做了一份流程圖：
流程圖1.0
流程圖1.0完成之後，看起來太過於複雜和繁瑣，不清晰，又優化了流程圖2.0版本，感覺好了很多：
流程圖2.0
4. 把所有的特殊情況都考慮上，那這個流程的閉環該是什麼樣？
根據已有的流程圖和組件規範，結合批量的需求，輸出了頁面的常規流程和考慮上特殊情況的全流程：
"本文是一個PaaS平臺設計的一個覆盤，筆者結合了實際的設計過程一一分享。
一、背景
PaaS平臺，公司內部產品線的名稱。PaaS平臺即服務，我的理解差不多就是“中臺”，只是在叫法上有所不同。平臺能力覆蓋範圍很廣，這個需求只是其中UI框架層部分。
批量操作功能web端已有，本次只是mobile端的能力拉平。需求來源於多個業務需求，比如，審批流程中的批量同意、批量拒絕，工單流程中的批量簽名等等。
二、開始設計
1. 批量的入口放在哪裡？
最初，我的想法是將入口放於頁面右上角的更多按鈕裡（下圖方案一）。
但是，這個想法很快遭到了PM的反對，因為右上角的位置目前在代碼層面配置了普通按鈕，如果要將批量的入口選在這裡，意味著技術上的改動會很大。而且平臺型產品在設計上有一個普遍的原則需要遵守，那就是組件和組件在迭代時應互相不干擾。
企業級軟件滿足客戶定製化的需求，就像是用積木去拼一個樂高城堡，不能因為需要多一個積木，就把之前的破壞掉重新做，那產品就有可能在無休止的返工改舊功能。當然這一定不是絕對的，但在批量入口的選擇上，還不足以耗費這麼大的成本。
右上角的入口不行了之後，又去調研了一些競品。本著不隱藏便於找到的初衷，又設計了多個入口方案，最後A/B測試，選了右下角的懸浮按鈕。
多種入口的設計方案
2. 全選的上限是多少？
- WEB端可以批量處理的上限是1000條，移動端本身“窗口唯一”的特性決定了它不具備處理這麼多數據的的場景；
- 列表頁目前採用的是分頁加載，全選的話，希望能做到選中的是所有列表條目，而不只有已加載出來的，這一點是要和研發明確確認的，萬幸的是可以做到。
3. 數據處理量大的話該怎麼辦？
數據批量處理的操作不同決定了所需耗時，批量關注和批量轉移數據耗時肯定差別很大的。
那在移動端進行數據的大批量處理場景是否存在呢，也許做業務線需求的時候你需要考慮，但是在做平臺需求的時候，do it，因為你猜不到用戶會怎麼用這麼功能。功能本身是無屬性的，但我們在設計的時候，這是一個需要考慮的異常情況，需要給出解決辦法，至少要確定用戶不會玩崩你的系統。
（和研發同事討論，暫定50條以上定義為大數據。小於50，數據由前端處理，走同步，大於等於50，數據由後端處理，走異步）。
那問題就來了，異步開始處理的提醒，過程中數據處理的隊列，完成後如何通知，一個異步隊列存在時是否還允許第二個隊列同時存在，隊列裡數據有幾種狀態，隊列中時是否能離開、離開後回來是什麼狀態……抱著這些問題，與PM和研發多次溝通確定方案，因為判斷的節點過多，我做了一份流程圖：
流程圖1.0
流程圖1.0完成之後，看起來太過於複雜和繁瑣，不清晰，又優化了流程圖2.0版本，感覺好了很多：
流程圖2.0
4. 把所有的特殊情況都考慮上，那這個流程的閉環該是什麼樣？
根據已有的流程圖和組件規範，結合批量的需求，輸出了頁面的常規流程和考慮上特殊情況的全流程：
常規流程及交互說明
"本文是一個PaaS平臺設計的一個覆盤，筆者結合了實際的設計過程一一分享。
一、背景
PaaS平臺，公司內部產品線的名稱。PaaS平臺即服務，我的理解差不多就是“中臺”，只是在叫法上有所不同。平臺能力覆蓋範圍很廣，這個需求只是其中UI框架層部分。
批量操作功能web端已有，本次只是mobile端的能力拉平。需求來源於多個業務需求，比如，審批流程中的批量同意、批量拒絕，工單流程中的批量簽名等等。
二、開始設計
1. 批量的入口放在哪裡？
最初，我的想法是將入口放於頁面右上角的更多按鈕裡（下圖方案一）。
但是，這個想法很快遭到了PM的反對，因為右上角的位置目前在代碼層面配置了普通按鈕，如果要將批量的入口選在這裡，意味著技術上的改動會很大。而且平臺型產品在設計上有一個普遍的原則需要遵守，那就是組件和組件在迭代時應互相不干擾。
企業級軟件滿足客戶定製化的需求，就像是用積木去拼一個樂高城堡，不能因為需要多一個積木，就把之前的破壞掉重新做，那產品就有可能在無休止的返工改舊功能。當然這一定不是絕對的，但在批量入口的選擇上，還不足以耗費這麼大的成本。
右上角的入口不行了之後，又去調研了一些競品。本著不隱藏便於找到的初衷，又設計了多個入口方案，最後A/B測試，選了右下角的懸浮按鈕。
多種入口的設計方案
2. 全選的上限是多少？
- WEB端可以批量處理的上限是1000條，移動端本身“窗口唯一”的特性決定了它不具備處理這麼多數據的的場景；
- 列表頁目前採用的是分頁加載，全選的話，希望能做到選中的是所有列表條目，而不只有已加載出來的，這一點是要和研發明確確認的，萬幸的是可以做到。
3. 數據處理量大的話該怎麼辦？
數據批量處理的操作不同決定了所需耗時，批量關注和批量轉移數據耗時肯定差別很大的。
那在移動端進行數據的大批量處理場景是否存在呢，也許做業務線需求的時候你需要考慮，但是在做平臺需求的時候，do it，因為你猜不到用戶會怎麼用這麼功能。功能本身是無屬性的，但我們在設計的時候，這是一個需要考慮的異常情況，需要給出解決辦法，至少要確定用戶不會玩崩你的系統。
（和研發同事討論，暫定50條以上定義為大數據。小於50，數據由前端處理，走同步，大於等於50，數據由後端處理，走異步）。
那問題就來了，異步開始處理的提醒，過程中數據處理的隊列，完成後如何通知，一個異步隊列存在時是否還允許第二個隊列同時存在，隊列裡數據有幾種狀態，隊列中時是否能離開、離開後回來是什麼狀態……抱著這些問題，與PM和研發多次溝通確定方案，因為判斷的節點過多，我做了一份流程圖：
流程圖1.0
流程圖1.0完成之後，看起來太過於複雜和繁瑣，不清晰，又優化了流程圖2.0版本，感覺好了很多：
流程圖2.0
4. 把所有的特殊情況都考慮上，那這個流程的閉環該是什麼樣？
根據已有的流程圖和組件規範，結合批量的需求，輸出了頁面的常規流程和考慮上特殊情況的全流程：
常規流程及交互說明
全流程
三、最後
至此，項目進入研發階段，等待產品驗證。
覆盤了一下之前做業務線需求的過程，兩者在思考方式和關注點上還是有挺大差別的：
- 權限的考慮：業務需求基本都需要多問一句：分權限嗎，而平臺需求是不考慮權限的；
- 場景：業務需求有比較明確的使用場景，而平臺需求則需要在多種業務場景裡提煉出一個流程來，更多的是要做到通用；
- 驗證環節：業務需求設計完成之後，需要對著最開始的需求點一一比對，查漏補缺。而 平臺需求則需要把多種業務場景嵌入流程中，校驗是否做到了通用。
以上，謝謝閱讀！
本文由 @瓶子 原創發佈於人人都是產品經理，未經許可，禁止轉載。
題圖來自Unsplash，基於CC0協議。
"相關推薦
