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

對于相對復雜的B端產品操作，用戶的入駐、熟悉過程存在較高的學習難度，我們可以通過什么方法來降低用戶的使用門檻呢？本文總結了3類場景+8種方法，希望能給你帶來一些幫助。

對于相對復雜的B端產品操作，用戶的入駐、熟悉過程存在較高的學習難度，我們作為產品設計者可以通過哪些方法來降低用戶的使用門檻呢？本文通過總結了3類場景+8種方法，希望我們在拓展功能邊界的同時，注重用戶使用效果，更好的發(fā)揮產品作用。

不知道從何時開始，很多B端產品的銷售團隊以產品功能多，業(yè)務邏輯復雜當成了宣傳亮點，以大而全為競爭優(yōu)勢，極力渲染自己的產品能夠解決業(yè)務場景中的“一體化痛點”。

誠然，這種推廣模式對于B端用戶的決策者而言，會有一定的吸引力，但作為產品團隊，我們始終不能忽略一個關鍵問題：新用戶、初期成長型用戶怎樣能快速掌握你的產品？怎樣能快速通過你的產品而達到他的目的？

全文概覽：

1. 產品初裝費的無奈
2. 降低客戶入駐門檻的3類場景分析
3. 降低用戶學習成本的8種方法
4. 寫在最后的總結

今天的文章很長，建議先收藏~

01 產品初裝費的無奈

我遇到有些SaaS平臺在收費內容中包含了“產品初裝費”，當然也有平臺會采用一些優(yōu)惠活動減免這部分“初裝費”。

這里的“初裝費”并不是我們日常理解的系統(tǒng)安裝、維護、實施的費用。而是給用戶開通了新的賬號，由平臺服務人員幫助用戶完成一系列必需的復雜操作，并維護好初始數據。

舉例說明：比如某個產品（平臺）提供了較為成熟的配置化審批流程自定義功能，包含了圖形化的配置、不同的條件分支、不同的業(yè)務種類、不同的數據權限及流轉過程，以及抄送、會簽/或簽、數據權限配置等等。（聽起來就蠻復雜的）

現在我的企業(yè)要使用此平臺完成各項業(yè)務流轉，企業(yè)本身一定有個性化的業(yè)務審批流程，企業(yè)操作人員大概率不知道怎樣在平臺中創(chuàng)建適合自己的審批流，便可以把審批流程的場景線下描述清楚，由平臺的服務人員代為配置。配置完成后企業(yè)直接使用即可。

這個過程似乎很貼心，而且將更多的產品服務融入其中，更有甚者借此宣稱為“更有溫度、更貼心的增值服務”。而在我看來，僅從產品設計和應用的層面來分析，這項“初裝費”的服務在一定程度上也是不得已而為之。

畢竟產品的設計、操作、初始化規(guī)則太復雜了，對于新用戶增加了大量的學習成本，如果一切均由用戶自行操作，可能會有大量用戶望而卻步，從而影響了平臺的推廣進度。尤其當你的用戶日常對互聯網軟件、互聯網操作并不熟練時，這樣一套“功能強大”的平臺，一定會把他拒之門外。（這也是我一直想探索的【平臺思維】與【用戶思維】的差別與矛盾）

而且我們現在討論的依然是用戶進入之后，怎樣快速上手。如果再向前思考一步，還有什么辦法能夠優(yōu)化“用戶進入”的過程？即在用戶正式使用之前，有哪些辦法能夠降低其入駐門檻？

尤其是A企業(yè)已經使用過同類的產品，我們要把企業(yè)“撬過來”的時候，有哪些可嘗試的功能來支撐？

所以今天的分享，我會整體分為兩部分：一方面探索產品層面用戶入駐的簡化過程；另一方面才是入駐之后，如何讓用戶對產品盡快由陌生到熟悉。

此過程我也處于初步探索階段，希望能夠為有同樣困惑的伙伴們帶來一點幫助，同時如果你有更好的設計方案，歡迎和我分享，我們一起匯集智慧做出更好的產品。

02 降低客戶的“入駐門檻”

首先我把平臺的新客戶分為三類，再針對每類的特點進行分析。

1. 全新型客戶

