嚮導

儘管這個奇妙、異想天開的名字，但精靈並不是一種特殊的使用者介面形式，而且他們只有一系列特定的公用程式。

精靈可用來執行多步驟工作。

新增印表機精靈的

精靈的多個步驟會顯示為一連串的頁面。

精靈通常包含下列類型的頁面：

• 選擇頁面可用來收集資訊，並允許使用者做出選擇。
• [認可] 頁面是用來執行無法復原的動作，方法是按兩下 [上一步] 或 [取消]。
• [進度] 頁面是用來顯示冗長作業的進度。

新式精靈設計會提高效率，讓進度頁面選擇較短的作業，並經常免除傳統 歡迎頁面，並在開頭和結尾 恭喜頁面。

所有精靈頁面都有下列元件：

• 用來識別精靈名稱的標題列，左上角有 [上一頁] 按鈕，以及選擇性 [最小化/最大化] 和 [還原] 按鈕的 [關閉] 按鈕。 請注意，標題列也包含圖示，以在任務欄上識別它。
• 使用頁面說明用戶目標的主要指示。
• 具有選擇性文字和可能其他控件的內容區域。
• 至少有一個認可按鈕要認可至工作的命令區域，或繼續進行下一個步驟。

雖然精靈有多個步驟，但這些步驟必須全部加到單一工作，從用戶的觀點來看。 這是「一個精靈，一項任務」的基本精靈設計原則。

因此在本文中，工作是精靈的基本功能（例如，安裝精靈的工作是安裝程式）。 子工作是較大工作的層面（例如，安裝精靈的子工作可能是設定要安裝的程式）。 最後，每個精靈頁面都會被視為指定子工作或工作中的步驟（例如，設定程式時可能涉及兩或三個步驟）。

附注： 與 設定、對話框和 進度列 相關的指導方針會顯示在個別文章中。

這是正確的使用者介面嗎？

精靈可用於任何需要多個輸入步驟的工作。 不過，有效的精靈有其他需求：

• 精靈是否執行單一不可部分完成的工作？ 請勿使用不是單一工作的互動（除非整個程序執行單一工作，否則絕對不應該是精靈）。 請勿使用精靈來合併獨立工作或基本上無關的步驟。

• 可以減少所需的問題數目嗎？ 在大部分情況下，是否有可接受的預設值適用於大部分情況，或稍後可以視需要進行調整？ 因此，可以減少頁數嗎？ 如果是，請嘗試簡化工作，使其可以在單一頁面上呈現（例如對話框），或完全消除輸入的需求（允許直接執行工作）。

• 必須循序提供必要問題嗎？ 是否有數個可能但選擇性的問題？ 如果是，請考慮對話框或索引卷標式對話方塊。

  正確：

  

  [Microsoft PowerPoint 列印選項] 對話框包含許多使用者輸入選項，因此您可以在精靈中呈現它們。 不過，不需要循序提供它們，因此對話框是較佳的選擇。

精靈是一種相對繁重的使用者介面形式;如果有合適的較輕量解決方案可供使用，請使用！

設計概念

過度使用精靈

從歷史上看，精靈與一般UI不同，因為它們的設計目的是協助使用者執行特別複雜的工作（步驟位於不同位置），而且通常會有內建的智慧來協助使用者成功。 目前，所有UI都應該設計成盡可能簡化工作，因此不需要特殊UI僅供此目的使用。

然而，相信精靈是一個特殊的UI，主要是因為它們被稱為「巫師」（比說，“對話”和“屬性視窗”更有創意）。 相反地，最好將它們視為多步驟工作，而不是特別注意這一事實。

建立精靈之前，請考慮使用者是否真的必須從程式的主要流程中斷。 可能有較輕、內嵌、內容相關的解決方案，最終會讓用戶感覺更有説明且更有效率。 例如，程式中設計錯誤的功能並不需要精靈來解釋和簡化它;它需要重新設計功能本身。 精靈不應該當做帶式輔助來修正程式更基本的問題。

