[翻譯]把toB產品當成樂高城堡去設計

本文轉自特贊,原文請戳這里。

網上關于toB類的產品設計相關的資源和文章特別少,更別說質量好的文章了。但是剛好我作為一個toB類產品的交互設計,這又恰恰是我個人十分需要不斷去挖掘和學習的。偶然看到一篇覺得非常有啟發的文章,值得收藏和轉發,特別是里面提到關于toB類的設計原則有四:清晰、高效、統一、美觀。

本文是關于Salesforce資深產品設計師探討了企業級產品設計可擴展性的難點和解決方案,也許能加深大家對toB 產品設計的認識。


下面是正文:

提到企業級產品,人們的印象總是不太好:難看,難用,還很貴。企業級產品因為自身的復雜,又要兼顧可訂制性(customizability)可擴展性(Scalability)往往來不及顧得上用戶體驗。然而這一切其實正在這一波互聯網浪潮中悄悄改變……

Salesforce 是一個處在快速上升階段的一個已經價值500 億美金的云計算公司。一年半以前,我離開亞馬遜的Lab126,加入Salesforce,選擇從消費級轉換到企業級產品設計,讓我對這兩者的差別非常感興趣,也讓我了解了這個行業如何為產品的可擴展性做設計,這篇文章我將對企業級產品設計的挑戰和應對策略做一個梳理。

一、設計企業產品的挑戰


1.樂高城堡挑戰

如果有人問我Salesforce 是做什么的,我都會把我們的產品比作一個樂高城堡。這個城堡可以是公司的銷售,客服,市場營銷,人力資源,數據分析,等等的組合解決方案。我們設計和輸出的是一個個樂高的零部件,讓用戶或者咨詢公司可以按照他們的需求組裝最后,我們希望幫助我們用戶的客戶愛上他們的品牌。

但是問題來了:如果我給一千個人每人發一大盒樂高零部件讓他們來造城堡,這一千個人會發揮他們的想象力給我搭建一千種風格迥異的城堡。企業產品也是這個道理。他們所在的行業,公司的業務流程,政府法規的管制,部門的工作目標等等都影響了企業解決方案的搭建,也時刻改變著人們如何使用這個系統。從這個角度來看,設計師在設計企業產品時最有效的做法(也是最大的挑戰),就是找到人們都需要的那座大眾城堡作為起點,對樂高的每一個零件都考量它如何為不同企業的應用場景服務


2. 同理心挑戰

為消費級產品(我們所說的toC)設計有一個優勢是設計師自己可以作為用戶之一來評審設計。如果連自己都不喜歡,那么這個設計一定存在問題。但是設計企業產品(toB)情況則完全不一樣。

首先,產品設計師自己可能沒有銷售或者客服行業背景。我很難想象銷售人員一天管理幾十個客戶,而每個機會都是百萬訂單是一種什么樣的體驗;又或者是只拿著十幾美金的時薪,連午餐都沒時間吃,卻還要在一天之中接上百個氣沖沖的客戶投訴電話會是一種什么生活。而且這些人不是我在街上或者公司廚房隨時都能碰到并有空跟我聊上一會的。

其次,產品購買者不一定是最終用戶。以客服行業為例,客服部門的管理者關心的是SLA(服務級別合同),KPI(關鍵績效指標),CSAT(客戶滿意度),而產品的實際用戶也就是客服人員關心的則是如何能盡快錄入信息,找到幫助文檔,或者是讓電話另一端情緒滿滿的客戶感受到自己的關心而不是敲電腦。設計產品時我們更多地是從產品經理和客戶管理層那里獲得需求。長此以往優先考慮商業需求,也就形成了企業軟件用戶體驗常常讓人難忍的現狀。

反饋鏈條繁雜冗長也是一個挑戰。從產品的最初銷售,到咨詢公司為客戶實現方案,到投入使用,再到需求的變化和產品的升級,時間跨度可以長達三年,可能有上百人參與這個項目。你從這些環節中聽到的反饋常常是某個公司在某個環節中的一份信息,有管中窺豹的感覺。用戶研究和產品設計需要利用這些信息描繪出整體的圖像。

這些挑戰都跟企業級產品所需要的可擴展性相沖突,也讓設計師的工作變得有趣起來。


二、如何設計擴展性好的企業產品?


1.? 了解商業和趨勢

很多時候商業問題都是產品經理或者BD更關心的話題。但是對于企業產品來說,產品設計師應該對商業運作和趨勢更加了解。下圖[1] 把UX放在Business, Technology 和Design 的中心,也包含了這個想法。


用戶體驗是商業,科技和設計的交集

以客戶服務行業舉個例子,全美42%的客服中心表示電話語音渠道需求在逐年遞減。對于Gen Y人群來說,社交媒體是他們尋求客服幫助的首要渠道[2] 所有的客服中心都有將客戶導向自動服務渠道的需求,因為人工服務成本高昂。美國著名調研咨詢公司Gartner 的預測顯示2020年全球客服行業將有85%的客戶關系管理將不會有人工介入[3]。這些信息都劍指一個更個性和智能的高效自動的客戶服務模式。那么我們如何利用科技的發展,公司的收購,產品的發展規劃來跑在曲線的前面去設計產品呢?在Salesforce,很多新功能的需求都伴隨著這個功能可以帶來的ACV (年化合同價值)。

從商業角度來規劃你的設計,能讓你在重要的決策會議上贏得一個座位和籌碼。

2. 定義清晰的產品范圍

