【 F2E – PK 心得 】公車動態網站設計 – 訪談到 UI 設計

12/05/2021 ・ 設計
F2E-公車動態網站設計-封面

關於 F2E 參賽

這篇文章主要是分享之前公司收到六角學院的邀約,參與 F2E PK 賽 的參賽心得紀錄。

PK 所製作的內容是『全台公車動態時刻查詢應用服務』活動的目標不是一個月內完成一個產品,而是透過活動練習不熟的技術和設計。而此篇文章將從 UI 設計角度,分享製作過程與收穫。

對我來說正想要練習的是:使用者研究與訪談。

所以我對這次的活動目標是:

當作一個產品開發,從使用者訪談到 Functional Map 、UI Flow、Wireframe 所有的設計流程都要走一遍,不要跳過、試著在初期放下對視覺的細節過度追求,理解使用者,想想是否有幫助到使用者。

雖然受訪的人不多只有 4 位(前期 2 位、中間 Prototype 2 位),但跟著這些受訪者的分享,了解他們的情境背景,以及使用流程,學到很多。

 

專案流程

從前述的目標擬定後,和工程師討論大致執行的專案流程會是:

F2E-公車動態網站設計-專案流程

(點擊圖片可放大)

 

整個專案時間執行時間約 8 個禮拜,前 3 ~ 4 週著重核心功能與設計,後 4~5 週則是工程師開發。而我將分享整個專案中重訪談發現核心功能擬定設計稿 Prototype 測試

 

步驟一、需求確認

因為時間比較緊湊,加上我和工程師都還有其他重要的專案在進行,時間相對又壓縮到更多,所以初期我和工程師討論,先讓我先做使用者訪談,從這些訪談抓出使用者最常使用的功能、流程,也許可以更快的確認我們的開發範圍。

之後我們找了兩位經常使用公車 App 的同事進行訪談。整個訪談的過程大概 20 分鐘左右,

在訪談前先擬定訪綱,針對幾個面向訪談:

  1. 什麼情境下使用公車 App?
  2. 操作流程分享
  3. 使用的這一個 App 的原因
  4. 和其他交通服務的差異
F2E-公車動態網站設計-使用者訪談與操作

(點擊圖片可放大)

 

在這個環節是我獲得最大的啟發,當跟著受訪者描述他在使用情境時,點下某些按鈕一邊和我分享他對這些按鈕、功能上的意思、對他的意義是什麼時,會發現他下意識的非常流暢的操作,他其實不在意那個畫面上的真正的美或醜,他更在乎的是是否能快速切到他想要的功能資訊上

我很少使用公車 App ,而受訪者分享最常用的公車 App 也是我從未用過的(我之前用過的公車 App 當初會用的原因是因為介面我喜歡,但我不是經常使用的用戶),所以當我訪談結束後反覆照著使用者的情境流程操作時,才理解為什麼他們使用了這個 App 之後就未再更換其他的 App 了,習慣它的介面流程、清楚簡單的功能介面。

 

使用者的描述 (節錄)

從這次的訪談,抓到一些受訪者描述發現是值得留意的,包含:

  • 因為是不熟的路線,所以我會在車上就打開 APP 看到哪一站要下車。這樣就會比較安心。
  • 有時候抓那個時機比較困難,像是還剩兩分鐘三分鐘,公車可能快紅燈就會衝比較快,所以我通常會先去等。
  • 如果我已經知道某些車的班次比較少,我就會先在家裡看(打開 App)還有多久才會到
  • 因為我很怕坐錯邊
  • 我通常會走到那個站牌現場看那個滾輪,他們上面就有印(公車方向)。這上面(App) 也有,但我,但我會去現場再看一次他(App 的公車路線)畫的路線在對一次。
  • 我最喜歡的是我可以看到這個區域附近有哪些站牌(附近站牌頁面) ,點進去可以看這個站牌所有的車(公車)時間表,我在這邊可以看哪班車最快到
  • 從他的地圖上比較難看得出他的方向是往哪邊,有點難用。
  • 如果要去某個地方 (不曾去過的),通常會先用 Google Map 搜尋
  • 多搭幾次就會知道車子會不會繞,如果我不清楚要搭多久或是會繞很遠,我會搭配 Google Map 使用