全新型客戶是我們最常見也最好理解的，對于“全新”的客戶來說，我們的設計可以圍繞【入駐操作效率】來優(yōu)化。

舉一個容易理解的例子，銀行很多業(yè)務涉及到監(jiān)管要求和風控等因素，需要線下辦理。隨著互聯網時代的到來，銀行也一直在探索更多線上化的可能性。但是不同的銀行對于同一類業(yè)務，開通的流程也有很多差別。

科技力量強的銀行，可能有些企業(yè)服務支持全線上辦理，通過web端進行資料填寫、安全認證，即可完成開通；

但還有很多銀行采取“先線上提交資料預約，再拿著紙質材料到網點線下辦理”的方式，平心而論，如果你是企業(yè)，在其他因素都對等的情況下你會怎么選？我也遇到過一些小銀行的客戶經理說，因為入駐流程的不便捷，導致他們某些業(yè)務很難推廣。

而且，即便是全流程線上處理，不同的入駐模式對于客戶也有不同的體驗。我們以需要審核企業(yè)資質的場景為例，下面就有兩種不同的模式：

1. 用戶注冊——>填寫企業(yè)認證資料——>平臺方審核——>企業(yè)登錄——>查看平臺全量功能
2. 用戶注冊——>自動登錄并進入平臺——>查看平臺部分功能（彈出待認證提示）——>填寫企業(yè)認證材料——>平臺方審核——>查看平臺全量功能

以上兩種模式，你會更傾向于哪個？或者你認為哪個企業(yè)的入駐門檻更低？

當然，其中可能包含不同業(yè)務模式，平臺對入駐企業(yè)的“真實性”、“安全性”等方面有不同的要求。第二種也可能會存在更多的垃圾數據，但是如果僅從“入駐門檻”的角度分析，第二種無疑是更低的。

而且現在越來越多的B端產品，尤其是SaaS類產品更傾向于采用第二種“開放注冊”的模式。（當然，這種方式也容易被競爭對手了解更多，但這就是另一個話題了）

再深入考慮一步，同樣的入駐流程，用戶注冊或企業(yè)認證時填寫的資料多與少，勢必也會影響入駐轉化率，這也是為什么現在越來越多的產品（尤其是C端），可能只需要一個手機號+驗證碼就可以注冊成功了。B端認證時所收集的資料，除去企業(yè)的基本資質信息之外，每多一個附加信息，就會增大一部分入駐的難度。

2. 半新型客戶

半新型客戶指這些客戶和我們產品存在一定的關聯關系，比如我們的產品是對某些存在合作關系的產品，在業(yè)務場景上的拓展，因此合作方現有的客戶也可以成為我們的客戶。

而對于這類客戶，從體驗上講，我們總不能讓他再來注冊一遍吧？因此，我們的設計可以圍繞【系統(tǒng)自動遷移】的思路進行優(yōu)化。

所以此時我們需要設計出一套可以從合作方平臺平滑自動遷移客戶信息的方案，讓這些存量的客戶可以直接登錄我們的產品，無需進行其他任何操作。

如果我們平臺所需的部分信息合作方無法提供，那我們再考慮如何通過補錄，或者簡化注冊的流程來解決。

• 補錄指的是用戶可以正常登錄平臺，但如果開展某項業(yè)務操作之前，需要有提示去進行信息補錄；
• 簡化注冊指的是用戶無法正常登錄平臺，但假設注冊需要10項數據，平臺能通過合作方獲取8項，那就再提供另外2項的信息，從而讓入駐流程更簡單。

當然，系統(tǒng)間的數據遷移過程也是比較復雜的，尤其對于同一個客戶，在不同的平臺均有業(yè)務操作，而客戶信息如果在某個平臺發(fā)生變更之后，多個平臺間如何進行數據同步從而保證客戶的操作連貫性，也是一個非常值得單獨探討的場景。

其中還會牽扯出很多種情況，包含功能架構層面、處理邏輯層面、技術架構層面等等，今天就不展開分析了，后續(xù)我會單獨整理一篇關于“數據遷移”的場景總結。

3. 競爭對手的客戶

最后，對于“競爭對手”的老客戶來說，我們的設計可以圍繞【打通技術壁壘】的可能性來探索。

