以小鵝通直播為例,探討SaaS對復雜B2C功能的產品設計原則

0 評論 8700 瀏覽 45 收藏 21 分鐘

如今,很多SaaS廠商開始瞄準“企業服務”賽道,其中重要的一環就是為企業元B2C業務提供標準化功能,以增值原業務。然而這類業務抽象為標準化功能時,會面臨3大設計難點,如何解決這些難題呢?本文作者以小鵝通直播為例,探究SaaS對復雜B2C功能的產品設計原則,一起來看一下吧。

在眾多企業全面嘗試業務線上化、經營數字化的今天,很多SaaS廠商開始瞄準“企業服務”賽道,其中很重要的一環就是為企業原B2C業務提供標準化功能,以增值原業務。但是這類業務抽象為標準化功能時,一定會面臨3大產品設計難點。

但是,如何解決這些難題呢?筆者作為B端產品經理,希望通過對個例的分析,探究SaaS對復雜B2C功能的產品設計原則。

一、開篇概述

在輸出《以小鵝通為例,探討SaaS產品如何解決“上手難、效率低”的用戶體驗問題》時,筆者發現小鵝通直播非常切合這3種情況,本篇文章就以小鵝通直播為例,代入【運營管理者、第三方講師、觀眾】3類用戶的視角,體驗一場直播【直播前準備、開播、直播中】的完整組織、落地、交付過程,觀察用戶體驗問題,分析得出復雜B2C業務的標準化功能的產品設計難的根本原因和通用原則。

二、體驗功能介紹

直播業務的復雜性很高:初期需要B端多角色協作、多運營環節逐步準備,后期在一個界面+限定時間范圍內,將所有內容和運營動作一次性呈現給C端用戶。

但平時我們更多接觸到的是C端公域帶貨類直播,如淘寶直播、抖音直播;而對小鵝通直播這種SaaS私域直播功能了解較少,所以在這里做一些補充介紹。

三、體驗情況

第一步:直播前準備

復雜B2C業務有2大特點,B端運營重、流程環節多,導致將其抽象為標準化功能時,產品設計一定會面臨一個問題——該功能的B端管理界面必然承載了大量功能,此時如何降低用戶負擔與使用成本?

1)第一眼感受:事情看著好多心好累

在很多SaaS中,復雜功能的創建和詳情頁面都非常長,人還沒開始操作,大略看到內容后,心就有點累了,更不用說在第一次使用時不了解它的情況下。

小鵝通案例:

① 創建直播:需要滾動6屏(普通筆記本電腦),并且第1個分類板塊【基本信息】就占了約4屏;

② 直播詳情-直播間設置-互動設置:需要滾動3至N屏;

③ 直播詳情-運營設置:需要滾動6屏,并且與這場直播關系更緊密的【開課提醒】、【直播間信息設置】被放在最后。

2)操作過程中感受:旋轉跳躍我閉著眼

SaaS的功能總在不斷增多,但由于功能總是單個單個上線,長期下來,功能的核心頁面內就散落了很多未經整體設計的功能點,導致頁面內功能點放置的位置(tab分類、tab下順序),缺少合理、統一的標準,既不是按業務流程定、也不是按運營場景定。

這導致,用戶日常使用時體驗會非常混亂。以小鵝通為例,當我按常規邏輯(業務流程/運營場景等)逐步設置業務所需功能時,出現了4種混亂體驗導致的問題。

小鵝通案例:

①我想編輯用戶進入直播間后看到的內容:創建頁:簡介、詳情、暖場圖;詳情-直播間設置-直播間裝修:皮膚、背景圖、菜單;詳情-運營設置:最下面的直播間公告、觀看人數/在線人數/直播間熱度是否展示。

②我想編輯直播內容來源和該直播內容都展示在哪些地方,需要經歷3個tab:開播設置、轉播設置、拉流設置。

③詳情-運營設置:功能的位置順序和實際業務流程順序差異很大。

小節總結:

對于復雜B2C功能的頁面,我們必須足夠了解和熟悉用戶實際使用案例,并在尊重“常規思路”的前提下設計功能。

  1. 分析提煉出功能的業務場景和流程,從中抽象出合理、統一的邏輯,作為眾多功能點分類和排序劃分的依據;
  2. 反復對比業務實際操作路徑與功能使用路徑之間的不同點,然后針對性的調整;
  3. 對于頁面長的問題,在交互設計和UI設計層面嘗試更多方案,例如“卡片”樣式;
  4. 整合清楚后,還可以針對B端操作效率場景,提供功能編輯時的“模板”功能,類似淘寶/千牛的商品信息模板功能。

第二步:開播

