如何從 0 到 1 ：設計 Hikingbook 的第一款穿戴式裝置的 App
以終為始拆解設計流程並與團隊密集協作進行開發
Hi 大家好！ 我是 Hikingbook 的產品設計師，家蔚。
2024 年 1 月，Hikingbook 正式發布了第一款支援 Apple Watch 的應用程式。
本文將介紹從設計師的角度如何「以終為始」進行目標導向的工作規劃、透過 Wireflow 降低實作的開發風險，在 0 開發經驗的平台上權衡使用者需求、商業考量、實作限制並打磨細緻的使用者體驗。
目錄
▍建立觀點並凝聚團隊想像、規劃整體開發流程
▍從使用者訪談了解需求，收斂開發規格
▍閱讀官方文件掌握最新的技術與最佳實踐
▍由設計師引導開發團隊，共同探索概念和實作可行性
▍Beta Program 收集使用者回饋並快速迭代
▍以終為始並持之以恆，讓美好的事物發生▋建立觀點並凝聚團隊想像、規劃整體開發流程
定義開發規格前，我希望優先研究現有上穿戴式裝置應用程式（以下簡稱 App）的基本功能和限制，讓團隊能夠快速了解市場上類似產品服務的現狀。
從Apple Watch 的 App Store 下載「戶外活動紀錄」、「離線地圖導航」、「運動數據統計」等類別的 App ，進行競品分析後，就能開始建立對穿戴式裝置 App 的基礎理解。
利用現有的 App ，讓團隊在實際投入開發資源前，快速了解以下三點：
- 使用者對穿戴式裝置 App 功能的最低要求。
- 潛在可能的實作限制。
- 穿戴式裝置上常見的設計模式。
只需要分析競品 App 的資訊架構甚至是單純整理操作介面的截圖，就能讓團隊聚焦對當前穿戴式裝置 App 的認知和想像。
完成初步分析後，團隊即可建立起統一的參考基準：
- 從產品設計的角度，觀察不同競品是如何設計功能相似的頁面、分析相似的功能在不同的設計中可能的取捨。
- 從程式實作的角度，推敲不同的產品是如何處理資料的同步、傳遞、錯誤處理等技術細節。
對於未開發過穿戴式裝置 App 的團隊，透過桌面研究就能獲得的資訊對開發規劃仍有許多參考價值。
結束開發前的研究後，團隊將整個開發專案規劃為 4 個階段，每個階段的最終成果都與下個階段環環相扣：
- 深入了解使用者，決定最終開發規格
- 設計與實作密切協作，根據規格探索開發可行性
- 發佈測試 Beta Program，優化產品並降低上線風險
- 正式版本發佈，未來同時維護手機與穿戴式裝置上的體驗
▋從使用者訪談了解需求，收斂開發規格
Hikingbook 最初是在 iOS 系統上開發的 App，在過去幾年中， iOS 系統使用者們持續不斷向團隊許願希望 Hikingbook 可以支援 Apple Watch 。
最終在 2023 年團隊決定將 Apple Watch 平台作為在穿戴式裝置上開發產品的第一步。
在深入穿戴式裝置 App 的開發前，最重要的一件事就是「決定開發規格」，確認規格後團隊才能建立明確的目標並以此規劃後續的時程。
為避免閉門造車、對幻想中的使用者進行設計，行銷團隊利用 App 內的推播、EDM 等方式招募擁有穿戴式裝置的受訪者。最終透過超過 20 次使用者訪談來定義目標客群、釐清該客群的痛點和需求。
近年登山、健行、越野跑的風氣興盛，登山的風格也逐漸多樣化，從長天數的重裝登山到短天數的輕量化快速登山等，在不同的登山風格和情境中，使用者的需求也大不相同。
在招募受訪者時，不限定為 Apple Watch 的使用者，而是針對所有擁有穿戴式裝置的 Hikingbook 使用者進行招募。因為團隊希望可以更全面地挖掘使用者對於「穿戴式裝置」需求。
從入門級的運動手環到高階運動手錶的使用者們提供了許多有趣的回饋，內容涵蓋最初購買穿戴式裝置的動機、日常的操作行為、自身運動的訓練目標等等。
若用「對運動數據的認知程度高低」為光譜來區分入門新手以及專業玩家，以下是一些值得分享的結論：
▍關於生理數據的需求：
- 專業玩家：在運動、訓練時會密切查看即時心率、心率區間，根據運動目標或是訓練目的調整身體狀態。
- 入門新手：在登山的情境中，在感受到疲勞、喘的時候才會查看數據，透過即時心率高低判斷身體狀態。
➡️「對於入門新手和專業玩家，即時心率都是他們最在乎的生理數據。而專業玩家能夠進一步根據心率區間，更準確評估身體狀態。」
▍關於運動目標、動機與運動數據的解讀能力：
- 專業玩家：運動目標（完成賽事、特定活動表現等）較為明確或是可以量化。因為訓練時間有限，希望透過科學化的方式有效達到目標。
- 入門新手：運動目標較模糊（保持身體健康、維持運動習慣等），單純希望透過穿戴式裝置簡單了解身體狀況（睡眠時間、消耗卡路里、行走步數等）
➡️ 「對於運動目標越明確的使用者，通常對運動數據的認知程度較高。希望透過解讀運動數據更有效率的達到目標。」
在穿戴式裝置的購買決策中，專業玩家與入門新手的看法也不盡相同：
▍關於穿戴式裝置電池續航力與最低門檻：
- 對入門新手來說穿戴式裝置可否維持 2–3 天的續航力是影響購買決策的門檻。因為 2–3 天的使用時間符合週休二日活動或是入門級登山縱走的時間需求。
- 若穿戴式裝置的電池續航力超過 2–3 天，使用者購買的意願較高。
▍對穿戴式裝置的期待：
- 入門新手與專業玩家在運動活動中，都希望能不拿出手機就不拿（甚至是不需要攜帶手機），能用手錶就用手錶，盡可能讓自己專注在活動當下（特別是在下雨時或拉繩等雙手不便於使用的時候）。
根據上述的訪談結論，團隊定義 Hikingbook 的 watchOS App 需要提供以下的核心價值：
- 手錶 App 作為手機 App 的延伸：讓使用者能在手錶上完成關鍵的操作（開始/結束紀錄、暫停紀錄和新增紀錄點）。
- 即時追蹤運動、生理數據：顯示使用者的數據，特別是心率、心率區間。
- 電池續航力延伸：硬體的先天限制讓 Apple Watch 的續航力不如高階的運動手錶，但在軟體端仍應該做相對應的優化，讓使用者在單日行程中能夠搭配手機使用。
▋閱讀官方文件掌握最新的技術與最佳實踐
掌握一個從未開發過的平台與相關的設計規範，最快的方式就是去閱讀官方文件。
以 watchOS 為例，Apple 在 Human Interface Guideline 中， Platform 的章節就收錄了 Designing for watchOS 的相關內容。
透過這份文件就可以快速掌在設計 watchOS App 時建議注意的限制、最佳實踐（Best Practice）等內容。
此外，在 2023 年 6 月的開發者大會上（WWDC） Apple 宣佈了 watchOS 10 的大改版。在設計上的改變主要反應於兩處：
- 調整實體按鍵的互動邏輯、強調數位錶冠（Digital Crown）與智慧型堆疊（Smart Stack）小工具的使用。
- 更新頁面排版與架構（NavigationSplitView、TabView、NavigationStack）。
時間拉回至 2023 年 9 月初，我決定以 watchOS 10 作為設計基礎。當時的決策原因如下：
- 目前支援上一代作業系統的 App ，必須在未來支援 Apple Watch 平台後續的系統更新才有可能持續保持最佳操作體驗。而對 Hikingbook 來說，直接以最新作業系統的規範進行設計，更有可能達到後發先至的效果。
- 若順利開發上線。有可能得到 Apple 官方宣傳支援 watchOS10 App 的流量紅利。
理想很豐滿但現實很骨感，雖然在設計前就訂下了這個決策，然而當時watchOS 10 都尚未對消費者正式發佈。因此官網上的官方開發規範、影片介紹和設計文件就是我唯一的參考資料來源。
強烈建議未來針對 watchOS App 開發的設計師優先去閱讀官方最新的技術文件，甚至向前閱讀更早之前的資料。前後對比之下，也能了解 Apple 對於 Apple Watch 的產品定位以及介面規範的演變過程。
將 Apple Design Resourcses 的開發文件匯入設計軟體也會大有幫助。匯入開發文件並設定元件庫（Library）後，也就做好設計前的環境建置了。
開發文件中不只有系統預設字級設定、參考色版甚至還有最新作業系統的 Layout 參考線可以使用，可以說是讓設計師最直觀理解開發規範的資料。
▋由設計師引導開發團隊，共同探索概念和實作可行性
從先前的競品分析中得知，在戶外活動分類下的 watchOS App 通常希望提供運動數據顯示、軌跡紀錄、匯入參考路線甚至是離線地圖等複雜的功能，但欠缺良好的資訊架構，導致頁面之間的跳轉邏輯也難以被使用者了解。
縱使在 Human Interface Guideline 文件中，明確建議 “Minimize the depth of hierarchy in your app’s navigation, and use the Digital Crown to provide vertical navigation for scrolling or switching between screens. ” ，然而 App 導航邏輯層次過深，仍然是在競品分析中最常出現的問題。
針對此情況，透過資訊架構的設計、排序資料之間的優先層級即可解決。
在下圖中可以看到，將整個系統區分為未紀錄/紀錄中兩個狀態，在不同的狀態裡，最深的導航層級不會超過三層（第三層通常是該元件自身的狀態變化），即可降低使用者迷失在頁面之中的可能性。
在完成資訊架構後，就進入 Wireflow 的環節，在穿戴式裝置上的 Flow 和系統狀態較為單純，故把 Wireframe 和 User Flow 結合一起討論。
此時最重要的不是介面的精緻度，而是掌握和開發團隊討論的節奏，聚焦實作的可行性和錯誤處理（Error handling）。
先前在進行使用者訪談時，開發團隊也同時在開發實作的 POC（Proof of Concept）來確認 Hikingbook iOS App 的核心功能是否能在 watchOS App 上實現。
在驗證功能可行性後團隊就回到追求系統穩定性的開發模式，此時仍有許多限制和不確定因素需要被考量，因此需要設計和開發團隊之間互相合作，才能共同打磨良好的使用者體驗。
經過至少兩輪所有畫面的 Wireflow 討論確認實作邏輯上的完備與可行性後，才進入 GUI 和 Interaction 的設計環節。
由於先前與開發團隊密集的合作，在這個階段不更改頁面架構的邏輯下，就可以把心力花在介面細節上。
而「新增紀錄點」功能是我想要特別介紹的 Flow。
「新增紀錄點」是 Hikingbook 手機 App 的一個重要功能，其作用是在使用者進行戶外活動時，可以透過新增紀錄點來紀錄當下的時間、天氣、座標位置、文字內容和照片，這對於登山的行程紀錄或是事後回顧活動特別有用。
為了在穿戴式裝置上實現同樣的功能，團隊在 iOS App 中新增 10 組預設的常用紀錄點名稱，使用者可以自行編輯預設紀錄點。
最後透過在穿戴式裝置上選擇預設的紀錄點，簡化輸入資料的流程，實現在活動中減少使用手機的目標。
▋Beta Program 降低上線風險，收集使用者回饋並快速迭代
最後，在設計與實作都完成後，進入 Beta Program 的階段。
這是團隊第一次在全新的平台上開發，不希望把不夠穩定的產品直接上線發布給所有使用者。
在開發中期，行銷團隊就同步開始招募參與 Beta Program 的測試人員。
擁有 Apple Watch 的使用者在加入 Beta Program 後，一旦我們發佈了新版本，測試人員就可以馬上下載，並且透過問卷表單回饋相關的使用心得。
如此一來，開發團隊也可以根據測試人員的反饋進行快速的除錯、修 Bug、甚至是調整 UI 。
經過一個月左右的測試在 600 多名測試人員的幫助下，根據測試者的建議，微調了部分的 UI 、修正程式的穩定性、降低運作 App 時的耗電量，最後才在 App Store 上正式推出 Hikingbook watchOS App。
測試過程中也有心得可以與大家分享，最初團隊希望透過表單收集測試者的回饋，但沒有考慮到如何針對舊版本的使用者收集新版本上線後的回饋。
舉例來說，被第一批 Beta 版本測試者反應過的問題，可能在下個版本就修正了，但對於已經修正的問題，第一批測試者不會主動回報，團隊無法得知第一批測試者對於修正版本的反饋。
或許建立更緊密、更直接與測試人員溝通的渠道是可能的解決方式之一，在填寫問卷資料的的心力消耗與反饋資料的二次收集是我們沒有考量到的問題。
後續只能從新一批測試人員獲得對新版本的回饋，不同版本間測試人員的分組也是需要考量的課題。
雖然使用者回饋收集的機制不盡然完美，但仍然感謝所有願意回報使用建議的使用者，團隊也盡最大的努力根據使用者的回報進行相關的調整。
▋以終為始並持之以恆，讓美好的事物發生
對於新創團隊來說，在顧及使用者體驗的前提下，如何透過最少的資源槓桿出最大的收益、探索未知的領域同時並採用合適的技術來打造產品是永遠的課題。
▍以終為始地設定每個階段的目標，則是最有效避免資源浪費的手段之一。
謝謝你看到這裡，希望 Hikingbook 團隊如何從 0 到 1 開發穿戴式裝置 App 的經驗能幫助到你。
身為產品設計師，很感謝開發團隊共同的努力，才得以打造出第一個 Beta 版本，也感謝行銷團隊協助招募測試人員和正式上線後的持續曝光，讓更多人看到我們努力的成果。
最後感謝在開發過程中提供幫助的所有夥伴：提供 Apple Watch 協助開發的 Mickey、無償參與使用者訪談前測的 Wayne 和 Prolong、最後是所有參與使用者訪談和 Beta Program 的 Hikingbook 使用者，沒有你們就無法完成這個專案。
最後，如果你也喜歡探索戶外的話，歡迎下載 Hikingbook 的 App 讓我們陪你一起安全登山。
若想了解更多功能介紹請前往 Hikingbook for Apple Watch。
有任何使用心得或是反饋，歡迎直接留言或透過 Facebook 粉絲團、Instagram 或客服信箱 support@hikingbook.net 聯絡我們！
