提升B端產品易用性:搭建幫助體系

4 評論 10688 瀏覽 134 收藏 37 分鐘

眾所周知B端產品業務場景和流程復雜多變,為了能夠讓新用戶迅速了解平臺的功能和操作,并且幫助老用戶感知信息的變更和功能的擴展,從而提高產品易用性,需要搭建幫助體系。一起來看看下面這篇文章有關幫助體系的知識內容吧!

一、幫助體系建設背景

1. 為什么要建設幫助體系

  • B端產品業務場景和流程復雜多變,產品使用門檻高,而B端用戶往往缺乏主動學習的動力,這導致我們經常聽到用戶反饋表示不懂如何使用、學不會,記不?。?/li>
  • 通過客服、技術支持等人工服務來幫助用戶上手使用產品,成本非常高,會擠占研發收入。并且現實中資源往往是有限的,客戶進線等待時間長,客服處理時效低,用戶體驗差,新用戶易流失;
  • 當產品核心/高頻使用的功能、或界面布局發生重大變動時,一套優秀幫助體系可以有效提高用戶的安全感和滿意度,讓用戶更好地接受新版本的改動,實現平滑過渡;(可見:降低B端產品迭代對用戶的影響:安全感與滿意度的雙重策略)。
  • 當產品發布新版本時,可以高效觸達用戶。有定期的新版本觸達,用戶會覺得這款產品一直在更新迭代發展,能有效提升用戶粘性,也更有機會促進用戶的增購復購。

為了讓新用戶迅速了解平臺的功能和操作,并且幫助老用戶感知信息的變更和功能的擴展,從而提高產品易用性,我們必須在整個系統層面上建立一個幫助體系。

2. 什么是幫助體系

幫助體系是什么?幫助體系并不是單一的某個功能,而是一種體系化的能力,通過多種不同的方式來幫助用戶更有效地使用我們的產品,其符合Jakob Nielsen于1994年提出的十大可用性原則中,其最后一條原則Help and documentation(幫助性指導原則)。

體系化的幫助是通過在B端用戶功能生命周期的不同階段提供差異化的引導及反饋,助力用戶在應用中成長。

二、搭建思路

我們圍繞B端用戶功能生命周期搭建幫助體系,旨在產品需要在每個階段都為用戶提供恰當的提示與指引,在降低人為干預的基礎上,幫助用戶降低認知成本,讓用戶在使用產品過程中做到自我解釋,提升系統在用戶感知中的易用性。

B端用戶各階段的訴求與幫助體系目標

我們將B端用戶功能生命周期切分為觀望系統階段、接觸系統階段、嘗試使用某一功能階段、使用中階段、使用后階段,以及產品迭代階段。

1. 觀望系統階段

在觀望系統階段,用戶通常還沒有開始接觸到系統本身,而是通過市場、銷售、伙伴、推薦等渠道先進入到產品官網。不過,這一階段的用戶基本都會有較明確的業務需求,而且大多數用戶在此之前已經粗略了解過對應的產品系統或解決方案。

所以在這個時候,用戶的主要關注點是了解解決方案、核心功能以及產品與他們的業務匹配程度。

觀察系統階段對于用戶建立對產品的初步信任至關重要,它直接影響到新用戶的注冊數和留資數。因此,在這個階段,我們的幫助體系的主要目標是通過提供清晰的內容介紹來讓產品取得用戶第一步信任,促進其注冊/留資。

為實現這一目標,我們與市場、銷售、生態渠道等相關部門的成員合作,共同打造產品官網。官網的內容包括但不限于產品介紹、解決方案介紹、客戶案例、公司介紹、使用手冊、模板中心和價格信息。

盡管官網的建設看似容易,但實際上需要深刻地理解產品、用戶、解決方案以及公司的線索渠道,而不僅僅是將各部門提供的內容和想法堆積在一起,也不能簡單地將其變成一個沒有業務價值的公司品牌介紹。

為確保官網的有效性,我們應當對各種線索渠道帶來的用戶進行畫像分析,有針對性地組織官網內容,通過滿足用戶的信息需求來建立初步的信任,并引導用戶發生注冊/留資的行為。最后但同樣重要的是,在官網上進行埋點跟蹤、線索的有效分發和線索質量反饋收集,這將對官網的持續優化和價值產出起到關鍵作用。