可以看到上述描述,得出一些常見的功能:

  • 使用者要到一個不熟的地點:即使公車 App 有路線規劃的功能,使用者還是會傾向先在 Google Map 上使用路線規劃後,查到想要搭的公車路線後,再到公車 App 內進行路線搜尋。
    • 另一個有趣的發現,即使 Google Map 提供的路線規劃上有公車路線資訊,但使用者還是會開啟公車 App。
  • 使用者會再三確認公車方向。
  • 使用者會提前開啟公車 App 確認公車抵達時間,以評估出門的時間。

 

使用者操作流程

從訪談中得到使用者最常使用的情境是:

  1. 上下班通勤使用
  2. 使用者要到(不熟的)某地

針對這項的情境,畫出使用者操作的流程,並將前述他們的描述放在流程內:

F2E-公車動態網站設計-使用者情境

(點擊圖片可放大)

將描述放在流程內後,可以清楚的看到哪一個環節使用者的顧慮、需要協助的部份。

 

使用者故事

依據訪談、流程接著再發展大致的使用者故事:

F2E-公車動態網站設計-使用者故事

從這些使用者故事,可以抓出一些功能需求(粗體字),延伸使用者故事描述再製作 Functional Map。

 

Functional Map/Flow Chart

在 Functional Map 階段,先抓出幾個功能:

  1. 搜尋 公車路線
  2. 附近的 公車站牌
  3. 附近的 公車站牌 的 公車路線
  4. 公車要多久抵達

分別將這些功能列出可能會需要的資料:

F2E-公車動態網站設計-Functional Map

接著針對 『附近的公車站牌』與『搜尋公車路線』畫出 Flow Chart ,確認流程:

F2E-公車動態網站設計-Flow Chart

(點擊可看大圖)

UI Flow

在 UI Flow 部分確認頁面之間的流程,其實從訪談描述和 Functional Map 就能大致歸納出我們的核心功能是哪些區塊和流程:

F2E-公車動態網站設計-UI Flow

(點擊圖片可放大)

 

從 UI Flow 可以看到頁面和流程並不是非常龐大和複雜,到這個階段可以彼此確認哪些頁面需要優先處理的,哪些是次要的功能。

在這個階段歸納出三大核心功能:

  • 路線搜尋
  • 附近站牌
  • 常用站牌

步驟二、 Wireframe 繪製

接著就能依照前述歸納的三大功能畫出 Wireframe :

F2E-公車動態網站設計-Wireframe

上圖僅示意路線搜尋的 Wireframe。

 

在 Wireframe 除了標注每個按鈕點擊後的流程,還有一些功能細節標註。在這些 Wireframe 完成時,也會一並和工程師過一下流程,一方面讓夥伴知道會有多少頁面與功能,另一方面也會確認功能的細節與限制。

有了這些 Wireframe 後再條列出每個 Wireframe 的操作描述,方便工程師在這個階段可以同時研究 API 串接以及功能:

F2E-公車動態網站設計-Wireframe-文字

(以上描述僅為擷取部分內容,未顯示全部)

 

步驟三、頁面設計

有了 Wireframe 的頁面和功能頁面確認後,其實到 UI 設計相對快很多,此時只要專注再每個頁面的資訊層級、排版、風格:

F2E-公車動態網站設計-頁面設計

(點圖可放大)

F2E-公車動態網站設計-路線搜尋設計稿

(點圖可放大,上圖為部分設計截圖)

 

在這一階段的設計,把握幾項重點:

  • 手機版優先:
    • 電腦版為手機版的延伸設計,所以先優先完成手機版介面後,在延伸畫面即可。
  • 簡化設計:
    • 因為路線及站牌資訊,是現階段對使用者重要的功能,所以在設計上盡量簡化,減少影響使用者瀏覽和搜尋的行為。
    • 讓工程師專注在功能的資料呈現。
  • 深色風格:
    • 因為是 PK 賽,想著如何在簡化設計下,加入一些品牌元素又不影響資料呈現?也許是主色和整體的介面風格。
    • 一開始使用五倍紅和白底介面的設計,想要一點不同的嘗試,何不來一點 Cyberpunk ?
      F2E-公車動態網站設計-Cyberpunk 截圖

      Cyberpunk 經常用於科技、電競、科幻、未來等相關意象的產品或服務中,當然這個風格已經從攻殼機動隊、一級玩家、駭客任務等大量電影、書籍形成科技產業象徵風格。

      所以在風格上改為深色與桃紅配色。