精靈確實具有適當的功能

精靈是簡化用戶體驗的其中一個金鑰。 它們可讓您進行複雜的作業，例如程式設定，並將其分成一系列簡單的步驟。 在程式中的每個時間點，您可以提供所需內容的說明，並顯示可讓使用者進行選取並輸入文字的控制件。

某些類型的多步驟工作適合精靈窗體。 例如，在 Windows 中，數個精靈牽涉到連線功能（因特網或公司網路，或列印機和傳真機等周邊裝置）。

線上精靈的

聯機到網路是適用於精靈之 Windows 中的一般工作。

在這裡，精靈的功能是調解已知和穩定（現成的作系統）和未知和可變的東西（與電話公司或因特網服務提供者的連線安排）。 運算生態系統的複雜性已經足夠重要，現在使用精靈來減少複雜性確實很有説明。

適用於 Windows 精靈的其他工作類型包括高端功能（例如語音和手寫辨識）和多媒體體驗（例如設定製作和發佈電影的選項）。 您也可以針對更基本的多步驟工作部署精靈，例如疑難解答。 簡言之，如果不同的使用者可能想要以廣泛不同的方式體驗您的程式，這表示需要精靈及其多個使用者輸入點的容量。

對於您的程式而言，判斷精靈正在服務的函式，以及該函式是否真的上升到部署精靈的層級，值得一點設計時間。

精靈長度

設計問題自然會圍繞頁面和選項的數目和組織而產生。 例如：

• 精靈有最佳的頁面數目嗎？ 還是至少一個理想的範圍？
• 精靈應該簡潔且簡化，讓使用者可以儘快完成？
• 應該有更多的頁面需要較少的選擇？ 或較少具有複雜度的頁面？ 哪個設計被視為更容易使用？
• 您可以藉由套用索引標籤頁面等 UI 慣例來設計更快速的精靈體驗嗎？

Microsoft用來建議三頁以下的精靈設計為簡單精靈，而四個以上頁面的精靈則使用進階精靈設計（請參閱 1999 年 Windows 用戶體驗 指導方針）。 但目前的精靈設計標準免除了簡單和進階表單（歡迎和恭喜頁面的使用）之間主要差異之一，因此這些類別現在感覺不足，決定設計選擇的頁面數目似乎是任意的。

您的精靈應該只要工作需要那麼長或短;其長度沒有固定的指導方針。 單頁精靈應該真的會顯示為對話框，因此兩頁可能是精靈最精簡的窗體。

正確：

此工作有如此少的選項，將它呈現為精靈會浪費。 對話框是這個使用者介面的適當表單。

在光譜的另一端，如果您有一個包含多個決策點和分支的精靈，而且經常導致使用者失去其瀏覽路徑的追蹤，您就已超過實際限制，而且應該減少精靈的長度。 或者，您可以將精靈分成數個不同的工作。

當您判斷精靈最適當的長度時，請特別注意您的目標使用者。 家庭消費者和辦公室工作人員等終端使用者的程式通常會使用精靈來隱藏複雜性：精靈越短越短，而且盡可能簡單、簡單的頁面設計，以及盡可能多的選項預先選取的預設值。 相較之下，適用於IT專業人員的伺服器精靈或程式往往較長且更複雜。 這個目標使用者群組對於進行設定決策的容忍度要高得多，而且如果隱藏太多複雜度，實際上可能會變得可疑。

如果精靈本質上簡化了複雜的工作，它應該對技術上複雜的對象執行相對最少的工作，而且對於新手使用者群而言，應該相對積極。

正確：

顯示語言精靈

此精靈頁面是專為終端用戶設計的，因為它可減少可能複雜的簡單邏輯二進位選擇：安裝或卸載。

正確：

在Microsoft SQL Server 2008 的安裝精靈中，頁面設計更忙碌，而且許多選擇需要更多思考，但目標對像是預期嚴格控制功能選取的資料庫管理員。

