在產品經理必修課：信息架構（上）中，我們詳細介紹了什么是信息架構及信息架構可以解決哪些問題。這一篇文章，我們會從信息架構組建的原則和方法來切入，與大家一同分享如何建立信息架構。

一、信息架構的組建原則

1. 對應性

產品目標與用戶需求互相對應。

一個好信息架構搭建的目的，應該是滿足用戶需要，方便用戶快速準確地找到相關信息。

例如新聞類產品，經常以時間順序組織信息架構。

因為用戶需求中，對于“新聞”的時效性的要求是唯一的重要要素。

同時，對于產品本身，只有提供最新的資訊才能在競爭中獲得優勢。

同時對于今日頭條而言，不僅在時間維度上順應用戶需求，提供最新的相關新聞。

還通過算法調整對每一個用戶進行針對性的新聞組織和推送。

有效地提高了用戶資訊的獲取率，降低了用戶挑選內容的門檻。

2. 延展性

一個好的信息架構，優秀的延展性是必不可少的。

用戶量激增，需求都做不完，如何在保持原有的APP信息架構基礎上。

對新增的需求進行設計，就十分考驗產品經理的基本功力。

如微信上【發現】功能，里面陸續出現了購物、游戲等模塊。

3. 一致性

保證用戶從多個不同的入口進入產品內部。

訪問對象都是一致的。

比如用戶從PC端訪問或者從移動端訪問，整體的架構和相關專有名詞一致。

4. 相關性

上下層級、層級中內容必須有相關性。

比如這里舉一個反例：

父級為【海外名?！?，子級中出現了【海外移民】和【海外房產】等與父級不相干的內容。

容易讓用戶變得迷茫：我訪問的對嗎？這里面會有我想要找的東西嗎？

5. 獨立性

同層級分類應該是相互獨立的。

同層級兩個分類不存在交集或包含關系。

再舉個反例：

在網站最高一級的導航欄中，【小測試】屬于【考試】的一個類別，存在包含關系，但是卻放在同一級導航中，不太合適。

6. 平衡性

如有有效地平衡信息架構的深度和寬度？

是不是信息架構越淺越容易被用戶所理解、方便用戶使用？

是不是信息架構越深越容易使用戶迷失、降低操作效率？

其實并沒有統一的答案，一切都要放在實際場景里面去考慮，以用戶體驗為中心進行設計。

寬而淺的信息架構，適合C端產品，用戶可以用較少的點擊完成相應的任務目標。

問題在于每層的“信息分類標準”太多，增加用戶每一層級的分類尋找難度。

窄而深的信息架構，適合B端產品，減少了用戶選項，專注于相關業務流程。

問題在于增加了用戶操作。

如何去平衡信息架構的寬窄深淺？還需要將用戶的使用頻次、設備的屏幕大小和產品的功能目標進行結合考慮，多練習多思考多迭代。

7.易于理解

使用用戶容易理解的語言進行信息結構拆分，如超市分區中，給貓貓狗狗的用品統一為【寵物用品】；但是采用【脊索動物用品】明顯不是在說人話。

當拿不準使用哪一個名稱進行信息架構搭建時，可以采用用戶測試來觀察用戶對分類和功能名稱表述的理解能力。

一個好的名稱應該是沒有歧義或者會造成用戶不解的。

二、信息架構的組建方法

1. 從上到下

從戰略層（產品目標）出發去考慮內容分類

1. 最先從最廣泛的、可能滿足決策目標的內容與功能開始進行分類
2. 再按邏輯細分出次級分類
3. 最后將想要的內容和功能按順序一一填入

以微信為例：

• 首先根據產品目標將“主要分類”即一級架構，分為“最近會話（微信）”、“通訊錄”、“發現”和“我”；
• 然后再進行“次級分類”分類，如“發現”下再分“朋友圈”、“掃一掃”、“搖一搖”等等；
• 最后將相應的功能（如朋友圈feeds、發朋友圈、朋友圈消息等）填入到相應的“朋友圈”分類中。

第一種，從上到下，從產品主要愿景，一步一步細分到每個功能特性。很容易理解，戰略定了一個大方向，管理層傳達并指導。執行層輸出，一步一步分解任務直到任務量清晰、執行后得到產品結果。

2.從下到上

根據“內容和功能需求的分析”而來的：

1. 先把已有的所有內容，放在最低層級分類中
2. 然后再將他們分別歸屬到較高一級的類別

這種分類方法其實就是在做“歸類”，需要設計師有一定的信息篩選、梳理、分類的能力，進一步通過用戶測試去檢驗分類的信息傳達有效性。

例如一個給中國電信客服做的ToB產品，得先了解客服人員每天工作的任務流、操作流、所需模塊集合，然后倒推規整為一個一個功能模塊，再倒推形成一個系統。

三、卡片分類法

下面要和大家分享的，就是我們在進行信息架構搭建時最為常用的一種方法。

卡片分類法：

把所有需要組織的元素寫到卡片上

然后要求測試者憑直覺把它們歸到不同的組別中

可以用于改善信息的分類標簽，分組及組織

十分廉價、便捷且高效

卡片分類法有2種：

1. 開放式分類法

在這種分類方法中，用戶按照對他們自己有意義的方式，自由把你所提供的卡片進行分組，然后他們為每個組別提出他們自己的名字。他們也具有重新命名卡片的自由，如果他們希望，也可以提出新卡片的建議。

當你想要理解用戶如何組織你的內容時，這種卡片分類方法是最好的，收集他們對組名和標簽的想法和建議對于使你的網站更直觀大有幫助。

