[譯] 如何建立一個設計體系來賦能團隊 —— 關注人,而非像素

這篇文章是有關咱們新的設計語言 HubSpot Canvas 的系列文章的第一篇。前端

這有一個老喜劇小品,大意是一個郵遞員對送信失去了興趣 —— 他更願意去送玉米卷。android

在這個小品中,一個男子在他的郵箱旁邊一直等郵遞員的出現,想質問他爲何郵箱裏一封信都沒有。儘管他也喜歡玉米卷,可是他說:「若是讓我在玉米卷和郵件中二選一,我不得不選擇郵件。」ios

玉米卷比郵件裏的帳單刺激多了,可是這個男子不須要玉米卷,他須要的是他的郵件。git

HubSpot 的顧客須要一個始終如1、功能強大、使人愉快的產品。因此 HubSpot 設計團隊須要創造一個設計體系,來幫助咱們持續地知足這些需求。github

在過去的幾年裏,咱們已經:canvas

  • 創造了一個新的設計語言(咱們叫它「HubSpot Canvas」,咱們已經在這上作了不少工做)
  • 從新設計了 HubSpot 平臺,更新了咱們品牌的視覺形象
  • 創建了一個鮮活的設計體系,能夠隨着咱們的商業進展而擴展

爲了實現這一切,咱們須要進行人才投資。咱們將咱們的 UX 團隊從 14 位產品設計師、2 位研究員和 1 位做家擴展到超過 34 位產品設計師、8 位研究員、3 位做家和 1 位產品插畫師(而且仍在持續招聘中)。後端

這就是咱們如何致力於投遞郵件的故事(而且忙裏偷閒也捎帶點玉米卷)。前端工程師


咱們爲何從新設計

咱們須要從新設計 HubSpot 平臺,主要有兩個緣由。首先,更好地履行咱們品牌的承諾。咱們的客戶喜好 HubSpot 這個品牌,它頗有趣、有活力、有個性。可是目前的產品並非這樣,它配不上客戶投入到生意中的努力。架構

其次,消除蔓延到咱們 UI 中的不一致性。咱們的用戶界面在平臺上不一致,致使難以使用、難以導航。以 Marketing Hub 中的兩個模態頁面舉例:ide

注意到按鈕位置、選項卡設計和交互模式中的不一致了嗎?這些不一致增長了客戶的認知負擔,使他們執行像保存或關閉對話這樣簡單的操做都變得困難,這天天都會拖慢他們的效率。

因此咱們決定從收集用戶針對當前設計的反饋開始,反饋並不「美麗」,可是卻有價值:

「看起來比實際須要的複雜多了。」

「太多選項,我已經眼花繚亂了。」

「有點密集恐懼症,沒有留白。」

「配色過期,看起來不爽。」

「太多灰色,全部的東西好像都被小方框圈起來。」

「沒勁。」

咱們意識到須要對客戶完全地從新定位和奉獻 —— 根據他們的個性、怪癖、動機、渴望、甚至(或尤爲是)他們的焦慮。最終,咱們決定給咱們的產品打造全新的設計,像咱們的客戶天天都用的那些普通應用那樣,不只好看,並且用起來簡單。

但隨之而來的是殘酷的現實:

從新設計咱們的平臺意味着咱們必須分裂橫跨兩大洲的 40 多個產品團隊。也意味着咱們須要從創造新體驗的資源中轉移一些設計和工程師資源,以便咱們修復現存的資源。而且在上線期間,咱們的支持和服務團隊還有客戶須要不斷適應產品的變化。

咱們開始這個進程時就知道,咱們不只僅是開始從新設計咱們的產品 —— 咱們須要徹底從新思考咱們設計和打造產品的方式。

咱們首先須要瞭解在咱們的組織架構和工做流中有什麼致使了用戶體驗的碎片化和低效率,並將它們替換爲有效的實例和系統。

