Hi，我是 Hikingbook iOS developer Riley。

Hikingbook iOS app 在今年邁入了第五週年，而在 2023 年，我們決定開發 Hikingbook for Apple Watch，讓使用者能在 Apple Watch 上更便利的使用 Hikingbook app。在 watchOS app 的開發過程中，我們嘗試了與以往不同的開發模式，希望 watchOS app 一上線，就能帶給使用者良好的產品體驗，讓 watchOS app 無縫整合進 Hikingbook 的產品體系中。

在這篇文章中，我們將會分享 Hikingbook Dev Team 是如何打造 Hikingbook watchOS app，揭開從 0 到 1 完成 watchOS app 的開發流程，並分享在開發 watchOS app 的過程中遇到了哪些挑戰。

開發流程

Hikingbook Dev Team 在 iOS app 既有的開發流程為：

• Spec Review：在 Spec Review 中，開發和行銷團隊的成員們共同參與討論，了解本次開發的功能主要目標為何。透過 Spec Review ，團隊成員會知道功能的開發「希望解決什麼樣的問題」、「要達成的目標是什麼」，以及「影響的使用者是誰」，並通過會議中的討論確認可行性，達成最後對該 Spec 的共識。
• Design Review：Spec Review 結束後，會由產品設計師進行設計，在設計完成後進入 Design Review 的環節，和團隊說明設計的概念、最終呈現的樣貌以及使用者操作的 flow 會如何進行。在過程中，開發者也會針對設計在實作上的可行性提出建議，大家會一起思考使用者操作的流程是否順暢並提供反饋，會後產品設計師也會根據大家的共識進行調整。
• Dev Implement：完成 Design Review 後，就會正式進入開發階段（Dev Implement），此時工程師們會根據已經確定的 Spec 內容，以及 Design 的最終版本進行開發。若工程師在開發的過程有發現問題，會再發起討論和相關人士確認如何調整，待所有功能開發完成後，最終交付開發完成的 app。
• Internal Test：App 功能開發完成後，會進入測試階段（Internal Test)，由 Hikingbook 成員測試開發完成的 app 是否符合 Spec 和 Design 的設計。若在測試的過程中發現問題，會再由開發者進行調整，待完全通過測試後，才會進入下個階段。
• Release：待所有功能通過測試後，就會正式 release，進行 app 的送審，並上架至 App Store 供使用者下載與更新。

開發流程 For Apple Watch

在這次 Hikingbook for Apple Watch 的開發中，我們針對原本的開發流程進行了一些調整。由於開發團隊成員過往都沒有開發 watchOS app 的經驗，而 watchOS app 與 iOS app 在 App Life Cycle、 UI 介面的呈現、使用的 API、使用者習慣操作的 flow 等面向上都有所不同，開發團隊需要較多的時間來摸索並熟悉 watchOS 的開發。

此外，由於 Hikingbook iOS app 已經是一個相當成熟的產品，我們希望 watchOS app 上線後，也是一個具有高穩定度的產品，讓使用者的使用體驗能達到相同的水準。

考量以上兩點，我們在開發流程上做了新的調整，讓本次的 watchOS app 開發流程如下：

我們在開發的過程中增加了 POC（Proof Of Concept）階段，在實際開發前先進行 watchOS 技術上的研究。此外，除了原先的內部測試（Internal Test）外，也增加了 Beta Test 作為外部測試，邀請有 Apple Watch 的使用者在產品正式上線前，就可以搶先體驗 watchOS app ，並提供意見反饋，供開發團隊參考與調整。

以下我們將更詳細的分享 watchOS app 的 POC、Develop Implement、Beta Test 這三個階段在開發過程中是如何進行的。

POC

在 POC 的階段，最主要的目標是確認 Hikingbook app 的核心功能在 Apple Watch 上實現的可能性。 Hikingbook app 的使用者在戶外活動時可以紀錄活動的軌跡，並可透過 Dashboard 查看活動中所累積的數據，對使用者而言這是在進行戶外活動時最重要的核心功能，因此，在 POC 階段我們優先嘗試相關功能實作的可行性。

另外，Apple Watch 比起 iPhone 可以提供更多的生理數據，也提供了 Workout Sessions 可以更精確的追蹤使用者在 Apple Watch 上進行活動的數據。我們也希望整合這些 Apple Watch 所能提供的資料進入 Hikingbook watchOS app 中。

綜合以上的考量，我們在 POC 階段我們主要針對以下幾點進行研究：

• iOS app 和 watchOS app 之間的溝通及資料傳輸方式
• watchOS app 的 Life cycle
• 透過 watchOS 操作 iOS app 的關鍵行為
• 透過 watchOS 蒐集 CLLocation 資料
• 了解 watchOS workout sessions 的運作方式
• 透過 watchOS 取得 HealthKit 所提供的生理資訊
• 確認 watchOS 是否可呈現地圖

在這個階段，我們對於 watchOS app 實際上會包含的功能尚未有明確的定論，關於 watchOS app 是可獨立 Hikingbook iOS app 下載、運作，擁有完全獨立於 iOS app 功能的 Independent watchOS app ，或是必須要依賴 iOS app 才能操作使用的 Dependent watchOS app 這點也尚未決定。

因此在 POC 主要是作為技術可行性的探究，並讓開發者能有時間認識 watchOS，在過程中，不需要開發完整的功能或是建立實際要在 app 中使用的 foundation，而是一個快速嘗試的過程，讓後續在討論 watchOS 的功能時，開發者能迅速的評估技術限制，並加速後續實際開發時所需的時間。POC 的範圍也不只限於這次 watchOS app Spec 的開發，而是希望更了解 watchOS 的技術，了解未來拓展功能的可能。

了解更多 Dependent watchOS app 和 Independent watchOS app 的差異：https://developer.apple.com/documentation/watchos-apps/creating-independent-watchos-apps/

在 POC 階段，我們也發現了幾個後續開發時可能會面對的潛在挑戰，並也因此可以先為未來實際開發做準備。

以 SwiftUI 進行開發

iOS app 的 UI ，大部分開發者熟悉的是以 UIKit 進行開發，在近年來 SwiftUI 的技術逐漸成熟，使用 SwiftUI 開發的比例也有所上升。而在 watchOS 中，對應 UIKit 的開發方式為 WatchKit，其中包含了 Storyboard 可供開發者使用。

然而，這幾年 Apple 強烈建議開發者以 SwiftUI 進行 watchOS app 的開發，在 WatchKit 的文件中，明確的提到：

Building your app with SwiftUI gives you more control over the user interface than designing it in a storyboard. When creating a new watchOS app, strongly consider using SwiftUI.

在 watchOS 7 釋出後，WatchKit storyboards 已遭 deprecated，必須使用 SwiftUI 進行開發，在 Xcode 14 開始，已不支援建立 WatchKit storyboard。

由此可知，現在要進行 watchOS app 的開發，開發者無可避免的必須面對 SwiftUI。若對 SwiftUI 不夠熟悉，在開發上可能會需要花費更多時間摸索。而幸運的是在 Hikingbook iOS app 中，我們已經以 SwiftUI 進行開發一段時間，因此在 watchOS 開發的過程中，可以較無痛地銜接。

watchOS app 與 iOS app 的狀態

雖然在 POC 階段我們尚未確定 watchOS app 是否為 Dependent watchOS app，但我們也希望對 watchOS app 與 iOS app 之間的關係有初步的了解。透過研究 Watch Connectivity 所提供的 API，我們發現可以透過以下幾個 API 了解對應 app 的狀態：

• isPaired： 可知道 iPhone 是否有已配對的 Apple Watch
• isWatchAppInstalled ：可確認 watchOS app 是否已安裝
• isReachable ：可判斷對應的 app 是否處在可以接收訊息的狀態

透過對這些 API 的研究，讓我們更了解在跨裝置 app 溝通時可能遇到的問題，以及技術上的限制，如 isReachable 只能判斷對應的 app 是否可以接收訊息，但無法直接透過這個 property 知道對應的 app 是在前景還是背景。後續我們也能更完整的思考跨裝置 app 之間溝通的 flow 該如何設計，並可以提早和產品設計師討論是否需要有引導使用者操作的相關畫面。

App 間的資料傳輸

watchOS 與 iOS 間的資料傳遞，若是在沒有網路的情況下，主要需要透過 WatchConnectivity 的 Framework 進行，它提供了不同的 API 供不同情境的傳輸使用：

• updateApplicationContext(_:)
• transferUserInfo(_:)
• sendMessage(_:replyHandler:errorHandler:)
• transferFile(_:metadata:)

在這之中需要注意的是，並不是所有的 API 都支援在模擬器上使用， transferUserInfo(_:) 在文件中有特別註明需在實機上使用，而 updateApplicationContext(_:) 雖未在文件中明確指出，但在 POC 的過程中，我們卻也遇到無法在模擬器上操作的情況，在 Apple Developer Forums 也可看到相關討論。

透過 POC 讓我們預先知道對於 watchOS app 和 iOS app 之間資料的傳遞，在開發的過程中會更需要仰賴在實機上運行及測試，以避免模擬器無法正確運行的情況。

在 WatchConnectivity 的實作中，我們也注意到了在資料傳輸格式上的限制，在傳遞 [String: Any]的資料時， Any並非什麼型態的資料都能傳送，而必須是 primitive types 的資料，如：String、Int、Double、Array、Data 等，因此在資料的傳遞上，可能會需將資料進行轉型處理。 此外，【iOS -> watchOS】與 【watchOS -> iOS】的雙向溝通，會因 app 是否已開啟、app 在前景/背景、watchOS app 是否處於 workout session 等因素而影響到資料的傳輸。

watchOS 的生命週期也與 iOS app 不同，不會長時間處於 active 狀態，使用者不需特別將 app 退到背景，而是將手腕放下就會使 app 進入 inactive 的狀態，這對於資料傳輸時所要選用的方法也會有所影響。

另外，在 2023 年 6 月的 WWDC 中，Apple 宣布在 watchOS 10 推出新的 Workout Mirroring API，根據 Build a multi-device workout app 的介紹，我們注意到這個新的 API 對於 app 之間資料的傳輸可以更加即時，也更符合我們對於 app 之間互動的需求。但需要考量的是在只有 watchOS 10 可以使用的情況下，對於後續是否要以此 API 作為整個 app 傳輸的基礎，有更多需要考量的面向。

watchOS app 安裝

在 POC 的過程中，我們嘗試了將 watchOS app 裝入 Apple watch 裝置中以觀察功能的運行，而在這個過程中，我們注意到要將與 iOS companion 的 watchOS app 裝進 Apple Watch 中，需要透過 iOS app 進行安裝，不像一般透過 Xcode 即可將 app 直接安裝進 iPhone 中。

而在多次的安裝過程中我們也發現安裝 watchOS app 時，較容易遇到各種問題導致安裝不順利，除了基本的 watchOS app 需開啟開發者模式外，iPhone、 Apple Watch 及 Xcode 需重新啟動讓 watchOS app 順利安裝也是時常會遇到的情況。雖然不是什麼大問題，但在開發的過程中無疑會影響到開發的速度，再加上上述在 Apple Watch 的模擬器中有些 API 無法正常運作，如何取得在實機及模擬器上的開發取得平衡也是後續開發過程需要考量的。

在 POC 的最後，我們將實作 Hikingbook iOS app 核心功能的結果以 Dependent watchOS app 的方式安裝進 iPhone 及配對的 Apple Watch 之中，並在 Hikingbook 團隊中示範如何做到 iOS app 及 watchOS app 中同步紀錄活動。透過這個分享，讓團隊更能想像 Hikingbook for Apple Watch 的完成的樣貌。

Dev Implement

Foundation 建立

在團隊完成使用者訪談並收斂 watchOS 的核心功能，並經歷 Spec Review 和 Design Review 後，確立了 Hikingbook watchOS app 會以 Dependent watchOS app 的樣貌登場，並會負載紀錄及查看活動數據的核心功能。緊接著也正式進入了 watchOS app 從 0 到 1 的開發階段。

首先最重要的是建立 watchOS 和 iOS app 之間傳遞資訊的 Foundation，如同網路層在 iOS app 中的重要性，由於 Hikingbook watchOS app 的資料來源主要來自於 iOS app 所傳遞，因此，我們以 Watch Connectivity 建立兩者的傳輸，為了讓所需的所有資料可以順利傳遞，讓使用者在 app 於前景時可以即時看到所有數據，並建立完整的 Error Handle，在資料無法正確傳輸時讓使用者還是有良好的體驗，我們花費了許多功夫。由於使用者可同時操作 iOS app 及 watchOS app，若太頻繁的傳輸資料，會造成裝置耗電嚴重，但若傳輸不夠即時，則會發生使用者在兩邊的 app 可能會看到不一致的資料而感到疑惑的情況，因此如何掌握兩者平衡也相當重要。

在開發的過程中，為了克服部分 API 無法在模擬器上使用的問題，我們使用了 command-line arguments 和 arguments passed on launch，指定在模擬器上運行時是用特定的方式進行傳輸，以加速開發的速度，避免部分 API 無法使用導致運行結果不如預期。另外，由於 app 間資料的傳遞頻繁，發生問題時要找到是哪一段資料傳輸發生問題較耗時，我們也善用 Log 打印 watchOS 及 iOS app 之間的傳輸情況，讓 debug 可以更加容易。

