打造 Bus+ 新樣貌!共創挑戰的探索旅程

本篇文章與「AAPD 第一屆產品設計挑戰賽」得獎隊伍合作,由成員們撰寫內容,分享產品的研究、設計方法及參賽的心路歷程。

文章目錄
一、比賽前
二、產品研究過程
三、比賽結束

一、比賽前

1. 參賽動機

我們是獲得銅獎的「不要披風!」隊伍,隊名來自於超人特攻隊衣夫人的經典台詞。隊員包括榕、牛頓、阿品、Eddy、Enola 和 Siang。每個人參加比賽都有各自的目的,例如增加經驗、與業界其他設計師交流等。我們對比賽有一致的共識,就是在這次的比賽中,交出精彩的產品設計提案!

隊長自爆對這句台詞特別情有獨鍾 (?)

2. 團隊運作

在這次的比賽過程中,團隊主要使用 Discord 頻道進行溝通。伺服器由小組隊長建立,分成不同類別的頻道,讓小組成員可以根據議題進行討論,避免文字洗版並方便組員找到重要資訊。至於會議記錄和文件製作,我們依賴另一位成員快速建立的 Notion 表單。考慮到討論次數頻繁,一位貼心的成員自告奮勇為大家建立了 Notion 的會議看板,幫助小組成員快速了解每次會議的目的和進行方向,以建立團隊有秩序的開會節奏。

Notion 公告欄,想確認開會時間來這裡就對了!

二、產品研究過程

1. 釐清目標:界定專案目標

選擇比賽專案主題

在專案一開始,我們需要先訂定好這次專案選擇的主題以及目標範圍。主辦方提供了三個企業主合作主題,我們先就題目提供各自的想法,並且以便利貼視覺化方式的呈現,再將這些想法歸納成篩選標準。透過這些標準投票,我們最終選擇的主題是 Bus+。「成員曾經是使用者且對 App 熟悉」、「現有競品多,想做出差異性有挑戰」是我們對主題的共識與挑戰。

用線上白板進行視覺化的討論

與企業合作互動與分享

在選擇完主題後,我們在線上開幕式中聽過企業主的分享,得到了更多關於優化的具體描述與期望,包括對於競品、商業目標、受眾輪廓的說明。在企業主的分享之後,我們更能理解到這次的專案,並不是像以往執行的 Side Project 只著重在設計,現在我們有了更明確的商業策略和實際企業的協作需求

開幕式中企業主的分享

因為 Bus+ 本身已是優秀的產品,為了在原本的基礎上找到新的機會,在專案初期我們透過和企業主的交流,更深入地去了解產品細節和期望目標。

2. 研究分析

建立假設以作為框架

在專案的初始階段,我們進行了深入的研究分析,以對於現有市場及產品進行現況的理解,並確立基本的方向。在透過二手資料研究及競品分析後,我們建立了假設,透過簡單的游擊訪談和內部工作坊的討論,歸納了使用者的輪廓和使用者旅程圖(UJM)。以一個清晰的起點,讓整個專案有了初步的框架。

內部工作坊:大家各自依照自身經驗、假設貼出想法,將同樣的描述歸納群組,並收斂出洞察

分工合作進行訪談

我們選擇透過深入的使用者訪談來對假設做驗證。選擇質性訪談而不是量化問卷的原因是我們希望鎖定的是痛點明確客群,而不是模糊的大眾。如果能先將使用者區分類型,從中找出對產品深刻體驗的族群,才能從中挖掘對產品策略有意義的洞察進行分群。

透過在市場分析階段時對於公開二手資料的研究,我們發現大眾運輸的使用者以台北、新北地區為主,其中又以「沒有駕照的學生」以及「想避開上下班塞車時間的上班族」為可以進一步聚焦的客群樣貌。

因此我們邀請了 20 位平時有轉乘體驗的上班族及學生,各自進行 1 個小時左右的深度訪談,並進一步分析訪談內容,找尋轉乘體驗中會發生的痛點。我們相信深度訪談更能帶領團隊找到切入點,同時也能同理用戶的需求