最後，請注意特定工作的執行頻率。 不常的工作可能會部署較長的精靈，而頻繁的工作絕對應該偏好簡潔。

分支

針對較長的精靈，您可能需要建立工作流程的分支，其中頁面順序可能會根據提供的「上游」用戶輸入而有所不同。分支原本就是針對使用者解除分配，因此您必須設計用戶體驗來傳達穩定性。 建議您不要超過兩個決策點，這會導致整個精靈中的分支，而且在單一分支內沒有一個以上的巢狀分支。

如需在分支精靈中建立穩定用戶體驗的指導方針，請參閱本文的一節中的 分支。

提供導覽指南

當工作中有許多步驟，且使用者可能會失去順序中的位置，或只是想要知道完成所需的時間，流覽指南會很有用。

導覽指南通常會顯示為精靈的頁面或區段清單，看起來有點像目錄，在每個頁面左側的欄或窗格中。 雖然清單會在整個精靈中保存（每個頁面上都會出現相同的頁面清單），但有一些視覺方式指出使用者目前處於序列的位置（例如，使用粗體來區分使用中頁面或區段）。

導覽指南可以是循序或非循序。 循序類型會呈現過去的頁面以及已知的未來頁面。 如果步驟為已知，而且頁面相依，則可以在步驟方面呈現未來，而不是頁面。 然後，您可以動態填入頁面，因為它們變成已知。 因為導覽順序已修正，因此導覽指南不是互動式的。

非循序導覽指南是互動式的，因此使用者可以直接重新流覽先前檢視的頁面。 您也可以在設計為選擇性的頁面瀏覽順序之前略過。 選擇性頁面在大部分情況下都必須有可接受的預設值。 使用這種類型的指南：

• 先前檢視的頁面一律可以直接檢視。
• 如果未來頁面具有必要條件，可能無法檢視這些頁面。
• 可以瀏覽的頁面應該明顯區別於無法使用或停用的連結，以及必要或選擇性的頁面。

在此案例中，使用者可能會對 [上一頁] 按鈕的意義感到困惑。 按兩下 [上一頁] 是否會引導您前往導覽指南中的上一頁或區段，或檢視的最後一頁或區段？ 因為 Windows 精靈現在會將 [上一頁] 按鈕放在精靈頁面的左上角，而不是使用其他認可按鈕在右下角，所以用戶會考慮 [上一頁] 功能，就像他們在網络上所做的一樣。 因此，最佳解決方案是為您的 [上一頁] 按鈕提供 Web 瀏覽意義（按兩下[上一頁] 應該會導致最後一頁或檢視區段），並使用精靈導覽指南進行循序流覽。

頁面完整性

精靈設計不僅牽涉到整個工作流程的相關決策，例如如何處理導覽和分支體驗，也涉及組成精靈的個別頁面。 設計良好精靈頁面最重要的原則是完整性：頁面的內容應該屬於一起。

如果每個頁面在概念上掛在一起，處理整體工作的一個層面，則精靈頁面會明顯更容易使用。 主要指令 是達成此目標的主要方法。 清楚識別頁面的目標或用途給使用者。 補充指令，以及頁面上的任何控件，都直接與主要指令有關。 雖然精靈頁面應該向用戶顯示需要某些想法的選項，但該工作並不像工作，因為頁面本身的完整性會緊密聚焦。

不幸的是，精靈設計工具通常會誤認為使用者快速按兩下一步， 按鈕，以證明其頁面的可用性、簡單性和完整性。 最終精靈體驗不是 Next、Next、Next、Next、Finish。 雖然這樣的體驗表明默認選擇良好，但也建議精靈並非真的必要，因為所有選擇都是選擇性的。

在視覺效果和文字方面，將這些元素剖析為裸機的基本概念。 抵制在單一頁面上組合多個子工作的衝動（“burrito 精靈”），或求助於索引卷標來呈現複雜的輸入需求。 單一頁面應該涵蓋精靈整體工作的單一子工作。