watchOS 版本問題

在實際開發的過程中，我們也遇到了 POC 時沒有注意到的問題，那就是在實際開發階段，我們以 watchOS 10 為主進行開發，在前期忽略了 watchOS 8 在 TabView 的行為和 watchOS 9, 10 的差異。雖然在 compile 時不會發生錯誤，但實際運行時，若在 watchOS 8 將一個 .carousel 的 TabView 放進 .page 的 TabView 中，無法讓 View 可以進行上下和左右切換的操作，而造成 watchOS 8 無法採用原先的設計相同的 UI 介面。在發現問題後，團隊開發者和設計師緊急討論，為了在 watchOS 8 上有更良好的體驗，重新打造了不同的介面來呈現數據。

在注意到了不同 watchOS 版本可能發生的問題後，在後續的開發，我們會以 不同 watchOS 版本搭配不同錶面大小的 Apple Watch 的模擬器及實機進行開發與測試，希望能確保在各版本及不同型號的 Apple Watch 的使用者都能有良好的體驗。

開發與測試並行

在開發的過程中，我們也將功能進行更細緻的切分，在整體 app 架構完成後，會在個別功能開發完成後，進入內部測試環節，而非等所有功能都完整開發才一次測試。透過這樣的方式可以讓開發步調更快速，當內部測試發現問題時，可以及時修正，在下一個版本再次測試。經歷了多次的內部測試及修正，仰賴不同部門緊密的協作，最後才能順利的完成 watchOS app 的開發。

Beta Test

在完成內部測試後，我們進入了 Hikingbook 史上第一次的對外 Beta 測試，透過行銷團隊招募有 Apple Watch 的使用者搶先體驗 Hikingbook WatchOS app。

在 Beta 測試的階段，我們希望透過使用者的回饋更了解使用者需求，以及避免 app 不夠穩定的問題。

Beta Test 參與的使用者人數高達 600 多人，提供我們更多元且真實環境下的操作經驗，透過使用者們實際在戶外活動的過程使用 Hikingbook watchOS app，讓我們更能掌握產品的穩定性，並透過他們真實使用後的回饋，讓我們能發現在內部測試中較難發現的問題。

在使用者的反饋中，許多使用者向我們反映了 watchOS app 耗電過快的問題，由於回饋的使用者人數較多，讓我們清楚的了解這並非單一裝置可能的偏誤，而是廣泛影響使用者體驗待解決的問題。而後開發團隊也根據這點進行優化，我們重新調整了資料傳輸的時機、傳輸的頻率，避免在不必要的時候進行資料傳輸，並發現 UI 上的動畫效果不間斷的更新也會造成耗電，因此也關閉了不必要的更新。透過這些調整，在 App 正式上線前，也成功地克服了耗電問題，讓正式上線 Hikingbook watchOS app 能帶給使用者更良好的操作體驗。

正式上線

在 2024 年 1 月 Hikingbook watchOS app 正式上線了 🎉

這次 watchOS app 的開發經驗對我們來說相當寶貴，除了仰賴團隊內外部緊密的協作，成功打造出 Hikingbook 第一個在穿戴裝置上的產品，也有參與 Beta Test 的使用者們的加入，讓產品能更完善。透過使用者們的回饋，也讓開發團隊感到與使用者們更靠近。

POC 和 Beta Test 這兩個階段乍看之下好像拉長了整體開發的時間，但整體而言，我們認為是相當值得的投資。透過 POC 降低了後續開發的風險，避免因為對技術的不熟悉而造成後續可能需要砍掉重練，付出更大成本的可能。POC 也讓開發團隊更快地掌握技術，在跨團隊的討論中，可以更快的回覆問題，並評估技術上的可行性。Beta Test 則讓我們在產品正式上線前增加了不少信心，了解使用者在真實戶外活動中使用的經驗，讓我們能有機會了解在一般內部測試以外可能遇到的問題，並能在正式上線前克服。此外，也提供了除了在 App Store 留下評價外，使用者可以更直接向開發團隊提供回饋的機會。

希望透過這篇 watchOS 開發的分享，讓大家更了解開發團隊在 watchOS app 傾注的心血。若你是開發者，對於開發 watchOS app 有興趣，或是你所屬的團隊有以開發 watchOS app 為目標，希望這篇文章能對你有所幫助！

⌚️ 歡迎你一起體驗 Hikingbook for Apple Watch 的完整功能！

📣 想知道 Hikingbook 產品設計師是如何設計 Hikingbook watchOS app，也歡迎前往 如何從 0 到 1 ：設計 Hikingbook 的第一款穿戴式裝置的 App 了解更多！

Dev Team 開發流程全公開：我們如何開發 Hikingbook for Apple Watch was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

以終為始拆解設計流程並與團隊密集協作進行開發

Hi 大家好！ 我是 Hikingbook 的產品設計師，家蔚。

2024 年 1 月，Hikingbook 正式發布了第一款支援 Apple Watch 的應用程式。

本文將介紹從設計師的角度如何「以終為始」進行目標導向的工作規劃、透過 Wireflow 降低實作的開發風險，在 0 開發經驗的平台上權衡使用者需求、商業考量、實作限制並打磨細緻的使用者體驗。

目錄

▍建立觀點並凝聚團隊想像、規劃整體開發流程

▍從使用者訪談了解需求，收斂開發規格

▍閱讀官方文件掌握最新的技術與最佳實踐

▍由設計師引導開發團隊，共同探索概念和實作可行性

▍Beta Program 收集使用者回饋並快速迭代

▍以終為始並持之以恆，讓美好的事物發生

▋建立觀點並凝聚團隊想像、規劃整體開發流程

定義開發規格前，我希望優先研究現有上穿戴式裝置應用程式（以下簡稱 App）的基本功能和限制，讓團隊能夠快速了解市場上類似產品服務的現狀。

從Apple Watch 的 App Store 下載「戶外活動紀錄」、「離線地圖導航」、「運動數據統計」等類別的 App ，進行競品分析後，就能開始建立對穿戴式裝置 App 的基礎理解。

利用現有的 App ，讓團隊在實際投入開發資源前，快速了解以下三點：

• 使用者對穿戴式裝置 App 功能的最低要求。
• 潛在可能的實作限制。
• 穿戴式裝置上常見的設計模式。

只需要分析競品 App 的資訊架構甚至是單純整理操作介面的截圖，就能讓團隊聚焦對當前穿戴式裝置 App 的認知和想像。

完成初步分析後，團隊即可建立起統一的參考基準：

• 從產品設計的角度，觀察不同競品是如何設計功能相似的頁面、分析相似的功能在不同的設計中可能的取捨。
• 從程式實作的角度，推敲不同的產品是如何處理資料的同步、傳遞、錯誤處理等技術細節。

對於未開發過穿戴式裝置 App 的團隊，透過桌面研究就能獲得的資訊對開發規劃仍有許多參考價值。

結束開發前的研究後，團隊將整個開發專案規劃為 4 個階段，每個階段的最終成果都與下個階段環環相扣：

1. 深入了解使用者，決定最終開發規格
2. 設計與實作密切協作，根據規格探索開發可行性
3. 發佈測試 Beta Program，優化產品並降低上線風險
4. 正式版本發佈，未來同時維護手機與穿戴式裝置上的體驗

▋從使用者訪談了解需求，收斂開發規格

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 需要提供以下的核心價值：

1. 手錶 App 作為手機 App 的延伸：讓使用者能在手錶上完成關鍵的操作（開始/結束紀錄、暫停紀錄和新增紀錄點）。
2. 即時追蹤運動、生理數據：顯示使用者的數據，特別是心率、心率區間。
3. 電池續航力延伸：硬體的先天限制讓 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 聯絡我們！

如何從 0 到 1 ：設計 Hikingbook 第一款支援穿戴式裝置的 App was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

嗨！我是 Hikingbook 的產品設計師家蔚。

無論你最初是被什麼所吸引，在踏上戶外探險的旅程後，往往能發現自然中蘊含無盡的靈感，而這份靈感正是 Hikingbook 社群背後設計的核心所在。

在本文中，我將深入探討、分享團隊在建構 Hikingbook 社群時的思路、決策與背景脈絡。每一個部分都像是獨特的山徑，將帶領我們一步步深入了解 Hikingbook 社群背後的故事，希望對大家有所幫助。

目錄
一、為什麼要打造一個新的社群
二、根據使用者行為及需求，規劃社群核心體驗
三、社群為使用者帶來的價值
四、Hikingbook 社群發展的最終目標
五、一人設計師如何根據目標訂定設計決策
六、對 Hikingbook 社群的未來願景
結尾

一、為什麼要打造一個新的社群？

從站內的豐富資料與使用者行為出發，結合公司願景，我們希望在現有的產品基礎上打造一個「以使用者為中心」並且「鼓勵分享與互助」的戶外社群，讓每一個人都能更容易且安全探索戶外。

▋戶外愛好者的現狀與公司願景

自 2019 年開放山林政策施行之後，越來越多的人開始探索台灣的山林，這群新的戶外愛好者和過去藉由登山社、登山協會等團體接觸山林的人有所不同。

這群戶外愛好者往往是透過網路上的資訊（如：文章、影片）或是身邊的好友開始接觸相關登山的知識，而非透過登山社團、協會進行系統化的知識傳承。

在數位科技發達的今天，有許多熱心分享資訊的網友，讓即時的山林資訊更容易的在網路上被更新與搜索。其中，也有很多戶外愛好者會透過查看 Hikingbook 站內的活動紀錄來研究路線資訊、評估行程規劃等。

從商業的角度來看，Hikingbook 站內已經有許多使用者建立的資料與一定的使用者基數，在使用者可以藉由多元管道獲取資訊的現在，發展社群功能後，能夠強化現有使用者對產品的黏著度並持續增加站內資料的豐富性，並期望吸引更多的潛在使用者。

從使用者的角度出發，Hikingbook 針對登山已經開發了一系列的相關功能：裝備管理、路線規劃、活動紀錄與離線地圖等等，根據使用者的需求我們持續開發具有競爭力的功能，並期待能夠達到我們的願景。

我們相信，人作為自然的一份子，都能安全、自在地探索戶外，獲得無可取代的美好體驗。

而事前瀏覽相關「活動紀錄」，已經是進行任何有風險登山行程前不可或缺的一步了。越了解你即將前往的區域，就越能降低行程中的活動風險，而這也是為什麼，我們希望打造一個社群，讓使用者能互相交流、讓 Hikingbook 陪你一起安全登山。

▋登山安全與社群發展的潛力

至今 Hikingbook 已經服務超過 20 萬名使用者並協助他們紀錄 10 萬筆以上的戶外活動，在 Hikingbook 的官網及 App 中，可以看到這些使用者產生的精彩內容。

在使用者訪談中我們得知，對於登山安全意識程度較高的使用者在規劃行程前，會使用 Hikingbook 查看其他使用者的活動紀錄獲取以下的資訊：

1. GPX 路線軌跡
2. 路況資訊
3. 行程時間
4. 通訊點
5. 水源
6. 住宿紮營點

了解這些資訊後，登山者能夠降低面對未知情況的風險與安排適合自己的行程規劃，其中學習評估行程時間更是重要。

舉例來說，同一條登山路線，以普通的速度（上河地圖 1.0 的大眾速度）有可能需要 5–6 天才能夠完成，也有腳程較快的人能夠在更短的時間內完成。因此如何安排路線與行程規劃是因人而異，也沒有絕對的對錯。

藉由比較多筆不同來源的活動紀錄，能夠協助使用者在登山前建立對於路線的基本認知，這也是提升登山安全的重要一環。

對於戶外愛好者初期不了解自己的體能狀況、無法評估路線難度的狀態下，Hikingbook 站內豐富的內容是相當具有參考性的參考內容。

從客觀的路線總長度、總爬升高度、活動總時間等數據到其他使用者主觀的評價、回報的路線資訊，都能夠協助新手降低風險。

因此，對於已經擁有這些珍貴資料的我們，希望在這個基礎上，打造一個「以使用者為中心」、「鼓勵分享與互助」的社群，讓樂於分享的使用者，帶領更多新的戶外愛好者一起安全地探索戶外。

二、根據使用者行為及需求，規劃社群核心體驗

對使用者來說 Hikingbook 最重要的價值除了紀錄活動以外就是參考其他其他使用者上傳的資料。因此在深入社群的設計前，將從兩個面向切入：

1. 提升站內資料的數量與品質
2. 如何更有效的呈現資料

從上述兩點出發優化核心的使用者體驗，為社群功能打下基礎。

▋多處漸進式調整提升 Hikingbook 站內的活動數量與內容品質

隨著 Hikingbook 這幾年的發展，團隊發現有一群熱愛紀錄的使用者，會透過 App 紀錄他們完整的登山過程、甚至在該紀錄中撰寫更多描述資訊，提醒未來參考此紀錄的使用者相關的注意事項。

在觀察到上述的使用者行為之後， 團隊在 2023 年初開始了以下的前置作業：

1. 優化 Hikingbook 中的紀錄面板：增加紀錄活動的即時數據，提升用戶紀錄當下活動的動機。
2. 調整活動紀錄儲存流程與詳細活動紀錄頁面：引導使用者在活動內留下具參考性的內容。
3. 下載路線時新增拍手流程：鼓勵使用者互相給予正面回饋。