記得兩年前讀《幕后產品》這本書時，網易云音樂當時對于是否支持“導入歌單”功能進行了激烈的討論，最終這個功能為產品帶來了非常顯著的效果，讓其他音樂平臺的用戶帶著他們的歌單順利遷移到了網易音樂。其中具體的場景和功能我記不清了，我也沒有使用過網易的“導入歌單”，但這個思路就是針對競爭對手中的老客戶非常有效的降低入駐門檻的體現。

以大家熟知的OA協(xié)同產品來舉例，假設A公司以前使用釘釘，現在你們新推出了一個產品，其中包含了其中的功能以及其他的客戶增值功能，那么有什么辦法能夠讓A公司更容易接受這一步的產品遷移呢？

我們知道，一旦客戶在某個平臺沉淀了三年及以上的業(yè)務數據，那么這些數據價值是非常大的，我們很難讓對方放棄這些價值。

《俞軍的產品方法論》一書中提到一個公式，我認為非常具有指引性：

用戶價值=新體驗-舊體驗-替換成本

相信我們都能重視新產品的新體驗，也一定是因為新體驗的優(yōu)勢才有機會讓客戶拋棄舊體驗。但我們千萬不要忽略【替換成本】，而數據價值在替換成本中占有最重要的地位。

所以我們的方案更加清晰了——支持舊平臺的業(yè)務數據導入（這里的導入并不一定指文件導入，我們不要被固有觀念影響）

當然也有可能客戶希望新舊平臺一起用，那我們的方案可能要修改為支持新舊平臺對于部分業(yè)務的數據同步/共享。

而因為這里的新舊平臺不存在合作關系，所以無論是數據同步還是導入，都只能通過我們的產品來探索方案。這也是為何我把這個場景的關鍵定義為【打通技術壁壘】。

• 如果舊平臺有OpenAPI，那我們勢必要對接上；
• 如果沒有OpenAPI，但是有數據導出功能，則需要用戶先進行導出，我們再支持這一類數據模板的導入。

但是如果我們是一個平臺級的產品，目標用戶所涉及的舊系統(tǒng)參差不齊，在模板導入上也很難做到標準化，這時我們可以優(yōu)先支持幾類常見的模板，后續(xù)再迭代更多的模板?；蛘咴O計出一款能夠自動識別多種模板的導入功能。

假設舊系統(tǒng)的數據無法導出，那就只能通過其他途徑線下收集這些數據，再由用戶批量導入了。一旦實際情況走到這一步，面對著具體的替換成本，這個客戶我們大概率很難“撬動”。

以上三類，是常見的降低客戶入駐門檻的思路，不知道讀到這里的你有沒有一些收獲呢？下面我們來看另一方面，對于新用戶，如何降低他們的學習成本。

03 降低用戶的“學習成本”

1. 在新功能首次使用時，貼心的提示很重要

首先，用戶首次登錄之后的整體布局、功能、重點操作的入口介紹很重要。

我們常見的平臺類產品，首次登錄的介紹功能比較同質化，多數以“浮動”、“突出”、“指引”為主。但是，這些靜態(tài)的標注，以及通用化的標注，對用戶來說真的有用嗎？代入用戶思維來試想：我們有多少次是通過這些提示來認識平臺的？

但是如果沒有這一步，似乎也會少點什么。所以我們應該思考的是，如何讓這一步新用戶指引更能貼合用戶的【入門水準】。

其次，用戶首次在正式使用某個功能時，功能的操作流程，溫馨提示等共性介紹也很重要，具體內容請看下一條。

2. 操作指引真的能完成指引嗎？

現在常見的操作指引，更多像是【頁面介紹】，告訴你這頁重點的操作在哪。如果不做指引，用戶多花幾秒的時間也能看個大概。

但是這個業(yè)務應該怎么做？有什么前后順序要求，需要提供哪些數據，能夠生成哪些結果，能夠為我?guī)硎裁?，這些問題用戶從哪里知曉呢？

所以真正有效的操作指引應該是怎樣的？

我的觀點是：至少要有一個單獨的功能帶著用戶把功能的效果簡單直接的介紹清楚，并半自動的帶領用戶進行關鍵節(jié)點學習，通過簡單的點擊、數據變化，把MVP流程快速“跑通”一遍。