設計或者重新設計一款企業產品戰線往往拉得很長。一個產品數月甚至是幾年的開發迭代周期,到被用戶采納使用又是數月或者幾年。這種情況下設計師僅僅說我們的方案更美觀,更好用是肯定沒有太大說服力的。清晰地定義產品的購買者(中小型公司),用戶群(銷售組織成員),用戶目標(提高生產力)和MVP (最簡可行產品,能夠在航海一般的設計過程和溝通過程中提供方向指引和自我約束調控。

3. 設計原則

設計原則可能是設計師最好的朋友了。在設計產品之前,你可以跟你的利益相關者一起商討這個產品的體驗應該遵循的原則。最好還給這些設計原則排個重要性的順序。因為沒有實際設計的限制,大家可以暢所欲言也比較容易達成一致。這些原則可以打開你的設計思路,幫助你做設計選擇。關鍵的是,當你和利益相關者對設計決策產生矛盾和辯論時,你們可以重新看看當時大家都同意的設計原則,來突破僵局。

Salesforce 的設計團隊就有這樣的四條設計原則[4]:清晰,高效,統一,美觀(我們的一個實習生還用三藩市的幾個知名建筑給這幾個原則配了插畫,讓這些原則生動起來)

舉個例子來說,對于Salesforce 的產品,清晰地呈現信息是跟用戶建立信任的首要原則。在沒有辦法的情況下,我們甚至可以犧牲效率換得Clarity。美觀的設計很重要,但是前提是我們要保證清晰,高效和統一。在實際操作過程中,因為我們很早就跟公司的高層領導統一了這些設計原則的考量,它也就成為了一套有力的監督系統讓每一個人都能來評審我們的產品。

4. 創造更多用戶研究的機會

由于同理心的挑戰,用戶研究在產品設計過程中更為重要。跟用戶研究員坐下來腦暴更多接觸客戶的途徑肯定有幫助。目標是建立一個方便管理的用研流程,保證每個開發周期里開始設計前問題空間(problem space)里的疑問都能有時間去探索,設計達到了一定的成熟度以后可以同步展開一些初步的定性研究。

如果是一些不需要專業知識的局部產品測試,現在市面上還有很多自動測試工具可以幫忙(在美國,通常使用的工具是UserZoom 和Validately)。他們可以自動篩選用戶,在短時間內低成本獲得足量的定量數據。

參加會議也可以短時間內接觸到很多直接客戶,而且你會發現客戶也很想向你了解產品的最新走向。Dreamforce 是Salesforce 在三藩市一年一度的客戶盛會。小到五個人的公司,大到世界五百強,大家都會聚到一起來討論新的趨勢。這也是我們設計師接觸各種用戶展開調研的好機會。

5. 為團隊溝通也做設計,不拖欠決策債

其實所有企業產品設計的挑戰絕對不僅僅是產品設計師的挑戰。我們的合作者,從產品到開發,從市場到銷售,都會真真切切地感到同樣的迷惑。作為領導者,設計師應該也考慮花時間為團隊溝通做溝通設計(Communication Design)。把合作信息用便利貼放到墻上去,管理好你的合作者的期望,盡可能讓合作變得透明,主動從設計的角度去跟進各個環節的進程。

聊到這你可能也發現了,企業設計有點像個黑盒子[5]。我們的首席設計師Craig Villamor 常說要消滅決策債務——你每一個拖欠著沒有決定的問題之后解決代價會變得越來越高。在企業設計的情境下,設計決策就像開一艘巨大的游輪:方向錯了還可以敏捷調整,如果船根本不動,就沒有向前行駛的可能性。

6. 建立設計系統(Design System)

回到樂高城堡的例子,建立設計系統(比如Google 的Material 設計系統)就好比給固定的模塊涂上特定的顏色,將常用的模塊提前安裝好讓人們隨取隨用。這樣即使產品由不同地區互不相識的團隊設計,也相對比較容易達到產品的統一性。在企業軟件的情境下,還有另一重障礙: Salesforce 的云平臺也開放給Salesforce 外部的個體開發者,跟app store 類似,任何經過Salesforce 審核的個體開發者開發的軟件,都可以放到Salesforce App Exchange 上供Salesforce 的用戶選擇和使用。而這些外部的個體開發者可能時間有限,可能根本沒有用戶體驗設計的相關知識,我們如何能夠節省他們的時間幫助他們高效完成部署又達到設計的一致性呢?我們的團隊嘗試開發了一套類似Bootstrap的Lightning Design System(https://www.lightningdesignsystem.com/)。和Bootstrap 原理一樣,開發者可以只寫一行代碼來聲明一個組件,所有的交互和視覺都由我們來提供。

這套設計系統獲得了很大的成功。對于內部開發團隊和第三方開發者,他們免去了實現設計細節的繁瑣過程。對于設計團隊,設計風格的維護和改進變得更加集中。

以上就是我關于企業及軟件產品設計的一些心得,如果你有什么想跟我分享或者討論的,歡迎發郵件聯系我qqwangxin@gmail.com

[1]http://www.helloerik.com/treatise-on-user-experience-design-part-1

[2]2015 Global Contact Centre BenchmarkingSummary Report

[3]Top 9 Call Center Trends for2016

[4]https://medium.com/salesforce-ux/defining-principles-to-drive-design-decisions-b647b68fb057#.d6238inth

[5]設計2B產品與2C產品的差異

作者 | Jason Wang,?Senior Product Designer at Salesforce,?a jolly fellow who enjoys California.

最后編輯于
?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,030評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,310評論 3 415
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,951評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,796評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,566評論 6 407
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,055評論 1 322
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,142評論 3 440
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,303評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,799評論 1 333
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,683評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,899評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,409評論 5 358
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,135評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,520評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,757評論 1 282
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,528評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,844評論 2 372

推薦閱讀更多精彩內容