結合以上三點，透過提升活動紀錄的數量與品質，並且鼓勵使用者在下載他人路線時給予肯定，創造一個正向的循環、增加活動紀錄對於使用者的功能與情緒價值。

接下來讓我們來聊聊文中不斷提到的「活動紀錄」的介面優化設計，解析原始設計與新設計各自的設計意圖。

▋最大化顯示活動資訊的前提下，規劃視覺層級分明的介面

在原始的設計中，強調的是在單一畫面中能看到更多的活動，引起使用者的好奇心後儘可能往下滑動；

在新的動態牆中，著重的是單一活動的資訊呈現：該活動連接的官方路線、所在的縣市區域並顯示部分活動描述、互動狀態等，提供使用者在意的數據，讓使用者更容易決定是否要查看更多內容。

調整資訊的優先層級與排版，讓使用者在瀏覽動態牆時，能夠更一目了然地看到該活動的關鍵資訊。

並期望在版面調整後，能夠間接鼓勵更多使用者上傳活動的相關資訊，使用者輸入越多的內容，在版面上呈現的資訊就越豐富。

▋讓系統可以伴隨使用者偏好，推薦相應的內容

建立起登山的習慣或愛好後，在「出發前進行路線的研究」，往往會成為一個使用者反覆執行的操作模式。

舉例來說，使用者在 Hikingbook 站上的搜尋不同紀錄的過程中，會逐漸發現對自己最具有參考性（行程時間相近、活動類型相似等等）的其他使用者，抑或是在站上隨意瀏覽活動紀錄時，發現了意料之外的內容。

1. 設計合適的活動紀錄排序方式
2. 協助使用者獲得有參考性的內容
3. 啟發使用者意想不到的活動靈感

考慮上面提及的三個目標後，就需要導入社群中最核心的「追蹤」功能。

藉由「追蹤」功能，賦予使用者決定自己要看到什麼類型內容的能力、建立使用者與活動上傳者之間的關聯性。

除了主動搜尋外，現在也能夠被動接受使用者自行篩選過的訊息來源

使用者根據自己偏好的「活動類型」、「路線規劃」、「紀錄資訊」等不同的面向，追蹤其他 Hikingbook 上的使用者，當這些被追蹤的使用者上傳他們的活動紀錄時，就可以在自己的動態牆上看到這些活動。

▋根據戶外活動的時效性調整動態牆的顯示邏輯

當然，我們也深知，戶外活動的紀錄是相當的時效性，搜尋同一條路線時，若出現一天前與一年前的紀錄，上傳時間越接近搜尋當下的紀錄是更有參考價值的。

因此在使用者的追蹤動態牆上，會優先顯示 3 個月內上傳的活動紀錄，儘可能提供最即時的資訊，在使用者瀏覽完 3 個月內的活動後，可以選擇要查看已追蹤使用者過去的活動紀錄，或是直接向下滑動，查看其他未追蹤使用者的最新上傳活動紀錄。

▋針對使用者原有的操作行為，進行微小的調整，就能帶來巨大的改變

除了顯示更豐富的資訊外，對活動紀錄的互動行為也有所修改。

過去需要使用者額外點擊一次後，在活動詳細資訊頁中才能進行以下的操作：下載路線、拍手、留言與分享活動。

但社群中是鼓勵使用者彼此互動與交流的，因此我將這些操作按鈕搬移到最外層顯示，減少使用者額外的無意義點擊與等待跳轉的時間。

使用者下載他人的路線時，系統也會跳出視窗邀請使用者對分享者的活動拍手，鼓勵分享者上傳的高品質內容。

在修改下載路線流程的一個月後，Hikingbook 站上的活動被拍手的數量，就相較上一個月顯著提升了 400% 以上，這對於建構一個互助、友善的社群是相當有意義的指標。 

透過其他部份的設計提升站內的活動紀錄的數量與內容品質後，透過「追蹤」功能實現新的資訊顯示邏輯、主動推薦內容給使用者，並且根據使用者的原有需求（可閱讀性、資訊時效性）等提供相對應的解決方案，減少使用者在搜尋資料的過程中不必要的摩擦力，並且在使用者旅程中的最後一步，鼓勵使用者彼此交流，建立正向回饋。

三、社群為使用者帶來的價值

從最積極的追蹤其他使用者或是主動查看所在位置附近的活動、路線到瀏覽 Hikingbook 編輯部精挑細選的使用者訪談，我們為你準備好了各種方式讓你能夠更容易的與他人建立連結、獲得靈感。

▋藉由每一位使用者的路線回報，打造即時的路線資料庫

回到使用者建立對於路線的認知上，雖然 Hikingbook 的官方路線資料庫中，有超過 1700 條的步道與路線。

但在日常與山友們的交流經驗中，團隊也了解這些路線的資料是無法滿足使用者需求的，永遠都有新的路線和尚未被收錄的路線資料。

Hikingbook 使用者上傳、更新活動紀錄的速度，絕對比官方主動更新路線資訊更快。正因如此，我們該做的不只是單純地新增站內的路線資料（雖然我們每個月都仍會持續更新路線、步道資訊），我們更應該做的，是提供使用者好用的工具，讓每個人都能使用這些工具建立有參考性的紀錄。

對上傳者來說，可以回顧自己過去行程中的運動表現、路線紀錄與心情感受；對瀏覽者來說，可以在出發前，了解其他使用者是怎麼進行該路線的規劃與實際的軌跡。

使用者儲存活動時，若無法直接配對到相應的官方路線，我們也提供了路線回報的功能，參考使用者實際的 GPX 軌跡搭配紀錄點，作為新的官方路線資料素材，替未來要走類似路線的使用者提供相關內容。

▋沒有明確目標，也能快速探索周圍地區的「附近活動」

關於戶外靈感，除了在事前的研究，若今天你臨時前往了一個你不熟悉的區域，但又想要快速地探索周圍的區域，那麼 Hikingbook 社群會是你的好助手。

社群動態牆中加入了「附近活動」的子分類，即使沒有追蹤其他使用者，只要點擊「附近活動」，即可馬上瀏覽所在位置方圓 50 公里內的活動紀錄，看看過去一年內在附近活動的 Hikingbook 使用者都在做些什麼戶外活動。

▋透過文字遇見不同面貌的 Hikingbook 使用者

戶外活動的規劃是非常多元的，同一條路線根據體能、攜帶裝備等條件的不同也可以有很多走法，每一個人都可以選擇用自己想要的方式來親近戶外。

無論是輕量化速攀或是重裝攜帶爽糧與同伴們共享多日登山的時光，都有各自的樂趣，因此，向你介紹社群中的「社群亮點」。

在社群亮點中，有來自 Hikingbook 編輯部的特別企劃，訪談介紹各式各樣的 Hikingbook 使用者，有透過鏡頭帶領我們一同冒險的攝影師小藍與 Danny、 在 14 天內完成無補給速攀中央山脈大縱走的 HikerCP、從工作到生活都追求挑戰的工程師 Joy Lee。

Hikingbook 編輯部會持續搜集來自使用者身上的精彩故事，並透過專文介紹給你，在社群中若不知道要追蹤誰，從這群使用者開始也是一個好方法 。

跟隨不同類型的戶外愛好者，用你喜歡的方式探索自然。

從主動搜尋活動紀錄到隨意瀏覽周圍的活動，不論你是怎麼樣的使用者，總是能找到適合你自己的方式使用 Hikingbook 社群。

四、Hikingbook 社群發展的最終目標

原本的活動動態牆中，更像是一個純粹展示自我與他人紀錄的平台，但在多次看到使用者在各自的活動紀錄中交流想法後，我們意識到，社群可以做到的事是更豐富的。

▋互相幫助彼此，才是社群的核心價值

「共同成長」與「互相啟發」不是空泛理想，而是在 Hikingbook 中的現在進行式，我們需要做的是放大並鼓勵這樣的體驗發生在每一名使用者身上。

CMX 的創辦人 David Spinks 曾經說過：

To build an audience, you help people.
To build a community, you help people help each other.

上文中提到的設計改動都是 Hikingbook 社群的基礎，透過鼓勵已經在站內相當活躍的使用者們，希望藉此影響其他的使用者產生相似的行為，最終形成一股友善的風氣。

這正是團隊期盼的社群發展方向，借助大眾的力量，幫助每一個戶外愛好者能用更安全的方式去親近自然，帶回自己獨一無二的體驗。

我們的工作只是打造並維護一個環境，使用者們才是社群真正的核心與靈魂所在。

五、一人設計師如何根據目標訂定設計決策

在執行大規模開發需求時從利害關係人確認開發需求、識別潛在風險、決定設計策略、控制開發時程等工作都是一人產品設計師需要面對的，接下來就和你分享我是怎麼規劃為期 4 個月的設計開發。

▋綜觀全貌後選擇最核心的角度切入，才能夠「以簡御繁」

起初在專案開頭時，花了兩天的時間進行設計的時程規劃，雖然上文中已經提及許多理想的操作情境，但在實務的設計上，其實還有很多錯誤處理（Error Handling） 、邊緣案例（Edge case）需要考量。

產品設計師需要從使用者的角度出發評估需求、對公司內部又必須權衡務實的商業考量，如何在有限的時間之中，產出一個足夠好且具有可持續性（未來可迭代開發）的設計是最大考驗。

因此在設計之初，我的作法是在需求規劃中逐一檢視所有的開發需求。識別本次專案中最複雜、最核心的元素，並根據資訊架構切分成多個子任務以利時程控管。

首先，在社群之中最優先需要處理的就是「動態牆中的內容」，因為這是整個項目中，出現頻率最高、影響使用者體驗最大的元件（Component）。

針對動態牆中的內容我提出了「容器(Container )」的概念，在需求規劃中可以看到原始的開發需求如下：

1. 使用者上傳的活動
2. 官方路線資訊
3. 編輯精選的內容集合（Curation）
4. Hikingbook 的使用者專訪（User Story）
5. 行銷部門的推薦內容

上述各種不同的資料就像是液體，需要與其性質相符的容器來承載，不同類型「容器」中的資料來源可能是使用者、行銷部門或是兩者結合（例如：編輯精選的使用者活動）。

這些看起來相似度高卻有細微不同的資料，將會根據資訊架構、演算法顯示於動態牆中。

為了維持使用者在瀏覽不同頁面時的視覺一致性，需要盤點這些容器中的資料結構，並根據資料結構來進行視覺提案、減少不必要的元素，降低後續開發實作的複雜度。

因此我決定從「使用者上傳活動」開始設計，該項目的資料結構是最複雜的，若能優先解決此處的設計規劃，剩下的工作就是簡化與比例的微調。

在開始設計前就決定好設計策略，以終為始來開展後續工作。

在決定好策略與最關鍵的設計的項目後，接下來與你分享實際設計的過程。

▋在設計時考量到 Edge Case，並提出相應的處理方式，節省後期開發人力的成本

在設計「使用者上傳活動」時，這並不是一個全新的元件，也因此，存在著一些我們已知的問題：

1. 使用者將活動命名的較長時會無法完整顯示
2. 無法在外層直接看到活動的互動狀態等等

因此，在開始設計時，就需要把這些問題納入考量，思考因應的方式。在整理完這些已知問題（Known Issue）後，我才真正開始設計 UI。

首先，我把單一容器中切分為五個部分：

1. Top header（頁首）
2. Cover Image（封面照片）
3. Body Content（主體資料）
4. Interaction Area（拍手、留言、分享、下載等互動行為和狀態）
5. Footer Matadate（頁尾詮釋資料）

這五個部分各司其職，在視覺層級上 Cover Image 吸引使用者的注意力、Header 負責提供貼文者、上傳時間等次要資訊，Body Content 補充詳細的活動資訊，Footer 則顯示清楚的運動數據。

透過這樣的視覺規劃，讓使用者可以在瀏覽動態牆時，透過掃視（Scan）的方式識別不同活動的資訊。

在完成最複雜的容器設計之後，剩下就是根據不同的內容，調整容器的資料結構，並再次與開發、行銷人員確認資料來源、建議字數、呈顯形式與限制，儘可能避免資料遺漏或是未定義的狀態。

在專案初期與相關利害關係人共同確認最後交付的產品規格，避免在完成設計提案後需要打掉重練。

藉由反覆的測試與迭代後才定下最後的 UI 提案，過程中驗證不同資料的顯示狀態、操作邏輯是否合理、易操作。

▋決定好介面的外觀形式後，如何展示給使用者也同等重要

在完成容器的設計後，接下來就是要如何把內容傳達給使用者。使用者在更新 App 後看到新的設計會不會因此迷失方向，需要重新建立心中的認知模型，因此接下來的工作便是「重構資訊架構」。

在重構資訊架構時，首先想到的是，要根據什麼邏輯來梳理資訊架構？目前的資訊架構有什麼樣的問題？

為了釐清以上的問題，我先回頭檢視原始設計的資訊架構、介面設計，試圖識別潛在的問題。

原始動態牆的互動行為與資訊架構：

1. 在「推薦」的子分類中上方有行銷部門希望曝光的內容（活動、商品等），下方則是使用者所在區域的當週熱門活動。
2. 在「活動」的子分類中則是依上傳時間由新到舊顯示使用者上傳的活動。