步驟四、Prototype 測試

設計好介面後,除了 Brief 給工程師確認流程外,覺得也許可以再找使用者操作一下 prototype 看看會不會有什麼問題。原先在進到測試前,難免會擔心會不會自己設計還是會偏離使用者需求太多,導致在測試階段後會需要大調設計稿。

但,我真的很慶幸前面的訪談與這次的 Prototype 測試,因為在這一階段測試時,發現使用者給的回饋大多其實只要調整文案、調整設計層級等。

F2E-公車動態網站設計-使用者的 Prototype 操作分享

 

步驟五、設計交付

確認 Prototype 測試後,微調內容、整理設計稿、設計電腦版等就提供於工程師。

此時會分別將核心功能頁面相關設計文件整理後於 GitHub 上開票,同步告知工程師,讓工程師可以依據功能查詢相關的文件:

F2E-公車動態網站設計-路線搜尋 UI 設計開票

這部分因為時間再加上工作關係,設計稿的部分其實 Components 和 Style Guide 並沒有整理的很明確,算是設計上可惜的部分。

但為了開法效率在顏色、 icon、字體,用現成的或開源的素材或服務,工程師只要查看元件命名就能找到對應的 icon 或 TailwindCSS 色票等。

 

收穫

過去沒有設計 APP 經驗,使用者訪談、探索、測試的經驗也較少,所以透過這次的活動,練習這些內容,從使用者身上學習,比我自己做設計有趣太多了!

整理訪談結果、擬定核心功能流程時,一方面想這樣真的夠嗎?還會不會需要其他的資訊?也許我可以嘗試不同層級的資訊呈現方式例如公車抵達的狀態、嘗試做多一點的設計,結果在 Prototype 時測試發現受訪者都在公車路線上卡了一下。發現後就調整簡化資訊。

另外一方面也很佩服現行的公車資訊的 APP 或服務,要滿足這一群使用者在等公車、趕公車、查公車的需求,雖然需求看起來很小,單純呈現資訊,但是只要使用者錯過了一班公車、搭錯方向、下錯站,任何一個環節都有可能導致使用者認為這個服務體驗差,而這樣的服務還有很多難以掌控的因素,包含公車司機的定位追蹤是否有開啟?路況如何?政府的 API 資訊是否夠完整夠即時?使用者的網路是否順暢?GPS 定位是否有開啟? 等各種虛擬或實體環境的資訊、設備的影響等,能感受到一個好的公車 APP 不是只有設計好頁面、切好版,更多的是需要公車、政府和使用者一起完成一個更完善的公車 APP。

比較可惜的是因為這次時間製作的較少,加上找的受訪者也比較少,初期的訪談 2 位、中間 Prototype 測試 2 位,總共蒐集四位使用者的經驗,但如果前期有加上一些量化的統計或比較相信會對製作上更有把握 ( 但相對那樣程度可能是已經到要推出到市場的產品了)。

另一方面因為我在訪談還有研究經驗較淺,所以解讀受訪者的資料或訪談的內容,可能需要有更多的練習或機會,也許會在判別和使用上更精準和快速。但相對的,這次的經驗也感受到受訪者訪談的力量與重要性。

結語

 

我還是很感謝這次六角的邀請,還有這次合作的工程師。完成了那些畫面和部分的功能。

雖然因為時間關係,沒有做完全部的內容,但我和工程師都學到很多,是很棒的經驗!

如果你想要閱讀這次的專案程式碼與設計相關文件,歡迎查閱以下:

如果你對這篇文章有任何的想法或是建議,都歡迎 E-mail 📨 給我!

謝謝你的閱讀~!