2. 接觸系統階段

進入到用戶接觸系統階段,用戶將會與系統產生初次交互。不過,由于B端系統是服務于業務的,其具備“流程性”這樣的特性,通常無法像C端產品那樣,一個功能點就可以實現一條業務流程,實現一個用戶需求。所以,在該階段用戶是希望找到實現某一業務目標(或流程)的單個/多個功能入口,并且有清晰的路徑順序。

故用戶的主要關注點是產品如何試用體驗、實現某一業務目標的路徑是怎樣的、遇到問題時是否有反饋和支持。

對此,幫助體系的主要目標是提供友好的使用體驗和清晰的路徑引導。為實現這一目標,可通過設計體驗版和Onboarding來幫助用戶快速上手產品,形式包括但不限于:新手任務、全局導覽、全局彈窗、空白頁、內容示例/模板(將在第四部分【幫助體系設計實踐】具體展開)。

好的Onboarding有利于提高用戶的功能激活轉化,功能激活轉化也會直接影響用戶的付費轉化。

因為相比于“AARRR”增長模型,在B端產品中會有所調整,調整為“獲客→激活→轉化→留存→拓展→定價”。在用戶的功能激活使用后,下一個漏斗將直接進入付費轉化而非留存,這個與B端產品的用戶價值特點與變現方式有關。

為確保Onboarding的有效性,我們應當對用戶核心關鍵動作做充分的鏈路式的埋點追蹤,其數據將有效地反饋出Onboarding的效益與產品的易用性。在現在的經濟環境和行業趨勢下,B端的產品易用性逐漸受重視,其一方面可以給用戶帶來良好的使用體驗,另一方面也是可以給銷售與實施交付團隊降低成本和提高成單與交付效率。

對于面向中小微客戶或中低客單的B端產品來說更是如此,能夠實現客戶自助使用和自助付費的PLG模式,將極大提高人效與利潤,在激烈的競爭環境下才能更好存活下去。

當然,還是需要將反饋與支持渠道在該階段放出來,一方面是沒有人想錯失用戶,另一方面用戶的反饋可以暴露出Onboarding不足之處和加深產品經理對用戶業務流程的認知。不過如何做到提高售前的效率,目前我還沒有特別好的思路與實踐,但是體驗過一回伙伴云的售前流程,感覺是可以值得借鑒的(不知道實際效果與數據如何哈)。

大致流程是:

  1. 前置大量的產品介紹、歸類好的解決方案、客戶案例以及演示培訓資料
  2. 客戶進線咨詢
  3. 了解客戶行業、規模、場景與具體業務訴求
  4. 小客戶就先發豐富的材料引導自助,大客戶的話就登記留資并轉給售前
  5. 小客戶也會視客戶價值決定是否也由售前直接支持(往往小客戶會更愿意分享交流,也是有利于產品的迭代更新的)

3. 嘗試使用某一功能階段與使用中階段

進入嘗試使用某一功能階段與使用中階段,用戶真正開始使用具體的功能,與系統產生更深的交互。此階段用戶是正在使用功能來實現某一業務目標(或流程),所以用戶的主要關注點是功能如何快速上手使用、使用過程是否順暢、遇到問題能否快速解決。

對此,幫助體系的主要目標是提供清晰的使用流程,并隨任務場景提供合適的幫助。為實現這一目標,我們可以將其拆解為操作前、操作中、操作后三個階段,結合具體的產品與業務,按每個階段的設計目標搭配不同的組件來幫助用戶。組件將在第四部分【幫助體系設計實踐】具體展開,以下是各階段的設計目標:

  • 操作前:高效傳遞重要信息,加深用戶對功能的全局認知,深化理解,助力精準觸達
  • 操作中:助力提效,就近提供提示說明,讓用戶知道做什么、怎么做
  • 操作后:及時響應,明確操作結果,并且能銜接到下一步操作流程

這也是為什么嘗試使用某一功能階段與使用中階段的用戶訴求和幫助體系目標一致,但是在功能生命周期中需要分開看待。

