提供介面化的商品建檔工具，降低人力資源管理維護
Project Background & Issues
我方是面向特定目標族群的綜合型電商平台，與多家廠商合作，提供通路管道販售商品。一直以來，廠商的新品提報與建檔流程，都是透過我方的商品開發人員（簡稱商開）與廠商端，長期使用表單溝通，其中有很多的痛點：
-
表單的格式無法被限制，廠商可以發揮各式創意填寫，造成來回修正資料的溝通成本非常高
-
廠商可以協助的程度很少，因為只有我們內部人員有權限編輯
-
廠商進度追蹤不易，只能敲商開line
Challenge
目標：新品提報功能介面化
讓整個上架流程，主要由廠商在我方開發的 SCM (Supply Chain Management) 平台上填寫資料，我方商開人員可以只做審查角色
-
如何在目前已有的開發進度下，提供未來功能的擴充性？
-
如何透過易用性測試，改善介面使用體驗？
-
如何在人力有限的情況下，提升後台的開發效率？
Deliverable
✔ 供廠商使用的商品提報與追蹤web介面服務
✔ 供廠商使用的商品管理web介面服務
✔ 供內部商開與廠商管理（簡稱廠管）使用的商品審查web介面服務
Outcome
✦ 上線1個月，即通過649品，81個廠商 🎉
✦ 幫助商開與廠管減少了一定的工作時間
✦ 增加資料驗證即時性＆增加資料正確性
✦ 廠商可以自行追蹤商品建檔進度
✦ 提報流程單純化，每個步驟職責分清楚，讓商開/廠商操作更容易上手，工程維護更容易
✦ 商品建檔資料錯誤時，有明確責任歸屬
Role
UI/UX designer: Prototype, Mock-up, User testing
Function Scope / User Flow
CASE 1
提供更好的介面擴充性
Situation
我接手的專案進度是，前任設計師已大致完成的 high-fidelity mock-up，由我接續處理並與開發端溝通。 由於整個商品的上架流程，從提報建檔，到可以在購物前台完整呈現圖文介紹，是一連串需要分階段來逐一實行的帶狀規劃，彼此之間可各自獨立，又有一定關聯，在規劃前面也需考量到後面。 前任團隊專注在當下的規劃範圍（商品提報建檔），沒有考量到之後的擴充功能（商品的更多規格、圖文編輯等）。
Task
如何在目前已有的開發進度下，提供未來功能的擴充性？
Research & Points
研究各家競品，發現由於商品管理平台通常功能很多，且是面向各式不同類型的使用者，可能是廠商端(2B)，也可能是直接由個體用戶操作(2C)，所以清楚的資訊架構很重要，使用者要夠容易在眾多項目中找到當前所需的，介面架構本身也要提供良好的功能擴充性。
Action
重構整個SCM平台架構的navigation導覽系統：
簡化Header、將主分類改成左側欄，並可收合，把畫面留給主要作業區塊
新增商品頁面從 popup panel 改成 full page tab view
Result
成功提升平台的擴充性與使用靈活度，後續的新增專案皆可順利基於這個新架構發展。
Takeaways
團隊需要能夠從前期的需求評估階段，劃分清楚專案的長期目標＆短期目標，用更全面的視角，審視整個線性帶狀流程後，再來評估出處在當下這個點的專案，該用什麼方式來處理。 而在確認需求後，多少會受到工程開發限制與時程需求的影響，如何從各方面評估斷點，是需要與需求端及開發端做更多思考與討論的。
CASE 2
改善資訊層級，幫助更好理解使用
在產品實際上線前，我們進行了幾場易用性測試，驗證使用者是否理解操作行為，其中獲得許多發現！發現造成諸多問題的原因是：資訊層級的設計，不當影響使用認知。
易用性測試現場
收斂後，按照優先級分類的待處理項目
測試過程的協作紀錄
任務行為紀錄
Issue & Action
誤把搜尋區塊當作提報的地方，直接在搜尋欄位輸入商品資訊...
→ 加強搜尋區塊的視覺群組化，並透過樣式設計，提升主要任務按鈕（新增一筆商品）的存在感
填寫多尺寸時，會跟規格欄位混淆＆不理解如何新增更多尺寸與按鈕的意思...
→ [迭代1: popup版本] 加強群組化右側多尺寸區塊，調整新增多尺寸按鈕的字串與呈現方式
→ [迭代2: tab view版本] 改成表格形式，並調整操作流程與按鈕呈現，讓新增多尺寸與複用價格資訊更直覺
Result
透過快速迭代 prototype 驗證效果，第二次的易用性測試效果明顯改善。
Takeaways
在這次易用性測試明顯感受到，使用者實際操作的認知，與我們的想像很不同
→ 需要足夠的 前期蒐集資訊 與 後期操作測試，才能真正融入情境，做出符合實際用戶需求的產品
→ 個人功力的累積，需要經驗或多看產品，能在一個基本的層面看出是否好操作
Design Consistency
建立統一的設計組件庫
以往內部的後台系統沒有前後端分離，也沒有一致的設計管理。開始做前後端分離後，為方便更有效率開發，前端工程師統一使用開源的組件庫。從我以設計師身份接手後，開始建立設計端統一的 library，包含各式常使用到的色彩定義、元件、行為定義等，對於後續開發的專案，都能確保一致的設計語言，也在溝通上很有幫助，並提升實作效率。
制定 Color Style & Effect style
建立 component 資料庫
可快速隨頁面需求切換 component 的型態
Result
Mock up 成果
商品提報頁
-
透過放置在高層級的顯眼按鈕，廠商可以在此頁清楚地知道如何提報新品，並依據他的需求，選擇一次匯入多筆商品，或是只新增一筆商品。
-
廠商可以針對還在草稿階段的新品編輯修改，並可快速複製商品或刪除，完善內容後即可勾選並送出審查。
-
在成功上傳或新增商品後，廠商可以輕易的透過搜尋，或點擊送審進度tab，來查看他所提報的新品目前審查進度在哪裡，是在審查中、未通過、還是已通過的階段。
新增商品頁
-
廠商可以流暢的順著介面動線，新增新品的各種繁瑣資料，而不感到混淆迷失。
-
依據所選的商品類型，欄位會自動做相應的驗證機制。e.g. 食品類 > 必填保存期限、書籍類 > 必填 ISBN、出貨模式是媽咪愛出貨 > 必填商品外包裝尺寸
-
可以方便快速的建立多尺寸商品，系統會自動帶入相同參數。
Wrapping Up
-
一個專案從收斂需求到拍板劃定涉略範圍，經過主導者與各方人員的溝通協調，需要用高層級的視角審視過整個大致可能的發展，才能在聚焦當下的範圍時，以能容納未來擴充的考量下去思考。這樣的思維模式是每個專案參與者，無論PM, designer, engineer都需要有的。
-
設計師很大一部分的專業在於介面的掌握度，需要能夠立基於商業策略、用戶角度、易用體驗等面向，以純熟且合適的設計方式來組織產品。
-
自有產品必須系統性地建立設計資料庫，確保產品一致調性與使用體驗，並降低溝通與製作草稿的成本。