身為知識庫貢獻者，您用文字幫助了五億位使用者。這是一項重大的工作。使用者從世界各地來到知識庫，他們期望能找到簡單的解決方案，但我們也希望用我們的聲音讓他們感到愉快。您要如何做到呢？以下是我們在研究中得出的一些心得。

語氣

寫作時請牢記品牌形象。Mozilla 的核心是使用者選擇。我們相信自由與彈性。我們重視隱私與安全。我們是一個由社群驅動的非營利組織，貢獻者遍布全球，共享共同價值。

您不需要在每次撰寫文章時都強調這個故事。這只是在描述功能時需要記住的一點。

寫作風格

為一般、非技術背景的讀者寫作。

我們希望我們的文章能讓所有人使用，而不僅僅是進階使用者。這意味著我們是為一般大眾寫作，而不是為那些非常熟悉電腦技術和術語的人。假設您寫作的對象不知道如何在沒有逐步說明的情況下更改偏好設定或新增工具列按鈕。此外，我們也應假設他們沒有更改任何預設的應用程式或作業系統設定。

總結來說，您應該遵循以下準則：

1. 保持簡短。 人們來到知識庫是為了尋找快速的解決方案。他們可能不在乎工具的內部運作原理——他們只想知道他們應該做什麼來解決問題。大膽地刪減一些字詞。看看您能用更少的字詞傳達多少訊息。這就像寫詩一樣！
2. 保持清晰。 避免使用術語。要具體。在標題和文章中使用讀者會使用的詞語。如果您 13 歲的姪子看不懂，那就寫到他能看懂為止。更詳盡的指南請見下一節。
3. 友善、有趣且有同理心。（簡而言之：要有人情味。） 好吧，使用者來尋求支援時並不期待有趣。這正是這種方式的強大之處。用一點幽默來點亮使用者的一天。但要小心，不要為了使用有趣的譬喻或表達方式而犧牲清晰度。如果您不確定如何平衡這一點，就直接寫明瞭的說明，並在引言或結論中使用這種語氣。
4. 講個故事。 要有開頭、中間和結尾。但不要寫成小說（見準則 #1）。
   • 開頭： 這為讀者提供一些背景。這篇文章是關於什麼的，我為什麼要在意？保持簡短。
   • 中間： 說明放在這裡。這應該回答「我該如何做？」
   • 結尾： 這篇文章或功能還有後續步驟嗎？告訴讀者如果他們想了解更多，下一步該去哪裡。

更全面的指南請閱讀下一節。

寫作風格（綜合）

• 對話式寫作風格 – 使用非正式、主動的風格，類似於您與人面對面交談的方式。
• 幽默與情感 – 使用幽默很棒，但有時很難或不可能在地化。像驚訝和「我不知道這個/我懂了！」這樣的情感可能更容易融入。
• 多種學習風格 – 就像在學校一樣，人們的學習方式各不相同。此外，看到相同內容以多種方式表達對每個人都有好處。
• 重複 – 當您用不同的方式和不同的媒體解釋某件事時，您顯然也在重複它，這是幫助人們記住重要內容的另一種好方法。
• 圖片與影片 – 使用圖片和影片搭配文字來解釋事物，不僅是僅次於親自幫助的最佳方式，也是一種輕鬆融入多種學習風格和重複的方式。然而，過多的圖片會使文章的地化更加困難，所以請盡量只在對步驟或概念有幫助時才新增圖片。例如，對於點擊按鈕的步驟，您可以說「點擊 OK」，而不是新增該按鈕對話方塊的螢幕截圖。
• 實作活動 – 特別是在教學文章中，給人們一些有用的事情來完成是很好的。閱讀說明並理解過程是一回事，但提醒並讓使用者嘗試操作通常很有幫助。

文章類型

為我們的知識庫文章使用一致的內容類型有許多好處，包括易於導覽、提高清晰度和組織性，此外還有助於我們更有效地建立內容。我們正在過渡到將外部知識庫文章分為四種類型，每種類型都有特定的目的：

• 關於（About）: 這些文章解決「什麼是…」的問題，提供基本資訊以幫助讀者理解一個主題。
• 操作說明（How-to）: 這些文章專注於回答「如何…？」的問題，引導讀者完成達成特定目標或程序的步驟。
• 疑難排解（Troubleshooting）: 這些文章透過解決與問題相關的「如何…？」問題，協助使用者識別、診斷和解決他們可能遇到的產品、服務或功能的常見問題。
• 常見問答（FAQ）: 這些文章包含對單一主題的常見問題的簡潔回答，這些問題可能不適合放在其他單獨的知識庫文章中，為常見查詢提供快速參考。

以有效且具描述性的標題開頭