B2C功能中有一類很特殊——平臺類/場域類功能,因為它們的用戶最少存在供需兩方,有時還有第三方。所以,必須通過平臺/場域的產品功能,表達出平臺/場域的規則,并且必須讓參與的幾方角色都清晰感知到這個規則,才能讓用戶在平臺/場域下順利見面互動、才能讓這個功能在C端成功運轉起來。

如上圖所示,公域是規則主導方,而SaaS不是。因此,SaaS對平臺類/場域類功能的設計思路難度是非常高的,極容易出現歧義、造成用戶體驗問題,并最終可能導致供方對平臺/場域運營不順暢,業務增值效果差。

1)我(B端運營者)輔導外部講師開播:雙方都難受

第一個設計原則:一定要向供方(即SaaS直接用戶、即平臺規則制定方)清晰、完整地表達出全部流程、各方操作視角,尤其是與需方和第三方首次銜接的環節,切不可產生“將C端收到鏈接后的路徑設計好就行,不用告訴供方太多,減少他的負擔”這種想法。

這是因為:

① 是供方與需方、第三方直接接觸聯系,只能由供方通過自己的方式傳達清楚規則,其他方才能輕松,進而供方才能輕松;

② 供方是主導方、責任方,他需要掌控感;

③ 供方本身就有引導的運營意圖,這些信息能幫助他完成初期運營引流。

小鵝通案例:

沒有充分理解到B端有輔導外部講師開播的作用和責任,因此沒有充分且清晰地提供相關信息給B端:

①B端運營者對“講師開播流程”的了解受限于“開播信息”,既不知道講師開播路徑、也不知道講師其實可以自己選終端開播,導致B端運營者無法盡到引導作用,例如提前告訴講師最好選擇哪種開播方式,結果直播中途才發現需要換終端,踩過一次坑后才知道得提前提醒新來的講師。

② 當運營者讓外部講師開播,用了4個以上頁面來說明,但互相之間指引沖突,含義沖突,或又其他產品表達問題,導致講師用不明白、供方也解答不了,最終成了卡點。(注:該案例也屬于“編輯設置時要來回跳轉”的體驗問題,并且是一個存在邏輯關系的功能流程內仍要跳轉多個頁面完成,與上方案例的純功能間分類/順序問題不同)

③ 點擊講師列表右側短信通知,會直接發送短信,而并沒有告訴B端運營者通知內容。

2)我(外部講師/學員):我是誰?這個界面是給我用的嗎?我現在要做什么?

第二個設計原則:SaaS在設計供方提供給第三方/需方的入口和使用路徑時,一定要立足實際使用者(第三方/需方)的視角進行設計,不是供方的視角、也不是SaaS視角。否則會影響實際使用者對功能的心理預期、使用路徑,最終導致第三方/需方使用功能時自我混淆。

小鵝通案例:

① 短信通知時,講師很可能通過手機自帶瀏覽器打開H5,此時講師很可能經歷兩次登錄流程。

② 小程序(微信打開H5鏈接):講師通過供方提供的開播鏈接開播時,他看到的使用路徑是清晰的(紅色頁面1、2、3);但一旦講師是通過鵝直播主頁開播,就很難以清楚找到自身的定位和使用路徑了(綠色頁面1、2、3),最少形成2個“阻礙”。

③ 客戶端/小程序(下圖紅色內容):下圖紅色內容-開播路徑的交互邏輯不符合B端私域:小鵝通直播是B2C業務,開播行為是B端商業行為而非C端即興行為,B端對“開始直播”環節,并不會過度追求“立刻感”,反而需要一定基礎準備所帶來的“安心感”。

④ 客戶端(下圖綠色內容):快速直播按鈕的交互不符合可預知性原則、統一性原則。

⑤ 客戶端(上圖主界面列表):不顯示每場直播的所屬店鋪,對講師和學員來說都是很大的干擾。

⑥ 客戶端/小程序:可以在選擇店鋪的菜單中放“沒有找到店鋪?點此了解”,給講師講解如何解決,從講師視角反向引導B端,解決講師開播環節的引導問題。

3)我(外部講師)在鵝直播上無法開播,必須等運營者登錄后臺修改信息

第三個設計原則:當業務需要分角色完成時,每個功能的位置/定位,除了考慮業務流程之外,還需要考慮角色分工(以此分析出會使用到該功能的角色),綜合確認該功能應該放在哪一個角色處管理,即功能位置放到哪一端。
同時,不同供方的角色分工情況可能是不同的,因此如果準備將某敏感功能放置到第三方管理,應該同時給供方提供對應權限管理功能。

小鵝通案例:

① 運營者創建時隨意選擇了結束時間,等講師準備開播時才發現“直播已結束,無法開播”,此時講師端無法修改結束時間,必須由供方的運營者登錄后臺修改后,講師再開播