2. 封閉式分類法

在這種分類方法中，分類標準和標簽是固定的。當你想要理解用戶如何適應內容到一個現有的結構中時，這種方法是有用的，當有新內容需要加入到網站中時也用這種方法。有時候你可以混合這兩種分類技術，在一組用戶當中執行開放式的卡片分類法，以決定高層級的分類類別，然后在另一組用戶當中執行封閉式的卡片分類，運用上一組用戶中得到的新分類類別，看看這組用戶是否很容易就能把存在的內容歸入到這些類別當中。

那么，如何開展卡片分類法呢？

主要有以下5個步驟：

（1）準備卡片

執行線下卡片分類的首要任務是準備你的卡片，創建一個文檔列出所有你要測試的條目內容，并對其進行編號——電子表格是理想的文檔方式，這些條目可以是某個站點地圖中的頁面，符合某個分類學標準的產品分類類別或者標簽。

列表中的每個條目要被分別寫在單張卡片中，卡片的背面要寫上相對應的編號，這種編號有助于你分類完成后進行高級分析。

對于卡片本身而言，使用真實的卡片而不是紙片，紙片可能會丟失，容易破損和撕裂。

再者，一次不要測試太多的事物。根據經驗，每次測試不要超過50到70個條目。

如果你正在組織一個巨大的系統，把它分成幾塊，然而每個模塊進行一次測試

選擇在卡片上寫什么是個挑戰，盡可能簡潔地總結內容才有幫助，而不是僅僅使用一個標題。

（2）在小型項目中使用

在小項目里，組織、分析結果都更簡單，并且你有機會在下次執行時做些調整。

你在早期需要作出的一項決策是進行團體測試還是個人測試，決策依據系統的復雜度，你的時間和預算多少而定。如果你剛剛開始，首先在個人測試的實踐中學習；如果需要的話，你總有機會進行大規模測試。

當你要組織大量的內容時，三個被試為一組進行測試能更快得達成共識。然而，他們需要更多的協調，花費你更多的時間和金錢。你也有可能會遇到激進的強勢的公司高層，他們會有污染結果的風險。

為了數據更有效，你所需的用戶數量應該多于典型可用性測試所需的數量。雅各布尼爾森(Jakob Nielsen)建議收集大約15個用戶的數據就能達到統計學上有用的結果。謹慎在測試中包含越來越多的用戶，因為隨著用戶的增多，返回的結果將會越來越少

（3）尋找對象

最好的結果是尋找網站的真實用戶，特別是當網站是一個小眾而專業的系統時。例如，如果你正試圖改善一個學生內網的內容組織，那么就去找學生。

對于更大眾一些的系統，例如電子商務網站，就需要找尋分布在廣泛的人口統計學指標下的被試，比如不同的年齡，不同的收入或者技術能力等。

如果可能的話，讓你的客戶區尋找用戶，客戶甚至能夠直接提供用戶。假設你正在重新設計客戶的員工內網，給被試提供一點點經濟報酬，例如禮品券，也有助于被試積極參與。

（4）匯總結果

準備工作的最后一步是準備好會議室，準備好一張大桌子或者布告牌——越大越好，你也需要在恰當的地方安置記錄工具。攝像機或者智能手機都可以，只要它能夠記錄、回放測試過程的錄音或者視頻，同時確保手邊具有足夠的飲料和點心。

一旦你準備好了卡片，用戶也到了。你就可以開始進行測試了!提供清晰的指導語。讓用戶知道測試過程將會被錄下來以供隨后回顧。向用戶解釋清楚他們只需要將卡片歸到他們認為有意義的不同組別中，無所謂對錯。如果你正執行一項開放式的卡片分類，給他們提供一些空白卡片,以供他們在分好組之后給不同的組命名。

當你在執行這個測試的時候，你要扮演一個主持人的角色；當用戶在測試過程中卡住的時候（這時候用戶很可能發出很多“呃”“啊”的詞），你要在他們身邊向他們解釋說沒關系。

事實上，知道哪里使得用戶感到困惑(卡住)是有用的。因為這表明你的卡片標準有問題。如果他們發現一些卡片很難被分類，把這些卡片放在一邊然后記錄是哪些卡片。

（5）打包記錄

一旦他們（指被試）已經盡他們所能分類好了，如果你有時間，可以隨意地問他們一些問題。你可以要求他們詳細解釋一下他們這么選擇的理由，對哪些特定的卡片的分類感到猶豫等等。

最后，記錄下他們對卡片的排列方式。最簡單的方式就是拍照。但是在一間小房間里，你很難確保所有的卡片都被拍下來，拍照不是永遠可行的方式。如果你已經對卡片進行編號，那么你就能記下哪些號碼被排列在一起。編號也有助于你做一些更詳細的統計分析，這就不是本文所要講的范圍。

一旦這些工作都做完了，在你的筆記或者照片上寫下被試的名字。為了減少任何潛在的選擇傾向， 在對下個被試測試之前重新打亂卡片。

總結

當你在建立或者補全信息架構時，千萬不要忘了建立它的7個原則：

1. 對應性
2. 延展性
3. 相關性
4. 一致性
5. 獨立性
6. 平衡性
7. 易于理解

以及靈活使用2個方法：

1. 從上到下構建
2. 從下到上構建

以及最為實用的卡片分類法。

用一句話作為結尾：

沒有信息架構的產品就如一盤散沙

風不用吹，就散了

本文由 @沙發君 原創發布于人人都是產品經理。未經許可，禁止轉載。

題圖由作者提供