不正確：

sql server 安裝精靈

由於需要三個相當密集的使用者輸入索引標籤，此精靈頁面正嘗試完成太多作業。

在大部分情況下，在整個精靈中維護每個頁面的大小，以培養一致的外觀和風格。 雖然 Windows 精靈允許可重設大小的頁面，讓頁面的大小符合內容量，但只有少數會使用此選項。

最後，透過序列維護每個精靈頁面的結構元素。 例如，請勿將 [上一頁] 按鈕從左上角向下移至頁面或兩個的認可按鈕區域。 此版面配置一致性層級可協助使用者在精靈中感到穩定。 將此視為頁面視覺完整性的基準。

尋找正確的通訊層級

用戶在螢幕上閱讀大量文字的容錯度較低，而且在UI介面中，其明確用途是快速移動工作。

精靈有過度溝通的傾向。 他們在螢幕上佔用了很多空間，這似乎鼓勵一個驅動器來填補空間。 這就像帕金森法的變化：UI 文字會展開以填滿可用的空間。

這種多餘的一個罪魁禍首是備援。 由於早期精靈設計中使用的範本，相同語言可能會出現在頁面上的多個位置，例如標題列、標題、本文、控件標籤等等。

值得聘請專業編輯來無情地修剪您的精靈文字。 排除個別頁面上不必要的問題和選項，並排除整個精靈中的整個頁面（例如傳統的歡迎和恭喜頁面）。 使用目標對象用來描述工作的語言，而不是您或小組在內部使用的技術或功能術語，以簡潔撰寫的主要指示，直接前往頁面的點。 這個以使用者為中心的方法對於改善程序精靈的通訊至關重要。

特別注意您精靈的語氣：有時您程式最持久的印象不是你說什麼的結果，而是你怎麼說的！ 在精靈中，當使用者要求輸入時，使用者會熟悉友好的交談語氣，並自由使用第二人稱詞（“you”）。 如需詳細資訊，請參閱 Style 和 Tone。

減少精靈頁面上的字數通常值得稱讚，但請小心不要太遠。 如果工作很重要，而且需要精靈，用戶確實很欣賞有足夠的資訊來做出明智的選擇。 下列範例示範如何壓縮精靈文字而不犧牲意義。

之前：

之後：

此精靈頁面的編輯版本提供工作導向的主要指令、移除主要指令下方不必要的說明段落，並修訂複選框標籤，以釐清複選框的目的。

如果您只做三件事...

1. 使用適當的UI對應您嘗試完成的工作，以執行作業;當您認為需要從使用者收集大量輸入時，不要只預設為精靈。

2. 仔細思考精靈的長度和結構;偏好簡短的非分支精靈，讓體驗盡可能簡單，讓使用者可以回到其主要工作或對程式感興趣。

3. 請確定精靈中每個頁面的完整性：頁面的內容應該清楚地屬於一起。

指引

常規

• 請先考慮輕量型替代專案，例如對話框、工作窗格或單一頁面。 您不需要使用精靈，您可以在任何UI中提供有用的信息和協助。

• 針對多步驟工作使用精靈。 針對具有意見反應的單一步驟工作使用多頁對話方塊。 如需詳細資訊，請參閱 對話框。

  正確：

  

  

  在此範例中，Windows 網路診斷是由進度和結果頁面所組成。 由於工作只是單一步驟，因此不需要使用者在精靈中所需的導覽按鈕。 它實際上會顯示為多頁對話方塊。

視窗大小

• 選擇視窗大小，以顯示所有精靈頁面，而不需要垂直或水平頁面捲動。 雖然頁面上的控件可能需要捲動，但精靈頁面本身絕不能。

• 大小視窗夠大，足以舒適地執行其工作。 版面配置不應該很擁擠，也不應該要求使用者過度捲動或重設大小。

• 但是不要讓窗戶太大。 較大的視窗會使工作感覺更複雜，而且需要額外的動作才能互動。