研究政府公開二手資料

根據要驗證的 TA 輪廓、體驗旅程以及其中的期待與痛點,我們先列出了訪談目標,接著根據目標定訂訪綱,希望能從中找出更深入的洞察。我們根據訪綱分工合作進行與使用者的深入訪談,總共收集了足足 21 份訪談結果 💥

記錄訪談的大鋼、結果(超級多!)

助教回饋解決疑難雜症

在研究的過程中,由於我們都是訪談新手,因此遇到許多問題與挑戰,例如不確定訪綱的設立是否明確、收集來的資料如何歸納等等。主辦方很貼心地提供了助教諮詢,讓大家可以在每週的助教時間提出各自的疑問,同時也可以在專屬的頻道中進行非同步討論。助教們都非常認真回覆我們的問題,讓我們的專案進行更有方向。

感謝助教提供了非常多協助 🙌🏻

3. 收斂定義

將研究結果提煉出洞察

我們將一連串的訪談結果進行提煉,透過句型「原本我以為⋯⋯,訪談後我發現⋯⋯」去彙整洞察,並且找出轉乘體驗中的痛點。

將這些提煉出的發現整理至原先的假設,對使用者輪廓及旅程地圖做驗證及迭代,最後產出完整的人物誌及使用者旅程地圖作為收斂。

將受訪者的目標與痛點歸納成 Persona
將訪談結果的洞察收斂對應到原本的假設

在整理 UJM 時,我們發現使用者通常在不同情境下,會有相對不同的轉乘體驗,因此我們將路線拆分出兩條模式,分別為固定路線及非固定路線

有趣的是,最終成果發表時,我們發現其他同樣以 Bus+ 為主題的組別,在經過使用者研究後也同樣分析出這兩條名稱一樣的路線。不同人做不同研究最終卻可以收斂出同樣結果,非常有意思。

由 Persona 展開的 UJM

由 HMW 作為研究終點

幾乎要榨光大家腦力的研究終於告一段落,我們由兩條路線不同的痛點整理出 HMW,作為研究收斂的終點。分別是:

  1. 「固定路線」:我們如何幫助使用者降低資訊模糊不清帶來的焦慮感、提升資訊的掌握感?
  2. 「非固定路線」:我們如何幫助使用者在選擇大眾運輸路線時,快速做決策並找到最適合他的路線?

4. 發想解法

天馬行空點子發想

由研究收煉出來的 HMW 作為發想的出發點,我們進行了組內的腦力激盪(Brain Storming)

在這個階段大家可以盡情發想,所有能夠符合 HMW 的解方。過程中我們得到了許多有趣的點子,由這些點子啟發出更多想法,是非常有趣的過程。

最終我們透過「最終受影響的受眾數量」、「功能創新程度」、「能夠解決問題的程度」進行衡量,並投票排序出解方的優先順序。

非常有趣的發想階段 🦄

認知走查觀察現有介面痛點

在認知走查中,我們想調查現有介面的痛點。選擇這種研究方法的原因,來自於比賽命題方向:優化

我們認為對現有介面的改善也是要進行的方向之一。因此我們運用訪談洞察的兩條不同路線對 App 進行調查。受測者的指定任務則是來自固定路線與非固定路線。我們指定情境與任務給受測者,觀察他們對介面的操作與認知。在訪談後,將觀察到有疑慮或是操作不順的流程,納入後續提案的參考來源。

在整理的表格貼流程截圖方便測試的人比對測試內容

接下來,我們整理大腦風暴發想結果,完成初步提案的 Wireframe 設計。在這個過程中,發生有組員因找到工作需要搬家,不得不請假一小段時間的情況。所幸,在組員默契不錯的情況下,我們順利完成 Wireframe 設計流程。

請假成員與接棒成員分配工作紀錄,各自在認領的工作項目註記並完成協作。

5. 測試驗證、迭代優化

易用性測試前期規劃

