入門資訊架構的思考方式（三）資訊架構過程的五個思考步驟

本文是資訊架構入門的系列文，前面文章討論了「資訊架構的三種基本角色」、「事前準備與內容提供者」、「評估資訊內容的影響力」。

如果你希望獲得 Soking 的課程、讀書會以及 UX 講座訊息，歡迎留下你的 Email，訂閱最新的 UX 活動通知：https://subscribe.soking.cc/

前述幾篇文章都是關於資訊架構前期規劃的討論，這篇文章我想談談執行過程的思考，包括我在進行 Sitemap、Wireframe 等資訊架構設計時，犯過哪些錯誤，以及我得到了什麼教訓。

下面我將依序說明五個思考步驟：

1. 先符合用戶達成目標的基本期待
2. 決定提供內容給用戶的方式
3. 考量例外、異常狀況提供用戶自救的方式
4. 提供有意義的互動與個人化成就
5. 延伸接觸點

一、先符合用戶達成目標的基本期待

過去我在處理資訊架構時，腦袋中沒有辨別主次流程的觀念，因此一討論完需求就打開軟體繪製當下對於介面的想像圖。

當我端出這樣的畫面來討論規劃時，會被開發團隊的夥伴不斷逼問某個按鈕會往哪邊去？有沒有錯誤狀態？沒有某些資訊會怎麼辦？等等細節問題。

產品設計師必須避免一開始就陷入細節的討論。

工程師或 UI 設計師的職責所在需要把產品具現化，所以他們關注細節如何執行是理所當然的事。因此當他們看到一個充滿細節的畫面，自然只關注細節應該如何處理。

好的第一步是優先處理用戶的主要任務情境是什麼，透過哪幾個步驟可以正常完成任務。即使在這個過程繪製了草圖來跟開發團隊其他人討論，也要注意將範圍限縮在「如果用戶要完成 A 目標，他會經過哪些必要的頁面步驟？有什麼選擇？輸入什麼資訊？得到什麼回饋？」

二、決定提供內容給用戶的方式

產品除了幫助用戶完成目標任務之外，通常要提供「選項」來幫助用戶，例如電商提供各種產品品項、多種金流支付方式、各種貨物寄出的方案等。

當這些「選項」變多，例如成千上萬筆的旅遊地點、隨時在變化的機票價格，就開始需要在資訊系統中提供輔助方式，來協助使用者找到他需要的內容。

我們可以用主動、被動的角度來分析這件事情：

• 用戶被動接收：如首頁、主題分類頁、站內推薦版位、演算法推薦。
• 用戶主動尋找：如網站分類選單、麵包屑、關鍵字搜尋、篩選器。

組織這些內容提供給用戶選擇以及自助式逛街行為，就是傳統意義上資訊架構所研究的領域。

除了空間動線的邏輯清楚、文案用語符合用戶習慣、介面互動回饋的好壞以外，內容這件事情很吃營運資源，這包括獲取內容的管道以及工程資源的持續投入。

在內容的這件事情上，UX 設計師最要緊的不是高唱用戶體驗，一昧的要求高品質圖文內容來支持服務流程的體驗所需。反而是要認清現實，仔細的評估眼下規劃的產品上線後可以獲得的營運資源以及內容品質，提出符合現況的解法。

舉例而言，像下圖這類 POS 機的產品示意圖為求美觀經常會在商品的品項上放圖片，看起來符合我們習以為常的購物介面的直覺。

但在現實情況中，大部份小型的店家都沒有能力拍攝好看的照片來建立產品目錄，精美的圖片對於店員操作過程的幫助，可能還不如文字形式的菜單。

為了避免這個落差發生，規劃內容呈現的設計過程，不要只使用設計師自己在網路上找到的漂亮假資料，盡可能拿到最後真實要用在產品上的內容。光是在討要資料的過程，就會逼使團隊認真思考未來該如何取得。

三、考量例外、異常狀況提供用戶自救的方式

除了正常流程外，我們要盡可能的考慮例外與異常狀況，好在用戶陷入異常情況時得以自救或避免損失。

常見的情境包括：

• 忘記帳號密碼，所有的用戶最討厭的事情，而且經常有用戶因為嚴苛的帳密規範，導致記不住帳號密碼的用戶寫下來放在某些公開文件中，反而造成資安漏洞。
• 不小心刪除不應該刪除的東西。
• 好不容易找到某個內容，但是誤觸介面而造成頁面重整。
• 用戶在使用過程網路斷線必須重連，例如刷卡因此失敗，應該要在用戶回來時引導他重新付款，而不是只告訴用戶冷酷的失敗結果。
• 用戶踩到失效的網址，要自動重導，提供 404 頁以及返回首頁的引導。
• 用戶用奇怪的方式進入目前權限不應該進入的地方，要提供溫和的告示（工程師寫的 alert 文案常常很兇），堅定的把用戶丟回他該去的地方。
• 第三方服務失效，造成用戶無法完成任務，例如FB登入有時候會壞掉。
• 用戶的 APP 端儲存了過期的檔案或者不應該存在的優惠券。
• 用戶換手機、換電腦，需要備份或轉移資料。

