中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

編輯導語：用戶幫助體系可以提升用戶的體驗，引導用戶走正確的路。本文作者梳理了B端系統的幫助引導性設計實踐，希望能夠幫助各位B端設計師搭建適合自己業務系統的用戶幫助體系。

閱讀前須知：

1. 文章有點偏學術性的設計課題研究范疇，所以可能讀起來可能會有一點晦澀。
2. 關于這個設計課題（B端產品的用戶幫助體系搭建），基本上目前公開層面并沒有很現成的總結性文章進行參考，起因也是企業產品層面的一次設計研究，所以有一些概念是根據我目前現有的知識水平結合想要傳達的意思所總結的，如果有更合適的措辭很歡迎進行指正。
3. 其實宏觀意義上用戶幫助體系是一個很大的設計命題，一切對用戶體驗有正向幫助的設計點其實都可以囊括進去，但是這里先做了一定的約束和取舍，不然文章的篇幅可能會非常長。
4. 文章中涉及的一些點單拎出來可能就可以寫獨立的文章，所以有一些點可能涉及并不深，看后期有沒有機會再補充深入。
5. 雖然是B端的用戶幫助體系的文章，但實際上B端的場景比C端會多一些，所以對C端的產品設計應該也會有一定的啟發。
6. 文章肯定存在不足和沒有考慮到的地方，很歡迎指正出來，同時有興趣的小伙伴可以一起討論這個設計課題。
7. 最后希望對有緣看到這篇文章的盆友了解這方面的產品設計知識有一定啟發和幫助意義。

B端產品因為其特殊的業務屬性和復雜度，通常其學習成本不低。這些成本不僅僅體現在對于復雜業務概念及流程的認知方面，同時體現在整個系統的交互成本方面。

為了保證用戶在一個大型業務系統的可用性，讓用戶有路可走且引導用戶走正確的路，避免無路可走和走彎路的狀況發生，引入一個在全局系統層面內能夠大范圍內覆蓋的B端用戶幫助體系對于提升用戶體驗是非常有幫助的。

Jakob Nielsen于1994年提出的十大可用性原則中，其最后一條原則Help and documentation（幫助性指導原則）是搭建B端用戶幫助體系的核心準則，在理想情況下，沒有幫助文檔就可以使用系統是最好的，但在某些情況下（尤其是B端系統），提供一些引導性的幫助其實是必要的。這些引導性幫助需要滿足三個條件：

1. 可以被直接發現；
2. 需要著眼聚焦于用戶核心任務；
3. 需要列出幫助執行任務的具體步驟。

這篇文章試圖通過梳理目前B端系統中已經被較廣泛使用，且形成一定用戶認知的幫助引導性設計實踐，幫助B端設計師搭建適合自己業務系統的用戶幫助體系。

一、文章結構

文章結構按照以下用戶幫助設計實踐的類型挨個詳細說明。

先引入一個概念：各個類型具體說明之前，我們先明確一個概念：B端用戶功能生命周期，簡單的講就是一個典型用戶（用戶不區分新手用戶、中間用戶和專家用戶）在一個B端系統中使用某一個業務功能的全周期。

這個周期可以拆解為：觀望系統階段（主要針對盈利化的SaaS產品，企業內部產品一般可以忽略）、接觸系統階段、嘗試使用某一功能階段、使用中階段、使用后階段、產品反饋階段。

產品需要在每個階段都提供給用戶相應的幫助支持，確保用戶在整個系統中順暢的進行功能體驗。引入用戶幫助體系的出發點就是在盡量降低人為干預的基礎上，讓產品在用戶使用過程中做到自我解釋，提升系統在用戶感知中的穩定性和可靠性。

二、主動式幫助：系統主動向用戶提供的幫助

主動式幫助的核心目的其實是為了讓用戶盡快熟悉產品，包括業務系統中涉及到的專業術語、功能介紹、操作流程、業務信息流轉等。在系統和用戶的互動中，系統通過主動式幫助來猜測用戶的行動意圖。

“我呢先向您提供了這些幫助，您自己來判斷是不是能真正幫助到您？“

主動式幫助出現的場景一般有兩類：