同樣,這兩個階段也需要根據具體的業務流程節點設置埋點進行跟蹤,用于分析用戶的激活情況和使用情況。該數據除了可以為產品優化提供數據支撐以外,還可以分析付費轉化的情況,以及供售前與銷售在合適的時間節點介入主動聯系用戶。

4. 使用后階段

此處的使用后階段,并非指狹義的某個功能點的使用,而是完成一個業務目標或一條業務流程。用戶的主要關注點是系統有明確的業務結果反饋、結果與預期相符滿足業務需求、遇到問題時是否有反饋和支持。

對此,幫助體系的主要目標是明確的系統反饋和提供反饋與支持渠道。明確的系統反饋是通過每一步系統操作反饋構成的用戶體驗。

精準的文案有利于提高系統給用戶反饋結果的清晰度。

比如:銷售出庫單創建流程結果呈現,一個使用添加成功非模態彈窗Toast,一個使用銷售出庫單創建成功的模態Dialog。顯然,后者的系統反饋會更加清晰,對象、操作及結果都清晰表達出來,并且這句話即使系統操作結果,也是一個業務流程結果。

此外,在這個節點設置反饋與支持渠道是因為,用戶使用到了這個階段,即使遇到了問題也不會輕易的放棄體驗(新用戶)/使用(老用戶)。新用戶會希望得到答案后,再決策系統是否適用,是否需要重新選型。老用戶會希望問題得以解決,繼續使用。

那么,這些用戶都值得投入人力進行支持,爭取將新用戶進行付費的轉化,老用戶可以續費或增購。

5. 產品迭代

產品迭代對整個B端用戶的生命周期來說,是一個觸發事件,不算一個階段,但是其又尤為重要。沒有產品可以做一版就可以不做到完美,沒有用戶的需求是不會變化,因此產品的迭代一定會發生。但是,任何的產品的迭代都會讓用戶回歸到“嘗試使用某一功能階段”,無論該用戶就是需求方還是非需求方。

隨著市場對用戶的教育,傳統軟件逐步轉型做SaaS,用戶其實還是能夠接受系統更新的,不過用戶需要提前及時得知更新內容、需要系統的新老使用體驗不斷裂、也需要知道迭代的價值性。

對此,幫助體系的主要目標是更新信息的有效觸達、更新價值的有效觸達、更新后引導上手,進而達到體驗平滑過渡。要實現這一目標需要針對不同程度的更新搭配不同的組件來觸達用戶和引導用戶,理想狀態是可以形成一套標準化規范,這樣每當更新的時候,用戶不會有太強的割裂感,逐步培養用戶習慣,降低用戶抵觸情緒。

核心思想就是提高安全感和滿意度。

三、設計原則

B端產品幫助體系時,應該遵循以下原則:

  • 易獲取:可以被直接發現;
  • 場景化:聚焦于用戶的業務流程;
  • 可執行:將流程拆解成可執行、有結果的操作步驟;
  • 可運營:內容可配置,效果可跟蹤;
  • 智能化:能根據用戶生命周期智能顯示相應的內容。

前四點是做好一個B端幫助體系必須要做到的,第五點相對進階,可以視具體情況完善。

內容的組織上,核心是要想辦法講清楚,把復雜信息轉化為易于理解的信息,減輕用戶的認知負擔。

應該遵循以下原則:

  • 可視化:通過概念圖、流程圖、表格形式,把抽象難理解的邏輯/概念可視化呈現;
  • 場景化:結合業務場景進行闡述,讓用戶更易理解;
  • 價值導向化:從功能價值和用戶利益出發,優于直白的功能描述,也有利于提高用戶的滿意度。

四、幫助體系搭建實踐

1.?第一步:搭建組件庫

我們可以基于產品界面的幫助指引分出三種形式:主動式幫助、被動式幫助、自動式幫助。基于這三種幫助形式設計相應合適的交互形式與內容組織形式,進而形成標準化的組件庫。

4.1.1.? 主動式幫助

主動式幫助是主動向用戶提供幫助,讓用戶盡快熟悉系統界面。

核心使用場景有兩個:

  1. 對新用戶進行幫助教學
  2. 新功能上線后,對老用戶進行提示

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

4.1.1.1. 推動性幫助:

推動性幫助一般不和用戶目標直接相關,缺少使用情境的支持,一般會被用戶選擇性忽略,因為在一定程度上它影響了用戶的正常操作流。當然如果運用場合合適,對于處于接觸系統階段和嘗試使用某一功能階段生命周期的用戶,是可以讓其了解到產品的初步框架和推動其嘗試完成一個核心業務流程。

交互形式有以下幾種:

4.1.1.1.1. 引導頁:

用戶首次進入產品或者產品中某個獨立功能的時候,將產品最核心的功能描述加入一些插畫或者視頻吸引用戶;文字部分不要長篇大論,提煉最核心的內容傳達給用戶,如果帶有一定的操作流程,可以以流程圖的形式描述功能使用流程。

4.1.1.1.2. 模態彈窗:

用戶第一次打開某個特定頁面時出現,讓用戶聚焦當前內容,常用于版本更新提示、新功能介紹、常規通告等應用場景。

缺點是用戶容易忽略或者無視,直接關掉,引導的效果差一點,所以彈窗教程建議保留二次進入的入口,當用戶需要的時候可以順利找到。內容上可以在文本的基礎上加入圖片、插畫、視頻講解等。

4.1.1.1.3 向導引導:

用戶首次進入相關頁面,且無操作時出現。有明確的指向性,提前告知用戶具體功能的使用場景,不僅會指向界面中的某些特定區域,同時會隨著操作的位置發生變化,讓用戶實際感知到功能的整個運轉邏輯和流程。

具體使用過程中有三種交互方式,隨著提示強度由強到弱依次是:分步式引導、氣泡提示、閃點提示。不過閃點提示屬于相關性幫助,后文將會提到。

4.1.1.1.3.1. 分步式引導:常用于頁面多個功能升級的引導組。頁面有多個升級點,直接平鋪會讓頁面臃腫不聚焦,通過「下一步」操作,逐步喚出剩余引導。建議最多不超過5步。

4.1.1.1.3.2. 氣泡提示:相對輕量的引導,有足夠的提示性但不影響其他功能操作,不過不適合展示過于豐富的內容,這會導致頁面太花。

4.1.1.1.4. 模板示例:

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

4.1.1.2. 相關性幫助:

相關性幫助會和用戶任務有直接和間接的關系,一般會出現在和用戶當前任務相關的情境中,通過情境內的提示來告知用戶相關的幫助性內容。隨用戶實際使用情境出現的,及時給用戶提供了必要且相關的信息,直接解答了當前任務中可能存在的疑惑。交互形式有以下幾種:

4.1.1.2.1. 文字提示:

作為最直觀的信息展示,一般會采用直接平鋪的展示方式,針對一些功能較多邏輯較為復雜的頁面,將對用戶有幫助的信息直接放在頁面上從而指導用戶的行為

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

4.1.1.2.2. 工具提示:

比文字直接展示要更簡潔降噪,沒有直接進行展示,而是在用戶需要的時候通過懸浮或者點擊元素以氣泡的形式喚出。在設計形式上有短暫性、匹配性、簡明性的特點。

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

4.1.1.2.3. 向導引導(閃點提示):

微輔助型提示,常與氣泡引導配合使用。在需要關注的地方閃爍,點擊閃點后喚出關聯氣泡提示。不對用戶造成視覺干擾,又能引起一定的關注。并且相比直接氣泡提示,閃點提示喚出的氣泡可以承載更豐富的內容,如圖文。

4.1.1.2.4. 鏈接入口:

當文字提示/工具提示無法承載過多的幫助性信息時,設置一個鏈接入口,讓用戶自行跳轉去相關頁面或模塊進行查看,獲取幫助。因此這一類幫助形式通常會和被動式幫助進行聯動

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

綜上,在各種交互形式下,內容組織形式可以視情況選用以下三種形式:直接平鋪式、循序漸進披露式、入口提供式。

  • 直接平鋪式:通過將幫助性信息一次性展示來達到效果,承接信息的載體小,若堆積過多內容,則會加重用戶的認知負擔;
  • 循序漸進披露式:通過將幫助性信息進行步驟拆解,一步步引導用戶熟悉產品功能和流程,適合復雜業務功能的具體教程說明。承接信息的載體大,但如果數量過多,頻繁的操作也會加重用戶的交互負擔;
  • 入口提供式:當內容信息和交互步驟都較多時,可以設置一個鏈接入口,讓用戶自行跳轉去幫助中心/文檔查看,獲取幫助。

