本文章是由機器翻譯。

在練習的可用性

對設計應用程式的導覽的策略

Dr. Charles Kreitzberg and Ambrose Little

內容

所認知的檢視
巡覽是一隱喻
為什麼 Get 相混淆使用者
群組到邏輯區段的多個頁面
建立一個框架
使用巡覽輔助
取得 Aways
本 「 軟體 」 檢視
複製大的 Guy
卡排序
UX 設計模式
清除的進入點
實作
控制項
測試追蹤，改變
總而言之

所認知的檢視

Dr.Charles B.Kreitzberg

取得巡覽的權限，是設計的其中一個最重要層面。在其中螢幕、 互動和視覺外觀的設計是的架構巡覽。最基本的 axiom，可用性的會是一應該讓互動軟體可能，一樣容易讓使用者專注於連線它們到軟體的工作。到程度，巡覽會造成混淆需要使用者的處理，來算出，會影響可用性。

巡覽是一隱喻

詞彙 「 導覽傳達旅行的位置。建議有您來擷取從點點和指示 (和限制) 如何取得有一個基礎架構所遵循的路徑。尚未，雖然我們談自由地巡覽之軟體產品，我們永遠不會實際上移任何位置。我們會保持在我們的互動，與回應中的螢幕變更影像時的一個位置。因此 「 導覽真的在比喻，心理的遊戲我們播放以取得我們的心智，設計解決。