這里有點像我們玩游戲時的【新手教程】，邊講邊練。

寫到這里我也突然好奇，為什么B端產品中，很少有真正的【新手教程】？是因為不重視？還是因為體驗要求<功能要求，亦或是因為領導覺得現階段夠用了，先去攻克更重要的功能了？

總之，這一類的問題，在優(yōu)先級排期時確實很容易被放到最后，最后的最后就是不了了之。（延伸閱讀：B端產品迭代，優(yōu)先級排序是一個復雜而艱難的抉擇）

3. 幫助手冊真的能幫助到用戶嗎？

每個B端產品都會有【用戶幫助手冊】或者【操作手冊】之類的功能介紹，入口可能藏在很深的地方，也可能很小，很難讓用戶發(fā)現。似乎是在和用戶“躲貓貓”，生怕對方發(fā)現點進來學習是嗎？

• 幫助手冊也有多種風格，最簡單無效的，是把平臺所有的功能羅列一遍，配上截圖和簡短文字，似乎是為了應付差事而產生的功能；
• 相對好一點的會通過不同功能的操作順序來組織手冊的內容，相當于把上述提到的“新用戶指引”、“平臺介紹”之類的功能一股腦擺在這里。不過只要你能耐心搜索，耐心查看，還是能學會一些；
• 更好一點的，會在上述的基礎上增加“常見疑問解答”，通過用戶在使用過程中產生的疑問，對應組織解決方案、操作步驟。

好一點的平臺，會把“常見疑問解答”中問題的類型進行歸集，同時增加模糊搜索功能，在用戶使用時遇到困難，即可通過搜索定位到對應的答案，這種交互顯然會更好一些。

同時，幫助手冊一定不是獨立的文字+截圖，適時搭配一些視頻、動畫、圖片說明，效果應該會再進一步。

4. 預測用戶在哪里需要幫助

操作指引、幫助手冊之類的功能，更多是需要用戶主動學、主動操作。之前我對于“產品的溫度”定義是：在合適的時機做出貼心的反饋。

當然這一步在B端產品中很難實現的比較完整，但對于一些基礎的常見問題，操作錯誤，操作提示，我們還是可以通過“用心感知用戶的使用過程，體會用戶訴求產生的時機”來逐漸優(yōu)化。

而且基于平臺大量的操作記錄，我們也可以在經常報錯、經常中斷用戶操作的節(jié)點增加對應的溫馨提示，或者幫助提醒。

• 比如用戶同樣的錯誤出現3次以上時，系統(tǒng)是否可以自動出現【去學習】或者【常見問題答疑】之類的教程？
• 比如用戶總是操作到最后一步的時候中斷，系統(tǒng)是否可以在出現幾次之后，詢問用戶“您是有什么顧慮嗎？”從而形成意見收集。

諸如此類的細節(jié)功能，只要我們靜心去觀察，去體會，勢必能夠尋找到很多優(yōu)化空間，從而讓你的產品真正變成一款“有溫度的產品”。

5. 視頻操作和圖文介紹，你更喜歡哪一個？

對于新產品的操作介紹，如果你的業(yè)務相對熟練，看圖文介紹可能更高效；如果你的業(yè)務操作很生疏，我相信視頻操作的講解更能讓你快速掌握。

但是很多產品只提供了圖文介紹，并沒有提供視頻操作。因為首先視頻的錄制、制作、剪輯會花費更多的時間和精力，哪有圖文來得快~也可能是產品團隊沒有意識到圖文的低效性，或視頻的重要性，所以壓根就沒想著提供視頻。

這里并不是說所有的產品都必須提供視頻指引，但如果通過我們的判斷，視頻能夠幫助用戶更好的理解產品，提升效率，那還是想辦法搞出來吧。

當然，視頻也不僅局限于操作視頻、對應的宣傳視頻，圖片拼接的視頻等等形式都是可以的，我們的目的不是形式，而是結果。

6. 復雜的業(yè)務一定要有例子

新用戶進入關鍵功能后，面對空蕩蕩的數據欄，“無助感”又會增加。所以我的建議是，在用戶沒有真正完成相關操作時，系統(tǒng)預制一個默認的示例。