在進行 Wireframe 繪製之前,我們針對研究的方向進行了幾個目標和目的的討論。在前期的規劃討論中,我們原先預期功能優先級和流程圖是重要的,但在重新對焦比賽主軸後,我們認為這些的重要性較為其次,因此調整了 UX 設計流程。同時,我們也參考了在其他比賽看到的設計團隊 — Aha! 雙北女子_資訊大食怪,將認知走查納入了前期調查流程中。

新手易用性測試的小建議

在開始進行前,由於團隊都是易用性測試的新手,對於受測者條件、測試時需要注意的事項、迭代優化次數或終點不確定實際上如何執行,因此我們討論後向助教尋求建議。

針對我們的疑問, Saha 助教指出一點最關鍵的因素﹔設計的人必須想清楚易用性測試驗證目標,以及找出正確的驗證目標。因此為了梳理易用性測試任務驗證的前因後果和脈絡,成員整理了從一開始的議題假設到解決方法的脈絡,這有助於幫助我們思考解法,確保有對應到想解決的議題,而非空穴來風的點子。

用近乎土法煉鋼的方法整理設計思路,同時也能清楚看到思考上的缺點
由於團隊提出的設計解法眾多,為了在進行易用性測試時節省時間,我們初步保留了與題目相呼應且更為精彩的設計方案,而深色區塊則是我們放棄的部分。

此外助教 Saha 分享另外一個很受用的觀點:「驗證的指標是可以透過訪談迭代的!」在後續的團隊做易用性測試中還真的發生需要迭代指標的情況,身為新手在一開始設立指標,容易因為時間因素或是思考不完整的漏洞,所以在研究的過程中記得提醒允許自己彈性的調整驗證指標,以免最終走入死胡同 XD

因為時間緊迫的緣故,我們對於測試應該著重在人數的多寡或是迭代次數很沒有把握,這時 Saha 指出明確的方向:「測試的目的是驗證自己的想法」,所以設定最少的目標人數值,就可以馬上迭代做動態測試!

在易用性測試中,因應快速測試目標,我們設定 3 人為最少的目標人數值

面對測試結果意見分歧的解決之道

在團隊討論的過程中,若面臨意見分歧而難以達成一致的結論,最終結論該怎麼決定呢?

一個令人印象深刻的測試情境是,當測試者在等待公車時,發現實際公車搭乘資訊與 App 顯示的資訊不一致,需要點擊「重整頁面」按鈕以確保能得到最正確資訊。對於受測者選擇用哪種方式獲取正確資訊,團隊內部出現兩種不同看法,有一部分人偏好手動更新資訊、另外一部分人則認為自動更新資訊更能幫助他們掌握即時資訊。當時為了收斂結果非常苦惱。在最後的解法裡,我們將「自動更新資訊」留在偏好設定供使用者自由調整(我通通都要!)。但回顧這個議題,我們認為除了之前的解決方案,在未來也許能透過 A/B 測試深入了解使用者的實際偏好。

對於重整按鈕是否要具備有自動更新功能,無論是小組內部或是受測成果都存在不一致的意見 (詳見紅字內容)

6. 最終設計

UI 風格演變:從「決策優先」到「優雅出行」的驚喜轉變

UI 風格討論初期依照顏色調性、展示資料風格等找了三種不同的方向,分別是「友善體驗、決策優先、優雅出行」,在經過一番討論後,小組第一次投票的風格是「決策優先」,不同於原先 Bus+ 優雅風格,以著重資訊展示為設計的首要目標。

然而計畫趕不上變化,在最後的兩週裡,第一版設計經小組討論後認為還有改善的空間,因此即使時間緊迫,小組成員仍決議重新設計其他版本。在新的提案版本中,最終選擇「優雅出行」風格的方案,這樣意外的結果,連小組成員都驚豔「這個版本雖然跟大家當初投票方向不一樣,但套用在成果上很好看!」

優化設計抉擇與小組共識之旅

在設計初版出來後,有細心的成員根據最終結果製作了優化方向,然而有一頁的成果讓團隊陷入選擇的膠著裡。