當大多數的人會認為需巡覽時，它們就會著重於功能表為移動螢幕畫面，方式]。但很相當可以撰寫功能強大的程式建置單一的螢幕。例如考慮 Microsoft Word。儘管其廣泛且功能強大的功能如您在 [圖 1 中所見，幾乎整個程式是建置在單一的螢幕。

[圖 1 Deconstructing Word — 它在所有的一個螢幕 ’s

正在處理的文件是在螢幕設計的核心。從功能區中選取的工具會將其套用文件至，並變更其內容或外觀。當一項工具都需要複雜的互動時，它通常顯示在子視窗透過文件。子視窗可能是強制回應 (Modal) 中使用者必須完成之間的互動，並傳回至文件之前關閉子視窗 — 一個範例是 [插入圖片] 指令。可能是一個精靈，引導使用者透過處理序。或者，子視窗可能會強制回應類似 [同義字] 命令，在這種情況下駐一邊，它可以保持開啟時適用於文件的使用者。

簡單的優點，一個螢幕的巡覽方法會是使用者絕不會變成 disoriented。文件會保持在隨時的純文字檢視中。使用者仍需要了解哪裡可以找到工具，以及如何它們工作，但將不會取得遺失 cyberspace 中或世界奇觀，他文件發生。除了在文書處理程式中使用幾乎通用，一個螢幕的開發架構中已經使用成功類似 Microsoft 小畫家] 及 [試算表程式，如 Microsoft Excel 的圖形程式。Excel 示範藉由切換使用中文件，當使用者按一下在左下角的 [圖 2 您可以看到關聯索引標籤上維護，比喻，在單一螢幕的多個文件的強大。

[圖 2]， Excel 會同時使用單一的螢幕

沒有大量的單一畫面) 比喻的簡易性的值。但是大部分的程式建置多個螢幕 (或頁面) 的隱喻。一旦您決定在設計多個頁面周圍展示層時，您可以產生大量的混淆。觀察許多的可用性測試的結果，我已經來實現每次您執行新的頁面的使用者，您執行的 disorienting 這些風險。

為什麼 Get 相混淆使用者

當您想想看時，很不驚人 disorienting 瀏覽螢幕畫面。disorientation，表示使用者都已遺失方向。請查看 [圖 3 ] 中的兩個使用者。鮑伯會使用單一的螢幕設計程式。Sally 使用多重螢幕周圍所設計程式。

查看這個圖表，很清楚 Sally 有認知工作更加困難。不只是她沒有考慮她是，且其中她需要請但複雜的開發的內部資料表程序進一步複雜 Sally 只能一次看到一個畫面，事實。缺少資料的鳥瞰檢視的地形，需要一起一小她的心理模型，在同一時間她學習不熟悉的軟體。許多額外的工作，而它可能導致工夫學習。

[圖 3] 取得使用者混淆

站台或產品的巡覽用來框架在展示層的整個設計。如果您取得它右您將移長度的方式來增加產品的可用性。您一開始設計巡覽，請考慮下列建議：

儘可能功能單一頁面巡覽

在單一頁面的隱喻是簡單強大。將頁面的更多的功能可以提高可用性許多，提供您注意螢幕設計，讓使用者不會混淆或負荷。有關單一螢幕設計的強大是人員查看新的資訊時不會遺失內容。

Web，頻率，搜尋引擎導致使用者的內部頁面，搜尋引擎最佳化 SEO 技術和 clunky 重繪的特性 HTML 和其基本的 UI 控制項的頁面的限制的文件方向的結果已經成為通用的標準設計的作法是許多 Web 網頁的建立。有順序的好具有許多頁面，並在任何地方，放使用者的情況下，但這些是極少數]。在無償連結也就是，萬象歡喜和 World Wide Web 的瀏覽的好，但不會轉譯也以牽涉到在哪些工作流程的情況下。

要瞭解如何 disorienting 這可能是移動資料的使用者從頁面通常失敗會導致設計更多比所需的頁面。我已經有告訴我在可用性測試它們會移至尋找它們要而不是使用網站的巡覽爭用頁面的 [搜尋] 方塊中直接的使用者。

現在我們能夠使用複雜的 UI 控制項建立豐富的 Web 網頁。索引標籤、 carousels、 accordions、 工具提示和子 Windows 就會立即可，並可以減少所需的螢幕畫面導覽的量。

在設計概念，我嚴重是我可以避免螢幕畫面巡覽。一個簡單的範例將告訴您原因。[圖 4 ] 顯示典型的網頁巡覽設計。

[圖 4] 一般的網站導覽

這裡公司都有一系列的產品，會呈現為第一頁上的清單。按一下所需的產品的名稱會上產品資訊網頁使用者從其他可以返回 [產品清單或瀏覽到第三個頁面並檢視 「 擔保 」。

現在我們來看，巡覽的單一畫面版本 (請參閱 [圖 5 )。在這個版本] 索引標籤控制項會呈現三個的產品。按一下 [] 索引標籤上，會顯示在產品說明。如果使用者在 「 瑕疵責任擔保資訊 」 連結上按一下 [，強制回應 (Modal) 的快顯視窗可顯示資訊。當使用者會關閉快顯視窗時，他或她位於回初始頁面。

[圖 5 A 的單一畫面導覽模型

不用說如果您需要處理許多的選擇，所以您可能會考慮清單檢視控制項] 或 [在輪播類似一個更有趣的控制項時，也沒有縮放] 索引標籤。只要從的圖表您可以看到如何更簡單的第二個巡覽的模型。且具有優點，您可以有許多的連結，在 [產品] 索引標籤上，並啟動每個個別視窗 (或精靈)。您永遠回到您的文件，只要按一下，並它的取得相同的產品，為您帶來快顯視窗時顯示。使用者將會發現它很簡單因為它會維護的內容。使用者永遠不會離開頁面以取得詳細資料。

不用說，我所設計的產品的大部分都有多個頁面。畢竟，有可容納到單一頁面上的功能數量的限制。並謹慎使用多個頁面可以簡化 UI 的群組功能，以有意義的方式。秘訣是要瞭解每次您執行新的頁面使用者您風險遺失內容和 disorienting 的使用者，因此我使用它們謹慎地並仔細。區段頁面以正確方式的相關硬體，我想，

群組到邏輯區段的多個頁面

鄉下的 HTML 連結我巡覽的夢魘。(很實際上我的同事 Ben Shneiderman 和我協助 perpetrate HyperTies，pre-Web 超文字瀏覽器與一個夢魘 — 但另一個時間說故事) 每次使用者按一下連結，它們會傳輸至新的頁面。不小心設計，巡覽可以輕易地感覺像在樹系中遺失。

當設計多頁的產品則會想到硬碟有關您選擇要彙總到區段的頁面的方式。[圖 6 會顯示一般的巡覽設計的群組頁面到小節。

[圖 6 ： 一般的巡覽設計

主功能表將是您，索引標籤 [首頁] 頁面開始，並提供三個區段的一系列。當您輸入一個區段時，則區段的功能表可讓您瀏覽該區段中的頁面。在內容] 區域或也我已顯示 multistate 的內容控制項。第 1 節會有索引標籤控制項，而第 2 節會有的 accordion 的控制項中。

像這樣的設計可以管理大量的頁面。例如，如果您有七個主要的功能表的區段，和每個區段都有七個的頁面，而每個頁面有 multistate 內容控制項包含七個窗格，您會有效地來控制 73] 或 [343 唯一的頁面。和因為不限數量的快顯視窗可以顯示每個內容窗格，您可以管理大量的房地產 Cyber。如果您需要更多頁面時，您可以擴充功能表使用投影片出和階層式功能表。

其中您需要特別小心是在情況下，當您找到需要建立 off-] 功能表巡覽。是經常容易植物連結或按鈕，在頁面採用其他地方的使用者的內容。我看到它建立問題的次數。盡可能，請保留巡覽功能表，並使用內嵌的連結] 或 [按鈕，變更控制項的狀態或建立快顯視窗。

巡覽 [圖 6 ] 所示的模型會有一個隱含的階層架構。您可以清楚地看到，如果您圖表的路徑。

從 [圖 7 ] 中的圖表，您可以看到水平的巡覽從區段的區段] 和 [巡覽的區段內。有需要解決的幾個問題。

[圖 7] 區段之間的巡覽

1. 當您巡覽 section 區段，您降落？這取決於您嘗試要達成的流程。在大部分的情況下最令人混淆的選項是降落區段 (例如，頁 A 在圖表中) 的第一頁上的使用者在第一次造訪的工作階段。您可以設計該頁面到區段 (亦即一節 「 首頁 」 頁面) 的 entryway 為。然後我想保留 [資訊看板] 功能表的狀態，如果使用者離開區段，並傳回，他或她會在相同頁面上。
2. 如果您需要取得從 (例如) 頁面 B，至頁面 G 嗎？

請小心真的因為如果您中斷巡覽模型您會得到混淆使用者。要求第一個問題是，您需要進行兩個內部頁面之間 「 跳躍點原因。如果使用者需要取得兩個區段，以完成工作，設計就可能需要調整。分割為兩個內部頁面之間的工作時，是拙劣 」 和 「 沒有效率。

我最近遇到這同時為的資料檔] 及 [記錄檔所寫入的檔案傳輸程式。因為我已在環境中，對應的磁碟代號變更每日結果中插入的 USB 磁碟機，我需要重設磁碟字母，每次我使用的程式。我有，移至 「 區段 A 」 設定資料檔案的位置和 」 區段 B 」 設定記錄檔的位置。是很方便且費時。

解決方案在像這樣的情況是將單一頁面上的所有磁碟的資訊，或如果這無法完成顯示 「 陰影複製 」 的第二個磁碟在快顯視窗 (Pop-Up Window) 中，讓使用者可以在不需要巡覽至第二個頁面中它填滿。

如果它就便利性的問題，您必須決定如果加入的複雜度是值得按一下 [您要儲存使用者。使用者必須進行移位頻率而定。如果是偶發性請要進入使用簡單的巡覽，然後額外的滑鼠按一下。如果是經常我想請考慮使用水平功能表列中的一個拉式功能表的頁面，以便使用者可以取得的內部頁面以一個步驟。我無法認為的情況下，在其中我想只傳輸到另一個使用者一個內部頁面。好的星形 Trek 的運作但會相當 disorienting 在軟體中。

建立一個框架

我要專注於最後一個區域會是在視覺化設計可以支援簡化巡覽的方式。首先，考慮您要在頁面框架哪些的項目 — 顯示一致地在頁面的元素。要讓使用者導向，最好的方法是要在可預測的位置有一致的元素。這些會成為 Visual 錨點，使用者。

大多數的框架的重要項目將是您，在頁面標題。這說明關聯名稱的頁面的使用者不僅它協助與支援人員的討論區。

請考慮色彩編碼以及。在先前的範例我使用色彩首頁區段區段 1 的綠色的程式碼，以淺藍色和橙色區段 2。這些色彩會說明使用者瞭解他或她位於哪個區段。我也會在視覺設計使用圖形和紋理支援 color-Blind 的使用者。

使用巡覽輔助

兩個常見的巡覽輔助，值得包括會是提示路徑] 和 [網站導覽。只是不要依賴它們解決設計問題。許多使用者不要請參魷 \ cs6 \ f1 \ cf6 \ lang1024 或瞭解提示路徑。但是對於那些人進行，是一個很有用的功能。使用性大師 Jakob Nielsen 的網站上 useit.com，他筆記更多和多個使用者會依賴提示路徑。提示路徑應該會反映在巡覽階層架構，不是頁面的歷程記錄查閱，他也會讓的點 (與我完全同意)。

網站導覽，可以協助使用者取得的巡覽的版面配置，但很少使用]。但是，它們應該包含，因為它們會說明取得所需的鳥眼檢視]，巡覽的使用者。只是不要希望他們補償的設計問題。

其中一個實用性社群的獨立笑話是每個使用性問題有相同的答案： 「 它相依 」。 不，也是以及巡覽。一些設計的規則 ； 大部分是指導方針] 和 [啟發學習法。這就是為什麼很如此重要研究使用者，並在瞭解使用之前先設計 UI 的內容。

記住，警告，與以下是一些建議的最佳作法：

1. 最小化所需瞭解，並決定巡覽選項，努力。它需要使用 UI，較佳的可用性，較少的工作。
2. 進行時，您可以使用單一螢幕設計。使用豐富、 多窗格控制項的快顯視窗及精靈啟用使用者執行工作的盡而不致訴諸 sideways 巡覽。
3. 在同一當您建立多個頁面，它們中合併區段。使其易於跳與主要的巡覽控制項的區段區段使用第二個控制項在區段中巡覽。不嘗試移更深層，如果您可以避免它。巡覽，更簡單、 多使用者快速地將達到熟練度。
4. 請確定索引鍵項目，例如功能表、 [標題和 [所有頁面顯示的其他資訊會從視覺的觀點來看一致地呈現。使用者應該會有在螢幕的某些項目會穩定，而且能夠使用它們來維護方向的意義。
5. 要非常小心使用傳輸至另一個內部頁面來自一個區段的 [內部] 頁面的使用者的巡覽項目。可以來完成但容易 disorient 使用者。
6. 使用提示路徑和網站導覽的次要巡覽輔助工具，但不要依賴它們]。
7. 7.always 考慮未來的擴充。如果您希望在未來加入新的功能，在 [開始] 中決定產品如何您將會展開巡覽完美地將新的畫面。

取得巡覽的權限，是產品的其中一個您可以執行以確保您的可用性，在最重要的工作。花時間取得權限，請確認您的設計與可用性測試，]，並您將會取得您要的結果。

本 「 軟體 」 檢視

Ambrose Little

巡覽種大多數的軟體人授與，需要的和，大部分的設計問題我們通常只查看哪些其他人正在進行依照其領導人的問題。從管理員得到 imperatives — 「 執行它看起來像 Office 「 或 」 讓它看起來像 Amazon.com"—but 我認為開發人員著重於使程式工作，我們沒有備用真的想設計許多時間。

有些我們是幸運，能夠實際資訊架構設計人員使用我們 (或其他 jack-of-all-trades UX 的人)。但有時候我們長期圖形設計工具，來處理巡覽，作為其設計，即使許多它們沒有在專業知識或背景。謝天謝地，有許多好資源有解決的巡覽，自黏問題，而且我想要在少數這裡觸控。

複製大的 Guy

先，很不一定要遵循產業) 族長幹嘛不正確。還有好的機會，它們有實際上花費許多時間和資訊架構，以取得它向右，並因此的哪些人有來預期中設定 [，音上的資源。在的觀念中它們建立慣例，並設定標準，因此改變方式軟體相關的期望應該會運作。

換句話說，out，Charlie 的點確實瞭解使用您的方案和您正在處理之項目的使用者更最好是。這些項目會在您的網域中包含資訊和網站或物件的內容。核心部分瞭解人員瞭解其與您的解決方案進行互動的目標，如果您取得該權限，它將移長度的方式，向協助您正確結構您的應用程式。

您可以從大的傢伙許多學習，但不要盲目地遵循因為其使用者可能不同。可能必須為更小的使用者或可能您的內容或產品以同樣太不同。其中一項這項差異的最佳範例我看過是嘗試模仿 Microsoft Office 功能區 (請參閱 [圖 8 )。

[圖 8 Microsoft Word 的功能區 (第部，共 Office Fluent UI)

為最新的在 Office UI 的配置的行，功能區會由許多開發人員會模仿。問題是在功能區似乎不正確的巡覽設計的放大。如果您不執行標準功能表、 索引標籤和其他控制項，您可以取得立即以錯誤的巡覽的設計但如果弄亂功能區時，您就會中斷，比喻。

索引標籤應該根據使用者的目標和工作。因此，還有索引標籤的 [插入項目] 頁面配置] 索引標籤的 [的檢閱文件的資料] 索引標籤。然後，在索引標籤，有的指令是一次著重和群組的使用者 (例如剪貼簿] 和 [圖 8 中的字型) 群組的相關的工作和動作。功能區會使用各種不同的大小，根據使用的資料 (與較小的剪下和複製大貼上圖示)，以協助的人員更輕鬆地發現，和使用常見的函式的按鈕。

簡，許多工作需要設計有效的功能區的樣式項目。因此，您應該不會調整它盲目地巡覽機制的應用程式。

所以，之前您模擬其他的應用程式先您必須決定其設計是否會在您的情況下的意義。您有相同的小數點位數嗎？(Amazon.com 和 Netflix 請使用建議根據大量會獲得正確的縮放好一點的使用者資料)。 辦公室有噸的受益於多層次的組織的功能區的命令但如果您只有少數的命令，一般功能表可能更好。

您有相同類型的內容嗎？什麼是適用類似 Amazon 可能無法正確的選擇在環境的資訊網站的電子商務網站。所適用的資訊的網站可能無法運作的應用程式。如同 Charlie，時人嘗試要完成一項工作，非正式的巡覽模型一般 Web 上可能不會是適當 — 您要協助達到其目標、 不扭曲或導致其向下兔子洞的人。

因此，不會，讓您？不要絕望 ！甚至，如果您不需要 UX 專家諮詢，有您可以採用，讓您巡覽更好的技術。這種技巧稱為卡排序。

卡排序

卡排序是最好是將人員，獲得您參與協助您組織您的內容 ( 見 [圖 9 顯示的範例) 的目標觀眾為方法。它但有些相同之處其他利害關係者的 [參與] 技術如類別負責共同作業 (CRC) 卡 (一個物件導向的設計或 OOD，技術) 使用者的新聞和的類似，它會仰賴，利害關係者積極地參與解決方案的設計 (和它使用的卡)。通常，它用於組織在的網站上的資訊，但技術可以用來協助組織在應用程式內的命令。

[圖 9 範例的卡排序從 Usability.gov/ design/cardsort.html

它會是一個使用者置中，而解決方案置中 (或網域-置中) 的方法，並且因此有助於發現設計，實際上互動與解決方案的人可有意義。我不會進入深度上實際的技術。suffice 就到，它會涉及分類您的資料，您的使用者。有許多資源免費線上 (例如：usability.gov/design/cardsort.html)，而且事實上有許多軟體套件，以協助它，例如 OptimalSort。但是，使用軟體之前，請考慮索引卡方法。專家會同意同時取得真實的人，在] 和 [使用實際的卡通常會產生良好的結果。

UX 設計模式

可能其中一個最佳的資源，在 UX 設計會是模式。是有大量的巡覽，從提示路徑都可協助使用者熟悉本身，搜尋結果中使用 Facet (中繼資料)，來主動篩選，它們，dives 到熟悉強制回應 (Modal) 對話方塊的強制回應 (Modal) 台] 的 Faceted 巡覽的設計模式和很多東西之間沒有驚喜。例如， [圖 10] 會說明清除進入點模式的範例。

清除的進入點

它不可為明顯哪些人可以或應該執行時啟動的應用程式，或造訪網站。您需要給予人員一組清楚的進入點，到應用程式或根據其最常見的工作或目的地的網站。

[圖 10 清除的項目點主要的範例

清除的項目點，沒有新的或不常進行的使用者可以覺得開啟的應用程式或網站時，立即中斷。藉由引導清除的進入點的人士，您可以想出什麼他們可以或應該執行關閉的負擔。

這個模式運作，如果您或可以找到一組最常見的工作或您的目標使用者的大型區段的目的地。會如果您無法這麼做，模式實際上導致更多的問題，因為方式取得並真的不他們希望指南的人。

很重要您的使用者的大部分是新的或不常進行的使用者，因為，除非工作有問題之只相關的工作、 一般使用者可能會清除進入點，尋找取得的方式。

不要被 deceived 到想很明顯地的人應該做。許多首頁頁面的所有項目背後的組織所提供的在 smorgasbord 並人都是混淆的左邊] 和 [不知道該怎麼辦，或從何處。清除的進入點會排除在混淆。

實作

這一輪清除的項目點模式是成功地識別目的地的頂端的工作。如果您採用以使用者為中心設計，您應該有已經識別這些做為位址的主要目標為您的使用者的工作。您可以使用該資訊來設計您的清除的進入點。

如果您沒有遵循以使用者為中心設計，您只需要一些 [參考資料] 可能同時在內部與外部，判斷使用者的主要工作和目的地。如果您的應用程式或網站已經存在，查看使用記錄檔是絕佳的說明。您通常也可以產生金鑰的工作，甚至是來自功能規格，但您應該會嘗試驗證使用者，或在至少業務利害關係者，確保您所選取的工作列使用金鑰的應用程式或網站的目標。

一旦您已關閉您的主要工作中做到，您應該考慮如何它們需要呈現。如果您有個以上的少數，應考慮如何您可能以視覺化方式，群組方式，但記住這不應該是您主要的巡覽的複本 — 它真的必須代表金鑰的工作。

顯示工作非常清楚] 和 [集中式應用程式或網站的 [開始] 檢視上。務必片語這些工作的使用者會嘗試完成，而非使用品牌的術語，像是工具的名稱或其他使用者不熟悉的術語。如果您可以通訊，是最理想的幾的文字工作，但您可能應該補充有用的描述，使其 abundantly 名稱則會清除人可以完成藉由選擇的工作或目的端。

請確定您不會建立設陷門透過突然中斷使用者至您的方案結構的中間。到達藉由選擇工作的目的地應該清楚地連接到工作 ； 這是一個好的開始，到一個的精靈，但它不必要精靈式 — 只進行 [強式連線之間選取的工作]，[藉由選取工作抵達的檢視使用者。

如果人可跳直接的子任務，您可以考慮有選取主要的工作時要顯示的。但請記住這不應該是完整的功能表或巡覽配置。

這是很好的習慣透過較不常見的自動繪圖這些使用者，以視覺化方式強調最常見的工作。這個主要進入點的檢視不應該以一般的巡覽結構或輔助工具] 資訊會括住。隱藏這些以使焦點進入點。

如果認為相關您會看到控制項通常只是 formalized 成可重複使用的程式碼的模式實作。如果您已嘗試執行任何 Silverlight 程式開發特別是 Silverlight 1.0 (或 heavy-duty 桌上型電腦的 UI 開發) 您可能已經來到控制項為您執行工作的一個更瞭解。手動繪製，並甚至文字方塊的基本互動的處理是不正確的簡單。

再加上，控制項，特別是例如，HTML 規格的平台控制項會建立隱含的標準 UI 模式慣例。有多個選取範圍，許多其他選項，但在 SELECT HTML 控制項已經成為該工作 Web 上的之 de facto 控制項]。與豐富的網際網路的應用程式 (RIA) 平台選擇大於，但不一定方塊中提供控制項將最後表單 (這會的不用說受到之前的平台控制項使用) 的慣例。您可以使用自訂控制項，實作的許多更複雜的和通常很有用模式，或您就可以利用從其中一個，例如 Infragistics 協力廠商控制項。

巡覽的不用說控制最常見項是 Charlie 指出時，需要使用好好和更謹慎地在以工作為導向的應用程式的超連結。有幫助類似的項目，將的群組之間的隱含的方式來表示使用者查看 (透過 [目前的選取] 索引標籤中) 的東西的巡覽的群組] 索引標籤控制項。有 Web 和桌面平台上上的即時-出功能表控制項： 如果這些使用小心到不超過三層 (最好是兩)，因為花了好一點 (如使用者嘗試迫切快速地將側邊從一個功能表移到其他) 來使用它們的滑鼠敏捷度，這可能是為一個意外 techies Live 的使用者和 breathe 功能表。有標籤定域機組的控制項協助該模式的實作，分頁控制項以該的模式協助這些，] 和 [等的對話方塊控制項的 [說明]。

tagging 和標記定域機組種好建立有彈性的組織，協助您尋找他們要尋找人員。它們可以補充更正式的組織配置，例如功能表。[圖 11 ] 顯示範例。

[圖 11] 從 Flickr 的標籤雲霧

請記住，考慮您選擇控制項 (模式) 的相關。不要只使用它因為它是最簡單方法或因為您是最熟悉它。請參閱以取得在更瞭解使用哪一個的模式和您可以也使用模式來引導您選擇的實作的 (如果有的話) 以選取目錄模式。

測試追蹤，改變

無論您設計哪些巡覽及組織配置，它會錯誤 — 至少一部份。即使它是正確的很可能您的需求將會隨時間變更了。因此，您需要投資在 Charlie 說過，讓具有可調整的巡覽的設計以及一個彈性。

不想要定期對您的巡覽結構進行大幅的變更，但您應該調整它們根據實際使用的資料和可用性測試。可用性測試一個不錯的選擇因為您可以發行應用程式前追蹤問題 ； 只是請務必保留空間，在專案排程執行，並根據結果的變更。

如果您使用資料 (例如，從 Web 的記錄檔] 或 [追蹤的功能的使用方式) 使用它來瞭解人如何使用現有的設計中，並據此進行變更。搜尋記錄檔是特別是資訊性的因為它們可以表示在您的巡覽配置的弱點，作為使用者的方法，來搜尋巡覽。如果不使用 Web 架構追蹤請考慮建立一個使用追蹤基礎結構，這樣您就會有資料備份，並通知未來的修改。

建立好的巡覽可以似乎有點龐大，當您有許多其他的開發人員擔心。如果您沒有專家在您的處置，您可以採取問題到下列一些我們所此處所述的建議您自己手中。

巡覽是非常重要，； 它是值得時間和您將會投入的資源]。您可以它以累加方式進行的動作的模式，協助，而且您還是可以使用像 Steve 庫格族的不讓我想好，要容易讀取 primers] 和 [Peter Morville 環境 Findability，等等。必須使用您的軟體的使用者將會為它 happier。

Dr.Charles Kreitzberg是 Cognetics Corporation 的 CEO (www.cognetics.com) 的提供可用性諮詢] 和 [使用者經驗的設計服務。他的熱情，建立與 delight 時支援產品的業務目標的使用者的直覺式介面。Charles 都住在中央紐澤西他 moonlights 為執行的音樂家。

Ambrose Little 存在中央紐澤西的四個的子系與他的妻子。他的已設計和開發軟體達 10 年以上且接受的 INETA 演說和 Microsoft MVP。最近，他的人設計的移到從技術的設計，並已在使用者經驗的 Infragistics 設計工具。