一個精心製作的標題不僅僅是一個標籤；它是使用者與您的知識庫文章的第一次接觸點。一個好的標題不僅應該吸引讀者的注意力，還應該作為文章內容的簡潔且資訊豐富的預覽。在為 SUMO 建立標題時，請考慮以下幾點：

• 清晰與描述性： 符合文章內容以及使用者正在搜尋的內容。要簡潔，但以使用者為中心。
• 包含關鍵字： 納入相關關鍵字以提高搜尋引擎能見度並幫助使用者找到您的文章。
• 簡潔： 保持標題簡短，同時仍提供足夠的資訊。較短的標題通常對使用者更友善。盡量將標題保持在 60 個字元左右。
• 以行動為導向： 在適用時使用動詞，以指示使用者可以做什麼來解決問題或達成目標。避免在標題中使用動名詞（以「ing」結尾的詞），以確保它們保持以行動為導向。避免使用包含「如何…」的標題。

撰寫好的引言

除了標題和目錄，引言是幫助使用者判斷他們是否來對地方的內容。

• 對於「關於」類文章： 提供概念的文字概述或定義，並專注於使用者為什麼應該關心它。
• 對於「操作說明」類文章： 提供任務的文字概述或定義，並專注於任務的重要性或好處。
• 對於「疑難排解」類文章： 描述使用者可能遇到的具體問題或症狀。使用清晰簡潔的語言書寫，盡可能避免使用技術術語。

請記住，一個好的引言通常可以作為一個好的搜尋摘要。通常您可以直接將其複製到「搜尋結果摘要」欄位中即可。

有效組織文章

這裡的總體思路是嘗試從簡單到複雜建立技能，同時盡量將大多數人需要的資訊放在靠近頂部的位置。因此，一個簡單、常見的解決方案通常會放在一個複雜或特殊案例的解決方案之前。

讓步驟說明易於遵循

撰寫步驟說明時要記住的主要事情是，要小心包含完成任務所需的所有操作。例如，如果在選擇偏好設定後必須點擊 OK 才能進入下一步，請務必將點擊「OK」作為該步驟的一部分。 一些額外需要考慮的事項：

• 達成一個結果總是有多種方法。我們應該總是選擇最使用者友善的方式，即盡可能使用圖形使用者介面和選單。
• 在描述如何存取使用者介面時使用完整的句子。
• 在給出說明時包含預期結果（例如，點擊「OK」，視窗將會關閉。）。

可讀性

文字必須易於閱讀。為此，您必須：

• 將文章分成帶有副標題的邏輯/語意小區塊。
• 使用編號或項目符號清單。
• 寫簡短或相對簡短的句子。
• 避免寫長段落。

文字量沒有限制。材料越多越好；但是，您不應該人為地擴充它。只提供有用、有價值和必要的資訊。

如何連結至第三方軟體的外部文件

在建立或更新涉及第三方軟體（如作業系統或外部應用程式）內操作的文章時，為使用者提供準確可靠的資訊至關重要。然而，在我們的文章中直接包含這些軟體的步驟可能會帶來挑戰：

• 資訊快速過時： 第三方軟體更新可能使我們的說明過時，可能混淆或誤導我們的使用者。
• 資源密集： 持續監控和更新多個外部平台的步驟將需要大量的精力和資源，這可能並不可行。

最佳實踐

為確保我們的使用者獲得最可靠和最新的資訊，而又不耗盡我們的資源，請遵循以下最佳實踐：

• 連結至官方資源： 每當說明涉及第三方軟體時，請尋找軟體製造商提供的官方文件或說明文章。連結至這些資源，而不是直接在我們的文章中寫出步驟。
• 提供背景資訊： 簡要解釋為什麼您要將使用者引導至外部頁面（例如：「有關調整系統設定的最新且最準確的步驟，請參閱官方 <軟體名稱> 支援頁面」）。
• 定期檢查連結： 雖然我們的目標是減少對第三方說明的維護，但定期檢查外部連結是否仍然有效仍然很重要。如果您發現連結已過時或損壞，請尋找更新的官方文件連結並提交修訂。
• 關於外部內容的免責聲明： 當引導使用者至外部連結時，請明確說明他們將離開 SUMO，且我們不對外部網站的內容負責。一個簡單的免責聲明或註記即可（例如：「點擊此連結將重新導向至非由 Mozilla 營運的外部網站。」）。

範例

想像您正在撰寫一篇關於設定 Firefox 功能的文章，該功能依賴於在 Mac 上更改系統級設定。與其在文章中直接概述步驟，您可能會這樣寫：

有關在 macOS 上調整系統偏好設定的最新步驟，請參閱官方 Apple 支援文件，請造訪本指南。請注意，點擊該連結將引導您至一個非由 Mozilla 營運的外部網站。

這確保您遵循的是直接來自來源的最新說明。

技術指南