根據使用者操作 Hikingbook 的行為並分析原先的介面後，我認為原先動態牆最主要的痛點就是內容與使用者的關聯性過低。

導致動態牆就算有很豐富的內容，在使用者瀏覽到有興趣的內容前，失去耐心的話就不會繼續瀏覽了。因此接下來，我將針對此痛點，探索設計的方向。

▋透過內容與使用者之間的關聯性，讓使用者更容易建立新的認知模型

從「與使用者自身關聯性高低」的角度出發，新版介面是透過二級導航（Secondary Navigation）處理與使用者關聯性高到低的內容分類。並將「推薦」中的分類打散，加入新的「商城」，重新梳理整體的資訊架構。

1. 追蹤中：顯示使用者主動追蹤的內容
2. 附近活動：根據使用者所在位置顯示方圓 50 km內的活動
3. 社群亮點：由 Hikingbook 編輯部主動更新的使用者訪談文章、當週熱門活動
4. 個人活動：顯示使用者公開的活動紀錄

以關聯性來處理資料結構上相似，但對於使用者優先層級不同的內容。

由於「追蹤中」的內容是由使用者主動選擇的，內容與使用者之間的關聯性是最高的，附近活動則是較為隱性，透過使用者當下的 GPS 位置來決定顯示的內容。最後才是顯示跟使用者關聯性較低，但在社群中充滿個人特色、值得專文介紹的各種 Hikingbook 使用者們。

透過資訊架構，搭建起使用者與內容之間的橋樑

目前 Hikingbook 社群上線約莫一個月，已經有超過 1000 名使用者在 App 內追蹤其他 Hikingbook使用者，也有近 2000 名使用者正在被追蹤中，也期待未來後續的發展！

六、對 Hikingbook 社群的未來願景

▋做好準備，期待美好的事物發生

對我來說社群是一個有機體，會有自己演化的方向與個性，就像是上文所描述的，作為設計者，我打造的只是一個「容器」，並希望這個容器對於使用者來說是好用且符合需求的，但容器內要裝填什麼內容，仍然是以使用者為主。

作為戶外愛好者的工具，你可以透過 Hikingbook 發現靈感、規劃路線、並在實際走訪時的導航路線以及活動後紀錄分享屬於你的冒險。

很榮幸 Hikingbook 已經陪伴了這麽多使用者一起探索戶外，也不斷被使用者驚艷，已經有人把我們的產品帶到了那麼遠的地方去使用或者是竟然會有人這樣子使用我們的產品。

加入 Hikingbook 後一路到現在，作為設計師的我已經接受了太多精彩的內容、從每一位使用者身上也學習到了太多。

而 「Hikingbook 社群」更像是一份禮物，獻給從過去一路支持 Hikingbook 的使用者以及未來想要參與其中的人們。

就像是米開朗基羅只是把大理石中多餘的部分去除，讓美麗的事物浮現，我也只是把不吝於分享的使用者們所上傳的珍貴紀錄，稍加調整後，讓這群使用者能更容易夠被看見、讓你們的分享的資訊可以幫助到更多的人。

希望未來在社群中可以看到更多的互動與交流，並在這個過程中，大家都能都安全的探索戶外，把自己接收到的資訊，再分享給更多需要的人。

結尾

Hikingbook 社群的核心是「以使用者為中心」、「鼓勵分享與互助」。在實際開發時，才真正體驗到要持續提供有意義的內容與處理各種錯誤狀況是多麼令人崩潰。

但看著 2023 年以來做的各種設計變更在有了使用者參與之後，真的讓 Hikingbook 站內的內容變得更加豐富，甚至連我在規劃自己的登山行程時，也都更常參考站上使用者的活動紀錄。

這種感覺真的是非常神奇，就像是你努力幫助互不認識的陌生人，結果最後收穫最多的竟然是自己。

在 Hikingbook 社群的設計中，我做的不是從 0 到 1 的創新，而是替未來發展從 1 到 N 的過程進行基礎的建設。

希望你會喜歡這篇文章，透過這篇文章與你分享在過去幾個月開發時的酸甜苦辣，也期待收到你的回覆，歡迎來信或留言交流，或者是在 Hikingbook 上一起追蹤各式各樣精彩的使用者吧。

連結戶外靈感，共赴自然之約：揭秘 Hikingbook 社群功能背後的設計 was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

本篇原文出自 Hikingbook 前產品行銷實習生 林庭宇 Jamie Lin

在 Hikingbook，我們十分重視夥伴能否與公司一起成長，即使是期間較短、可能仍在摸索職涯方向的實習生，我們也希望能提供充分的嘗試與實作空間，協助個人在完成工作目標的同時，也達成自己心目中的進步指標。以下這篇實習心得來自 Hikingbook 2022–2023 間的產品行銷實習生庭宇，邀請大家來認識她這一路的學習！

嗨，我是 Hikingbook （已經離職的）羊駝編，我叫林庭宇，也是 2022 年 5 月到 2023 年 5 月為期一年的「 Hikingbook 產品行銷實習生」，這段期間我是全職實習，也就是一週要進辦公室五天，所以跟著公司也接觸到了很多專案，產出了很多行銷相關的作品。這篇文章我會敘述自己在這一年學到的知識與想法上的改變，歡迎對在新創公司實習或是工作有興趣的新鮮人一起看下去。（延伸閱讀：我為什麼來到 Hikingbook 實習？）

一年的實習說長不長、說短不短，身為行銷實習生對我來說學習最多的就是累積實戰經驗、站在產品角度看產品與用戶。這是我第一份真正進到公司裡面有主管、同事共事的工作，工作間產出的作品也會真實且直接的呈現在客戶（用戶）面前，影響到的不再是只有我自己，也會影響到公司整體。這一年除了在專業技能的表現上有所提升外，改變我思維最多的是一些不管在工作或是人生目標上都可以適用的達成目標的方法與概念。

累積實戰經驗、站在產品角度看產品與用戶

「產品行銷實習生」的工作內容有以下三大類：

• 社群行銷
• SEO 文章
• 電商

社群行銷的部分包含了社群媒體 FB、IG 的經營，還有 YouTube 影片的產出。在社群媒體經營方面是我比較拿手的部分，比較缺乏的是以前的我並沒有想過我產出一篇內容的動機與目的，很可能就單純是為了我覺得有趣而製作。但是在公司裡，社群經營的最終目標是流量的轉換，一是他透過社群知道我們，對我們產生印象甚至是好感，二才有可能願意下載 App 成為我們的用戶。在比較深入的想過用戶的需求、根據歷史資料推測出用戶喜好過後，再搭配創意產出內容，我認爲是在需要認真經營流量時很穩定踏實的方法。

在 YouTube 影片方面，我以前就有在經營 YT 頻道，所以基本的剪輯拍攝沒有問題，不過問題一樣出在以前的我沒有想過為什麼我要做這部影片？這部影片是要給誰看的？他們需要怎樣的內容？幫助他們解決什麼問題？舉例來說，在擔任產品行銷實習生的過程中，有幾部影片明確設定是為了吸引「已經知道 Hikingbook 的人、可能對訂閱 Pro 有興趣的人」，根據客群再去想他們可能對哪一個功能最感興趣、對他們來說最有價值，再根據自身經驗或是在登山圈見聞的故事去做包裝。有了以上的思考過後再進入撰寫腳本、取材、剪輯後製，一直到發布宣傳的文案手法上，都會比較知道應該怎麼做，也會對達成公司目標有實質上的幫助和成績。

部落格 SEO 專欄文章每月會固定產出一篇，從登山者會需要哪些資訊的角度去撰寫，小到登山申請的連結、山上交通的資訊，到他在攀登那座山時可能會用到哪些裝備讓登山過程更舒適，其中的裝備是否有可以結合電商去做行銷的？還有他在閱讀到哪些部分時會有動機想要下載 App，例如介紹路線時可能會想確保安全、下載路線軌跡，整篇介紹完時可能會有想登山的衝動與想像，就會想下載 App 來記走過的軌跡等。這些都是在寫文章時會去推想的，讓文章不論對可能的潛在用戶或是公司都帶來更大效益。

電商的工作項目從選品、上架、設計、文案、EDM 行銷、辦活動，在這一年內都有接觸到，很廣泛的學習到電商營運的冰山一角，也是跟金錢最直接有感的連結。跟團隊一起定義出我們想要商城給人的感覺、我們的用戶可能會需要或是喜歡怎麼樣的商品與行銷手法，再去實作驗證這件事預估跟成果有沒有差距，再到如何改善預估的準確率，或是如何維持預估的準確率。

社群、部落格、電商，三個項目的產出都是非常直覺且直接的。網路貼文有多少按讚轉發、影片觀看數、部落格文章搜尋點擊次數、電商銷售額等。在這樣結果可以數據化的項目中，我們很好在過程中檢視階段性的結果，並對作法做調整。這也是我在實習中學到很多的一件事。

達成目標的方法與概念

在設定了目標之後，我們是不是會試著找許多的方法來達成它呢？例如我要透過 YouTube 影片獲利，我就要先累積一些片量，訂出自己的人設、頻道定位、適合行銷哪類的產品等，有非常多考量的面向，一次要全部解決是不太可能的。在實習學到幾個非常重要的觀念：

把目標拆小，小步快跑
如果把一個大目標當成一個事項來做，那可能會需要很久的時間、很多的努力才能完成。我們可以把目標拆小，分成很多子目標，這樣在做的過程中除了比較有成就感以外，也比較好去分配時間，在遇到問題需要尋求幫助時，也更好形容自己遇到的問題，釐清自己需要哪些資源才能完成工作。新創公司每天步調都很快，大家每天都有不同的事項要處理，時間的掌控更加重要，小步快跑的思維告訴我們：完成階段性小目標後，可以先驗證作法的可行性和效果，之後再去做優化。

找方法達成目標
不知道大家在為了達成某個目標的時候，會不會有「不確定怎麼做」才能達成目標的狀況發生？之後這個目標就會被拖延下去，漸漸的這個目標好像就不再是目標。
在公司裡運用 OGSM 一頁計劃表來計畫工作的目標和規劃工作的內容，所有的工作內容都是基於為了達成某個目標而去做的，在這樣的框架下，有明確的目標和方法（雖然需要一點時間擬定），但都會更加堅定的去做每個項目。

適時檢視成效
以往在學校做專案時，並沒有養成每天或是每週、每月定期檢視成效的習慣，往往都是在失敗或是成功了之後才在推測原因，但這樣會很難避免失敗，也會很難複製成功。適時檢視成效可以讓我們根據得到的結果來改變達成目標的方法，在實習中公司有定期的：

• 每天 stand-up meeting（主要是說明一下工作事項，但也督促自己推進工作進度）
• 每週 社群經營、推播等
• 每天 電商活動檢視流量、營業額等
• 每月 All-Hands（說明整月工作內容成果、下個月待辦重要項目）

定期的回顧可以讓我們少走一些浪費時間的路，更有效率達成目標。

進到一家公司工作當員工，和自己接案當老闆是很不一樣的體驗，各有各的優缺點，不過很重要的一點就是不論在哪裡都要感到持續進步。在 Hikingbook 實習的這一年我接觸到很多行銷的工作，對我來說都是累積，每一項也都可以專精下去成為專業。給自己多一點機會嘗試，相信走過的路都會在某個時刻開花結果！

我們很高興看到庭宇能在一年間的實習帶走屬於自己的學習，希望這些經驗能讓她未來的道路走得更順利、更有自信。

想看更多 Hikingbook 的故事嗎？歡迎追蹤我們，一窺產品背後那些你不知道的大小事！

產品行銷｜實習心得 was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Internships are to learn what you never did in a classroom. I am a mobile application development intern at Hikingbook Inc and a second-year computer science undergraduate at the National University of Singapore. Having gone through 3 months of full-time internship here, I have penned down my experience below. Whether you are looking to apply for a position at Hikingbook or interested in software development internships, I hope this article could be of help to you!

What I do

As a mobile application development intern, I mainly help with the development and enhancement of features for our application Hikingbook. At the start of my internship, I was working with user authentication. On the frontend side, adding more sign-in buttons to our app, along with some API calls. Afterwards, I was slowly exposed to more of our app and helped with additional user interface and database migrations. Moving on, I began to implement entirely new features for our app (Referring to our gear management feature!).

How I learned

Throughout the entire internship, I received guidance from Zheng-Xiang (our CEO, senior developer and my supervisor). Before embarking on my tasks, I would receive a rundown and have my questions answered. What I really appreciated about this rundown was that I was always given the reason behind my tasks which really deepened the knowledge I picked up at Hikingbook. For instance, once when we were integrating SwiftUI framework into Swift UIKit, not only was I shown how we are going about it but also the conceptual differences of both frameworks that led to the challenges of integrating them both.

Beside task rundowns, I was also free to ask questions throughout the work process. As a rule of thumb, when I encounter problems, I search around the code base and the internet for possible solutions. Only when nothing comes up or when the problem-solving has taken too long with little progress would I consolidate my findings and approach my supervisor for help. Without fail, I would always receive a detailed explanation for the problem at hand and possible solutions that I could use.

Technical aside, my day-to-day at Hikingbook