• 針對可從更多螢幕空間獲益但不需要螢幕空間的精靈，請使用可重設大小的視窗。 指派適當的最小大小。 當頁面需要與可重設大小的內容互動，例如大型清單檢視時，可重設大小的視窗會很有説明。

  正確：

  

  更好：

  

  在此範例中，調整視窗大小可協助使用者查看完整清單。

• 請考慮使用動態大小的精靈，其頁面大小會視需要變更其內容。 這樣做可讓精靈容納具有各種內容的頁面版面配置。

• 如果使用者可能認為變更在精靈的體驗中缺乏穩定性，偏好使用靜態重設大小而不是動態。 視覺穩定性通常勝過內容的住宿。 大部分的精靈都應該採用標準、靜態視窗大小，並針對特殊案例保留動態重設大小。

精靈長度

• 讓您的精靈盡可能簡潔且簡化。 拿掉不必要的選項和問題，並使用智慧型預設值來減少使用者輸入所需的頁面數目。
  • 例外狀況： IT 專業人員和其他技術用戶對於較長的精靈和詳細的輸入需求具有較高的容忍度。
• 將您的精靈設為至少兩頁。 改為將單頁精靈重新設計為對話框。
• 只要增加每個頁面的複雜度，就不要減少精靈的頁面計數。 例如，包含三個需要使用者輸入的索引標籤的精靈頁面，應該重新設計為三個不同的頁面。
• 不要藉由讓每個頁面如此簡單，讓使用者不經心地按 [下一步]，以增加精靈的頁面計數。 這是常見的精靈設計缺陷。 如果精靈頁面至少不需要某種程度的思考，它可能根本不需要在精靈中。

分支

• 偏好使用非分支精靈設計，而不是分支。 非分支精靈通常更簡單、更短且易於流覽。 分支精靈可讓使用者更難判斷工作中的步驟數目，以及其順序所在位置。

• 如果您必須分支，請使用下列其中一種技術來協助用戶設定方向：

  • 列舉頁面。 常見的技巧是指出使用者在每個頁面上的順序位置，例如步驟 X 為 Y 的片語。請確定端點 （Y） 穩定。 如果變更值，這會損害使用者的信心。

  • 包括子步驟的概念（如步驟 2a of 6）。

  • 讓步驟與頁面無關，其中每個步驟可能涉及數個頁面。 例如，旅遊服務可能會根據業界建立完善的電子商務慣例，採用精靈組織。

    正確：

    

    邏輯標籤可為分支精靈的使用者提供適當的方向。

  • 將選擇性步驟視為列舉序列中的持續性步驟。 例如，如果分支只是略過幾個選擇性步驟，只要略過意見反應中的步驟，而不是重新編號。 因此，如果使用者在第 2 頁上做出選擇，導致第 3 頁和第 4 頁成為選擇性，則顯示步驟 1、2、5 和 6/6。 請勿重新編號步驟 5 和 6。

  • 如果精靈採用單一分支，且分支會在工作初期發生，請在該時間點啟動順序，然後直接使用非分支方法。 也就是說，從分支的點開始，依序進行到分支結尾。

• 如果您必須分支，請在單一精靈中將分支數目限制為一或兩個。 一律不要在分支中包含多個分支（「巢狀」分支）。

認可按鈕

• 當用戶認可工作時，請使用認可按鈕，該按鈕是主要指令 的特定回應（例如，列印、連線或開始）。 請勿使用一般標籤，例如 Next（這並不表示承諾）或完成（非特定）來認可工作。 這些認可按鈕上的標籤本身應該有意義。 一律使用動詞啟動認可按鈕標籤。 例外狀況：
  • 當特定回應仍然是泛型時，請使用 Finish，例如 [儲存]、[選取]、[選擇] 或 [取得]。
  • 使用 Finish 來變更特定設定或設定集合。