② 小程序/APP:講師無法看到本場直播的數據情況,需要靠運營者在后臺截圖發給講師;客戶端中提供了講師數據海報,可以提供基礎數據情況,并且滿足分享場景

小節總結:

對于平臺類/場域類功能,SaaS必須先保證自己梳理清楚完整業務流程、角色分工、角色協作環節,才能將抽象出來的業務用產品設計表達出來,讓功能達到以下3點效果。

  1. 向供方提供靈活可“自定義”的平臺類/場域類功能的同時,全業務流程的功能邏輯清晰明了
  2. 在連接需方/第三方的環節上,為供方提供清楚的說明與幫助
  3. 在需方、第三方使用的端口產品上,功能界面和使用路徑符合實際使用者的期望

最終才能將平臺/場域的規則定義權掌握在自己手上,才能向直接和間接用戶提供既便捷簡單又靈活豐富的產品功能。

第三步:直播中

像小鵝通一樣,有一些SaaS是“幫助B端做toC生意”,其核心業務功能看似是提供給B端,其實最終會交付給C端。對于這類功能的產品設計,除了考慮“B端目標”外,還要非常重視從“C端視角”出發思考。
當我們做純C端產品時,不可能忘記以“C端視角”思考。而一旦面對的是SaaS的“附屬”C端功能,就容易陷入一種思維陷阱——過于關注B端的期望和目的,而不深入C端的價值和體驗:

  1. C端對這個功能會有什么心理和反應
  2. 是否能達成商家使用這個功能的運營目的等

1)我(C端用戶)過五關斬六將才進了直播間, 結果看著五花八門的東西迷失了方向

B端的運營需求是沒有盡頭的,最終很可能會搞出一堆花里胡哨卻沒什么效果的功能,并且還會加劇B端的錯誤運營思路。這一點在直播功能上體現的尤其明顯。

直播與C端的接觸會被限定在一段時間內的,B端之前設置的各式各樣的運營手段,會在一段時間內集中、輪番地呈現給C端用戶。因此,在直播下B端的運營行為是非常快速且緊湊的,C端用戶的情緒心理也會被不斷沖擊,在此情況下,如果功能因忽略C端心理而設計得過于粗糙或復雜,價值傳遞的效果就會大打折扣,還可能讓用戶產生抵觸感,很容易導致用戶流失。

2)我(B端運營者)不知道C端會看到一個什么樣的界面、會經過什么樣的路徑

SaaS的toC功能與純toC產品不同:

  • 純toC產品:產品設計者可以清楚知道并控制產品的最后結果;
  • SaaS的toC功能:產品設計者給B端在每個業務環節、每個場景上都提供了豐富的運營功能,B端根據自己的目的自由組合功能點,形成最終的toC功能和界面。

因此,對于多個功能點需要在一個界面中展示時、需要在一個流程中依次出現時,純toC產品很容易平衡考慮,而SaaS的toC功能則要復雜很多,若產品設計者都沒有考慮,或沒有可視化給B端的話,B端運營者就無法知道“C端用戶在某個流程、某個界面中會走的路、會感受到的信息價值”,導致B端無法自我平衡運營行為和內容。

小鵝通案例:

① 當該直播有很多針對“用戶進入直播間”環節的功能,如付費售賣+直播預約+信息采集+購買前后私域引流+……,會導致引流環節的跳轉多→門檻高→流失率增高。

②該直播有很多針對“促進分享裂變”場景的運營功能,如邀請達人榜+分享有禮+招募推廣員,會導致B端運營沒有核心目標或運營行為過多,對應的C端會看到太多信息+太多路徑而迷茫。更不用說一個直播間界面上還要展示“引流、氣氛互動、營銷帶貨”等等場景的運營功能。

小節總結:

避免只關注B端不關注C端的“一條腿走路”式產品設計。

  1. 設計每一個toC功能,都應該從C端視角出發思考和設計,尤其著重C端的①場景和價值點、②功能使用路徑與體驗;
  2. 產品設計者需要梳理清楚C端在該業務功能下會遇到的所有功能、界面、路徑、岔路口,不光是某個靜態頁面內多個功能如何呈現,還有該功能完整流程的動態過程中多個功能如何呈現。這樣才能在設計toC功能時,意識到單個功能點對C端在整個業務下感受的影響;
  3. 產品設計者觀察到的全面的C端視角,應該通過B端對toC功能的管理界面,通過可視化等設計手段,將這種視角信息傳遞給B端運營者,讓他們擁有C端視角,才能真正平衡最終的運營行為。

四、設計原則總結圖

本文由 @B端編外產品 原創發布于人人都是產品經理,未經許可,禁止轉載

題圖來自 Unsplash,基于CC0協議。

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

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!