我們和資訊架構的距離
這本書乍看好像很硬，所以先摘錄一些（個人主觀看來）和 Jubo 設計有關的部分，讓大家入門。
資訊架構會成為一門學問，是因為資訊爆炸。
當資訊多到人們找不到自己需要的內容，人們就開始分類、排序、製作索引…採用某些方式整理資訊。資訊技術的出現和發展，則提供了更多組織資訊的可能性。
尋找資訊
— 摘自第三章〈為尋找而設計〉
人們對資訊的需求，並不像去餐廳點餐那麼單純：顧客在點了排骨飯、廚房製作A、店員將A端上桌，結束— — 這樣的流程很難套用在「尋找資訊」的過程。
使用者並不一定知道自己在尋找的是什麼，因此他所尋找的資訊也未必有「最正確的」標準答案。書中將資訊的需求分成四種型態：
- 已知項目尋找 Known-item seeking
這個需求最接近上面餐廳點餐的例子，使用者明確知道自己要找什麼，只要撈出最佳解答的資料，就完成了尋找資訊的任務。
例：找出捷運大坪林站的英文 - 探索式尋找 Exploratory seeking
有時候使用者並不確定自己要找什麼，他可能不了解自己想尋找的東西，因此缺乏明確的目標，或是需求沒那麼強烈，只要找到部分可供參考的資訊就能夠滿足。使用者在探索的過程中，一邊尋找也一邊在學習，也可能透過找到的內容改變尋找的方向。
例：找出連假期間有空房的飯店 - 地毯式研究 Exhaustive research
使用者也可能會需要特定主題相關的全部資訊，不論他是否知道自己想找什麼，都會竭盡全力把所有能找到的資料通通找出來。這種時候他會相當專注，願意多次嘗試各種查找的方法，並且極具耐心。
例：進行競品分析時挖出所有對手產品 - 再尋 Refinding
還有一種情形，使用者清楚知道自己要找某個「以前看過的東西」，儘管不記得確切是什麼，但如果看到就能夠立即判斷是不是，或隨著找到的線索修正尋找的方向。
如果有「稍後閱讀」或類似的功能，他就可能在看到的當下、把這個內容存起來，以便日後尋找。
例：找出某篇在社群網站上滑過的貼文
Q：Jubo 產品的使用者，在尋找資訊的時候會有上述的哪些需求呢？
資訊空間
— 摘自第四章〈為理解而設計〉
建築物的外觀和空間配置，可以讓人們快速地辨認出「這裡是哪裡」，同樣的概念也可以應用到「資訊空間」當中。資訊組織和陳列的方式，不只會影響使用者如何「尋找」，也會改變他對這個空間的「理解」。
同樣是網站的首頁，銀行和電商呈現的樣貌就會有所不同。因此我們一進到這個資訊空間，就知道自己可以做什麼。
銀行網站列出個人金融方面，有信用卡、存款、貸款、保險等服務，我可以依據自己所使用的服務類別去查找，但我無法得知「如果我需要的內容不在這裡」，需要怎麼找到我想要的資訊。
電商網站則呈現挑選過的商品，促使我直接進入查看商品內容，一旁則有主題分類、可以依據商品類別進行瀏覽，如果有特定需要的內容，也可以直接在搜尋框打字進行搜尋。
案例：Jubo NIS ：以個案為中心 v.s. 以模組為中心
Jubo NIS 絕大部分的模組，架構都是 Patient list — Data list — Form。
這樣的架構讓使用者便於批次作業，但我們也會持續從客戶、商業或品牌口中聽到「以個案為中心」的需求。儘管只是系統資料被組織和呈現的方式不同，線上也提供了快速切換模組和住民的導覽功能，但使用者所理解的資訊空間就是「以模組為中心」。
為此，健康儀表板每隔一段時間，就會重新被提起討論。（可喜可賀，去年終於進入開發排程）
這個新模組並沒有創建新的資料，但透過新的設計頁面 — — 把單一住民的資訊集中在頁面上，跨越模組與模組之間的高牆，讓使用者藉由不同的空間型態來理解這個資訊架構。
組織資訊的方式
— 摘自第六章〈組織體系〉
組織資訊，簡單來說就是「把相同的東西分類在一起」。
分類聽起來容易，但實際執行上會面臨各種問題：照片要按照日期還是活動主題排列？同一個住民的檔案要集中在一起，還是相同模組的檔案要集中在一起？（可以回想照片中心和檔案中心的討論）
最終我們需要回歸到實際場域的需要，依據使用情境決定一種或多種組織規則，這樣的規則不一定適用其他類型的產品（如果需要通用，勢必要投入更多研究和測試），但可以讓目標的使用族群順利的理解和找到所需的內容。
Q：你覺得 Jubo 主產品（NIS/DC/HC）的模組分類是依據什麼樣的規則？
分類也有階層的關係，最典型的例子就是生物分類：界門綱目科屬種 — — 同一層的內容彼此互斥，上下層的內容有父子關係。階層的觀念簡單且容易理解，設計良好的階層可以快速讓使用者掌握資訊空間的概況。
建立階層時，需要注意平衡「廣度」和「深度」，前者指的是單一階層中的類別數量，後者則是階層中的層級數量。太深的階層容易讓使用者查看幾個階層之後放棄探索，太廣的階層則可能讓使用者不確定要進入哪一個分類。
雖然階層能輔助使用者理解，但這樣的空間結構並不是絕對的，考量實際使用情境的需要，我們也可以建立跳脫階層關係的捷徑：例如文字加上底線的超連結，或是我們 NIS 在 Patient list 右側的快速新增按鈕。
需要注意的是，跨越階層與分類的連結可以帶來方便，但是如果使用太頻繁，可能會讓使用者在資訊空間迷失方向，最終搞不清楚自己在哪裡、又要怎麼回到原本所在的頁面。
命名的方式
— 摘自第七章〈命名體系〉
我們幾乎無時無刻不在做「取名字」這件事，大到產品名稱、小到頁面上的一個按鈕，設計產品時需持續為各種東西命名。命名是資訊空間與使用者溝通的方式。好的名稱需要同時滿足兩個條件：能夠反映其所代表的內容，同時能夠讓使用者理解。
以 Jubo NIS 在 Patient list 的篩選器來舉例，多數的 Filter 我們都有設置「全部」的選項，讓使用者可以一次查看全部的住民 — — 但是如果每個篩選器都把這個選項叫「全部住民」，那麼使用者就必須點開 Filter 才能知道它究竟可以篩選什麼條件。
再舉一個 NIS的實例，[輸出列印2.0] 選取 Google sheet 格式的按鈕 — — 它曾經叫做 Google sheet，但導入和客服發現我們的使用者不懂 Google sheet 是什麼，最終改成了現在的「雲端 Excel」。
書中為命名的方式提供了一些建議：同時考量內容、使用者和脈絡，盡可能限制命名的範疇，以及我們較常會碰到的 — — 建立一致的命名體系。
一致的命名可以幫助使用者學習和理解，一旦看過一兩個命名，就能很快反應過來其它命名可能代表的內容。這裡摘錄幾點一致性的影響因素：
- 文法格式
嘗試採用單一格式，避免混用動詞型（照顧您的愛犬）、名詞型（愛犬飲食）和問句型（如何訓練愛犬如廁？）
*中文體系或許包含更多注意事項，例如動形名組合的順序 - 顆粒程度
同一組命名最好描述相同層級的細節，例如中餐廳、鼎泰豐和小籠包可能就是三種不同層級的名稱。 - 完整性
盡可能使命名體系涵蓋完整的範圍，否則使用者往往會感到困惑，例如命名包含白班、小夜，使用者可能就會期待有大夜。
書中介紹了許多產生命名的方法，例如內容分析、卡片分類或搜尋記錄分析等，然而我們實務上要應用有點難度。實際發生的情形通常是「我有一整個模組要設計，然後這裡有個欄位/功能鍵要取名」，因而沒有辦法花太多時間在命名上。
以下分享一些採用過的方法：
1. 蒐集表單 — 看看機構現在是如何稱呼這個欄位，優點是這樣他們通常很好懂，缺點是如果每家命名不同很困擾。
2. 參考競品 — 邏輯同蒐集表單，同時可以參考競品建立整個命名體系的方式。
3. 跟從官方名稱— 與官方規範/書籍/表單採用完全一致的命名，優點是比較能夠說服大多數機構接受，缺點是官方可能取名取的很難懂（例如品質指標的約束…）。
4. 使用者測試 — 通常是內部測試（為了命名約外部測試…成本有點高），可以詢問會接觸第一線使用者的商業或客戶成功同仁，提供畫面看看他們是否能夠意會到名字指稱的內容。
資訊空間中的導覽
— 摘自第八章〈導覽體系〉
在實體空間當中，導覽指標讓人們知道自己在哪裡、協助規劃前往下一個地點的路徑 — — 在資訊空間當中，導覽系統也有同樣的作用：
- 提供脈絡的線索（Context）
告知使用者現正位於資訊空間的何處，他所處的頁面可能包含什麼樣的內容，以及周邊有哪些相似的資訊。 - 增加移動選擇的彈性（Flexibility）
讓使用者從資訊空間的這一處，快速前往空間中的其他位置。彈性越高，他所能連結到（抵達）的方向就越不受限，例如上面介紹到「跨越階層」，就是提升移動彈性的方式。
書中將導覽類型分為「內嵌式」和「附加」兩種，前者是多數資訊產品必備的導覽功能，也是我們目前的產品線中採用較多的部分，因此會比較詳細地介紹。
內嵌式導覽主要分成三種：
- 全域導覽 Global Navigation Systems
用最直（粗）觀（暴）的方式去解釋，就是網站的 Header 或 App 底部的 Tab bar。
全域導覽的目的，是讓使用者知道「這個網站有哪些內容」以及「如何前往查看其他資訊」。原則上，它會出現在網站中的所有頁面，並且通常都有「回到首頁」的連結，有的時候也會特別在導覽項目上標示「使用者所在的頁面」（非必要，也可以由下方的區域導覽處理）。 - 區域導覽 Local Navigation Systems
區域導覽的用途，是讓使用者知道「這裡是哪裡」和「這裡有什麼」。有些資訊空間會直接整合全域和區域導覽，例如點擊全域導覽的某個類別時，會展開對應的區域導覽選項。 - 內文導覽 Contextual Navigation
有些資訊與資訊之間的關聯，沒有辦法直接藉著上述兩種導覽形式串連起來，因此就有了內文導覽的出現。具體的例子像是：電商平台在單一商品頁面加入「你可能也想看看」區塊，點擊可以查看類似的商品。
內文導覽的重點不在於是否符合資訊架構，而是內容之間的連結度是否合理或足夠，才能讓使用者理解或產生興趣。
以衛福部的網站來舉例，全域導覽就是上方深灰色的部分，區域導覽則是白色方框左上角的「現在位置」，但是並沒有內文導覽的部分。
再以我們的 NIS 來舉例：
左側欄告訴使用者有哪些模組，並且讓他們在模組間進行切換，就是全域導覽；Header 和 Subheader 顯示使用者在「物理治療評估 — 簡志為」，並且告知這個頁面是「檢視物理治療收案評估」的內容，就是區域導覽；巴氏量表欄位旁的 Chip 點擊可以查看評估內容，則是內文導覽（這部分在我們的產品當中確實比較少）。
Q：除了上述舉例，Jubo 產品還有哪裡、應用了怎樣的導覽系統呢？
搜尋行為
— 摘自第九章〈搜尋體系〉
搜尋其實是導覽的一種，但因為搜尋是一個相當龐大且複雜的領域，因此書中特地將它獨立出來介紹。以下只會簡單摘錄一些設計時可以注意的部分，並不會逐一介紹建立索引、演算法背後的邏輯等等（有興趣可以去讀書）。
搜尋功能乍看也很簡單 — — 在頁面上放一個搜尋框，使用者輸入內容，系統吐出結果 — — 但就像一開始討論的資訊需求有許多種，搜尋並不能直接解決問題。
是否要採用搜尋系統，作者建議了幾個思考方向：
- 使用者在尋找的資訊是什麼？
以資訊需求的第二個例子來說，如果他們並不知道自己要找什麼，顯然也無法從搜尋功能獲益。又或者他只是想要方便地瀏覽某些特定的內容，那麼提供合適的介面和篩選功能，或許比搜尋框更有用。 - 除了搜尋，是否有其他更有效的替代方案？
使用者「感覺找不到東西」，不一定代表他就是需要搜尋的功能，有時候優化導覽系統才是真正的解方。然而假設資訊空間的內容多到難以瀏覽，那麼可能真的得提供搜尋功能，幫助使用者找到需要的內容。
以 Pinterest 來說，使用者如果只是想在上面逛逛，那麼首頁推薦的圖片，或是由圖片連結到另一個圖片的機制，就比放上搜尋框還要更重要。（當然 Pinterest 的搜尋做得很棒，讓兩者相輔相成。）
即便決定了要採用搜尋功能，仍需處理許多問題：
- 優先查全（recall）還是查準（precision）？
可以想見，搜尋結果越精準，那麼找到的東西就越少，反之，如果想要找到越多資訊，就可能有越多結果不是使用者要的。
我們需要回到根本的問題「使用者需要什麼樣的資訊？」，設想他可能需要的搜尋結果，才能決定合適的搜尋方式。例如在電商平台搜尋的時候，尋找的內容不必太過精準，但是要盡量呈現商品給使用者看。 - 搜尋結果要呈現哪些內容？
我們需要讓使用者知道他找到的東西是什麼，取決於使用者對搜尋結果的了解，需要呈現的資訊量會有一些差異。如果使用者很清楚自己要找什麼，呈現標題可能就足以讓他判斷這是不是他要的內容；反之，如果使用者並不了解搜尋的主題，那可能需要在搜尋結果置入更多細節。
假如每筆結果的內容量都較多，則可能需要控制整個搜尋找出的結果總數，否則除了搜尋效能問題，使用者的螢幕也會被偏長的內容佔滿。 - 要提供怎樣的搜尋介面？
搜尋介面並不一定只是一個搜尋框。
影響它的因素，包含前面反覆討論的「資訊需求」（他們有多積極想要尋找資訊？有多少耐心瀏覽資料？）；使用者對「搜尋」的知識（他們是否會運用 AND, OR, NOT，或是專有名詞來搜尋？）；後端資料庫處理資料的格式，能夠支援搜尋的功能到什麼樣的程度（例如非文字的資料是否能被搜到）等等。
如果使用者並不想要投入太多精力搜尋，那麼也許只要給他一個搜尋框就好 — — 他們對進階、精準的查詢方法沒有興趣；反過來說，如果使用者充滿學習的動機，我們就應該把握這個時候去教育他們，尤其是在他們搜尋中碰到挫折、希望尋求更好的方法時。
上述每一問題都足以自成一短篇，想知道詳細歡迎開書閱讀！
講了這麼多，這本書對我們有什麼用？
了解資訊架構的邏輯和方法，可以用更巨觀的角度看待我們設計的產品和功能，當自己被設計問題或使用情境困住的時候，能夠在這裡看到不同的切入點（理想上啦）。
另外說一下，這本書看似很大一本、外觀又長得很硬很難懂，但裡面的舉例和說明都很平易近人。建議對上述摘錄有興趣，或是在設計相關功能時，可以對照章節參考書籍內容。（前兩章是前言介紹，十到十三章是比較深入的應用，其他章節都適合直接閱讀。）