公車路線頁面優化成果。左:Before,右:After

當時小組成員對於路線方案的 Google Maps 顯示樣式、地圖圖釘的 Icon 風格和中間重整按鈕顏色定義這幾塊議題陷入意見分歧。為了解決討論項目太多的情況,我們先決定初步方向再做第二版的篩選。我們梳理了議題討論順序後,根據達成的結論進一步拓展了第二版方案。在這過程中,逐漸形成共識,選出最終結果。

根據首頁的顏色配置提出黑白版本的初版 (左邊與中間),在這一次的討論中,我們主要聚焦在 Bottom sheet 與 Map marker 的配色,快速討論後得出右邊的結論版本。特別謝謝成員配合小組意見光速修改。
在最後一次三種版本設計裡,我們比對其他頁面的 UI 狀態,對「立即更新時間」按鈕顏色與 Tab 的 Active 顏色定義做結論後,最終選擇中間版本。

在沒有人能統籌意見的情況下,要有效凝聚與推動小組共識的方法難度很高。做出小組決議的方法,除了投票,要確保大家的想法能有效地互相碰撞,最後得出全體有共識、信服的結果。在團隊合作上,這是很值得學習的議題。

三、比賽結束

1. 反思學習

專案管理的關鍵角色

在比賽一開始,我們並未明確分配專案管理的角色,而是依賴大家自主進行進度管理。雖然所有成員都是認真負責的成熟大人,然而在時間逼迫的情況下,我們逐漸感受到時程變得混亂的問題。幸運的是,隨著比賽進行,有一位組員自願承擔後半段的專案管理工作,這使得我們的專案得以順利進行。

這次經驗讓我們深刻體會到專案管理在協作中的重要性,特別是在面對時間壓力的情況下,明確的管理角色能夠提高團隊的效率和合作能力,並確保順暢而成功的專案進行。

商業策略的影響力

我們的團隊成員對產品商業的了解有限,因此在專案設計的進行中有點忽略了商業策略的制定。尤其這次是和企業進行合作,這部分是我們覺得比較可惜的地方。成果發表的時候,透過其他組別的分享,讓我們深刻認識到,產品設計不僅僅是技術和美學的表現,更需要有明確的商業策略支持,以確保產品在市場上有競爭力。

2. 收穫心得

雖然我們在過程中面臨了一些挑戰,因為高壓的準備導致隊伍內發生摩擦,但在結束後的實體聚會中,我們成功地彼此交流,不管是比賽的心得還是經驗的分享,我們經過這次的比賽都建立了良好的關係。銅獎的肯定更是讓我們對自己的付出更有信心。每一位成員除了在比賽中發揮自己的專業能力外,也能教學相長、從彼此身上帶走一些新體悟與新能力。

比賽結束後的聚餐,慶祝得到銅獎以及大家都找到工作!

最令人開心的是,我們之中有超過半數的成員都在比賽結束後成功地轉換了工作!我們一邊找工作一邊準備比賽,最後大家一起成功轉職,在賽後的聚餐討論起這些過程真是格外珍貴。

感謝 AAPD 產品設計挑戰賽提供這樣的機會讓我們認識彼此、認識自己的不足,並在互相合作的過程中快速成長。對於每位成員來說,都是非常棒的體驗!

以下為成員在團隊中的角色及社群連結,如果想進一步聊聊,歡迎和他們聯繫!🙌🏻

  • 歐陽融 Rong [UXR]
  • 呂品函 阿品 [UXR / UXD]
  • 林曉君 Eddy [UXR / UXD / UI]
  • 賴湘蕙 Siang [UXD]
    🔗 LinkedIn
  • 范媛雅 Enola [UXD / UI]
    🔗 LinkedIn
    🔗 作品集
  • 林映辰 Newton [UI / 簡報]

--

--

AAPD — As A Product Designer
AAPD — As A Product Designer

We share digital product design experiences & help designers find their purpose and passion. Follow our Medium Publication ↑ and Facebook http://fb.me/aapd.tw