• 單一精靈可以有多個認可點，但偏好使用單一點。
• 如有必要，您可以在頁面上重新命名或隱藏認可按鈕。 這項彈性是舊版精靈中無法使用的新精靈設計的優點之一。 請注意，隱藏認可按鈕與停用認可按鈕不同。
• 避免停用正認可按鈕。 否則，用戶必須推斷認可按鈕停用的原因。 最好讓認可按鈕保持啟用，並在發生問題時提供有用的錯誤訊息。 只有在這樣做的原因很明顯且明確時，才能接受停用按鈕。
• 請勿混淆導覽按鈕（下一步和上一步）與認可按鈕。 下一步表示在精靈中進行，而不需承諾;[上一頁] 應該一律可在下一頁使用，然後按兩下 [上一步] 按鈕應該會復原效果。 如果不可能，使用者會做出承諾，而該承諾會透過認可按鈕上的特定標籤來表示。 如需 [下一步] 和 [上一步] 按鈕的詳細資訊，請參閱 瀏覽。

取消按鈕

• 請勿要求使用者確認他們是否真的打算取消。 這樣做可能會令人惱火。 例外狀況：
  • 動作會產生重大後果，如果不正確，則無法輕易修正。
  • 動作可能會導致用戶的時間或精力大幅遺失。
  • 動作顯然與其他動作不一致。
• 允許使用者重新啟動精靈，以防錯誤地取消。
• 請勿停用 [取消] 按鈕。 異常：
  • 如果取消是有害的，這可能是在獨立精靈中執行工作時的情況。
  • 如果無法取消，當精靈無法控制所有步驟時，就可能是這種情況。

關閉按鈕

• 針對 [Follow-Up] 和 [完成] 頁面使用 Close。 請勿使用 Cancel，因為關閉視窗不會放棄此時完成的任何變更或動作。 請勿使用 Done，因為它不是命令式動詞。
• 執行工作之後，[取消] 應該會變成 [關閉] （針對獨立的精靈）。 Close 的效果只是關閉視窗。

其他控制件

• 僅針對選擇使用命令連結，而不是承諾。 特定認可按鈕表示承諾比精靈中的命令連結好得多。
• 使用命令連結時，請隱藏 [下一步] 按鈕，但保留 [取消] 按鈕。

使用頁面 （與對話框或內嵌 UI）

• 一般而言，偏好頁面至對話框。 用戶預期精靈會以頁面為基礎。
• 使用對話框來協助完成頁面， 例如使用物件選擇器和瀏覽器。
• 使用對話框來提供套用至整個頁面的錯誤訊息，以及按下認可按鈕的結果。
• 使用內嵌簡報進行簡單的動態行為， 例如漸進式洩漏和關係型UI。
• 針對套用至特定控件的錯誤訊息使用內嵌簡報。

精靈頁面

• 專注於有效率的決策。 減少頁面數目，以專注於基本資訊。 合併相關頁面，並將選擇性頁面從主要流程取出。 讓使用者完全透過精靈按 [下一步] 可能看起來是很好的體驗，但如果使用者不需要變更預設值，則頁面可能不需要。

• 將每個頁面設計成具有單一用途和視覺一致性。 如需詳細資訊，請參閱 頁面完整性。

• 請勿使用歡迎頁面—盡可能讓第一頁正常運作。 只有在下列情況下，才使用選擇性的 [用戶入門] 頁面：

  • 精靈具有成功完成精靈的必要條件。
  • 使用者可能無法根據精靈的第一個 [選擇] 頁面瞭解精靈的目的，而且沒有進一步說明的空間。
  • 開始使用頁面的主要指示是「開始之前：」。

  不正確：

  mappoint 安裝程序歡迎頁面

• 新式精靈選擇功能第一頁。 這裡沒有作用，但按 [下一步] 。 為什麼強制使用者在其寶貴的時間上支付此令牌稅？

• 在要求使用者做出選擇的頁面，針對最有可能的情況進行優化。 這些類型的頁面應該會顯示實際的選擇，而不只是指示。

  • 如果您未使用用戶入門頁面，請說明選擇第一頁頂端精靈的用途。