1. 用戶接觸系統，熟悉系統并嘗試使用系統中某一功能階段，這些情況主要針對狹義上的新手用戶。
2. 現有用戶遇到了新的功能及界面時（產品功能或者界面發生了迭代），這種情況針對了廣義上的所有新手用戶。

目前針對此類幫助的解決方案一般有這么幾種：模板示例、文字/圖文教程、向導形式、工具提示、文字提示。

同時針對主動式幫助是否對當前的用戶目標有直接關系，是否依托于某個具體用戶使用情境或者脫離于具體使用場景直接展示，可以將主動式幫助分成兩種類型：推動性幫助和相關性幫助。

1. “ 推動性幫助 ”

推動性幫助一般并不和用戶目標直接相關，它的一些設計形式會在相對隨機的時機（實際應用時一般也有大概的時機選擇范疇，比如監測到用戶長時間未和系統指定區域進行交互）出現，給用戶推送一些幫助內容，推動的方式也會有兩種形式，直接平鋪式和循序漸進披露式。

直接平鋪式通過將幫助性信息一次性展示來達到效果，比較適用于新功能上線需要告示通知的情況。循序漸進披露式通過將幫助性信息進行步驟拆解，一步步引導用戶熟悉產品功能和流程，比較適合復雜業務功能的具體教程說明。

兩種展示形式各有優缺點，前者由于信息承載體較小，若內容過多，信息的接收和理解會加重用戶的認知負擔。后者由于信息載體的數量較多，但如果數量過多，頻繁的操作也會加重用戶的交互負擔。

同時由于兩者均缺少具體的用戶使用情境作為支持，推動性幫助一般會被用戶選擇性忽略，因為在一定程度上它影響了用戶的正常操作流。當然如果運用場合合適，回到上文提及的用戶功能生命周期，對于剛接觸系統和嘗試使用某一功能的階段，通過教程和向導形式在幫助用戶形成產品的初步框架層面會起到一定的的引導作用。

下面講講主動式推動性幫助形式中每個具體的幫助設計形式（注：以下對每一種設計形式的羅列說明并不會涉及到具體的產品界面截圖，但是會有比較簡單的框架說明。）

1）模板示例

模板示例，在B端產品一般表現為提前給用戶提供一條具備相對完整性的示例，比如示例文檔、示例數據等。通過讓用戶直接感受到最終呈現效果來反向推動用戶進行類似的功能操作。當然模板示例需要支持編輯和刪除。

2）文字/圖文教程

教程，簡單的新手教程通過純文字形式來說明，一些比較推崇設計感的產品在運用新手教程形式時在文本的基礎上加入圖片、插畫、動畫等視覺表現形式，對于一些比較復雜的業務操作流程，甚至可以加入視頻講解和實例演示，不管用什么形式，其目的都是幫助用戶快速理解系統的功能特性。

新手教程一般會出現在用戶剛打開某一特定頁面時，比較常見的內容承載體是彈窗，對于涉及到較為簡單業務邏輯的功能說明或單頁面功能，通常會采用讓用戶一次性進行學習。

對于涉及較為復雜業務邏輯的功能說明或多頁面功能聯動，通常會進行分步講解，通過循序漸進的形式將所有知識點逐漸披露出來，讓用戶有充裕時間進行信息的接收和理解。

當然針對這兩種形式，用戶都可以選擇跳過或忽略。而系統中是否保留二次進入的教程入口，可以根據各自產品的成熟度來決定。

3）向導形式

向導形式和教程的區別在于它有明確的指向性，向導會提前告知用戶具體的功能使用場景，因此它會具體指向界面中的某些特定區域，同時會隨著具體操作的具體位置發生變化，讓用戶實際感知到功能的整個運轉邏輯和流程。

向導主要圍繞某個操作的引導說明，系統將用戶所在當前頁面的核心功能和操作在視覺上突出顯示，這里的設計處理一般也會有兩種方式：正常層級處理和蒙版處理，兩種設計處理的核心目的都是為了讓用戶的視線聚焦到當前頁面的核心功能上。

2.“ 相關性幫助 ”