• 若要了解如何實際建立新文章，請參閱 Create a new Knowledge Base article。
• 若要了解如何編輯現有文章，請參閱 Submit a minor edit or update to a Knowledge Base article。
• 有關知識庫運作方式的概述，請參閱 About the Knowledge Base。
• 有關文章文件的完整列表，請參閱 Improve the Knowledge Base。

標題

• 標題長度： Google 的搜尋結果頁面最多會顯示 60 個字元。如有必要，您的標題可以更長，但請確保您的重要關鍵字包含在前 60 個字元內。
• 大寫： 標題的第一個字應該大寫，以及專有名詞和名稱，而不是每個主要單字都大寫。使用「句子」樣式，而非「標題」樣式。（這也適用於章節標題。有關其他大寫規則，請參閱下方的樣式指南與文案規則部分。）但是，不要僅為了更改大寫而編輯現有文章的標題，除非您同時進行其他標題更改，因為這樣不會建立重新導向，並且連結到該文章的 wiki 連結將會失效（bug 1969540）。
• 不要在文章標題中使用冒號，因為這會阻止建立指向該文章的 wiki 連結（bug 749835）。同時確保文章標題中沒有多餘的空格，這也會導致 wiki 連結無法運作。
• 嘗試變化命名文章的方式。不要在每個標題中都使用相同的詞語或片語。例如，不要總是文章以「如何」開頭，並避免使用「設定首頁」等「ing」結尾的任務名稱。
• 請記住，整個解釋不必都放在標題中。您可以使用摘要為使用者提供有關文章內容的額外資訊。

Slug

當您建立新文章並輸入標題時，SUMO 會自動建立一個 slug（文章 URL 末尾 kb/ 後面的部分）。審核者可以編輯現有文章的標題，但 slug 保持不變，除非手動更改（這是設計使然）。slug 有 50 個字元的限制。空格會呈現為破折號。slug 應與標題一致，但考慮到更緊湊的空間限制，不必完全相同。

修正 slug

請務必檢查自動產生的 slug 的結尾。有時一個單字會被截斷或以破折號結尾。請修正這類問題。

更新現有文章的 slug

當您更新現有文章的標題時，請保持目前的 slug 不變，除非新標題代表了與現有 slug 不再一致的重大變更。保持 slug 的一致性有助於避免連結失效並保留 SEO 價值。

分類、產品與主題

在大多數情況下，一篇文章屬於「操作說明」或「疑難排解」類別。偶爾，我們會撰寫其他類別的文章，例如「如何貢獻」類文章（如此篇）。文章的歷史記錄頁面會顯示其類別。

文章也「與」至少一個產品相關。它們也屬於一個主要「主題」，並可選擇一個「子主題」。

關鍵字

文章中的關鍵字欄位可用於改善 SUMO 上的搜尋結果。但它只應在特定情況下使用，因為濫用實際上會損害搜尋。我們很少需要使用關鍵字。詳情請參閱 When and how to use keywords to improve an article's search ranking。

撰寫好的搜尋摘要

文章摘要與標題一起，幫助使用者判斷一篇文章是否能回答他們的問題。我們稱之為「使用者信心」，它直接影響點擊率。即使我們在搜尋結果列表的頂部提供了正確的文章，使用者也需要在搜尋查詢和我們顯示的結果之間建立心理聯繫，以便他們點擊進入文章。

操作說明文章的摘要應包括文章涵蓋的主題。疑難排解文章應嘗試包括症狀。此外，摘要應遵循以下準則：

• 簡短扼要。還記得分類廣告嗎？就那樣寫。搜尋引擎可能會截斷超過 140 個字元的任何內容。如果您使用較長的摘要，請將重要資訊放在開頭。注意： 當摘要達到 140 個字元時，知識庫軟體會顯示還剩 20 個字元，因為內部搜尋限制為 160 個字元。
• 不要使用 wiki 標記。
• 不要在每個摘要中都使用「本文解釋」。盡可能變化。可以考慮使用其他片語：
  • 我們將向您展示
  • 我們將解釋
  • 此頁面解釋
  • 本文描述
  • 了解如何

步驟數量

在引導使用者完成一個過程時，請考慮使用有序列表（編號列表）。通常，將總步驟數保持在六到七步的範圍內是一個好習慣。

平行結構

為您寫的每一步都使用相同的措辭或詞語模式。平行結構在知識庫文章中很重要，因為它使內容清晰易懂。當相似的元素具有一致的格式時，使用者可以更順利地理解和完成任務。這種結構簡化了說明，減少了錯誤，並確保資訊有效傳達。

例如：

1. 找到Firefox 關閉時清除歷史記錄。如果已勾選：
   1. 點擊 Settings… 按鈕。
   2. 確保未勾選表單與搜尋歷史記錄。
   3. 點擊 OK。

方向提示

