【 F2E – PK 心得 】公車動態網站設計 – 訪談到 UI 設計
12/05/2021 ・ Design
目錄
關於 F2E 參賽
這篇文章主要是分享之前公司收到六角學院的邀約，參與 F2E PK 賽 的參賽心得紀錄。
PK 所製作的內容是『全台公車動態時刻查詢應用服務』活動的目標不是一個月內完成一個產品，而是透過活動練習不熟的技術和設計。而此篇文章將從 UI 設計角度，分享製作過程與收穫。
對我來說正想要練習的是：使用者研究與訪談。
所以我對這次的活動目標是：
當作一個產品開發，從使用者訪談到 Functional Map 、UI Flow、Wireframe 所有的設計流程都要走一遍，不要跳過、試著在初期放下對視覺的細節過度追求，理解使用者，想想是否有幫助到使用者。
雖然受訪的人不多只有 4 位(前期 2 位、中間 Prototype 2 位)，但跟著這些受訪者的分享，了解他們的情境背景，以及使用流程，學到很多。
專案流程
從前述的目標擬定後，和工程師討論大致執行的專案流程會是：
(點擊圖片可放大)
整個專案時間執行時間約 8 個禮拜，前 3 ~ 4 週著重核心功能與設計，後 4~5 週則是工程師開發。而我將分享整個專案中重訪談發現與核心功能擬定、設計稿 Prototype 測試。
步驟一、需求確認
因為時間比較緊湊，加上我和工程師都還有其他重要的專案在進行，時間相對又壓縮到更多，所以初期我和工程師討論，先讓我先做使用者訪談，從這些訪談抓出使用者最常使用的功能、流程，也許可以更快的確認我們的開發範圍。
之後我們找了兩位經常使用公車 App 的同事進行訪談。整個訪談的過程大概 20 分鐘左右，
在訪談前先擬定訪綱，針對幾個面向訪談：
- 什麼情境下使用公車 App？
- 操作流程分享
- 使用的這一個 App 的原因
- 和其他交通服務的差異
(點擊圖片可放大)
在這個環節是我獲得最大的啟發，當跟著受訪者描述他在使用情境時，點下某些按鈕一邊和我分享他對這些按鈕、功能上的意思、對他的意義是什麼時，會發現他下意識的非常流暢的操作，他其實不在意那個畫面上的真正的美或醜，他更在乎的是是否能快速切到他想要的功能資訊上。
我很少使用公車 App ，而受訪者分享最常用的公車 App 也是我從未用過的（我之前用過的公車 App 當初會用的原因是因為介面我喜歡，但我不是經常使用的用戶），所以當我訪談結束後反覆照著使用者的情境流程操作時，才理解為什麼他們使用了這個 App 之後就未再更換其他的 App 了，習慣它的介面流程、清楚簡單的功能介面。
使用者的描述 (節錄)
從這次的訪談，抓到一些受訪者描述發現是值得留意的，包含：
- 因為是不熟的路線，所以我會在車上就打開 APP 看到哪一站要下車。這樣就會比較安心。
- 有時候抓那個時機比較困難，像是還剩兩分鐘三分鐘，公車可能快紅燈就會衝比較快，所以我通常會先去等。
- 如果我已經知道某些車的班次比較少，我就會先在家裡看(打開 App)，還有多久才會到。
- 因為我很怕坐錯邊。
- 我通常會走到那個站牌現場看那個滾輪，他們上面就有印(公車方向)。這上面(App) 也有，但我，但我會去現場再看一次他(App 的公車路線)畫的路線在對一次。
- 我最喜歡的是我可以看到這個區域附近有哪些站牌(附近站牌頁面) ，點進去可以看這個站牌所有的車(公車)時間表，我在這邊可以看哪班車最快到。
- 從他的地圖上比較難看得出他的方向是往哪邊，有點難用。
- 如果要去某個地方 （不曾去過的），通常會先用 Google Map 搜尋。
- 多搭幾次就會知道車子會不會繞，如果我不清楚要搭多久或是會繞很遠，我會搭配 Google Map 使用。
可以看到上述描述，得出一些常見的功能：
- 使用者要到一個不熟的地點：即使公車 App 有路線規劃的功能，使用者還是會傾向先在 Google Map 上使用路線規劃後，查到想要搭的公車路線後，再到公車 App 內進行路線搜尋。
- 另一個有趣的發現，即使 Google Map 提供的路線規劃上有公車路線資訊，但使用者還是會開啟公車 App。
- 使用者會再三確認公車方向。
- 使用者會提前開啟公車 App 確認公車抵達時間，以評估出門的時間。
使用者操作流程
從訪談中得到使用者最常使用的情境是：
- 上下班通勤使用
- 使用者要到(不熟的)某地
針對這項的情境，畫出使用者操作的流程，並將前述他們的描述放在流程內：
(點擊圖片可放大)
將描述放在流程內後，可以清楚的看到哪一個環節使用者的顧慮、需要協助的部份。
使用者故事
依據訪談、流程接著再發展大致的使用者故事：
從這些使用者故事，可以抓出一些功能需求(粗體字)，延伸使用者故事描述再製作 Functional Map。
Functional Map/Flow Chart
在 Functional Ｍap 階段，先抓出幾個功能：
- 搜尋 公車路線
- 附近的 公車站牌
- 附近的 公車站牌 的 公車路線
- 公車要多久抵達
分別將這些功能列出可能會需要的資料：
接著針對 『附近的公車站牌』與『搜尋公車路線』畫出 Flow Chart ，確認流程：
(點擊可看大圖)
UI Flow
在 UI Flow 部分確認頁面之間的流程，其實從訪談描述和 Functional Map 就能大致歸納出我們的核心功能是哪些區塊和流程：
(點擊圖片可放大)
從 UI Flow 可以看到頁面和流程並不是非常龐大和複雜，到這個階段可以彼此確認哪些頁面需要優先處理的，哪些是次要的功能。
在這個階段歸納出三大核心功能：
- 路線搜尋
- 附近站牌
- 常用站牌
步驟二、 Wireframe 繪製
接著就能依照前述歸納的三大功能畫出 Wireframe ：
上圖僅示意路線搜尋的 Wireframe。
在 Wireframe 除了標注每個按鈕點擊後的流程，還有一些功能細節標註。在這些 Wireframe 完成時，也會一並和工程師過一下流程，一方面讓夥伴知道會有多少頁面與功能，另一方面也會確認功能的細節與限制。
有了這些 Wireframe 後再條列出每個 Wireframe 的操作描述，方便工程師在這個階段可以同時研究 API 串接以及功能：
(以上描述僅為擷取部分內容，未顯示全部)
步驟三、頁面設計
有了 Wireframe 的頁面和功能頁面確認後，其實到 UI 設計相對快很多，此時只要專注在每個頁面的資訊層級、排版、風格：
(點圖可放大)
(點圖可放大，上圖為部分設計截圖)
在這一階段的設計，把握幾項重點：
- 手機版優先：
- 電腦版為手機版的延伸設計，所以先優先完成手機版介面後，再延伸畫面即可。
- 簡化設計：
- 因為路線及站牌資訊，是現階段對使用者重要的功能，所以在設計上盡量簡化，減少影響使用者瀏覽和搜尋的行為。
- 讓工程師專注在功能的資料呈現。
- 深色風格：
- 因為是 PK 賽，想著如何在簡化設計下，加入一些品牌元素又不影響資料呈現？也許是主色和整體的介面風格。
- 一開始使用五倍紅和白底介面的設計，想要一點不同的嘗試，何不來一點 Cyberpunk ？
Cyberpunk 經常用於科技、電競、科幻、未來等相關意象的產品或服務中，當然這個風格已經從攻殼機動隊、一級玩家、駭客任務等大量電影、書籍形成科技產業象徵風格。
所以在風格上改為深色與桃紅配色。
步驟四、Prototype 測試
設計好介面後，除了 Brief 給工程師確認流程外，覺得也許可以再找使用者操作一下 prototype 看看會不會有什麼問題。原本進到測試前，難免會擔心會不會自己設計還是會偏離使用者需求太多，導致在測試階段後會需要大調設計稿。
但，我真的很慶幸前面的訪談與這次的 Prototype 測試，因為在這一階段測試時，發現使用者給的回饋大多其實只要調整文案、調整設計層級等。
步驟五、設計交付
確認 Prototype 測試後，微調內容、整理設計稿、設計電腦版等就提供於工程師。
此時會分別將核心功能頁面相關設計文件整理後於 GitHub 上開票，同步告知工程師，讓工程師可以依據功能查詢相關的文件：
這部分因為時間再加上工作關係，設計稿的部分其實 Components 和 Style Guide 並沒有整理的很明確，算是設計上可惜的部分。
但為了開發效率，顏色、 icon、字體使用現成的或開源的素材，工程師只要查看元件命名就能找到對應的 icon 或 TailwindCSS 色票等。
收穫
過去沒有設計 APP 經驗，使用者訪談、探索、測試的經驗也較少，所以透過這次的活動，練習這些內容，從使用者身上學習，比我自己做設計有趣太多了！
整理訪談結果、擬定核心功能流程時，一方面想這樣真的夠嗎？還會不會需要其他的資訊？也許我可以嘗試不同層級的資訊呈現方式例如公車抵達的狀態、嘗試做多一點的設計，結果在 Prototype 時測試發現受訪者都在公車路線上卡了一下。發現後就調整簡化資訊。
另外一方面也很佩服現行的公車資訊的 APP 或服務，要滿足這一群使用者在等公車、趕公車、查公車的需求，雖然需求看起來很小，單純呈現資訊，但是只要使用者錯過了一班公車、搭錯方向、下錯站，任何一個環節都有可能導致使用者認為這個服務體驗差，而這樣的服務還有很多難以掌控的因素，包含公車司機的定位追蹤是否有開啟？路況如何？政府的 API 資訊是否夠完整夠即時？使用者的網路是否順暢？GPS 定位是否有開啟？ 等各種虛擬或實體環境的資訊、設備的影響等，能感受到一個好的公車 APP 不是只有設計好頁面、切好版，更多的是需要公車、政府和使用者一起完成一個更完善的公車 APP。
比較可惜的是因為這次時間製作的較少，加上找的受訪者也比較少，初期的訪談 2 位、中間 Prototype 測試 2 位，總共蒐集四位使用者的經驗，但如果前期有加上一些量化的統計或比較相信會對製作上更有把握 ( 但相對那樣程度可能是已經到要推出到市場的產品了）。
另一方面因為我在訪談還有研究經驗較淺，所以解讀受訪者的資料或訪談的內容，可能需要有更多的練習或機會，也許會在判別和使用上更精準和快速。但相對的，這次的經驗也感受到受訪者訪談的力量與重要性。
結語
我還是很感謝這次六角的邀請，還有這次合作的工程師。完成了那些畫面和部分的功能。
雖然因為時間關係，沒有做完全部的內容，但我和工程師都學到很多，是很棒的經驗！
如果你想要閱讀這次的專案程式碼與設計相關文件，歡迎查閱以下：
- 公開程式碼：F2E-BusTravel | GitHub
- 設計稿：公車動態網站設計｜Figma
- Demo ：五倍公車旅程 (建議以手機操作，尚有部分功能未完成)
- 活動影片連結：六角學員 x 五倍紅寶石 PK 賽 ｜Youtube
- F2E 活動連結：The F2E 前端 & UI 修煉精神時光屋
如果你對這篇文章有任何的想法或是建議，都歡迎 E-mail 📨 給我！
謝謝你的閱讀～！