在用戶遭遇異常狀況時，溫和堅定的告知現況，避免產生慌張或者怪罪系統的情緒，並給予可以自救的指示，例如 chrome 瀏覽器的離線小恐龍。

這些例外與異常狀況，通常就是考驗用戶體驗的時刻，因為用戶很少會記得我們正常運作中的產品幫他解決多少次問題，產品正常運作對用戶來說，本來就理所當然。

但是一次嚴重的錯誤或損失，導致用戶必須付出高昂的代價，例如：害用戶在手機轉換過程遺失了全部的資料，害用戶在重要節日無法完成預約，害用戶在連續輸入錯誤後鎖住帳號必須親自跑一趟實體店面才能解鎖。

這些負面事件都可能讓用戶永久離開我們，甚至產生公關危機。

這就是為什麼在易用性三原則裡面，有效性（Effectiveness）是擺在第一位，因為不管服務有多高端大氣上檔次，都非常難喚回被惹火的用戶。

四、提供有意義的互動與個人化成就

有的人會說這是會員流量池，或者遊戲化設計、成長駭客行銷等等。無論用什麼形式的名詞來描述，總之產品在有用之餘，還要讓用戶多做一點有意義的事情。

你可以說這是累積個人化資料，越多的用戶行為累積，投入了時間以及情感後，日後要斷捨離的成本也越高。

常見如：累積點數、留言、評價、分享、投票、個人清單、邀請好友、成就、任務、會員階級、群眾募資等。

最理想的狀況是將用戶原本在現實世界或其他服務內的互動行為，轉移到我們所設計的產品中。

例如路線記錄服務 Strava，記錄自行車騎乘或跑步時間以及 GPS 等資訊是滿足基本用戶期待。但當用戶的路線騎乘記錄可以被其他人挑戰，成為一個虛擬的競賽時，就將數據上傳的行為變成了有意義的互動以及成就挑戰。

更別提，當用戶發現可以用產品來發揮創意時，甚至會引發社群的模仿以及免費的病毒擴散。

五、延伸接觸點

有沒有可能在用戶還沒有打開我們的 APP 或網站前，就先提供我們的服務給用戶呢？甚至我們的服務有沒有可能與別人合作，在對的情境下一起服務客戶，達成雙贏？

在 iOS 的裝置中，提供用戶在手機未解鎖狀態下可以使用小工具，也可以長按桌面的 APP icon 來呼叫功能入口。

另外，產品可能在不同的平台提供服務給用戶，不一定發生在自己的網站或 APP 內，舉例如下：

• 網路媒體依賴臉書來提供內容、推送自己的文章給 LINE、以 RSS 或 Email 遞送訂閱內容。
• Youtube 提供嵌入內容在任意網站，也允許第三方開發者透過 api 引用內容。
• Netflix 除了自有管道也透過 Amazon 電視盒、AppleTV、中華電信 MOD 機上盒等形式提供內容。
• 新型態的社群電商用一個後台來管理臉書粉絲團、LINE 官方帳號等地方的客戶名單與訂單，沒有傳統意義上的網站。

舉個有名的例子，2017 年的時候 Google Map 曾經直接在 APP 內提供 Uber 叫車的功能，讓用戶在搜尋路線時可以即時看到 Uber 的預估抵達時間與車資，甚至進一步可以直接叫車與付款。（但這合作經過一年多就終止了）

結語

感謝你看完這麼長一篇文章，雖然文章中沒有直接告訴你 sitemap、wireframe 等資訊架構的設計文件怎麼畫，但這個思考步驟是我經常在產品設計的工作中使用的撇步。

如果你也有類似的作法或者有趣的觀點，很希望你能跟我分享你的經驗。

或者有關於資訊架構階段的設計規劃問題，也歡迎留言討論。

如果你希望獲得 Soking 的課程、讀書會以及 UX 講座訊息，歡迎留下你的 Email，訂閱最新的 UX 活動通知：https://subscribe.soking.cc/

相關文章：

• 快速認識UX設計中的服務流程圖
• 入門資訊架構並學習UX設計師的思考方式（一）觀察與練習的方法
• 我的產品設計文件演進史
• 談UX設計師評估資訊架構時內容的影響力、維護成本與可用性
• 線框圖（Wireframe）標註的識別規劃小技巧

查看獸群之心的 UX 文章目錄