因此這個故事的第一部分就是,咱們怎樣定義這些挑戰、咱們如何着手從新設計咱們的產品,以及咱們創造的工具,它能夠賦能咱們的設計團隊,使之可以儘量保持持續、高效、自主的狀態。


問題的根源

去年,個人父母決定賣掉我兒時的房子,我被他們弄去幫助清理閣樓 —— 一個塞滿了積累 20 年雜物的閣樓。你可能會想到,清理期間我吐了無數個槽。好比:「WTF,咱們竟然保留着這玩意?太棒了!」但更多的是:「WTF,爲何咱們還留着 87 年的豆豆娃?(譯者注:一種毛絨玩具)」

好吧,以一樣的方式,咱們的設計團隊首先須要審查咱們過去十年在 HubSpot 暢想過、開發過、交付過的每一個組件。咱們須要下降到細緻的程度來更好地理解目前產品的體驗如何。每一個設計師都被要求仔細檢查他們各自的 App,找到每一個組件、截圖、命名並存檔,以便評審。

作個小測試:你認爲多少個日期選擇器(date picker)算「太多」?

三個仍是四個?

呃,咱們如今有八個。

這是在咱們的「閣樓」裏發現的其餘東西:

  • 100 多個灰色陰影
  • 3 個不一樣字體對應着 40 多個文本樣式
  • 16 個不一樣樣式的模態頁面
  • 6 種不一樣的主級別按鈕(這意味着根本沒有主級別按鈕)
  • 5 種表格過濾方式
  • 確認操做在左側的模態頁面
  • 確認操做在右側的模態頁面
  • 成千上萬行自定義 CSS

這是同時存在於 HubSpot 平臺的全部按鈕樣式:

這裏有你的按鈕樣式嗎?

是什麼致使了這種狀況?咱們怎麼有這麼多按鈕?咱們怎麼有這麼多的日期選擇器?

這是那段古老、黑暗的日子裏,Slack 上的真實對話:

讓 SaaS 來阻止這些無心義的討論吧。

真實的狀況是,沒有一個 HubSpot 的設計師或開發者真的想去花時間來重作日期選擇器。

咱們意識到,咱們的團隊創造了這麼多看起來多樣化但本質相同的樣式和組件的緣由,是咱們的組織架構出了明顯的問題。簡而言之,構造新東西看起來更簡單,正在起做用的東西卻很難被發覺。

HubSpot 的產品團隊由圍繞解決客戶特定需求的小規模、自治團隊構建而成,這讓咱們做爲一個產品開發組織能夠迅速發展,而且能夠對客戶變更的需求迅速作出反應,但這種方式對於保持不一樣的產品團隊的一致提出了挑戰。

當大家有超過 40 個可以快速構建、發佈、迭代的產品團隊時,確實很容易出現忽視整體客戶體驗的狀況,牢牢地專一於一個特殊的問題一般意味着戴着「眼罩」看其餘全部問題。由於有這些眼罩的存在,咱們的設計師和開發者不知不覺地在用戶界面上重建已經存在的元素、組件和圖案,這致使了用戶體驗的碎片化和混雜的設計,還有技術債。

咱們小型、自治的團隊架構不許備改變 —— 由於這是咱們基因的一部分。因此很明顯,咱們須要爲創造更好地調整咱們的產品團隊的工具和系統付出更多的努力。經過把全部人鏈接到集中的設計體系這種方式,保證在持續發展的同時,有一套統一的用戶體驗。

這可讓咱們的設計師和開發者的心思從「像素」中解放出來,讓他們有更多的時間考慮「人」。

講原則

審查能夠幫助咱們識別設計過程當中的問題,而且明確咱們發展文化的哪些方面致使了效率低下。可是在建立情緒板前、在研究排版前、在咱們激烈的討論橙色的完美色調以前,咱們須要講原則

咱們須要對咱們的核心信仰達成共識,這是遇到難以抉擇的問題時咱們惟一能夠依靠的標準,咱們須要發現咱們的團隊認爲有責任維護的理想。