As a small start-up of 5, we are all kept updated on each other’s tasks and work progress. At 10: 30am every morning, I attend our standup meeting where we pull up the company’s Kanban board and give updates on the tasks completed the previous day and the current day’s tasks. Then after, I might have a weekly meeting with Zheng-Xiang for a progress review. Following that, I look through my tasks for the day and start breaking them down into sub-tasks with time estimations to keep myself on track. Once done, I start to work on them for the day.

So everyday I code, ask questions, have standup meetings… and then?

I attend more meetings. Something surprising to me about Hikingbook is that despite our small size, we have a great number of meetings. However, I don’t believe this is all bad! As an intern, I think meetings are a great way to learn about things outside of your work scope. In all these meetings I was encouraged to actively participate in them, contributing my ideas and receiving constructive feedback. As someone on the quieter side, these meetings taught me to improve myself as a presenter, even watching others present was a learning opportunity to me.

Soft skills aside, the meetings exposed me to the workings of a startup company. I was able to see statistics that detailed the user usages, see the efforts made to answer customer feedback, and overall how everyone’s work made the company work as a whole. I think this is something I never can experience at school or at the bigger companies and a key takeaway of my internship.

Rumour has it that interning at a start-up is all about the grind.

Yes, interning here was grinding for sure, not chill but worth it. As I worked on each task, I find myself learning and applying new concepts. Many times as the deadlines approach, the stress levels build as I try to learn, solve problems and finish as much as possible especially since my delay may delay others. But when I do complete the tasks, the sense of accomplishment is great. If I really could not do it, I am able to let my supervisor know and my workload will be adjusted to better suit me. Moreover, as mentioned before, I could always ask questions when problems arise.

How’s the team?

The team can make or break anyone’s internship experience and I really enjoyed working with the team at Hikingbook. The work culture here is friendly and flexible. Throughout the day, in our cozy workspace for all 5 of us, spontaneous conversation breaks out from time to time. We also have Slack channels for random chats and news-sharing. As per the name, most of us are hikers (sans me, coming from Singapore with no mountains) and we love the outdoors. Our monthly team building has us travelling to hike, to eat and have a good time together. We also have birthday celebrations, monthly company outings and monthly one-on-one chats.

Challenges

The biggest challenge I faced in my internship was time management. In the beginning, I struggled to understand the large code base and at the same time pick up 2 new programming languages. As such, I was slow to complete my tasks and my Pull Requests (PR) had more mistakes. On the bright side, I was able to overcome this challenge with time and patience. The more I worked with the code base, the faster I am altering it. Also, another thing that really helped me was to start writing notes as I learn. This helped me to research and deepen my understanding of new concepts and it also helped me to retain new information better.

And now the at the end…

Reaching the end of my full-time internship here is a bittersweet moment. I remember starting this journey with an equal mix of trepidation and excitement, unsure of what to expect working in a different country. Now at the end of this journey, I have no regrets, I am heading back with many lessons learned, skills gained, and relationships forged. I really appreciated my experience here and all the people at Hikingbook who made my internship worth it. A huge thank you to you guys!

To end off, to all the job-seeking readers I wish you all the best! And, if you happen to like hiking, love the startup culture, or you are just curious of it, why not give Hikingbook a try?

手機 APP 開發｜實習心得 was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

本篇原文出自 Hikingbook UI/UX 產品設計師 Tiffany Lin

在上篇 Hikingbook App 最大改版 中，團隊的產品設計師與大家分享了改版計畫從規劃到實作的心路歷程。今天這篇文章，就讓我們一起來看看，到底實際改版後，有哪些不同吧！

舊版跟新版有什麼差？來比對看看吧！

地圖頁

開始紀錄登山軌跡吧！

舊版：

• 流程：(1) 按「開始登山」（紅框處） > (2) 選擇「新增登山行程」 > (3) 輸入行程名稱 > (4) 按「確定」 > (5) 按「開始紀錄」鍵來紀錄軌跡> (6) 選擇是否要紀錄起點 （完成）
• 介面 ：「開始登山」鍵與介面缺少足夠對比度，圖示意義較不明顯。
• 問題：流程較複雜、無法快速開始紀錄、狀態不夠明顯。許多使用者不知道按下「開始登山」後，還需要再按「開始」才會開始紀錄軌跡。

新版：

• 流程：(1)開始鍵 > (2) 選擇是否要紀錄起點 （完成）
• 介面 ：使用顯眼的顏色為主要按鈕、搭配直觀的「開始」圖示來代表「開始紀錄」。可看到更大範圍的地圖，不會被過多 UI 所遮蔽。
• 優化：簡化紀錄的流程，使用者只需按下「開始鍵」，方能開始紀錄軌跡，同樣也可自由選擇是否要「紀錄起點」再開始紀錄。

查看地標

距離目前位置遠嗎？那裡天氣如何？

舊版：

• 流程：(1) 點選地圖任一地標 > (2) 滑出地標資訊頁（完成）
• 介面：所有資訊用多欄的方式顯示。可以從資訊頁頂部用下滑手勢的方式關閉此頁。
• 問題：文字顏色、大小、樣式皆一樣沒有變化，沒有階級區分，不知道哪些資訊為主要或是次要。進階功能無法馬上察覺和理解。

新版：

• 流程：(1) 點選地圖任一地標 > (2) 滑出地標資訊頁（完成）
• 介面：若點選的地標為紀錄點，會顯示此為第幾個紀錄點。地標名稱字級設定為最大、也位於最顯眼的位置，再來則是水平距離和座標。特別注意的是右方灰色區域，顯示的是紀錄此行程的進階資訊，包括天氣、抵達時間、當日已走時間。最下方的橫向功能表，雖在最底部，但樣式卻較為醒目，能讓使用者在短時間就發現這些進階功能的存在。
• 優化：
  在研究使用者階段我們發現，山友時常去記算點到點之間所花費的時間，用於排程登山計畫的時間表，我們則將這樣的需求添加到地標的資訊頁中（當日已走時間），更方便山友詳細地參考山友紀錄的行程時間。下方的進階功能，除了擁有明顯的按鈕樣式，也添加了圖示去增加理解度。橫向功能則是新增「查天氣」的功能，可依照目前選取的地點座標，去連結當地的天氣狀況，方便山友即時觀察氣象。

查看下載路線

剛剛下載了別人的GPX，該怎麼看呢？

舊版：

• 流程：(1) 點選 icon > (2) 滑出「參考的登山行程」頁> (3) 選擇要顯示的路線 > (4) 已被選擇的路線會變為紅字（完成）
• 介面 ：圖示含義較無法快速理解，文字中「參考」解釋較為廣泛（是指導航嗎？還是只是觀看）、「行程」釋義較多，首次使用的用戶較難快速理解去使用。
• 問題：圖示與文字不夠簡白直接，狀態改變後僅有文字顏色變更，略為隱晦。若使用者想要將路線關閉，需滑到列表最上方，選擇「不選擇參考路線」才會關閉路線，而在列表有很多路線的狀況下，使用者就需要滑很久才能達成目的。

新版：

• 流程：(1) 選單 > (2) 點選 icon > (3) 滑出「選擇顯示路線」頁 > (4) 選擇要顯示的路線 > (5) 已被選擇的路線右方的 icon 會由灰變為紅色（完成）
• 介面 ：文字改用「顯示路線」更為直接，用代表顯示意味的「眼睛」圖示去增加使用者聯想到實際功能的功用，並使用圓底當作按鈕的背景，暗喻是「可按的」區域，當開啟時會是紅色配景搭配「張開眼睛」的圖示，反之是灰色搭配「關閉眼睛」的圖示。
• 優化：由於新版將地圖上功能都整合到一「選單」功能中，所以流程會比舊版多了一個步驟，將所有功能都透過統一的入口去展開，讓使用者可以一覽所有功能。當使用者觀看的路線已被開啟時，再次打開「選擇顯示路線」頁，系統將會自動滑到該路線的位置，不需要再做多餘的滑動。

新增紀錄點

這裡有水鹿耶？趕快來打個卡！

舊版：

• 流程：(1) 進入「新增登山紀錄」頁 > (2)開始編輯 > (3) 按「完成」（完成）
• 介面：下方功能左至右分別為：天氣、展開鍵盤、相機、座標、收起鍵盤，圖示意義都很明確沒有問題，但左二和右一「展開鍵盤」和「收起鍵盤」，分別為兩個圖示則是較不普遍的做法。（Android 只會有一個，而 iOS 系統較少有收起鍵盤功能）
• 問題：使用者選擇完一個項目後，切換下一個項目編輯時，無法即時顯示上一個項目選擇了什麼。

新版：

• 流程：(1) 進入新增登山紀錄頁 > (2)開始編輯 > (3) 按「完成」（完成）
• 介面：考慮到使用者較常會編輯的為「文字區域」及「上傳照片」，因此把這兩個功能放置在最顯眼、同時也佔頁面中最大的區域，讓使用者易於點選和編輯。
• 優化：由分欄位的顯示的方式，使用者可以及時看見每一欄位所選擇的內容。且因版面資訊較少，編輯時也不會因為鍵盤滑出，而遮擋過多資訊。

儲存登山行程

安全下山了！怎麼儲存？

舊版：

• 流程：(1) 結束行程 > (2) 跳出通知是否要「前往編輯行程資訊」 > (3) 按「前往編輯行程資訊」> (4) 滑出「新增登山行程」頁 > (4) 編輯 > (5)按「完成」（完成）
• 介面：用一頁的欄位方式顯示所有資訊。
• 問題：使用者必須要先輸入行程資訊方能開始紀錄，每次結束行程後都會跳出通知詢問是否要編輯。

新版：

• 流程：(1) 結束行程 > (2) 滑出「編輯登山行程」頁 > (3) 編輯 > (4) 按「儲存行程」（完成）
• 介面：縮小封面照的顯示尺寸，給頁面較多的留白空間減少視覺壓力。將文字內容可能會較多的「說明」和「後記」移至下一層級，避免所有資訊全部顯示、內容看起來較為冗長。將「完成」改為更有動作感的文字「儲存行程」，同時增大了按鈕的可點區域，增加使用者的控制感。
• 優化：使用者在不需經過任何選擇、不需輸入任何文字的情況下，即能快速地開始紀錄，而在結束行程後，即使不做任何編輯也能夠直接儲存行程，較為符合一般下山後就已經很累的情境；此時系統會將預設好的標題帶入後儲存，待使用者之後再進行編輯。

同步＆上傳機制

你知道同步是什麼嗎？

舊版：

• 流程：(1) 進到個人列表 > (2) 按左上角「同步」鍵 > (3) 系統會將所有行程都上傳到雲端（沒錯是所有） > (4) 可於個人頁尚查看（完成）
• 介面：不少使用者以為圖示是「重新整理」的意思，而「手動同步」機制的作法較少在紀錄 App 使用（通常是紀錄完當下就已上傳完成）。
• 當初使用「同步」的原因：因行程有距離、軌跡、多張照片、紀錄點、時間、座標…而每個行程距離有長有短，內容資訊量多寡也會相差甚大，無法達成儲存當下就自動同步，以免影響操作速度。
• 問題：而大家對於「同步」的理解也難有統一的解釋。最常發生的問題是，因為無法選擇單個行程同步，若使用者一次同步的內容數量過多，則可能造成服務器超載，導致 App 閃退或同步失敗。

新版：

• 流程：(1) 進到個人列表 > (2) 選擇要上傳的行程 > (3) 按右上角「上傳」鍵 > (4) 系統將上傳此一行程至雲端（完成）
• 介面：改為一次上傳一個行程，在上傳期間可以看見上傳進度。
• 優化：一次上傳一個行程，避免不斷地重複來回傳送資料，未上傳時會有明顯的 UI 表示「未上傳」 ，並建立在行程後系統自動提醒上傳的推播機制，不會在執行任務當下被干擾，而使用者只需要按一次上傳，往後已上傳的行程若有做任何編輯或刪除，系統都將自動同步。

探索頁

看看山友們都去哪裡？

舊版：

• 流程：(1) 探索頁 > (2) 查看行程（完成）
• 介面：一個行程所佔的版面較大，使用者無法快速瀏覽多個行程，每個行程下方有拍手數目、留言數、觀看次數。使用原生的標籤頁供使用者切換要顯示的內容，但由於類別較多，且原生元件有一定的限制，文字只能全部置於固定寬度、觀看時稍顯吃力。
• 問題：尋找行程時，優先考量的行程內容為路線資訊，但介面並未顯示這些訊息。切換顯示類別的點按區域太小。

新版：

• 流程：(1) 探索頁 > (2) 查看行程（完成）
• 介面：兩個行程為一行的方式顯示，並顯示每一行程的時間、距離、體能等級、天數、紀錄點數量，供使用者快速找到他們需要的行程。最上方切換模式用橫向捲軸的方式，文字彼此間距可以保留多一些空間，點按的區塊也更大。
• 優化：考慮到使用者尋找行程時，會透過路線資訊來評斷是否要進去觀看，將重點資訊盡可能的一次顯示於最外層，即使顯示尺寸有限，但資訊擺放位置並不互相干擾觀看。使用者若要切換顯示內容，只要從螢幕的右方往左方滑動就可以輕鬆切換。

成果心得

