電商管理後台
設定動態可下單時段功能
專案簡述
提供電商平台人員能自訂義平台的每日配送時段，以供消費者於結帳時選擇。
可設制各時段的結單時間、訂單量
於節日、特殊情況時，可額外設置指定的獨立時段，以應付臨時業務。
專案架構
此產品是一個已在營運的蔬果電商網站，為公司接手其他團隊繼續開發與維護的項目。
客戶初期以下單48小時內配送交貨（以下簡稱48小時快配）的商業模式為主軸經營，希望拓展24小時快配的業務。
此專案將介紹於既有的管理後台中，重構舊功能以滿足商業模式改變的需求。
目標需求
設置每日輪迴的下單時間，讓消費者能夠於下單時選擇
可獨立設定各時段的截止下單時間，與最高訂單的接收量
於特殊日時能開關指定可下單時段，以負荷臨時的業務量
負責項目
訪問客戶目標需求｜分析功能與評估｜撰寫需求文檔(PRD)
介面重構設計｜交互邏輯的定義｜測試與驗收
規劃流程
以流程圖來建立使用者旅程，建構實現需求的操作方向
需求確認
通過視覺化的流程圖呈現功能的操作步驟，詳細與客戶核對目標需求，並確認操作邏輯是否符合預期。在與客戶溝通的同時也了解其業務流程，在規劃功能時即以平台的商業模式作為依據。
分析目標與評估限制
分析舊功能與新需求之間的不同，並且了解既定的程式碼限制，通過與團隊的溝通討論，設計出最小可行性的流程。
新舊功能對比
由於舊版的配置可下單時段的功能是靜態的，平台人員只能輸入固定的可下單時間，時間也只會在隔日顯示於消費者前台。考量到未來客戶的業務邏輯可能還會有變動，於是將可下單時段重構設計為動態的邏輯循環，兼容新舊需求，讓平台方能有更多的彈性去滿足任何情況的改變。
內部定義與溝通
繪製邏輯圖：
以視覺的方式向開發團隊解釋動態設定的邏輯流轉。
撰寫需求文檔：定義前、後端工程師需設定和記錄的參數與頁面交互邏輯，讓內部人員能有清楚的依據進行開發。
以時間軸的圖示表達時間設定邏輯
通過圖像與文字相互輔佐，確保團隊的每個人對於目標需求的認知相同，以減少執行上的錯誤造成開發成本增加。
專案管理
開發時，透過notion看板來掌握功能的開發進度，以及紀錄測試產生出的bug，讓工程師能知道哪些事情是待修復的。
透過圖文記錄能了解bug的詳細情境以及目標需求，進而提高修復效率和掌握進度。
建立狀態看板，讓Bug的重要度清楚呈現
介面設計
配送時段設定
承襲原有的後台設計規範，針對新功能的加入重新安排了畫面層級的配置。
將常用的每日配送時段資訊放在頁面上方，讓平台人員進入此頁時，可快速了解日常開放的時段內容、最高訂單量以及時段的開放下單時間。將此區塊固定高度，在有多個時間被設置時，也能最大限度地瀏覽整頁資訊。
原畫面於2.處放置了搜尋欄位，由於此頁面最主要是展示時間、訂單上線數量、開放下單的時間區段，經過評估，認為「搜尋」的功能在此處並無實質用處，因此移除搜尋欄位。
特殊日配送時段的設定功能放於頁面下方，並將區塊規劃於100vh內能夠看見的範圍，讓平台人員可以清楚知曉已設置了哪些時段為特殊日，進而設定所需的業務內容。
每日配送時段
將新增每日配送時段的頁面保留原有的「起始/結束時間」、「訂單上限」欄位，新增「開放下單時間」，讓人員可以直接設置此時段從何時開放下單、何時截止下單。達到不過度更改平台人員現有習慣，也能設置新業務需求的功能。
特殊日配送時段
選擇指定修改日期後，平台人員可以直接勾選既有的「每日配送時段」，來達到修改平時該時段的訂單上線、開放下單時間，在遭遇颱風天、節慶等日，就能夠預先關閉或是增加訂單數量，彈性設定而不影響隔日的可下單時間。
如果想指定某個非每日配送時段的時間，則可以使用「新增時段」來達到額外設置區間的目標。
專案成效
日期（X軸）與訂單量（Y軸）長條圖（N為功能上線日）
最終動態設定可下單時段功能如期上線，幫助客戶完成24小時快配的需求。功能運行的第一天(圖中N日)，平台訂單量即比以往平均值(N日前)提高了50%，未來的一周也持續以每日增加5~10%的訂單量成長，為客戶帶來亮眼的業績。
專案回顧
這次的專案是在一個已上線營運、有完整架構的產品上，增加全新的大功能，而新需求跟原先客戶的商業模式有所不同，在規劃上必須考量到開發成本、客戶目標以及未來延展性的面相，對比以往的經驗來說很具挑戰性。不過藉由收斂需求、與團隊討論，以及綜合曾經設計過類似邏輯的經驗，最終一同產出了很棒的結果。而這次的專案我也擔任了PM之一的角色，透過撰寫需求文檔讓我更清楚思考整體功能的細節定義，減少邏輯破洞和提示畫面的遺漏，進而提升設計品質和速度，讓我學習到了許多。
