專案時間：2017-2018
工作內容：互動設計、UI設計
專案地址：美餐網
美餐網的業務是為企業定製企業員工用餐綜合解決方案，它的點餐系統是整個流程中的重要組成部分，包括了 iOS、Android、Web 三端客戶端。我在美餐工作期間恰逢公司產品線更新，參與了點餐客戶端3.0的互動設計、UI 設計及後續迭代工作。
專案背景
美餐網的業務是為企業定製企業員工用餐綜合解決方案，它的點餐系統是整個流程中的重要組成部分，是整個產品線中與使用者直接接觸的部分。
從2017年開始，由於市場需求和業務規劃，美餐的業務線開始擴充。具體表現在除了原有的線上訂餐業務，美餐規劃了多種不同型別的企業餐解決方案。而原有的客戶端顯然無法滿足新業務的需求，因此「餐客戶端 3.0」就提上了日程。我作為產品團隊的一員，參與了它的設計過程。
核心目標
對接新業務雖然迫在眉睫，但是顯然不能直接推到重建。在此前的美餐業務線中，與美餐客戶端相關的只有"線上點餐"和"電子美餐卡"(用於到店支付)這兩項業務，而其中"線上點餐"業務不論是使用者量還是業務地位是美餐的核心業務。
我們需要在儘量不影響原有核心使用體驗的情況下接入新產品線。同時由於客戶的需求有輕重緩急，而新業務的不可能短時間立即全部完成實現，因此需要讓接入過程逐步地過渡。
因此專案的核心目標是：
- 漸進式地對接新業務線需求和功能
- 符合(或儘量少地影響)原有使用者的點餐使用習慣
- 在以上條件下優化整體用餐流程的體驗
我的工作內容概述
調研和分析
我在設計團隊中參與了包括對內和對外的實地調研、訪談、問卷等方式的產品前期調研。獲取了既有的業務資訊、產品結構等資訊，為後續設計提供依據資訊。
計劃和定義
我和產品部門同事合作，定義了產品的核心目標以及後續漸進式的功能接入過程。
設計產品結構和流程
我和產品、設計同事一起定義了產品的整體結構和使用流程。
UI和互動設計
我參與了 iOS、Android、Web 三端的UI和互動設計，並和設計同事一起建立了UI元件庫。
設計工作流程優化
我和設計、開發同事配合根據當前產品設計過程的痛點對我們的設計工作流程進行了優化，詳情可見此文章，此處不贅述。
需求來源分析
進行設計之前，應該先分析需求的來源。美餐的 toB 業務特性決定了我們設計客戶端時需要主要從如下兩個相關方獲取資訊：
直接相關方
- 客戶端的直接使用者（即客戶端使用者）
間接相關方
- 使用者所屬公司的負責部門
- 美餐內部業務相關部門
- 餐廳負責人等等
經過了解，實際的業務現狀表明，間接相關方在決策中的優先順序遠高於直接相關方，這是我們的客戶端產品設計與其他 toC 產品設計的主要差異之一。在實際設計過程中，像來自大客戶的需求、美餐內部業務邏輯等這類間接相關方因素往往都會對產品設計造成巨大影響，在兩方需求完全矛盾的情況下，直接使用者的使用資料的優先順序就排在其後。
產品結構梳理
明確了需求的來源和優先順序，我們就可以來依次分析核心目標。分析兩個關鍵點，對接新業務和符合原有使用體驗。我們通過梳理產品線、業務的關係來搞清楚，對於美餐客戶端來說，有哪些新業務、功能要在哪對接，原先最核心的使用體驗是什麼。
如下圖所示，在舊的業務體系中，客戶端只與"線上點餐"和"到店"這兩項業務有關。
在新業務體系中，與美餐客戶端相關的變化有：新的食堂業務，新的取餐功能。(非核心功能和細節在圖中省略)
舊的核心流程
舊客戶端的基本結構如下圖所示，其中的核心流程"線上訂餐"就是我們要重點照顧的物件。在設計新客戶端時，需要考慮到讓新版"線上訂餐"部分的使用體驗與舊版不要有過大的差異。
向新功能過渡
不論是功能的實現還是業務的開展，都是需要時間逐步完成的。對於美餐客戶端來說，不可能讓它維持現狀停止更新，直到一年半載後所有新功能開發完畢所有業務實施成功後一鍋端上3.0。況且除去規劃好的需求，實際中還會不時有來自業務或客戶等相關方的緊急需求來"插隊"。這都促使我們必須以漸進的方式逐步釋出功能，將客戶端從2.0過渡到3.0。但是隨之而來的挑戰就是這種方式會使產品出現相當一段時間的"中間形態"，這是我們設計在設計過程中必須考慮的問題。
我們將已規劃好的需求根據優先順序進行了排期，並根據排期制定了漸進式對接新功能的釋出的策略。
設計中的關鍵點
用餐別區分業務線
在開始設計後，我們遇到的第一個問題就是如何將眾多新業務線的功能合理地併入美餐客戶端。先對比一下新舊業務體系下的用餐型別及其基本資訊。
我們發現，用餐型別比舊版多了一倍，還包括一些處於業務尚未定義的狀態，基本資訊也更多。2.0中只有一種能在客戶端中檢視的用餐型別，它採用了預設直接進入線上點餐的流程。 本以為可以通過判斷讓使用者直接進入他們對應的那種用餐型別，但是實際業務資料表明，有相當多的使用者是會對應超過一種用餐型別的（例如每天中午都能在線上訂餐、到店吃飯中二選一），因此必須考慮多種用餐型別同時出現的情況。
我們先嚐試了將各種型別作為獨立入口的方案（如下圖），測試後發現有兩個主要問題：
- 有多用餐型別的使用者習慣於對比當日所有型別後做決定，需要經常來回跳轉以檢視不同型別；
- 按型別分類不符合使用者的認知概念，使用者習慣於從日期、早中晚飯、用餐型別的順序來認知；
於是我們設計將各種用餐型別歸為不同的餐別，在餐別列表中按類別顯示，這樣有以下好處：
- 解決了上一方案的問題；
- 可以無縫對接原有點餐流程邏輯，不影響原有使用體驗和習慣；
- 任何使用者只需顯示他對應的用餐型別，不論同時有多少型別都不互相影響；
- 有擴充套件性，如果未來有新業務線需要開展新用餐型別，只需新增一種新的餐別型別即可；
(待續)