也許改版後不是最完美的樣子，但能確定的是，這個成果是團隊半年來付諸了許多心力和時間去完成的，真的辛苦大家了！

身為產品設計師，時常在使用者與公司目標之間做拉鋸戰，我們能做的就是洞見產品的可能性、積極參與使用者、馬不停蹄地與團隊溝通，為了就是想把問題想得更透徹，試著想出更適合的解決方案。我相信優化產品的過程是永無止盡的，是否真的變更好用了？我知道不保證每個人都這麼想，但是在盡力後，就放寬心去等待市場的回饋吧！不管是好的或是不好的回饋，都能讓我們有機會做更好。

這次改版上線後不久就碰上了疫情，相信很多產業都深受打擊，關閉山林也是現階段最好的做法。雖然不能馬上知道大家的回饋有點可惜，但我還是很開心能透過自主的力量去經歷改變產品的過程，即使有小小的改變，仍很值得！

優化產品的過程是沒有盡頭的，而 Hikingbook 團隊的核心價值之一便是 — — Iterate 持續迭代、專注優化，因為所謂「完美」的產品並不存在。透過這次 App 改版的分享，希望能帶大家一窺團隊在持續優化使用者體驗的道路上，得到的寶貴收穫。若有任何想法，都歡迎在留言與我們分享！

Redesign 實例分享 — Hikingbook App（上）

Hikingbook App 改版前後比一比 was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

本篇原文出自 Hikingbook UI/UX 產品設計師 Tiffany Lin

如果你已經使用 Hikingbook App 一陣子，最近是否有注意到我們的介面有大幅度的調整與優化呢？你眼前看到的畫面，是團隊歷經半年的改版計畫，所產出的成果，也是有史以來最大的改版！今天這篇文章，由團隊的產品設計師親自執筆，要來跟大家分享如何從最初的洞察問題、到著手實作、及最終順利完成改版的過程。與我們一起重溫這趟難忘的旅程吧！

為什麼決定要 Redesign?

1. 改善多個次要問題

即使每個都不是很嚴重的問題，累積起來卻可能造成很大的影響。

會發現這些問題，主因是平日在做產品測試時就能明顯察覺到，雖持續有修正過一些地方，但是零碎的修正較容易有思考不周的漏洞出現，這次希望能把需要改動的地方都一次整理好，將所有問題都列入全面性思考，才能做更細緻的調整。也因客服部偶爾也會收到一些來自使用者的建議，有些確實值得思考、也將這些建議納入審視，漸漸也能明顯知道哪些地方會造成使用者不適。

例如：圖標 (icon) 意義不夠明確、顯示狀態方式太過隱晦、執行任務時不斷跳出通知、缺乏動態互動去引導操作…等等。這些都不算太大的問題，卻成為不小的障礙。

設想當使用者操作產品的同時，假設執行 1 個任務需操作 5 個步驟 ，卻在每一步操作各出現了 1~2 個小問題，而這些小問題累積起來就像是層層關卡，不斷阻撓著使用者要執行的任務，導致使用門檻一直提高，還可能讓使用者卻步，不僅會造成使用者感到挫折失望、而最糟糕莫過於使用者最終放棄使用產品。

2. 補強目的不夠明確的功能

由於團隊開發前期未有足夠時間全面性地安排版面，有些進階功能藏在較不明顯的位置，大幅降低功能存在的功用。

例如：擺放層級太低、缺少分類導致訊息過多、未將複雜任務拆解為多個簡單步驟…等等，若未提醒使用者或引導去發掘，一般使用者將很難去發現、也無法理解其意義，導致「沒發現 」或是「不想用」這些功能，最後犧牲掉的是團隊付諸心力開發這些功能的寶貴時間。

任何所設計出來的產物都一定要有存在的「原因」及「目的」，心理學家 Donald A. Norman 在他的著作 The Design Of Everyday Things 一書中提到了最淺顯易懂例子：門上有門把因為要供人「拉開」、茶壺有把手要供人「拿起來」。這些看似日常的道理，都是最佳的使用者體驗設計。

3. 使用流程不夠簡易、不直觀

在 App Store 我們收到不少使用者反應：使用操作複雜、初學者難上手…等等的意見，舊版 Hikingbook 的操作方式確實與市面上常見登山相關的 App 不太一樣（尤其紀錄軌跡、同步機制的操作方式），有這樣的問題一方面是因為一些產品初期所開發的功能，目的為滿足單一需求，但當新的功能越趨越多種，未將全數的流程做好合併，導致一些主要流程的步驟被打散、使用起來也變得較不直覺、不明確。

經過多次收到類似意見及觀察身旁人使用產品的經驗，加上我自己也為使用者之一，確實認為使用流程可以再精簡化，來達成使用者進到某個頁面時，能馬上確立下一步要做什麼事、按下某個按鈕前也不應出現疑慮、困惑等情緒，必須讓使用者有自信地做出每個決定。

4. 當前狀態不夠明顯

Hikingbook 的核心功能之一，無非是可以紀錄登山軌跡和紀錄點，讓山友都能記錄下屬於自己獨一無二的活動。平常觀察山友們頻繁地分享各自的登山活動，卻也察覺到不少使用者「沒有紀錄任何軌跡」，因想確認是否為本意行為，於是我開始隨機長期觀察同一使用者，卻發現許多使用者在初次紀錄的幾個活動都是沒有軌跡的，直到第二次、第三次之後的活動紀錄，才開始有軌跡資訊。

進而發現，最大的障礙是因為使用者無法看見「現在沒有在紀錄軌跡」的狀態，即使有，卻因為「沒有」與「有」兩種狀態在 UI 上未有明顯的區別，或是當使用者在成功改變狀態時，App 也沒有適當的提醒機制告知使用者「狀態已改變」。

人機互動博士 Jakob Nielsen’s 提出了啟發式評估（Heuristics usability），廣泛且通用的 10 種原則，其中第 1 項就是可視化的系統狀態（Visibility of system status）：「系統必須告知使用者將前往何處，並在合理的時間內給予適當的回饋。」

簡單的例子：使用播放器聽音樂時，我們會知道要按下播放鍵 ▶️，當還沒按下播放鍵以前介面是顯示著暫停鍵 ⏸，則我們知道現在音樂暫停中，所以會知道下一步要按播放鍵才能播放音樂。

5. 缺乏一致性介面和風格

Hikingbook 成立初期因為開發產能有資源上的限制，許多介面上的元素和元件並未達成全面性的統一，也因此導致使用者需要花費較長時間來習慣操作，而在風格上則因為初期尚未有自己固定的設計系統（Desgin System），導致不同時期所創建的功能沒有達成一致性的呈現。

就像看到「＋」你會知道可以新增某個東西；看到「右側卷軸」你會知道這一頁應該可以往下滑。這些符號及樣式，在大部分的產品上都代表同樣的意義，擁有一套統一邏輯的元件和模組就非常重要，將能大大增幅使用者體驗的順暢度。

現在這些你看到就能懂的樣式，在最初被設計成為介面上的元素時，也並非是這麼的直覺，這中間必須經過一段人機設計（HMI）與使用者溝通、互動的時間，讓使用者慢慢建立認知，最終理解意義並能夠直覺地操作。不過這些通用的樣式並無法滿足現今複雜多元的產品，無時無刻都會有新的功能或服務被創建，則擁有一致性的介面＆風格是格外的重要。

擁有一致性的介面（UI），是確保一樣元素他們的外觀和行為是統一的，有助於使用者對他們的假設是成立的，並觸發他們的熟悉感、增加控制感和可靠性，同時也能減少使用者的學習成本，避免增加混亂。

擁有一致性風格（Style）能強化用戶對產品的認同感與信心。使用者產生認同感時會對產品增加參與度（黏著度），也能帶動分享或介紹的意願，讓大家知道：「快看！我在使用這個很酷的東西。」

風格的一致所顯現的審美標準也代表著該產品的品質和質感， Apple 正因他們嚴謹地規範著各式各樣的樣式、元件及模組，來達到介面與風格一致性。即是消費者只使用過 iPhone，當他第一次使用 iMac，也不需花費很多時間去學習，因為即使在是不同裝置上，相同元素的動作和行為都是相似的。

發掘了這麼多問題之後………讓我們開始吧！

設計流程（Design Process）

1. 理解你的用戶— 同理思考（Empathize）

謹記「以人為本」是使用者體驗的設計核心，我們第一步是先嘗試去了解用戶的想法和行為，以下舉例幾個問題供參考：

• 用戶使用我們產品的目的是什麼？ — 使用目的
• 用戶為什麼想使用這個功能？ — 察覺動機
• 用戶使用我們產品的時候是開心的嗎？什麼時候會感到煩躁？
  — 理解情緒
• 用戶實際上最常使用的頁面為何？ — 觀察數據

…等等，可依照自己的產品取向去定義更多問題。

2. 避免過多「我覺得」 — 定義問題（Define）

初做 UX 很常犯的錯，在還沒得到驗證以前，卻脫口說出：「我覺得使用者….，所以應該會……」，『假設』在精實設計（Lean UX）中確實是不可缺少的一步，為的是在最短的時間內做出 MVP (Minimal viable product) 再去市場驗證，最後再迭代出更好的產品。假設的目的是讓你能夠有一個起點，進而去發散更多、更深的疑問。

要有條理的定義問題，我們先收集用戶想法，並且用一些問句去歸納結果。
例如：「我們是誰？」、「我們要幫使用者解決什麼？」、「我們該如何幫助？」、「使用者是誰？」、「使用者的目的是什麼？」…等等。

收集一定的資料量之後，將收集用戶的資料加以整理，並依照所設立的目標，將他們分們別類、理出優先順序，關鍵的問題就會漸漸聚焦。

收集使用者想法可以透過以下幾個方法：

• Google Analytics：
  以量化方式觀察使用者行為。（被動）
• PMF (Product Marketing Fit)：
  透過簡單的問題，檢視產品與市場相契合度。（主動）
• 線上問卷（Questionnaire）：
  可在問卷中提出已經從內部發現的既有問題，進而去捕捉用戶概略的想法。（主動）
• 參與相關社群媒體：
  觀察「可能為用戶」族群所討論的議題。（主動＆被動）
• 涉略相關領域消息：
  培養對趨勢的敏感度，避免過時或不切實際的想法。（被動）

每一種方法都有它的優勢及缺點，特別注意的是使用「主動式」方式時，要考慮盡量在不干擾用戶習慣的情況下去接觸市場，避免造成負面觀感，反而造成反效果。

3. 創作時間 — 發想解決方案（Ideate）

我們有時利用頭腦風暴（Brainstorming）的方式，一起思考較無法聚焦的問題。後期則是我會製作線稿（Wireframes）搭配流程圖（Flowchart）的方式，用可視化的方式發表給團隊。因新創開發時程較為緊湊，我會事先完成 60~70% 的內容再進行發表，所以這時已經有一定基礎的架構，請大家檢視過後，提供意見及修正辦法，最終加以討論收斂想法。

先由設計師架構好再邀請團隊討論的好處是，不會花費過多來來回回的討論時間，也能將時間投注更多在之後的調整階段。

4. 驗證時刻— 測試（Test）

經內部討論多次後，將每個需要解決的問題，最終都收斂成一個解決方案，並落實在原型（Prototype）之中，我們舉行了易用性測試（Usability Test） 活動，目的在於真實地去接收使用者的聲音，去驗證我們改版後的成品，是否真的有達到我們改版的目地：變得更好用？

執行這個階段時是我認為最緊張、同時也是最興奮的。能夠知道使用者對我們的作品是什麼想法，這是每位 UI/UX 設計師既嚮往又怕受傷害的過程！

擬定測試計畫

在開始測試前我列出了計畫表，我知道測試非一蹴可成，也不可能只由我「設計師」一人可以完成，因此我必須詳細安排前、中、後時間點，各個階段要完成的項目且需要得到的什麼結果，接著才繼續進行下一階段。

每一階段都與前一階段有著環環相扣的因果關係，過程不僅會需要公司的全員參與，同時也會增加比以往多的交流時間，作為設計師同時也是主使人，我們需要主辦各式活動，舉行前也應評估進行方式並確保其目的性，才能將「協作設計」的功用激發到最大效率。

團隊緊密的討論同時能讓目標更明確、或是發現自己未預期到的盲點。而跟著計劃走還能確保在團隊發散想法期間，最終成果還是能夠保持一致的目標，避免不小心偏移方向。

易用性測試（Usability Test）

計畫安排完成後，在外部測試前也我們還進行了內部測試（Pilot Testing），確保測試流程沒問題，進入最後的微調階段，直到確保所有測試內容都沒問題，就可以開始招募測試者。

最終我們邀請了五位測試者，將已經設定好原型的手機供測試者操作，並請測試者依照情境和題目指示，完成我們所指定的任務。

測試時全程錄影及隨時筆記，觀察測試者在第一時間的行為、情緒變化，並且針對測試者發生每個反應去詢問原因、和執行關鍵步驟明顯有障礙的原因，接著測後訪談，去了解使用者操作步驟的動機和邏輯，或是有無發現任何更深層的原因，最後則是讓測試者提供自己在操作時的任何想法。

結果是……?