相關性幫助會和用戶任務有直接和間接的關系，一般會出現在和用戶當前任務相關的情境中，通過情境內的提示來告知用戶相關的幫助性內容。

通常的設計形式有兩種，第一種設計形式涉及到用戶的交互行為，當鼠標焦點靠近相應的任務組件或者當用戶啟動了相對應的任務流時，相關性幫助就會出現。

相關性幫助被用戶忽略的可能性比較多，因為它一般都是跟隨用戶的實際使用情境出現的，及時給用戶提供了必要且相關的信息，直接解答了當前任務中可能存在的用戶疑惑。

依據信息呈現的設計形式類型，可以將相關性幫助分成三類：直接展開式、循序漸進披露式、入口提供式。

相關性幫助對于新手用戶和中間用戶來說是輔助高效完成任務的利器。和推動性幫助最大的不同就是相關性幫助是某單個用戶的行為觸發的，而不是主動“推”給用戶的。

下面分別講講主動式相關性幫助形式中每個具體的幫助設計形式。（注：以下對每一種設計形式的羅列說明并不會涉及到具體的產品界面截圖，但是會有比較簡單的框架說明。）

1）工具提示

工具提示因為其較強交互性、高自由度的體驗形式，出場率非常高，也經常會在一些產品的新手幫助中被濫用。如果在一個產品中被頻繁使用，甚至會起到反向效果，使整個產品信息過載和臃腫。

Material Design在對工具提示（Tooltip）的官方定義是這樣的：“When activated, tooltips display a text label identifying an element, such as a description of its function.”

工具提示僅僅起到提示的作用，它會出現在當用戶激活某一控件的時候，針對某一特定的元素通過簡要的文字來闡述其功能特性。所有的工具提示都需要滿足短暫性、匹配性和簡明性的要求。

• 短暫性指工具提示出現和消失的時機需要恰當和短暫；
• 匹配性指工具提示需要出現在與之關聯的元素附近；
• 簡明性則是對工具提示承載的文本內容提出了要求，要盡可能具備簡短性和描述性。

工具提示的核心設計原則就是要明確指向用戶可能會出現疑惑的功能或者模塊，通過用戶的行為（hover或click行為）提供及時且直接展開式的幫助。

2）文字提示

文字提示作為最直觀的信息展示，一般會采用直接平鋪的展示方式，針對一些功能較多邏輯較為復雜的頁面，將對用戶有幫助的信息直接放在頁面上從而指導用戶的行為不失為一種簡單粗暴的設計方法。

具體的設計實踐一般有：頁面標題、頁面功能輔助說明、占位提示等。

3）向導形式

相關性向導的設計形式其實和推動式向導差不太多，其主要差異點在于相關性向導是在用戶通過鼠標或鍵盤或手勢觸發某一個功能時，系統給用戶提供的前置性解答，減少和避免用戶走歪路和原地打轉不知所措的情況。

大多數起到相應功能解釋的作用。推動式向導重點解答用戶可以做什么，而相關性向導是解答用戶該如何做，為什么要這么做，以及做了后的結果會是如何的。

4）鏈接入口

入口提供式幫助作為直接展開式的變種，出現的場景大都是因為后者（如頁面直接展示、工具提示展示）無法承載過多的幫助性信息，需要提供一個鏈接入口，讓用戶自行跳轉去相關頁面或模塊進行查看，獲取幫助。因此這一類幫助形式通常會和被動式幫助進行聯動（后面詳細涉及被動式幫助時再詳細講）。

入口提供式幫助最簡單的設計形式就是在當前相關功能區域提供一個（文字）鏈接入口，通過和其他設計元素進行視覺上的差異化處理來引導用戶自行進行獲取幫助。

同時關于異常情況的引導也屬于主動式相關性幫助設計形式的一種。當用戶進入正常流程的末端節點或非正常流程中時，加入相關的引導性鏈接入口對于用戶重新進入正常功能流程非常有用。

相關性幫助由于立足當前用戶使用情境的原因，應用范圍會比推動性幫助更加廣泛，在涉及用戶具體行動目標的地方，都可以引入相應的相關性幫助形式來幫助用戶更高效的完成任務。