方向提示是指引使用者到使用者介面中需要採取特定操作的具體位置或位置的參考或指示。這些提示幫助使用者更有效地導覽和與軟體、應用程式或網站互動。它們通常包括「在右上角」、「在左側選單中」或「在搜尋欄下方」等片語，為使用者提供清晰的位置感以尋找和執行操作。

在您的知識庫文章說明中，請確保在操作之前提供方向提示。例如，不要說點擊按鈕，而應使用在右上角，點擊按鈕。這種格式有助於使用者輕鬆地在介面中定位和執行操作。

樣式指南與文案規則

如前所述，您寫作時應使用主動、對話式的風格。避免說「如果使用者的書籤已遺失」，而應說「如果您的書籤遺失了」。以下是您在撰寫支援文章時可能遇到的其他常見樣式和文案問題： 始終使用 Mozilla 介面中出現的術語。 例如：

• Plugins 沒有連字號。
• Add-ons 有連字號。
• Home page 是兩個字。

一般電腦術語：

• Website 是一個字。Web page 是兩個字。
• Log in 和 log out 是動詞。例如：「Log in to the website.」。sign in 和 sign out 也適用。不要使用「log into」或「sign into」。
• Login 和 logout 是名詞（通常用作形容詞）。例如：「Click the login button.」
• 使用 email 而不是 e-mail。
• CD-ROM 的複數是 CD-ROMs。

連結至 mozilla.org 與 firefox.com 不應包含語系：

• 使用 https://www.mozilla.org/ 而不是 https://www.mozilla.org/en-US/
• 使用 https://www.firefox.com/ 而不是 https://www.firefox.com/en-US/

在句子中加入連結時：

• 避免使用「點擊這裡」或「這裡」作為連結文字。
  • 應： 前往您的帳戶設定以取消您的訂閱。
  • 不應： 點擊這裡以取消您的訂閱。

將以下項目大寫：

• 專有名詞和名稱，包括品牌名稱、產品名稱和功能名稱
• 完整句子的第一個字
• 縮寫和首字母縮略詞的字母，除非它們通常是小寫的
• 編號或項目符號清單中的第一個字
• 鍵盤上按鍵的名稱
• 冒號後完整句子的第一個字
• 標題或章節標題的第一個字

Mozilla accounts:

• Mozilla accounts 中的「a」始終是小寫，除非在導覽項目中與其他使用標題大小寫的導覽項目一起出現。
• 始終使用「sign in」和「sign out」。
• 在動詞形式中，使用「sign in to your account」（而不是「sign into」）以符合文法。
• 您也可以使用「Sign in with Mozilla」。
• 「Sign」應始終用作動詞。如果您將其用作名詞，請使用「login」。
• 使用「sign up」作為建立新帳戶的行動呼籲。

有關如何在知識庫文章中提及 Mozilla accounts 的詳細資訊，請參閱 Editorial guidelines for Mozilla accounts。

不要使用 「i.e.」與「e.g.」。這些拉丁縮寫可能會讓使用者感到困惑。為了清晰起見，當您想以不同方式解釋某事時，請使用「換句話說」或「換個方式說」來代替 i.e.。當您想舉例時，請使用「例如」、「舉例來說」或「諸如」來代替 e.g.。

在一系列項目中不要使用牛津逗號。 例如，使用「擴充套件、佈景主題與外掛程式」（不含牛津逗號），而不是「擴充套件、佈景主題、與外掛程式」。

使用被認為是普遍理解的首字母縮略詞。例如：

• HTTP
• USB
• URL

數字 出現在產品版本、錯誤代碼、按鍵和按鈕中時，將不會拼寫出來。

以主動語態撰寫說明。 主動語態和現在式簡化了說明，使其更易於遵循並鼓勵立即行動。例如：

「重新啟動 Firefox 以更新」而不是「Firefox 必須被重新啟動」。

拼出反斜線(\)和正斜線(/) 以避免路徑和搜尋中的混淆。

例如：「一些圖片的路徑名稱包含反斜線（\\）」。

鍵盤快捷鍵 將鍵盤快捷鍵或組合快捷鍵的第一個字母大寫：Ctrl + Shift + C 或 Command + Shift + C。

不要使用俚語和慣用語。 我們所有的文章都會被翻譯成多種不同的語言，所以它們會被非英語母語者閱讀和翻譯。俚語和慣用語可能含糊不清，這會讓讀者感到困惑，並使翻譯更加困難。

我們為許多項目提供了特殊的視覺樣式，可以透過在項目周圍添加適當的 wiki 標記來實現。 最常見的樣式請參閱 Markup cheat sheet。

我們有一種特殊的 wiki 標記 – {for} – 允許您針對特定版本的 Firefox 或特定作業系統提供資訊。 例如，您可以為執行 Windows 的使用者顯示一組說明，為使用 macOS 的使用者顯示另一組說明（詳情請參閱 如何使用「For」標籤）。