結果是，以為會照著劇本走，卻時常被打破規則，甚至劇情超展開（「他為什麼會按那裡？！」）的事情都發生，在測試中很意外地發現平常內部完全無法察覺到的問題，原因是內部人員對於自己所開發的產品本身就已經有既有的認知，所有的想法都是建立在相似的基礎之上，這時候唯有透過外部測試，才能從更多角度去觀察問題所在、發現使用者痛點在哪裡。

這讓我釐清「優化產品」其實並沒有所謂的唯一辦法，唯有持續觀察用戶行為、隨時跟進用戶思想並且要善於嘗試及隨時維護，才有機會做出更貼近使用者需求，同時也滿足企業目標的產品。

結語

從發現問題、研究使用者、思考解決方案、做測試…，最後依照需求做完所有調整，團隊約莫花費半年的時間才告一段落，對於我們來講，是一段又愛又恨的長期抗戰，中間發生過意見歧異、也有發生過討論多次卻未達到共識的時候，不過在每一次的深入討論後，都能彼此給予真實的意見，也不斷激發新的想法，狀況越是膠著的時刻，有時反而會成為了精進的墊腳石。

透過設計協作，也證明這些設計想法不只是設計師一人的想像，當團隊們互相產生質疑、點出問題，都代表著我們對自己的產品有高標準的要求，即使遇到開發上有什麼阻力，也都盡量做到零死角溝通，讓我每一次在設計過程中都能避免掉一些的問題，也能增加及時修正方向的敏感度，最後與開發部達成一個最佳平衡。

作為產品設計師，我們時常需要用使用者的角度去思考，並從企業目標的方向去行動，有時的確實很難達成雙贏的局面，但是經歷這次改版流程後，我認為使用者體驗設計並沒有「最完美」的方案，從不同角度切入總會有不同的成果，取決於你該如何在保有最初的目標，同時盡力去滿足現今市場。

使用者則是隨時被世代的趨勢所牽動著，不可能一成不變，負責開發產品的我們也必須以動制動，才能順應趨勢。雖然團隊規模不算很大，也希望能盡我們所能的力量，為社會產出更友善也更易幫助到大眾的產品。

今天能夠分享這個改版計畫其實感動又感激！這些都是團隊經過了多次的琢磨、一起努力累積而成的結果，也要感謝一路上給予支持的人，願意告訴我們真實的意見，才能有這次的改版成果。

以上就是團隊的產品設計師拆解改版過程的心路歷程，是否比你想像中的還要複雜些呢？這次的改版計畫，針對 App 最核心的功能 — — 地圖、定位、記錄、活動等，做出了大幅度且縝密的優化，所有的努力，都是為了提供給我們的使用者更易用的體驗，不管是在登山前的規劃、登山中的記錄、到登山後的分享，都能順暢、滿意地完成操作。

實際改版後，到底有哪些不同呢？歡迎到下篇一探究竟！

Redesign 實例分享 — Hikingbook App（下）

Hikingbook App 最大改版 was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

以下的對話，是否也曾出現在你身邊？

「媽，我週末要去走 OO 山喔！你不要擔心，我會自己注意安全！」
「老婆，我下個月連假能不能去 XX 山四天三夜？唉呀，不會很危險啦，妳放心！」
「兒子啊，爸跟媽下禮拜報名了 OXO 健行活動，好久沒去山上走走了，有領隊帶很安全啦！」

如果你常在爬山、或者你的家人愛爬山，想必這些對話都不陌生。上山前，通常都會跟家人報備一聲，希望他們可以放心。但通常，聽的那一方若沒有爬山的習慣，就算知道你要去的是 OO 山，也可能完全不清楚這座山、或這條路線的狀況。

如果登山者順利完成行程並返家，這種資訊上的落差並不會有太大的問題；然而，當登山者在山上遇到意外時，往往難以立即對外聯繫，通常只能依靠家人發現遲歸，向相關單位求援。此時容易產生兩個問題：第一，家人過了多久之後才發現登山者已經遲歸？有沒有可能因為時間差而延誤了搜救？第二，當家人向警消通報的時候，往往無法提供確切的資訊給搜救人員，好一點的可能知道是去了哪座山，差一點的可能只知道去爬山，但相關資訊卻是缺乏的，讓搜救任務變得更加耗時、困難。

Hikingbook 最新推出的「安全守護」功能，就是為了解決這個資訊上的落差，透過即時、可靠的雲端系統，以「留守人」為核心，串起山上與山下的安全連線。

在今天的這篇文章中，我們會跟大家分享，「安全守護」的機制是如何設計的，以及我們怎麼在這樣的功能中，實現「讓所有愛山人安全爬山」的理念。

「安全守護」是什麼？

「安全守護」是 Hikingbook 的開發與設計團隊，花了近半年時間打造的新功能，希望可以搭建起登山者、留守人、與搜救人員三方面的溝通橋樑。

• 在山上的登山者：登山的過程中，不需額外操作，系統便會定期更新位置；此外，能透過「安全守護」，快速發送含有重要資訊的訊息給山下的留守人或當地消防單位。
• 在山下的留守人：可以即時追蹤登山者的行程狀況與位置，若登山者未在預定的時間內下山，「安全守護」會發送主動通知，讓留守人第一時間掌握重要資訊，並可即時協助對外求援。
• 搜救人員：有了留守人提供的重要資訊，有助於搜救人員在第一時間縮小搜救範圍，提高救援的成功率，進而減少人力、時間成本的消耗。

由下方的架構圖就可以理解，「安全守護」串起了這三方的聯繫，讓登山者可以放心登山、山下親友或留守可即時追蹤、也讓搜救人員在有需要的時候取得必要資訊，減少搜救負荷。

定義「登山者狀態」

為了讓山下親友或留守人能夠了解登山者行程的狀況，「安全守護」設計了「開啟『安全守護』」、「開始登山」、「逾時」、「結束『安全守護』」、「安全下山」等近 10 種「登山者狀態」，這些狀態代表登山者目前登山行程的狀況，當狀態改變時，「安全守護」便會主動通知山下留守人，讓他們可以第一時間掌握動態，做出反應。

此外，為了讓留守人能夠根據登山者狀態，獨立判斷狀況並避免有錯誤警報（False Alarm）發生，在發出通知時，會提供每個狀態的詳盡說明，讓即使對登山活動不了解的山下留守人，也能夠根據說明，決定下一步採取的動作（或不採取動作）。

「安全守護」定義近 10 種「登山者狀態」，讓山下留守人直覺、快速地了解登山者的當前狀況。

「安全守護」與網路

「安全守護」系統是透過網路來搭建起山上與山下三方的橋樑，因此下一個問題就是：當登山者在山上沒有網路時，是不是就沒用了？

其實並非如此。因為一個 APP 軟體，雖然會受到硬體上的限制（如：手機網路訊號），但我們在設計「安全守護」時，目標是把軟體能做到的事做到極致，讓軟體能發揮最大效用。因此，即使登山者在沒有網路的環境下，「安全守護」仍會有以下運作機制，以確保他的安全：

• 隨時監控登山者的網路狀態，一旦恢復網路訊號（例如：抵達山屋、抵達有網路的定點），「安全守護」便會立刻更新當前位置。
• 登山者沒有網路時，除了「安全守護」無法取得最新的登山者位置之外，其餘功能皆能夠正常運作，包括：登山者狀態最重要的「逾時」，及其他時間相關的狀態。只要超過時間，系統就會通知山下留守人，確保可做出即時的反應。
• 當登山者不幸發生意外，透過「安全守護」的即時行程網頁，能夠知道登山者最後走過有網路的區域，便能夠協助搜救人員擬定第一次的搜救行動，縮小搜救範圍。

「安全守護」與衛星電話

較有經驗的山友看到這邊，可能會好奇，「安全守護」的設計，是否要取代衛星電話？

其實，「安全守護」並不會、也無法完全取代衛星電話。衛星電話提供了幾近 100% 的可對外聯絡功能，但並無法自動提供包括即時位置、狀態變更等資訊給山下留守人，也沒有位置與地圖結合的視覺回饋給山下留守人，因此，「安全守護」的定位，應該是與衛星電話相輔相成的，若能兩者並用，將可大幅提高登山者的安全。

以一般狀態的登山行程而言，「安全守護」便有足夠的回報機制，讓山下留守人能即時追蹤登山者的動態。而萬一登山者發生意外，在沒有網路，但登山者尚有意識能主動求援時，他可以透過衛星電話對外求援；若是在登山者失去意識、或手機遺失等無法主動對外求援的狀況時，「安全守護」依舊能夠在逾時下山的時機點，代替登山者主動通知山下留守人，不錯過黃金救援時間。

結語

「安全守護」是一個看似簡單，運作機制實為複雜的系統，簡單易用的操作介面，背後有著龐大且堅韌的系統支持。最終的目的，無非是希望所有愛山人，都能更安全地探索山林的美好，期許未來能共同打造更成熟、更好的登山環境。

Hikingbook 致力於提供登山安全的創新解決方案，整合完整登山前中後歷程，讓登山可以更安全、更方便。我們相信，人身為大自然的一份子，都能安全、自在地徜徉並享受山林；透過創新科技，希望讓每一位山林愛好者都能盡情探索自然之美。歡迎造訪我們的官網，或關注我們的 Facebook、Instagram、Youtube。
若有任何問題，歡迎隨時來信至：support@hikingbook.net最後，如果你喜歡這篇文章，也請幫我們拍個手，給我們繼續寫下去的動力唷！🙂

「安全守護」：串起山上與山下的安全連線 was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

如果你是常用軌跡記錄 App 來追蹤自己的活動（跑步、單車、登山等）的人，在使用不同 App 的時候，有沒有看過像是下圖「失控」的軌跡？你是否懷疑過，是不是自己的 App 設定或手機哪裡有問題？

先別急著怪罪 App 或手機！其實，會出現像圖片中鬼畫符的軌跡，是因為 「GPS 定位誤差」所造成的結果；自從 GPS 技術問世、普及後，如何穩定 GPS 訊號，就一直是運用 GPS 技術的公司需要克服的問題，也是不少學術研究探討的主題。今天這篇文章，就要來跟大家談談，在 Hikingbook App 內，我們怎麼去解決這個問題，現在就一起來了解吧！

話說從頭：GPS 與定位

【Hikingbook 科普教室】認識 GPS

GPS（Global Positioning System）是 1973 年美國國防部因應軍事需求而研發與建立的全球衛星定位系統，於 1983 年部分開放給民間使用（軍用版 GPS 比民用版 GPS 精準），2000 年全面開放。隨著科技的發展，GPS 系統有越來越多的演進，減少 GPS 誤差與加速處理，如：DGPS（Differential GPS，差分全球定位系統），以及在智慧型手機廣泛使用的 AGPS（Assisted GPS，輔助全球衛星定位系統）等。

GPS 定位系統，是由至少 24 顆環繞在地球周圍的衛星所組成（至 2019 年，共有 31 顆在運行），而至少要收到 4 顆 GPS 衛星的訊號，才能夠定位。因此，如果處在不見天日的地方，如：地下室、密閉空間或是抬頭只能看到一小片天空，如：高樓大廈林立的街頭、室內，都會造成定位不準或無法定位的狀況。

GPS 系統組成，可以分成三大部分：衛星、地面監控站、接收設備。地面監控站會傳遞軌道與時間等資訊、並且下指令給衛星，同時監控衛星狀況；衛星把同步後的時間與軌道資訊，傳向位於地球的接收裝備；接收裝備接收到至少 4 臺衛星所傳遞的資訊，便能計算出所在位置。三者的關係可以用下圖來理解。

既然 GPS 只需要衛星就可以運作，自然就不需要網路囉！這樣大家應該可以理解，為什麼在沒有 4G 訊號的山上，你的登山 App 依舊可以定位你的位置了吧！（至於為什麼在山上打開 Google Map 仍是一片空白呢？這個我們有機會再來跟大家聊聊囉！）

GPS 定位不需要網路，有衛星訊號就行！

硬體與軟體的協力：GPS 晶片與 App

如果說 GPS 靠的是衛星，理論上同一臺 GPS 接收裝置（如：智慧型手機、平板）取得的定位資訊是一樣的，那為什麼還會常聽到有人說「某某 App 定位超準，不像另一個 App 很容易亂飄」？

這是因為，雖然同一臺 GPS 接收裝置取得的定位資訊是一樣的（如下圖），但每個 App 看待 GPS 資訊的方式卻很可能是不一樣的；換句話說，每個 App 處理 GPS 資訊的演算法不同，造成最後每個 App 呈現出來的結果不同。打個比方，就像是一樣的食材，經由不同的廚師料理，就會產生不同的料理，是類似的道理。

我們在 App 中看到的定位資訊，是 GPS 晶片、作業系統與 App 協力合作的結果。

iOS 與 Android 的「Location Framework」

在了解 GPS 最基本的運作原理、也知道 App 中的定位資訊是硬體與軟體合作的結果後，對於一個 App 開發者來說，能優化的其實就只有 App（軟體）本身。也因此，在說明 Hikingbook GPS 穩定演算法之前，我們必須先來認識 iOS 與 Android 兩大平台的 Location Framework，看看到底一個 App 可以取得的定位資訊有哪些。

[iOS] Core Location

在 iOS 13 的系統版本中，可取得的定位資訊包括：座標、海拔、樓層、水平準確度、垂直準確度、時間、瞬間速度、方向。