3. 主動式幫助的設計實踐指導

主動式幫助的理論闡述暫告一段落，下面再匯總講講主動式幫助（包括推動性幫助和相關性幫助）的設計實踐指導：

1. 主動式幫助的幫助信息需要做到簡明扼要，因為主動式幫助在一定程度都會造成用戶注意力分散，因為幫助信息的及時性、信息性和相關性非常重要。
2. 確保用戶也可以主動跳過會忽略系統提供的主動式幫助，主要針對推動性幫助。
3. 幫助內容要清晰具備可訪問性，對用戶可能需要的信息進行推送提示，對和用戶當前任務直接相關的幫助信息進行及時的相關性提示。
4. 根據產品的發展階段及成熟度，考慮主動式幫助是否可在其他地方重復訪問。

三、被動式幫助：用戶主動向系統尋求幫助

被動式幫助的核心設計目的是為了讓用戶遇到問題的時候系統能夠提供一些響應式的幫助，包括面向新手用戶、中間用戶和專家用戶三類群體。簡單的說就是通過內置的幫助和指導性說明來解答用戶使用產品過程中遇到的疑惑。

被動式幫助一般會依托于主動式幫助，產品發展的初期階段，主動式幫助是必須的，當產品發展到一定規模具備一定成熟度后，被動式幫助的引入就可以極大的提高整體產品的使用體驗。

完善的被動式幫助一般會集成包括主動式幫助中的一些共性幫助信息，目的都是為了幫助用戶熟悉產品，幫助用戶更好更高效的使用產品。“我呢這里提供了很多幫助，遇到問題時再過來看看能不能幫到您？“

被動式幫助使用的場景就比較廣泛了，甚至整個用戶功能生命周期都可以涉及。從用戶觀望系統、接觸系統、熟悉系統并嘗試使用系統中某一功能、使用系統、系統使用后、到最后的產品反饋，整個系統使用閉環都可以經由被動式幫助提供必要的幫助支持。

目前針對此類幫助的解決方案主有三種：幫助中心/幫助文檔、客服支持、全局常駐性功能

同時針對被動式幫助是否對幫助信息進行匯總性展示以及系統是否已經存在相關幫助，可以將被動式幫助再增加一個劃分維度：匯總性幫助和臨時性幫助。匯總性幫助的設計形式主要是幫助中心/幫助文檔和一些全局常駐性功能，而臨時性幫助則主要是客服支持。

設置被動式幫助的核心目標是回答用戶的問題，幫助用戶解決遇到的問題。對于在全生命周期的用戶來說，這類幫助的存在可以引導用戶完整學習產品的整體功能。

1. “ 匯總性幫助 ”

尼爾森可用性原則幫助性原則最開始的設計實踐就是此類匯總性幫助，即需要給系統提供一份足夠詳細和周全的幫助文檔，幫助用戶去了解系統和熟悉功能操作。

對于業務盤根錯節且流程復雜的大型ToB類系統，缺少一些匯總性幫助文檔，會讓用戶在遇到問題時陷于束手無策的境地。這些幫助信息可以極大節省產品的培訓成本，讓用戶去自主去學習整個產品的邏輯。同時對于產品本身，匯總性幫助可以提高整體產品的完整度。

一般情況下，這類匯總性幫助會是最會被主動忽略但經常提及的用戶幫助信息，一個良好的匯總性幫助模塊是一個新手用戶向專家用戶轉變的最有效學習工具。

下面講講被動式匯總性幫助形式中每個具體的幫助設計形式（注：以下對每一種設計形式的羅列說明并不會涉及到具體的產品界面截圖，但是會有比較簡單的框架說明。）

1）幫助文檔

幫助文檔，隨著軟件行業的發展，很多系統會拓展其承載的內容，形成一個用戶幫助中心，因此這里也用幫助中心來統一措辭。

通常幫助中心會由一些極為詳細的文檔、視頻教程以及各種解釋性材料組成，用戶可以通過幫助中心來獲取他想了解的問題，當然前提是系統本身提供了足夠詳情和完整的解答性內容。