因此設計團隊進行了一些構思練習來創建咱們新設計語言的基礎。咱們爭論,咱們排序,而後咱們肯定了五個核心設計原則,這五個原則指引咱們完成了一百萬個微觀和宏觀設計決策。

這些原則是:

清晰 咱們的設計原則是清晰和專一,咱們的工做幫助用戶在功能優先級、可視化層次和上下文識別性方面進行下一步正確的選擇。

人性化 咱們培養一種給體驗賦予人性的觀念,使得不一樣文化之間產生共鳴,咱們的工做每次都給給用戶提供有趣而且優雅的交互。

Inbound 咱們增強了 Inbound 方法的信息和含義,咱們的工做使用戶的入站路徑清晰,幫助他們理解爲何這是正確的。

整合 咱們經過建立統一的系統解決用戶的需求來簡化用戶的體驗,咱們的工做經過提供改進的、高效的方法幫助用戶達到偉大的目標。

協做 咱們設計了強有力的系統鼓勵人們一塊兒無縫地工做,咱們的工做幫助人們用天然、直觀的方式互相創做和協做。

咱們在從新設計產品的許多細節時,這些原則幫助咱們保持一致和專一。你能夠修改按鈕顏色、線寬、頁眉尺寸,可是你不能改變你的基本信仰,在設計的這些方面,你必須保持堅決。


一個新的視覺角度

咱們的設計團隊進行了若干個會議來從新設計咱們產品中的核心頁面,而後選擇四個產品設計師做爲一組,讓他們花一週的時間徹底投入到造成概念、設計中,而且最終和客戶一塊兒測試幾個不一樣的視覺方向。這些會議產出了一些很是不一樣的設計方向,讓咱們感到很新穎,使人興奮。

這是設計語言團隊中的兩個成員 Drew Condon 和 Jackie Barcamonte 最初的設計概念,請欣賞:

HubSpot 之前的設計

是否是耳目一新?不同凡響、使人興奮,和那些呆板、沉悶的「商業軟件」明顯不同。

設計語言團隊和客戶經過多輪的調查和訪談,最終嘗試了三種不一樣的設計方向。當咱們看到下面的敘述,咱們知道咱們找到了成功的方向:

「讓我感到生產力大增。」

「我感到本身很牛,我想我徹底知道應該作什麼。」

「這頗有趣,這纔是我想要的 HubSpot。」

「新一代的網頁。」(有些人真的這麼說)

「看起來不像商業軟件。」

「讓我感到掌控一切。」

下面是咱們採訪的客戶最喜歡的設計方向的進化:

HubSpot 之前的設計

第一輪訪談最受歡迎的設計

第二輪訪談改進的設計

當咱們讓用戶驗證過咱們的設計方向後,就是時候把這些視覺樣式應用到咱們全部的核心 UI 組件上了。我說的是上百種組件:按鈕、連接、查詢框、表格、定位、模態頁面、輸入框、彈出框(這個列表還很長)。這是從新設計過程當中不那麼有趣的部分,但卻更須要一絲不苟,並且十分耗費精力。

可是這些一絲不苟、耗費精力的工做對於咱們公司和客戶來講是一個長期投資。我想起有一個週五下午,設計語言團隊和我花了整整兩個小時來開會,這使咱們十分崩潰。

咱們那天的工做是決定咱們大多數獨立組件(按鈕、控件、輸入框等等,都是咱們用戶界面的基本要素)的外邊距和內邊距。

那次會議有五我的參加,咱們花了差很少15分鐘仔細推敲咱們全部新按鈕的外邊距。這意味着 HubSpot 支付五個設計師的工資,讓他們坐在一個屋子裏辯論像「文字和文本框的距離」這種索然無味的問題。

可是。

自從兩年前那次討論以後,咱們沒有一個前端工程師、產品設計師、研究員、做者或插畫師須要再考慮按鈕的外邊距了。

這就是建立一個設計體系的美好之處。推敲一個細節一次,你就能夠把你所有的產品開發團隊解放出來,讓他們專一於解決客戶的實際問題。