[Android] Location

而在 Android 10 的系統版本中，可取得的定位資訊包括：水平準確度、海拔、方位、方位準確度、緯度、經度、GPS 資訊提供者、瞬間速度、瞬間速度準確度、時間、垂直準確度。

從以上兩張表可以發現，Android 提供的定位資訊比 iOS 來得多，也因此在設計 GPS 穩定演算法時，Android App 或許可以更加準確（畢竟可參考資料較多），但其實只要使用最基本的座標、海拔、水平準確度、垂直準確度、速度與時間，便可設計出好的穩定演算法。

座標、海拔、水平準確度、垂直準確度、時間，是穩定演算法不可或缺的資訊。

Hikingbook GPS 穩定演算法（Hikingbook GPS Stabilization Algorithm）

其實，GPS 的原始訊號是很雜亂的，因此如果都不做處理，在 App 裡的呈現會非常混亂，幾乎無法參考。因此，只要有支援軌跡記錄的 App，理論上都應該要對訊號作處理，才能讓使用者看到的是接近實際行走路徑的軌跡。

Hikingbook GPS 穩定演算法（Hikingbook GPS Stabilization Algorithm）從 v5.0 推出記錄軌跡功能後，經歷多次的改版、修正與精進，才演進到最新版本 v6.5.3 所使用的設計（如下圖所示）：模型預測、準確度啟發式篩選、平滑與簡化。以下就來認識這三種設計怎麼畫出穩定不亂跑的軌跡。

1. 模型預測（Predictive modeling）

當開始記錄軌跡後，利用所累積的過往定位資訊與預測模型，能夠預測未來的定位資訊並進行校正，可大幅減少第二步驟被篩選掉的資訊。

2. 準確度啟發式篩選（Accuracy Heuristic Filtering）

利用 GPS 提供的資訊，捨棄掉不合理的資訊，如：準確度過小、距離過大等，降低軌跡四處亂竄的可能性。

3. 平滑與簡化（Smoothing & Simplifying）

適度簡化軌跡點數，不僅能夠減少 GPX 檔的檔案大小，也能夠平滑軌跡，減少在同一個地點停留導致軌跡混亂的狀況。

下圖是有使用與沒使用 Hikingbook GPS 穩定演算法記錄的結果差異。

此外，依據測試，在相同路線下，使用 Hikingbook GPS 穩定演算法所產生的 GPX 檔的檔案大小，比未使用小了 14 倍之多（如下圖），這樣的好處是可以加速資料處理速度、也更不佔裝置（手機、平板）的儲存空間。

在未來的 App 版本，我們仍將持續優化演算法的設計，讓每一次記錄的軌跡，都可以滿足「在不增加過多資料負荷下，盡可能貼近實際行走路跡」的目標。如果你在使用軌跡記錄時，仍有遇到一些異常的狀況，也歡迎隨時透過客服告訴我們！

結語

透過 Hikingbook GPS 穩定演算法，讓 App 使用者可以更準確地記錄所到之處；準確而不亂飄的完美軌跡，不僅可以保存真實的美好回憶，也讓這份紀錄更具備參考價值，進而讓登山資訊的流通、傳遞更有效，讓每個人都可以貢獻自己的足跡、分享寶貴經驗，貢獻社群。

參考資料：

• GPS：https://en.wikipedia.org/wiki/Global_Positioning_System
• iOS Core Location：https://developer.apple.com/documentation/corelocation/cllocation
• Android Location：https://developer.android.com/reference/android/location/Location

Hikingbook 致力於提供登山安全的創新解決方案，整合完整登山前中後歷程，讓登山可以更安全、更方便。我們相信，人身為大自然的一份子，都能安全、自在地徜徉並享受山林；透過創新科技，希望讓每一位山林愛好者都能盡情探索自然之美。

歡迎造訪我們的官網，或關注我們的 Facebook、Instagram、Youtube。
若有任何問題，歡迎隨時來信至：support@hikingbook.net

最後，如果你喜歡這篇文章，也請幫我們拍個手，給我們繼續寫下去的動力唷！🙂

GPS 穩定演算法：完美軌跡背後的秘密 was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

「路線規劃助手」是 Hikingbook 在 2019 年 9 月下旬推出的「Hikingbook Pro」訂閱式服務中，最重要的一個功能。它是一個線上的智慧規劃工具，可在網頁瀏覽器或 Hikingbook App 中使用，並支援全球登山路線地圖。登山客可以使用「路線規劃助手」，快速、自由地規劃登山路線，做好行前準備，並可在完成規劃後，將產出的路線直接匯入 Hikingbook 或其他登山 App 中做為參考，大幅提升登山安全。

舉例來說，只要選擇路線的起點及終點，就能馬上取得實際行走的登山路線，以及該路線的距離、海拔高度變化、與預估行進時間，如操作影片所示。

以上的概念聽起來是否有點熟悉呢？沒有錯，這個直覺、自由、快速的操作概念，就是來自於 Google Maps 在規劃路線上的設計；而 Hikingbook 「路線規劃助手」從設計到開發，秉持的正是以下目標：

我們的目標，是將「路線規劃助手」打造為「登山人的 Google Maps」。

做為 Hikingbook 第一個進階功能，「路線規劃助手」有其特殊意義。因此，今天這篇文章，就讓我們來更深入的談談，它背後的設計理念。

為何是路線規劃？

選擇開發「登山路線規劃」的工具，起因於我們對臺灣近幾年登山環境與風氣的觀察。在登山活動日漸興盛、休閒化、大眾化的當下，「行前規劃」比以往更應該要受到關注。

行前規劃是登山前準備必要環節，也是登山活動風險管理的關鍵之一；事前是否有做好妥善的規劃，關乎到行程是否能安全、順利的完成。而在行前規劃中，「路線規劃」可說是最重要的部分，必須先掌握路線基本資訊——包括里程、海拔變化、預估時間、山屋營地等，才能針對裝備、糧食、交通等其他面向進行規劃。

因此，我們可以說，登山前的路線規劃，是登山安全的基礎。然而，觀察臺灣近年來登山活動的現況，會發現有近半數的山難事件，是因為迷途失聯而發生（資料來源：消防月刊），顯示了許多登山者缺乏事前完善的規劃與準備，導致在山上迷路、走錯路、或錯估時間而遲歸。

缺乏事前的規劃，一部分是因為尚未建立正確的風險管理觀念，另一部分則是因為缺乏適用的工具。觀念的建立需要持續、長時間的推廣，但好用的規劃工具，卻是可以較快開發出來的。因此，我們選擇「路線規劃」的工具做為 Hikingbook 第一個進階的功能，目標除了提供登山者一個更方便直覺的數位工具以外，也是實踐 Hikingbook 服務核心價值「安全」的其中一步。

釐清問題：登山前的路線規劃為何困難？

讓我們想像兩個常見的場景：

難得的四天清明連假，你想去走需要好幾天的百岳行程，於是在兩三個月前開始規劃「南湖大山」。

週五的晚上，你臨時起意，想要隔天週末去走「黃金三稜：無耳茶壺山」。

假設這兩條路線你都沒走過，你可能就會開始 Google 這幾個關鍵字：「南湖大山」、「黃金三稜」、「無耳茶壺山」。然而，接下來你有可能會遇到以下這些問題：

1. 資料零散而雜亂

隨著網路建設的普及，只要會上網搜尋，就可以輕鬆取得登山路線相關的資訊；然而，網路上的資料琳瑯滿目，同一座山，不同隊伍可能有不同的行程安排、不同的路線走法。他們走完後的記錄，也因為天氣、人員數、人員體力、突發狀況等因素，導致實際走的路線、距離、時間皆不盡相同；再加上臺灣地質脆弱，多天災，山路易崩塌，造成取得可靠、可信的資料相對困難，需要花很多時間或者是東拼西湊成為有用的參考資料。

2. 冷門路線資料少

冷門路線因為較少人走，可搜尋到的資料數量少、不易取得，而且往往找到的資料也是幾年前的，參考價值不高。換句話說，雖然網路搜尋方便，但卻不見得有你想要找的登山路線。

3. 新手入門門檻高

臺灣的山區常常沒有網路訊號，因此，幾乎不可能到了現場或走到半路才開始查資料，這也是為何事前的規劃十分重要。然而，對於剛開始接觸登山的新手而言，面對龐大與繁雜的資料，若缺乏適當的指引或教學，很難判斷哪些資料、細節是重要的，或甚至連去哪裡找到重要的資料都沒有頭緒。

換句話說，「規劃路線」對新手而言，門檻是高的；也因此，市面上有許多的商業登山團來滿足了「不會規劃」的需求。然而，若把自己的生命安全都全權交付給一個陌生的嚮導與領隊，其實是具有高風險的事；就算跟團，也應該對路線有基本的掌握，並逐漸培養自己規劃的能力，就如同許多事物，「魔鬼藏在細節裡」，正是許多的細節累積起來，決定了登山行程的安全。

4. 資料無法修改與互動

在網路上找到的資料，可能是文字、照片或路線地圖，同一個路線或地點，只能透過人工方式交互對照。另一方面，路線地圖多為圖片，無法修改與互動，因此筆記或註記與路線地圖會分散在不同的地方，多半只能列印出來後直接寫在紙上。換言之，資料無法修改與互動，造成資料分散，難以彙整。

設計目標：解決問題、滿足需求的線上工具

當我們試圖釐清問題後，下一步就是進入功能設計與開發的流程，並輔以使用者訪談，以確認、驗證功能需求。概括而言，「路線規劃助手」必須達成以下要求：

1. 自由、直覺、快速

使用者能夠根據自己的想法，規劃出想走的路線。以操作介面而言，地圖上的任何一點都是可以點選的，而兩點之間只要在路線資料庫內存在路徑，系統都可自動畫出建議的路徑，並在幾秒內完成。

2. 產出一致性

所有路線的資料來源與產出結果的計算方式是一致的，因此可作為客觀的參考。舉例來說，路線的預估時間，是綜合參考英國索爾福德大學應用統計系的研究動態與其他計算公式，所計算出來的。因此，不管是腳程較快或較慢的人，都可以使用這個預估時間作為參考基準，來推估自己需要的時間。

3. 高互動性

使用「路線規劃助手」，可在互動式、完全程式化的地圖上操作，不只能直接觀看附近的路線與高度變化狀況，也能像 Google Maps 一樣任意拖拉、縮放、或以地名、山名搜尋，具備高互動性，而非只是單一張圖片。

4. 降低規劃門檻

除了讓介面好操作以外，為了降低新手初次嘗試規劃路線的門檻，我們加入了「路線範本」的設計，讓新手或是不熟悉路線的人，可以在既有的官方範本的基礎上，依據個人需求再進行調整，而不需要從零開始。

目前上線運作中的「路線規劃助手」

對應到上述的目標，目前上線運作中的「路線規劃助手」，可以讓登山客以下面幾種方式規劃路線：

1. 直接套用路線範本

選擇好路線並匯入之後，就可以在地圖上看到路線，如操作影片所示。

可直接使用範本中的行程中繼點作為行進依據，也可一目了然看到路線里程、預估時間、總上升與下降高度等基本、重要的資訊。

2. 匯入 Hikingbook 行程資料庫中的路線

不在範本內的路線，可以選擇匯入 Hikingbook 資料庫中其他山友的紀錄。流程跟匯入範本是很接近的。

3. 直接在地圖上自由規劃

最自由、彈性的規劃方式，只要在地圖上選擇起點與終點，剩下的工作就交給「路線規劃助手」吧！可使用地點或座標搜尋，貼合不同類型登山客的需求。

「路線規劃助手」可在 Hikingbook 網站上使用，也可在 Hikingbook App 中使用，如下圖。目前的版本，在網站上操作，將可以有較好的使用體驗，而我們選擇優先優化網頁版體驗而非 App 內原生畫面的原因，其實還是回到設計與開發的初衷：登山前的規劃，應該是在行程前就完成的事，愈是有風險、難度的行程，愈應該盡早規劃；考慮到許多事前作業仍會在桌上型電腦或筆電上進行，故我們將「路線規劃助手」的第一版，以電腦上的操作為優先考量，而將在 App 上的體驗優化，排在未來版本更新的計畫中，也請各位拭目以待。

結語

從發想、設計、到開發「路線規劃助手」，我們希望可以協助登山客，增加規劃的自由度並降低門檻，不論是老手與新手，都能夠很輕易地規劃路線，降低迷途風險，增加自身登山的安全性。

預防迷途，從規劃開始。

這次的主題就跟大家談到這裡，謝謝每一位讀到這邊的你，我們下次見囉！

若你想更了解「路線規劃助手」的使用方式，請點擊下圖看詳細介紹。

Hikingbook 致力於提供登山安全的創新解決方案，整合完整登山前中後歷程，讓登山可以更安全、更方便。我們相信，人身為大自然的一份子，都能安全、自在地徜徉並享受山林；透過創新科技，希望讓每一位山林愛好者都能盡情探索自然之美。

歡迎造訪我們的官網，或關注我們的 Facebook、Instagram、Youtube。
若有任何問題，歡迎隨時來信至：support@hikingbook.net

登山規劃不求人：「路線規劃助手」設計理念 was originally published in Hikingbook Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.