一般幫助中心會由三部分組成：關于產品介紹，關于產品入門和使用，關于常見問題的匯總。

關于產品介紹的部分會主要針對現有的產品架構，對產品的主要模塊進行介紹，同時會羅列并解釋產品中會出現的業務詞匯表，若涉及到對外SaaS化產品，會有一個產品購買的收費相關的說明。

關于產品入門和使用的部分會針對產品功能的實際應用場景，具體對核心功能進行功能操作指南說明，幫助用戶了解如何使用產品功能可以最大化提高產品效能。

關于常見問題（FAQ）的匯總，則主要針對業務上或產品中用戶可能頻繁遇到的問題進行實現解答，方便用戶遇到同樣的問題時，系統能及時提供幫助。

關于幫助中心的設計實踐因為篇幅限制，先簡單說下，最核心的設計原則就是遵循尼爾森可用性設計原則：

1. 方便搜索；
2. 針對用戶的核心任務；
3. 描述要盡量步驟化和流程化，但注意不要運用大量文字篇幅。

幫助中心實際上大量文檔的匯總集合，因此文檔是否結構化清晰化展示是衡量一個幫助中心是否閱讀體驗良好的關鍵。另外由于大部分用戶實際上都不喜歡閱讀文檔，如何在文檔中直接傳達出切中要害的信息也是幫助中心設計者需要好好考慮的事情。

2）全局常駐性功能

全局常駐性功能通常作為匯總性幫助信息的入口，其在產品頁面中的具體表現形式就是其代表的功能操作控件始終存在于界面中，方便用戶隨時進行操作，常見的如全局搜索框、幫助中心入口、聯系客服入口、便捷性操作（如返回頂部、面包屑、導航菜單切換等）等。

另外B端產品一般會涉及的首頁，也叫儀表板，通常也會起到幫助用戶的作用，通過將一些用戶重點關注的信息通過集中性展示，通常會是一些重點信息的概覽、提醒、各種常用功能的入口等，可以在很大程度上減少用戶的操作成本。

2.“ 臨時性幫助 ”

臨時性幫助的設計形式一般為目前一般大中型B端產品都會配置的客服支持系統。

1）客服支持系統

針對客服支持系統的設計，本身也是一個非常大的產品設計命題，這里簡單的說明一下，企業通過引入智能機器人客服，可以幫助解決至少八九成的簡單且重復性的用戶反饋，而通常用戶在產品使用過程中遇到的復雜問題仍需要依靠人工客服來進行幫助支持，目前絕大部分產品都采用智能客服+人工客服的模式（聽說鵝廠例外），通過智能客服先行過濾已在系統幫助中心的問題反饋，而后人工客服介入。

另一方面，產品發展的前期階段，人工客服的資源分配是更加及時，當產品發展到一定規模，人工客服的資源就會被極大的稀釋掉。因此有些產品也會通過全局常駐性功能的形式，將客服支持的聯系方式在頁面中透出，讓用戶更加主動去尋求針對性幫助。

關于智能客服支持和人工客戶支持的協同，關鍵點在于前者問題知識庫的業務覆蓋率是否足夠廣，問題識別的準確率是否足夠高，所呈現的答案滿意度是否夠高，如果三者均無法做到，用戶的使用體驗會大打折扣。

臨時性幫助的產品核心在于一套內嵌在系統中或喚起的第三方的即時通訊工具，這里的客服支持系統也經常會和全局常駐性功能進行組合使用。

關于被動式臨時性幫助形式中客服系統的設計形式（注：以下對每一種設計形式的羅列說明并不會涉及到具體的產品界面截圖，但是會有比較簡單的框架說明。）

3. 被動式幫助的設計實踐指導

被動式幫助的理論闡述暫告一段落，下面再匯總講講被動式幫助（包括匯總性幫助和臨時性幫助）的設計實踐指導：

1. 匯總性幫助主要是幫助中心的文檔撰寫，需要確保文檔是全面且詳細的，用戶是主動過來尋求幫助的，那么文檔的展示就需要符合用戶的閱讀習慣，同時通過一些設計形式來幫助用戶更有效的理解提供的內容。
2. 臨時性幫助主要針對客服支持系統，智能客服和人工客服的組合使用來及時解答用戶疑惑，提升用戶體驗和整體滿意度，人工智能不智障是關鍵。