• 使用 [認可] 頁面，在用戶認可工作時清楚說明。 [認可] 頁面通常是選擇的最後一頁，且 [下一步] 按鈕會重新標記，以指出要認可的工作。

  • 請勿使用只摘要使用者先前選取專案的摘要頁面，除非工作有風險（涉及安全性或遺失時間或金錢），否則使用者可能需要檢閱其選擇的好機會。

• 使用 [進度] 頁面來顯示冗長的作業狀態。 成功完成時，進度頁面應該會自動前進到下一個步驟。 只有當使用者需要看到問題時，它才應該停留在進度頁面上。 按兩下 [返回進度] 頁面應該不會有任何副作用。

  • 使用單一確定進度列。 請遵循 確定進度列指導方針，包括：
    • 清楚指出完成。 除非作業已完成，否則請勿讓進度列移至 100%。
    • 請勿重新啟動進度。 進度列會在重新啟動時遺失其值（可能是因為作業中的步驟完成），因為使用者無法知道作業何時完成。 相反地，讓作業中的所有步驟共用一部分的進度，並讓進度列移至完成一次。
  • 提供進度列上方目前步驟的簡潔描述。 對於快速作業，這類文字是不必要的;僅進度列就已足夠。 對於需要一分鐘或更長的作業，文字可能會很有説明。
    • 使用句子片段，通常是以動詞開頭，並以省略號結尾。 範例：正在複製檔案...、安裝必要的元件...
    • 將文字放在列上方，而非下方。
    • 不正確：
    • 進度列的
    • 在此範例中，說明文字應該會出現在進度列上方。
    • 避免將進度頁面雜亂無章，其中包含不必要的詳細數據。 此頁面不適用於技術支援;它適用於使用者。
    • 不正確：
    • 進度列的螢幕快照
    • 在此範例中，GUID 之類的技術詳細數據對使用者毫無意義。

• 請勿使用 [恭喜] 頁面，但不會結束精靈。 如果使用者清楚看到精靈的結果，只要關閉最終認可按鈕上的精靈即可。

  • 當使用者可能執行相關工作做為後續作業時，請使用 Follow-Up 頁。 請避免熟悉的後續工作，例如「傳送電子郵件訊息」。
  • 只有在看不到結果時，才使用 [完成] 頁面，而且沒有更好的方法來提供工作完成的意見反應。
  • 具有 [進度] 頁面的精靈必須使用 [完成] 頁面或 Follow-Up 頁面來指出工作完成。 對於長時間執行的工作，請關閉 [認可] 頁面上的精靈，並使用通知來提供意見反應。

• 只有在輸入很複雜且使用者需要檢閱、工作涉及重大風險（例如財務轉換），或精靈會根據不明顯的使用者輸入採取動作時，才使用摘要頁面（透過透明度建立信任）。 摘要頁面通常不符合此相關性列，而且可以省略。

• 如果無法完成精靈，請使用錯誤頁面，因為無法從中復原的問題。 在此頁面上，說明問題在清楚的語言中，沒有技術術語的用戶無法理解。 也提供使用者可以採取的實際步驟來解決問題。 如需詳細資訊，請參閱 錯誤訊息。

  • 例外狀況： 如果精靈完成併發生可能復原的次要問題，請將問題顯示為額外的工作，而不是錯誤。 使用正面、成功導向、鼓勵語言，而不是錯誤、失敗或問題等詞彙。 請勿使用錯誤圖示。

導航