4.1.2. 被動式幫助

被動式幫助是為了讓用戶遇到問題的時候系統能夠提供一些響應式的幫助,通過內置的幫助和指導性說明來解答用戶使用產品過程中遇到的疑惑。

核心使用場景是依托于主動幫助,集成包括主動式幫助中的一些共性幫助信息,提升產品體驗。被動式幫助可以分為兩種類型:匯總性幫助和臨時性幫助。

4.1.2.1. 匯總性幫助

一個良好的匯總性幫助模塊是一個新手用戶向專家用戶轉變的最有效學習工具。對于B端產品來說,缺少一些匯總性幫助文檔,會讓用戶在遇到問題時陷于束手無策的境地。這些幫助信息可以極大節省產品的培訓成本,讓用戶去自主去學習整個產品的邏輯。同時對于產品本身,匯總性幫助可以提高整體產品的完整度。匯總性幫助有以下兩種形式:

4.1.2.1.1. 幫助中心:

幫助中心的設計應當包含以下三部分:產品介紹,產品使用手冊,常見問題FAQ。并且應當符合以下原則:

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

幫助中心實際上大量文檔的匯總集合,因此文檔是否結構化清晰化展示是衡量一個幫助中心是否閱讀體驗良好的關鍵。另外由于大部分用戶實際上都不喜歡閱讀文檔,內容組織上需要簡明扼要。

4.1.2.1.2. 全局常駐功能:

全局常駐性功能通常作為匯總性幫助信息的入口,其在產品頁面中的具體表現形式就是其代表的功能操作控件始終存在于界面中,方便用戶隨時進行操作,常見的如首頁儀表盤、全局搜索框、幫助中心入口、聯系客服入口、便捷性操作等。

4.1.2.2. 臨時性幫助

臨時性幫助的設計一般是采用智能客服+人工客服的模式。通過智能客服先行過濾已在系統幫助中心的問題反饋,而后人工客服介入。

關于智能客服支持和人工客戶支持的協同,如何達到用戶響應及時但客服成本又能得到較好控制。關鍵點在于前者問題知識庫的業務覆蓋率是否足夠廣,問題識別的準確率是否足夠高,所呈現的答案滿意度是否夠高。

4.1.3. 自動式幫助

自動式幫助是通過一些系統自動化處理的方式來增加系統的容錯性,最大化減少用戶的決策壓力。

自動化幫助主要將復雜性轉移給了系統,從而減少用戶的決策步驟和操作風險。針對一些用戶操作風險較小且系統能力能夠支持的場景,可以直接交付系統來自動完成。

針對一些用戶操作風險較大且系統能力也能夠勉強支持的場景,可以提供部分選項供用戶進行選擇,同時提供必要的容錯能力。自動式幫助可以分為兩種類型:提醒性幫助和自動性幫助。

4.1.3.1. 提醒性幫助

提醒性幫助通過提醒的形式將功能的運行情況、用戶的交互操作反饋給用戶,讓用戶自行決定是否繼續行動。核心點在于讓最有可能是用戶需要的信息更接近用戶,從而減少交互成本。提醒性幫助有以下四種形式:

4.1.3.1.1. 參數模板預設:

將高頻的內容錄入、參數配置場景封裝為模板或方案供用戶選擇

4.1.3.1.2. 交互反饋:

當用戶進行系統操作后,無論成功還是失敗,系統都需要給予反饋。常件的操作反饋形式有:toast、表單錯誤校驗、模態彈窗、獨占式頁面。

  • toast:一般3s左右消失,因體積小、展示位置靠上、自動消失等特點時常被用戶忽視。常用于操作結果、系統性無明確后續指引的反饋,例如“提交成功”、“操作失敗”、“服務器無反應”。

  • 錯誤校驗:當操作出現輸入錯誤時,為用戶展示明確的提示性消息,引導用戶修改內容

  • 彈窗提示:提示性和阻斷性都很強,能夠讓用戶聚焦信息本身。通常提示內容可為用戶提供指向性引導,需要強關注。

  • 獨占式反饋:提交后頁面切變為獨立展示的頁面級狀態反饋。比彈窗的阻斷性更強,信息獲取更沉浸。在設計時建議搭配狀態插圖強化氛圍,并提供操作按鈕為用戶提供通路。

