導讀：樹形結構是交互設計中的基礎組件，可用清晰的層級結構來展示層級信息，便于用戶根據數據之間的關系來逐級找到相應的節點及數據。樹形結構使用較為廣泛，例如導航、空間或邏輯組織、頁面定位、級聯選擇等，其結構可展開或折疊，并根據相應的使用環境可進行相應的適應性改造。

一、定義

從更廣義的角度上來說，樹狀結構（Tree structure），又可稱為樹形結構，或稱樹狀圖，其是一種將層次結構式的構造性質，以圖象方式表現出來的方法。以樹的象征來表現出構造之間的關系，不過在圖象的呈現上，它是一個上下顛倒的樹，其根部在上方，是內容的開頭，而下方的內容稱為枝干與葉子。

在樹狀結構中的基本單位，稱為節點（Node）。節點之間的鏈接，稱為分支（branch）。節點與分支形成樹狀，結構的開端，稱為根（root），或根結點。根節點之外的節點，稱為子節點（child）。沒有鏈接到其他子節點的節點，稱為葉節點（Leaf）。

在進行介紹之前，我們先做一個小測試，如圖：

樹形結構的CheckBox應該位于折疊icon的前面，還是后面？

這里就不說明答案了，相信讀完這篇文章，你會有明確的答案。

二、結構

樹形結構是一種層次嵌套的結構。一個樹形結構的外層和內層有相似的結構， 所以，這種結構多可以遞歸的表示。樹狀結構只是一個概念，可以用許多種不同形式來展現。

相對來說，樹狀結構是一個比較復雜的交互組件，包括若干組成部分。標準的樹狀結構包括選中狀態、節點展開/折疊按鈕、單選框或復選框選擇器、類型圖標、描述文字、計數器、帶有編輯、導航或刪除等操作的附加按鈕等。設計師也可以根據需求，在樹狀結構內定制任意的組件。

樹形結構就像一個包含分層數據的列表，充當物品的容器，可以展開和折疊節點。當用戶展開節點時，樹形結構會根據當前顯示的級別數，動態更改每個級別的縮進。

由于場景不同，樹形結構所含的元素也有所差異。標準的組織樹應該包括但不限于以上元素，

根據需求，用戶可以通過基本元素組合成所需要的樹形結構。

三、應用方式

樹形結構的應用范圍很廣，常見的應用方式包括導航、定位、選擇、組織等。在不同的應用場景下，樹形結構的表現形式、所包含的元素、可用的操作都有所不同。

接下來，我們就詳細介紹一下這四種場景的應用方式及注意事項：

3.1 導航

導航是樹形結構在web端最常見的應用方式，以至于很多人都不清楚其嚴格意義上算是樹形結構，特別是包含多級導航左側導航，常見于B端產品后臺頁面和一些復雜數據的展示頁面。

如語雀的個人中心文檔列表。

該應用場景下的樹形結構只具有子節點、葉節點以及折疊標識，而且折疊標識位于節點的后方。節點的操作也比較簡單，只有選擇與折疊，較少具有刪除、拖動等其他操作。

3.2 組織

組織，常見的有行政組織、空間組織等，是樹形結構形式、功能最完整、全面的表現形式。如ERP、采購系統、財務系統中都會包含的人員管理，往往都是以組織的形式進行管理、展示。如企業微信、釘釘中，人員的部門結構。

這種場景下，樹形結構是產品的基礎核心，所有的人員權限操作都是依附于組織。在人員管理中，行政組織往往會被抽離出來，作為樹形結構，成為導航，用以對人員的管理。除此之外，還需要對組織本身的管理，包括新增、合并、刪除、導入/出、排序等。

3.3 選擇

樹形結構的選擇場景多用于下拉選擇框，可以是一個，也可以分配到多個下拉選擇中。選擇功能并不是頁面或功能層面的需要，往往是下拉選擇的選項過多，且具有相應的隸屬關系，因此對選項進行層級組織顯示，便于用戶選擇。

