概述
問題
COVID-19 帶來的新正常生活型態讓遠端工作可能成為未來的趨勢，團隊間的溝通協作也愈加依賴視訊會議軟體。知名視訊會議軟體爆發的資安問題，導致許多民間公司及公家機關單位紛紛尋找安全的替代品。
我們的解決方式
我們開發了一套機敏單位內部音視訊會議的替代方案。通訊資料在地化以及整合客戶端提供的安全加密模組的視訊會議軟體服務，讓在工作團隊間的協作及溝通整合上有更安全可靠的選擇。
DELIVERABLE
✔︎ 完成跨筆記型電腦、Android 平台的平板裝置以及手機裝置的會議軟體設計
ROLE
產品設計師 – 研究、使用者體驗設計、使用者介面設計、原型設計
提供簡單易用的視訊會議應用
專案挑戰
- 開發時程及預算上的限制，專案功能面上的需求較為單純，但需要在四個月的時間下以最快速的流程完成獨立產品開發，且兼顧良好的使用者體驗。
- 應用程式涉及平台橫跨筆記型電腦、Android 平台的平板裝置以及手機裝置，降低不同解析度的畫面下將切換應用程式時的學習曲線並提高易用性。
- 產品有前台與後台，需整合前後台視覺規範
開發時程
本次專案總時程約四個月。
- 第一個月我協助產品需求的釐清及協助使用規格制定，並且規劃使用流程。
- 第二個月時進行整體視覺 Guideline 制定及高保真原型製作，並與研發部門密切討論各種實作上的限制，產品設計部門在第二個月底完成所有交付。
- 後續時間則與研發部門密切溝通，進行測試及提供反饋，進行靈活快速的動態修正。
研究
在這個階段中，我與 PM 合作一起釐清使用者的產品規格及客戶需求，以使用者旅程定義出每個階段的主要任務，並找出服務接觸點及痛點，盡可能地流暢整個使用旅程。
此專案目標是為了解決視訊會議的安全性問題，功能層面不需過度複雜，只需要有基本的會議及主持人功能，而目標使用者多為中高年齡層的男性。
- 根據客戶提供的需求，使用者有可能花費過多時間在尋找欲邀請的聯絡人。希望可以盡可能減少使用者開啟會議的前置作業，但同時能滿足客戶需求規格。
- 產品整合了合作機敏單位自行研發的資安保護機制，需提升使用者體驗並減少不悅感，及不知道如何解決的錯誤狀態。
- 因產品技術上的限制，使用者們的串流會在伺服器端混合後再傳送給會議成員，而非端點混合。故研發部門希望盡量避免於串流畫面上設計樣式（如靜音、關閉鏡頭等符號），以減少服務負擔，可能造成會議主持人無法輕易執行焦點串流的指定。
設計重點
目標（一）
減少使用者開啟會議的前置時間
減少使用者開啟會議室前的前置時間及準備，達到快速開始進行會議的目標。
設計過程
我認為開啟會議按鈕位置以及選擇會議成員這兩個流程會影響使用者達到快速開啟會議的目標。
開啟會議的使用流程
在初步的設計架構中客戶初步提出的需求，應用程式首頁可見項目有進行中的會議列表以及通訊錄。
為了達到目標，我們評估了是否將通訊錄保留在第一層位置：
在發想的階段我習慣利用空白的空間思考不同解決方法的可能性，用紙筆或是白板畫出來非常快速，也能讓思考脈絡更有組織，逐步釐清使用者的需求以及尋找合適的解決方案。
有了初步的概念後，我將使用流程分為三個階段，分別為：應用程式首頁，選擇會議成員，進行會議。並針對需要與團隊討論的開啟會議步驟提出了兩種版本 Flow，使用原型軟體繪製出較為工整且流程脈絡清晰的的 Wireflow，分別與PM、設計團隊及工程師討論。
- 由於產品限制開啟團體會議至少需要兩人以上，即使有通訊錄列表，也無法只選擇單一使用者進行雙人會議。
- 通訊錄的人員帳戶資訊皆由後台提供，在前台並沒有可編輯項目及名稱以外資訊，將通訊錄放在第一層的位置並沒有太大的意義。
基於以上兩點原因，我選擇簡化應用程式入口，不將通訊錄保留在第一層位置，而是在使用者確認開啟會議時再進行選擇成員的流程。
選擇會議成員
根據顧客提供的需求，使用者所見聯絡人需為樹狀的群組分類權限，能看見每個用戶分屬哪個群組，並且有著子母資料夾形式的聯絡人脈絡。每個使用者之間分屬不同的群組，也擁有不同的群組權限。
但我們認為此種做法使用者很有可能花費過多時間在尋找欲邀請的聯絡人。而在與顧客對談後，了解顧客的期望是管理者能夠直接掌握每個使用者的可見群組權限，但一般使用者能夠選取權限內使用者就夠了。
產出
最後，我們把選擇會議成員的位置放在開啟會議之後，這個做法簡化了整個應用程式的首頁，讓使用者更直觀做出加入會議或是開啟會議的行為，減少不必要的摸索。
而群組權限，因為是由管理者直接操控，我們決議將他移到後台管理者直接管理，能夠有效減少一般使用者開啟會議的步驟。
客戶在檢視後也同意此種做法更加符合使用者體驗。
目標（二）
減少未知感的錯誤狀態體驗
A. 在尚未進行技術面的優化期間，先解決在會議途中錯誤彈窗影響會議進行的問題。
B. 減少使用者遇到錯誤時的不確定感，並且提供解決錯誤的辦法。讓使用者不至於卡在錯誤頁面不知所措，或無法察覺應用程式已經斷線。
設計過程
A. 錯誤彈窗的出現時間點
研究
我與開發人員進行會議，深入了解專案技術面的限制。
此專案程式中包含了兩組伺服器，分別為會議列表伺服器及視訊會議伺服器，跨伺服器的整合上在早期版本的運作中可能會出現非預期的錯誤狀態。
當前設計的錯誤彈窗只能判斷是否有錯誤狀態出現，無法判斷是由哪個伺服器發生問題。故可能會出現當使用者正在使用視訊會議時，在後面執行會議列表更新的伺服器發生錯誤，錯誤彈窗便覆蓋當前會議，影響當下會議的進行。
發想
了解技術面的限制後，我們使用了折衷的解決辦法：
不論何種錯誤，皆自動關閉當前會議並回到會議列表跳出後再錯誤提示
此方案雖然會中斷使用者進行到途中的會議，但可以兼顧兩個伺服器的錯誤狀態。 且即使為會議伺服器的錯誤，會議中斷後會議列表仍然在運作，使用者能從會議列表重新加入會議。這是在當前技術限制下，較為理想的解決方案。
B. 錯誤彈窗的內容
研究
確認錯誤彈窗一率都回到列表以後再進行處理後，也了解當錯誤發生時能夠以錯誤的編號判斷錯誤的類型，有些錯誤是可以由使用者端或是程式自動嘗試排除錯誤並持續使用。
而此專案運行中可能會發生的錯誤回應總共有四種，分別為網路、伺服器、帳戶以及資料錯誤。
發想
我以使用者可操控的行為將錯誤狀態分類，為使用者端可以自行處理的錯誤，與使用者端無法自行處理的錯誤。 分類後，能夠在使用者端處理的錯誤為網路跟伺服器錯誤，而帳戶及資料錯誤是無法由使用者端自行處理，需求助 IT 人員由後台系統進行處理或是判斷錯誤原因並提供解決方式。
分為兩類錯誤狀態後，我提出了兩種錯誤彈窗的解決方案：
（1）使用者端能夠嘗試除錯的錯誤
讓使用者了解應用程式當下運行狀況，除了降低使用者未知的焦慮，也可以減少 IT 人員處理問題的負載量。
（2）使用者端無法處理的狀態
告知使用者問題管轄負責人員，讓使用者知道誰可以解決該錯誤問題。
產出
我們將錯誤狀態的跳窗設計放在會議列表端，當在會議列表端發生錯誤，錯誤跳窗會直接出現。
若為會議進行中，會議或會議列表發生錯誤，則系統會自動將進行中的會議結束後出現錯誤跳窗。 此時即使進行中的會議被強制中斷，回到會議列表排除錯誤後，使用者仍能從會議列表重新加入會議。
這是在當前技術限制下較能夠兼顧使用者體驗的解決方案。
而在錯誤跳窗的提供的資訊中分為兩種狀況：
- 使用者端可解決的異常，會告知使用者應用程式當前錯誤的問題、運作的狀況，以及可解決問題的行為，減少使用者因未知產生的焦慮感。
- 使用者端無法處理的錯誤狀態為後台系統端才能解決的異常，除了告知使用者應用程式當前錯誤的問題，讓使用者了解尋求相關人員協助，最後提供結束應用程式的按鈕作為 CTA 協助使用者處理當下能執行的行為，不至於卡在這個頁面
目標（三）
指定焦點串流的替代位置
因技術上的限制，研發部門希望盡量避免於串流影像上設計樣式及功能，以減少服務負擔。需要在不影響串流影像及兼顧使用者體驗下，整合會議主持人執行指定焦點串流的功能。
設計過程
我分析了市面上多數競品的作法，大多數競爭品項都是將執行指定焦點串流的功能放在每個串流影像的畫面右上角，主持人能夠直接選擇自己所看到的欲指定的畫面進行釘選，是較為直覺的作法，也是我們初次提出的設計方案。
與研發部門討論了解在我們的技術架構限制，讓畫面上避開資訊呈現以外的物件較能減少錯誤的產生。因此，我們要為釘選串流畫面的功能尋找一個能夠平衡研發與使用者體驗兩個面向的作法。
我研究了若將此功能與畫面分離，如何達到使用者的期望目標：
- 會議主持人能夠在此執行新的釘選畫面指令
- 會議主持人需要能夠辨識目前釘選的畫面為哪位使用者
為了達到 2. 的目標，會議主持人需要能夠將串流畫面與使用者名稱連結，我認為在控制台中已經存在既有的參與者名單及操控功能，將釘選功能整合在此處，可以減少按鈕，也減少讓使用者需要重新學習的時間。
如此，控制台擁有四項操控功能：
- 移除會議成員
- 關閉及開啟會議成員麥克風
- 關閉及開啟會議成員鏡頭
- 釘選串流畫面
以及三項狀態檢視：
- 會議成員麥克風是否開啟
- 會議成員鏡頭是否開啟
- 目前釘選串流畫面
為了區分操控功能與狀態顯示，狀態顯示為留存在畫面上的資訊呈現，而操控功能則為隱藏的執行選單。針對操控功能的呈現方式我設計了兩種方法，分別為 Hover 及右鍵呼叫選單，並使用兩版 Prototype 提供給成員進行簡易的內部測試。
最後結果認為：
- Hover 的方式能有效減少使用者摸索功能的時間
- Hover 減少呼叫點擊的行為，能快速達到操作目標
- 右鍵選單對於視覺的干擾較 Hover 選單強烈
產出
反饋
兼顧開發限制與使用者體驗的設計
這個專案時程短、功能多且跨平台，在有限的時間排序功能的重要性讓資源合理地分配在各個項目，並且在開發限制與使用者體驗間達成平衡，以達成階段驗收的目標，我認為是這個專案學到最多的地方。
現實世界中的開發流程也許並不如理想，最重要的是在開發過程持續靈活的調整步伐，與團隊在專案進行中密切的溝通，讓所有利害關係人的意見能達到共識。
隨時同步彼此工作狀況
作為設計團隊的主要成員，我主導了很多與開發人員溝通的項目。而專案進行的第三個月開始，逢台灣政府升第三級警戒，所有人開始 Work form Home，會議則移至線上進行。
無法當面共同工作，我們比在辦公室依賴更多的文字溝通，使整個團隊彼此之間能夠隨時更新並掌握進度，有問題迅速提出討論解決辦法。
也因此我學會了更加詳細的表達，有脈絡的以文字整理出清晰的會議紀錄，主動追蹤每個項目，確認項目的利害關係人都瞭解自己的任務，並且整合最後結論公布於團隊，以確保所有人都有在狀況內。
提供研發工程師完善定義互動設計規範
這個專案為新開發專案，除了涉及多個平台，所有設計系統及開發項目都是從零開始建立，在設計交付上，我為了減少設計與研發工程師的溝通落差做了許多努力，也執行了一系列的完整設計交付規劃。
- 除了設計文件之外，交付到 Zeplin 上面的設計稿我清楚註記功能、行為以及相關頁面的連結位置，工程師在執行開發時，能快速對照頁面功能以及關聯頁面，減少來回查找分散資訊的時間。
- 互動設計的細節，我以高保真的互動模型或是影片進行交付，讓研發部門能夠具體了解設計需求，減少憑空想像及來回溝通的時間。
與測試工程師及研發工程師共同有效執行設計品質控管
除了提供動態原型增加設計與研發的溝通效率外，我也會執行設計品質控管以減少設計與開發間的落差。
拿到新的測試版本後，我使用表單的方式記錄下日期及版本、涉及的平台、遇到的問題、期望行為，以及與設計稿對照的截圖，提供研發部門更具體的修改意見，讓在工程師逐步開發新項目的過程中，有效率的持續回頭修改，調整已開發項目的不足。
建立簡單但完整的 Guideline 使設計部門及研發工程部門達成產品視覺整合
因專案時程急迫，團隊分頭進行設計，我與團隊中另外兩位設計師分別負責不同項目，為了整合整體視覺，我快速建立了一套 Guideline，讓設計團隊在同時進行不同的項目時能快速掌握設計原則，減少產品彼此間的視覺落差。 這是我進入公司後第一次在開發前先導入設計系統的專案，有別於之前疊床架屋且雜亂無章的設計，此專案有系統性的規範原則，提供給整個設計團隊做靈活的運用。