4.1.3.1.3.?智能推薦/填充:

數據填充后的推薦選項、自動模糊匹配、記住并自動顯示上一次輸入的內容

4.1.3.2. 自動性幫助

自動性幫助則直接省略了用戶的交互過程,將相應的行動交給系統后臺自動處理。**核心點在于讓系統幫助用戶做決定,直接解放用戶的一部分工作。**自動性幫助提醒主要有以下形式:

4.1.3.2.1. 自動糾正:

將不符合規定格式的數據進行自動糾正、文本錯別字的自動拼寫糾正、自動識別數據類型并進行分類、容錯性較大的搜索匹配等。

地址智能識別功能就是自動糾正的其中一種應用。

2. 第二步:搭建幫助體系

結合B端用戶功能生命周期,按照上文的搭建思路,我們可以靈活搭配組件搭建幫助體系:

幫助體系可以模塊化、組件化,但是搭建幫助體系應當全局考慮。在每個產品模塊或功能設計開始中,就根據B端用戶功能生命周期選用合適的組件搭建幫助體系。在功能設計之初就開始搭建幫助體系,會有以下的好處:

4.2.1. 自省產品方案:

在功能設計之初開始搭建幫助體系可以促使我們更深入地思考產品的設計方案。通過思考如何解釋和幫助用戶使用不同功能,可以幫助發現潛在的設計缺陷或用戶體驗問題。這有助于提前識別并解決可能存在的問題,確保產品方案更加完善和用戶友好。

4.2.2. 交互一致性:

在構建幫助體系時,可以定義一致的交互模式和設計準則,以確保不同部分的幫助內容在用戶界面中保持一致。這可以減少混淆和用戶困惑,提供更好的用戶體驗。

4.2.3. 提高產品易用性:

幫助體系的早期搭建可以確保用戶在使用產品時獲得及時的指導和支持。這提高了產品的易用性,減少了用戶的困惑和不滿,讓用戶更容易理解如何使用產品。

4.2.4. 提升上線質量:

通過早期的幫助體系搭建,可以在產品上線之前識別和解決潛在的問題和錯誤。這有助于提高產品的質量,減少了上線后需要緊急修復的問題的數量,也降低產品迭代對用戶造成的影響。

4.2.5. 提升上線效果:

一個清晰和有效的幫助體系可以幫助用戶更快速地掌握產品的功能和優勢。這可以增加用戶的滿意度,并提高他們的使用率。如果用戶在開始使用產品時遇到困難,他們可能會更快地放棄或尋找替代方案。通過提供良好的幫助體系,可以增加用戶的粘性,提升產品的上線效果和市場競爭力。

當然,如果產品仍在孵化期,處于MVP驗證階段時,我們可以不用上線整套的幫助體系。因為MVP階段我們需要直接和客戶溝通收集反饋,以完成產品快速驗證迭代和提升PMF。不過,在產品設計、界面與交互設計上面還是需要提前做好準備,把整體的基礎打好,會有利于后續版本的迭代建設。

3. 第三步:鏈路式埋點跟蹤工具

我們可以根據公司的實際情況選用鏈路式埋點跟蹤工具(自研or外采),此處所強調的是幫助體系的建設一定要有完善的鏈路式數據跟蹤,這將會支撐幫助體系的持續建設和產品易用性的持續提升,從而量化出幫助體系所帶來收益。

五、最后

以上是對幫助體系搭建的思考與拆解,單一的幫助形式是散落不起眼的,但是通過一些設計手段將這些點進行整合和連接起來形成幫助體系,那么產品整體的易用性也將會得到顯著提升。

本文由 @Kuang扶正義的匡 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 牛逼,幫助很大

    來自北京 回復
  2. 厲害??

    來自廣東 回復
  3. 實用,可收藏

    來自浙江 回復
    1. 多多交流~

      來自廣東 回復