四、自動式幫助：系統自動幫助用戶解決問題

自動式幫助的核心目的是通過一些系統自動化處理的方式來增加系統的容錯性，最大化減少用戶的決策壓力。當一個系統足夠聰明（或者背后的產品設計者足夠考慮全面），能夠預判用戶的預期，那么它就能非常主動的給用戶提供建議和幫助，甚至幫助用戶自動執行一些任務。

“我呢先幫您解決了一些可能會出現的問題，同時我猜您會大概率會需要這些幫助“。

自動化幫助主要將復雜性轉移給了系統，從而減少用戶的決策步驟和操作風險。針對一些用戶操作風險較小且系統能力能夠支持的場景，可以直接交付系統來自動完成。針對一些用戶操作風險較大且系統能力也能夠勉強支持的場景，可以提供部分選項供用戶進行選擇，同時提供必要的容錯能力。

自動式幫助出現的場景同樣一般會分散在用戶使用產品的各個階段。當然這類幫助在C端產品中會比較常見，在B端產品中。目前針對此類幫助的解決方案一般有這么幾種：自動提醒、自動填充、自動糾正。

同時針對自動式幫助是否直接對用戶目標的行動過程進行省略，可以將自動式幫助再增加一個劃分維度：提醒性（也可理解為半自動性）幫助和自動性幫助。提醒性幫助的反映在用戶可感知的界面上主要是告知用戶可能的選項，將最終決策權依舊留給用戶，而自動性幫助則主要是自動幫助用戶進行任務的處理，直接省略了用戶的決策過程。

自動式幫助分散在產品的各個功能操作細節中，可以提升用戶對產品的滿意度和認可度。

1. “ 提醒式幫助 ”

提醒性幫助通過提醒的形式將功能的運行情況、用戶的交互操作反饋給用戶，讓用戶自行決定是否繼續行動，在B端系統中最典型的設計形式就是數據輸入的報錯，默認參數的預設，數據填充后的推薦選項，重要數據的默認靠前展示、自動模糊匹配、記住并自動顯示上一次輸入的內容等。其核心點在于讓最有可能是用戶需要的信息更接近用戶，從而減少交互成本。

2. “ 自動性幫助 ”

自動性幫助則直接省略了用戶的交互過程，將相應的行動交給系統后臺自動處理。在B端系統中比較典型的設計形式是數據輸入格式的限制（如將不符合規定格式的數據進行自動糾正）、文本錯別字的自動拼寫糾正、自動識別數據類型并進行分類、容錯性較大的搜索匹配等。其核心點在于讓系統幫助用戶做決定，直接解放用戶的一部分工作。

關于是否采用自動式幫助，首先需要考慮的一點是在當前的目標場景中，是否需要加入自動式幫助來自動為用戶做出某些決定，只有產品設計者確定這百分之百是用戶真正需要的，才采用自動性幫助，退一步，如果猜測這大概率是用戶可能需要的，可以采用提醒性幫助。如果用戶的實際目標是比較模糊的，不要做出可能違背用戶本意的決定。

畢竟自動式幫助做得好會在整體產品體驗上是錦上添花的功能點，而做不好反倒會嚴重影響到用戶的實際產品體驗。

五、總結

B端產品的用戶幫助屬于分散在整個系統的單點體驗，需要通過一些設計手段將系統中的點進行整合和連接，設計手段可以采用一些用戶反饋形式，用戶通知形式，以及匯總性的幫助中心形式等。

整個用戶幫助體系就像現實環境中的超市導視系統，主動式幫助像一個熱情的服務員，而被動式幫助則像服務前臺。如何通過一些幫助手段來指導用戶的行動，不讓用戶在整個復雜的系統中迷失方向是設計的關鍵點。

最后送上B端用戶幫助體系的結構圖，希望對你有一定啟發和幫助。

作者：慕歌；公眾號：UX Chocolate設計的底線在哪里

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

題圖來自Unsplash，基于CC0協議