該場景下的樹形結構操作較為豐富，可以包括單選、多選、折疊，但不支持節點的移動、刪除、編輯操作等。這種類型的樹形結構有一個特有的名稱-treeSelect(樹選擇）。

如下圖：

在移動端中，則被稱為級聯選擇，常見的應用方式有地理位置的選擇。如圖京東、淘寶的收貨地址管理的編輯頁面。用戶在選擇地址時，需要根據地理區域的層級關系，逐步選擇到目標區域。

3.4 定位

定位，與導航的功能類似，區別在與導航實現的是頁面之間的跳轉，而定位實現的是單一頁面內的內容展示，其多用于數據頁面的展示，位于頁面右側，往往與左側導航聯動使用。

定位功能的樹形結構取決于展示頁面的數據結構，將其結構映射到定位功能的樹形結構上。

該場景下的樹形結構操作與導航類似，定位的形式根據頁面數據的結構進行展示，或單級、或多級、或展開、或折疊展示。另外，在一些產品官網的宣傳頁面，也會采用這種定位功能，雖然展現形式不同，但本質上是一致的。

如在阿里云產品介紹頁面，頂部的Tab是可以點擊，并使頁面滾動到目標區域，可以使用戶精確定位需要查看的信息，同時，減少用戶的滾動操作。

3.5 其他

除了以上提到的四種應用場景，還有兩種場景也是較為常見的樹形結構的表達形式，分別是數表格與思維導圖。

樹表格類似復合表格，樹表格多用于顯示和處理大量分層數據，具有一定的數據聚合功能，體現了高數據密度。因此，具有較為明顯的復雜性，然而應用場景和狀態較為簡單，不具有多面的操作應用。

思維導圖是基于樹狀結構的最原始的應用方式，思維導圖是一種將思維形象化的方法。從結構本身而言，這種場景較為簡單，更加注重節點的編輯、刪除等功能，可歸為組織的編輯狀態。

四、交互方式

根據不同的作用對象，樹形結構的交互方式也有所不同。樹形結構的交互方式樹形結構的交互分為兩大類，宏觀操作與微觀操作。

4.1 宏觀操作

宏觀操作，是對樹形結構本身的行為與交互，主要包括滾動、選擇、排序、搜索等。一般情況下，該類操作不會對樹形結構本身變更，往往樹形結構的不同展示形式。

宏觀操作多屬于一級操作，用戶通過宏觀操作為后續的微觀操作做鋪墊。同時，宏觀操作多屬于常規操作，用戶對這些交互方式也較為熟悉。

4.2 微觀操作

微觀操作，又可稱為二級操作，通過宏觀操作后，用戶找到相應的目標子節點，從而進行下一步操作。其主要包括有展開/折疊、選中態、導航、編輯、單擊、拖放等。

五、鍵盤操作

基于Web端的B類產品，更多的場景是鼠標操作，樹形結構也多為鼠標操作，但也應該充分考慮鍵盤操作，以滿足特殊場景下的功能實現及體驗。

基本操作應該包括：

→（右向箭頭）進入下一級節點

↑（上向箭頭）在同一級節點，向上切換同級節點，順序進入已展開一個同級子節點

↓（下向箭頭）在同一級節點，向下切換同級節點，順序進入已展開一個同級子節點

←（左向箭頭）返回上一級節點

??（回車鍵）選中子節點時，點擊回車鍵進行切換折疊與展開

上文給出的是基本操作，但設計師可以定義自己產品的鍵盤操作，但不要與用戶的認知有太大差異，否則會造成不必要的誤解

六、設計應用經驗

經過多年的B端產品設計沉淀，在樹形結構方面有一些共性的應用經驗分享。

6.1 樹形結構的橫向擴展與縱向擴展

由于樹形結構為多層嵌套形式，因此會存在橫向與縱向的擴展，橫向擴展決定了樹形結構的高度，深度則決定了樹形結構的寬度。

原則上，樹形結構的橫向擴展不受限制，而縱向擴展不應該超過四級。因為在頁面中，樹形結構區域的寬度是一定的，通常狀態下，由于層級縮進，隨著深度的增加，節點字段的顯示空間會受到擠壓，更有甚者會出現橫向滾動。過深的層級結構，一方面會增加用戶的操作成本，另一方面也會造成字段顯示不全，對用戶的識別增加負擔。

6.2 數據加載

數據加載可分為兩種加載方式：同步加載與異步加載，即同步樹與異步樹。數據加載要考慮樹形結構的整體加載與部分加載，要明確用戶當前的加載節點，加載完成后應該立即刪除加載狀態指示。

當存在大量數據或數據存在服務器時，通常采用采用異步加載，根據用戶點擊展示點擊節點的數據，可有效的減少因加載非用戶所需而產生的時間消耗，提高用的操作體驗。與此相反，可采用同步加載。

6.3 初始狀態顯示

樹狀結構的初始狀態是指加載完成后，樹形結構的折疊與展開狀態。如果樹形結構的根節點下有大量的子節點，那么折疊的初始狀態可能更加符合用戶的認知。

相反，應該讓樹形結構處于展開狀態。

6.4 錯誤警告狀態

任何操作都需要系統給與用戶反饋，無論是顯性的亦或是隱形的。同樣的，樹形結構也包含了相應的操作反饋和狀態反饋。其中，樹形結構中的子節點操作反饋狀態分為兩類。

其一，輕量型的提示應該就近的顯示在樹形結構內部，讓操作與反饋存在頁面上的關聯。部分模塊的異常狀態，并不影響其他功能的操作，因此也不必打斷用戶的操作。

其二，重量型提示如導入二次確認等，需要非模態彈窗提示，其目的在于，可以打斷用戶的操作路徑，讓用戶停下來關注提示內容，從而避免誤操作。

6.5 樹形結構的節點數量限制

為了產品的使用體驗，一般項目一次顯示最好不超過200個節點，對于較大數據結構可嘗試橫向擴展樹形結構，并采用分布加載的方式，減少用戶的等待焦慮。同時，應該確保用戶可以過濾和檢索數據。

6.6 自動排序

作為數據展示的框架時，樹形結構可以保留一定的自動排序功能，將數據以某種規則進行展示，便于用戶查看與尋找，如樹作為選擇功能時。作為某種頁面或者內容結構時，最好屏蔽自動排序功能。如作為導航使用時。

另外，還有一些需要根據應用場景，來判斷如何實現的設計細節。

例如，是否需要展示過濾結果的組織結構及過濾后的結果展示？應該如何拖拽規則及拖拽的應用范圍，是否包括組織變更？彈窗添加還是就地編輯？如何決定組織樹的批量操作……

這些都需要設計師根據業務場景的實際需求，進行定制化的考量。

七、寫在最后

從本質上說，樹形結構只是一種幫助用戶查找分層信息的工具。通過樹形結構用戶可以是快速、輕松地到達用戶想要到達的地方，也可以是打開、關閉、滾動和瀏覽。但是，不意味著僅僅因為信息是分層，樹形結構就是最佳的展示方式，設計師應該進行基于場景業務的定制化設計。

#專欄作家#

弘毅道，公眾號：體驗設計師（uxd-si），人人都是產品經理專欄作家。

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

題圖來自Unsplash，基于CC0協議