Hikingbook App 最大改版
歷經半年，從問題洞察到改版實作
本篇原文出自 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 最核心的功能 — — 地圖、定位、記錄、活動等，做出了大幅度且縝密的優化，所有的努力，都是為了提供給我們的使用者更易用的體驗，不管是在登山前的規劃、登山中的記錄、到登山後的分享，都能順暢、滿意地完成操作。
實際改版後，到底有哪些不同呢？歡迎到下篇一探究竟！