咱們把咱們全部精美的新組件,包括使用他們的引導,放進了 Sketch(咱們的設計工具)中。這讓咱們團隊的生產力當即爆發了出來,並同時(忽然地)讓咱們的設計工做緊密一致了。


團隊協做

在這個進程開始前,咱們並無一個集中的地方讓設計師知道哪些元素或組件已經存在,也沒有讓他們在本身的設計中使用這些現成的元素或組件的方法。設計師和開發者盡他們最大的努力決定使用哪一個組件或圖案,可是他們的主要參考點是那些已存在的產品 —— 那些明顯不一致的產品。

爲了解決矛盾(當咱們加速咱們的工做流的時候),咱們爲咱們的新設計語言創建了一個健壯的樣式和組件庫。這個 30 頁的 Sketch 文件被以「組件族」的形式組織起來,它存儲了組成咱們產品用戶界面的每個獨立元素或組件。這個組件庫每週更新,而且被一個小規模輪值設計師工做組和專門的前端開發者團隊管理。

須要一個圖標?過來拿。

圖標由 Joshua MulveySue Yee 和 Chelsea Bathurst 設計。

須要數據可視化?給你。

數據可視化由 Drew Condon 設計。

須要一個按鈕?如你所願。

咱們如今有一種主級別按鈕了,是橙色的,咱們喜歡橙色。

還須要其餘任何東西嗎?HubSpot Canvas 有一切你想要的。

每一個 Sketch 包中存在的組件,一樣在 React 中有一個組件對應,方便你將任何模型轉化爲代碼,就像組裝樂高玩具那樣。

這表示着咱們的設計師不須要花時間調整像素、撰寫說明書或者擔憂有關他們設計的響應性。也意味着咱們的開發者們不須要花時間把自定義 CSS 調來調去(實際上他們幾乎徹底不用寫了)。

這意味着咱們的開發者能夠有更多的時間構建,也意味着咱們的設計師能夠用更多的時間研究、設想和迭代,不只僅快,並且高保真。

這是 HubSpot 設計師通常狀況下的工做流的概覽,使用了 Sketch 庫和 Runner、Craft(由 Invision 開發)插件。

爲了適應 HubSpot 的發展,咱們的組件庫也在持續更新。它主要由一個由設計師和開發者組成的核心團隊維護,但產品團隊的每一個人貢獻着本身的力量,並幫助改進。任什麼時候候,一個新的組件被建立或修改,它都會被存儲進 Sketch 庫並對全部人開放,這極大地減小了「野組件」和重複組件的數量。


擴充設計體系

咱們的 Sketch 包也只是更大的設計體系中的一小部分,爲了讓它在長時間內真正發揮做用,咱們須要建立一些對於開發者來講切實有效的工具。咱們認識到,創造始終如1、功能強大、使人愉快的產品體驗的最好方式,是讓創造這種體驗的人們更簡單方便地工做。

閱讀下一篇來了解文檔如何培養設計和開發之間的共同全部權、咱們如何普遍使用咱們的設計體系,以及咱們爲開發者建立了哪些工具。

最後:

人比像素更重要, 就像郵件玉米卷。 玉米卷兒雖好吃, 郵件纔是最痛點。

感謝: 插畫:Sue Yee

參考文獻: Atomic Design,Brad Frost 著; Designing The Perfect Date And Time Picker,Vitaly Friedman 著; Finding the Right Color Palettes for Data Visualizations,Samantha Zhang 著;

初次發表於 HubSpot 博客

若是發現譯文存在錯誤或其餘須要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可得到相應獎勵積分。文章開頭的 本文永久連接 即爲本文在 GitHub 上的 MarkDown 連接。


掘金翻譯計劃 是一個翻譯優質互聯網技術文章的社區,文章來源爲 掘金 上的英文分享文章。內容覆蓋 AndroidiOS前端後端區塊鏈產品設計人工智能等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃官方微博知乎專欄

相關文章
相關標籤/搜索