• 只有在移至下一頁而不承諾時，才使用 [下一步]。 按兩下 [上一頁] 或 [取消]，當無法復原其效果時，會被視為承諾專案。
• 使用 Back 來更正錯誤。 除了更正錯誤之外，使用者不應該按兩下 [上一步] 以在工作中取得進展。
• 透過導覽保留用戶選取專案。 例如，如果使用者進行變更，請按兩下 [上一步]，然後按下一步]，則應該保留這些變更。 除非使用者明確選擇清除變更，否則使用者不需要重新輸入變更。
• 除非重複步驟有害，否則請勿停用 [上一頁] 按鈕。
• 允許使用者在下列流覽案例中流覽或修改選項：
  • 使用者提供輸入、按兩下認可按鈕、按兩下 [返回] 以檢閱先前的變更、不會變更任何專案，然後按兩下 [認可] 按鈕。 一般而言，這應該可行，而第二個認可應該只會前進到下一頁（因為工作已經完成）。
  • 使用者提供輸入、按兩下認可按鈕、按兩下 [上一步] 以檢閱先前的變更、變更專案，然後按兩下 [認可] 按鈕。 一般而言，這應該可行，而第二個認可應該以變更的輸入重做工作（取代或復原第一個動作的效果）。

幫助

• 設計精靈頁面以提供足夠的資訊，以便不需要參考程序說明中的檔。 精靈已經將用戶從他們想要的直接互動中帶走;要求使用者尋求外部說明會更進一步地從這個狀態中移除它們。 說明應該是例外狀況，而不是規則。
• 如果您必須提供 [說明] 的存取點，請使用頁面內容區域左下半部的連結（在命令區域上方）。 此連結應該是簡短的，且通常會以使用者最有可能想要回答的問題形式來表達。
• 正確：
• 具有說明連結的精靈頁面
• 此 [說明] 鏈接是適當的，因為這類基本背景資訊會使精靈頁面變得太多。

發簡訊

常規

• 使用您和您的 來參考使用者和使用者的計算機、檔、設定等等。 請勿使用第一個人（我，我的）參照計算機或精靈。 不過，在用戶選取的選項中使用第一個人是可以接受的。 範例：我只使用 複選框。
• 每個精靈頁面都必須有 主要指令。

標題

• 將精靈的名稱放在標題欄中。 使用 標題樣式大寫。
• 標題不應包含標點符號，但有問號的標點符號除外。
• 請勿在精靈標題中包含精靈一詞。 例如，使用 [連線到網络] 而非 [網络設定精靈]。

按鈕

• 不要在 [上一頁] 按鈕中包含文字。 請改用箭頭圖像，未標記。

• 請在 [下一步] 按鈕上加入文字。 除了 Next 一詞之外，請勿使用圖像（例如 > 或 >>）。

• 使用本身有意義的特定認可按鈕標籤，並且是主要指令的回應。 在理想情況下，使用者不應該讀取任何其他內容才能了解標籤。 用戶比靜態文字更有可能讀取命令按鈕標籤。

• 可能的話，請勿針對認可按鈕標籤使用 [完成] 一詞，因為通常有較佳、更具體的認可按鈕：

  • 如果按鍵認可工作（因此工作尚未執行），請使用以動詞開頭的特定標籤，該標籤是回應主要指令的動詞（範例：Print、Connect、Start）。

  • 如果已在精靈內執行工作，請改用 Close。

    例外狀況：

    • 當特定標籤仍然是泛型時，您可以使用 Finish，例如 [儲存]、[選取]、[選擇] 或 [取得]。
    • 當工作涉及變更設定或設定集合時，您可以使用 Finish。

• 使用動詞啟動認可按鈕標籤。 例外狀況為 [確定]、[是] 和 [否]。

• 使用 句子樣式大寫。

• 請勿使用結束標點符號。

文件

• 雖然大部分的 Windows 精靈在標題中不再有精靈一詞，但可以接受將精靈稱為檔中的精靈。 此參考應為小寫。
• 正確：
• 如果您是第一次設定網路，您可以使用 [連線到網络] 精靈 取得協助。
• 舊版 Windows 的某些舊版精靈可能包含標題中的精靈。 參考其中一個精靈時，可以使用 [X] 精靈來避免說 [X] 精靈精靈。
• 將精靈內的個別畫面稱為頁面。