示例的好處不僅能讓用戶看到使用后的結果，還可以通過示例了解功能規(guī)則和使用方法，并快速復制、修改、生成自己想用的信息。

至于用戶已經完成第一次全流程操作之后，示例是保留還是消失，可以基于我們產品的實際形態(tài)，以及示例數據（默認數據）后續(xù)是否還有其他用處，自行決定。

7. 復雜的業(yè)務步驟場景化

大多數B端產品有一個常見的使用問題：功能菜單的排列是很割裂的，沒有結合用戶的使用場景“適時”出現。而是往導航欄一擺，自己找去吧~

經常有一些相對復雜的場景，用戶需要在多個一二三級菜單內反復切換，如果不是對產品達到一定的熟悉程度，要么會找不到下一步要怎樣做，要么出現步驟遺漏報錯的時候也看不懂缺失了哪一步。

常見的解決辦法有兩個：

• 一是【功能場景化】，把多步驟操作連接到一個大的步驟指引里，不要讓用戶自己找；
• 另一個是【報錯直達+改錯返回】，也就是對于前置步驟缺失或數據錯誤的報錯，要有“去修改”之類的按鈕直達，用戶依然通過最簡單的點擊找到下一個要去的地方。同時在修改完成之后，要有對應的“返回”，返回上一個操作節(jié)點繼續(xù)進行。

這個修改方案可能很多同行都知道，但是在真正落地時會遇到多方阻力，不過從用戶體驗和執(zhí)行效率上來講，這些功能都應該是標配。

8. “倒裝”的思路也能用到產品上

在我剛轉型產品時，遇到過一個問題，擬物化表達出來可以這樣理解：

1. 小明想吃西紅柿炒雞蛋，于是去廚房準備露一手，但是發(fā)現家里的炒鍋壞了，于是去找鄰居借了一口鍋；
2. 然后在切西紅柿的時候發(fā)現家里沒有西紅柿，于是去樓下超市買了幾個西紅柿；
3. 準備起鍋燒油的時候又發(fā)現家里沒油了，于是又去買了一壺油。

類似的問題在產品應用上也經常遇到，尤其是新用戶在第一次使用時，很多需要提前配置的規(guī)則沒有做，需要提前維護的數據沒有錄入，等到真正做業(yè)務的時候走一步卡一步。

所以衍伸而來一個新用戶初始化的功能，通過“倒裝”的思路把這些前置條件按順序、按指引逐一維護好。一次設置、長期受用~

以上，就是我針對【降低用戶學習成本】的方式探討?？赡苡行┓椒ㄎ覀円矅L試過，但是真正把它做好，做到適時、適度確實很難，需要我們產品同行一起去探索。

預告：

恰巧最近在看兩家SaaS平臺的【幫助中心】功能，綜合評估屬于同類產品中做的不錯的，從幫助指引、示例提示、操作演示、視頻教程、步驟連接、疑難問題解答等幾個大的方面都有對應功能的產出，值得我們借鑒和優(yōu)化。

爭取下個月整理分享出來，讓我們能夠更具象地解決這類問題，敬請期待~

04 寫在最后

即便我們把這些功能都設計出來，也并不一定能夠解決用戶的所有問題，尤其是對于平臺類產品，本身所涵蓋的場景很多，相互之間的關聯度確實比較復雜，也許一對一面對面教用戶，也需要很長時間才能“出師”。

而且本篇文章通篇僅站在產品功能設計的角度來分析，實際應用中還會摻雜業(yè)務規(guī)則、產品特性、公司理念、團隊資源等諸多內容，所以最終所呈現出來的功能，有時并不是產品團隊能夠主導的。

但這并不代表對于這些問題我們視而不見或不去嘗試，不去向著更便捷、更智能、更“傻瓜”而努力。尤其對于產品團隊，我們設計出來的所有功能都是為了讓用戶真正用起來，從而體現更多的價值。

所以降低用戶學習成本，優(yōu)化產品操作鏈路，提高問題定位速度，簡化功能理解難度，是每一個B端產品勢必要去探索，一定要為之精進的方向。

都說B端產品是為了場景賦能，提升效率，當我們真正“以用戶為中心”來考慮問題，代入場景時，才是效率躍遷的開始。