Smashing Podcast 第 9 集與 Stephanie Walter：我如何使用 UI 框架？

作為一名開發人員，我喜歡 UI 框架的一件事是它們通常帶有默認樣式，但這是我們在項目中應該依賴的東西嗎？ 簡單地使用默認樣式並相信製作框架的人在設計這些組件方面做得非常好？ 加入我今天的播客節目，我將與 UX 設計師 Stephanie Walter 討論我們在構建 UI 框架時應該考慮的事情。

顯示註釋

• 斯蒂芬妮的網站
• 斯蒂芬妮在推特上

每週更新

• Anna Prenzel的“如何使用 Angular 和 RxJS 創建卡片匹配遊戲”
• Sarah Drasner的“如何在 JAMstack 上創建無頭 WordPress 網站”
• “魔術翻轉卡：解決常見的尺寸問題” ，作者 Dan Halliday
• “Django 亮點：用戶模型和身份驗證（第 1 部分）” ，作者 Philip Kiely
• Shajia Abidi 的“如何使用 React 和 Leaflet 創建地圖”

成績單

Drew McLellan：她是以用戶為中心的設計師和移動體驗專家，她跨越了令人愉悅的產品和界面，特別關注性能。 她曾為盧森堡大學、歐洲投資銀行、寶馬和微軟等客戶開展項目，她幫助這些客戶從戰略到最終產品的整個過程中向他們的受眾交付成功的項目。 她是產品設計方面的 Google 開發人員專家，也是一位充滿激情的教師，她在眾多博客文章、文章、研討會和會議演示文稿中分享她的知識。 所以我們知道她是一位專家級的用戶體驗設計師，但你知道她曾經有一份為埃爾頓約翰爵士安裝地毯的工作嗎？ 我的 Smashing 朋友，請歡迎 Stephanie Walter。 你好斯蒂芬妮，你好嗎？

Stephanie Walter：嗨，我非常喜歡這個介紹。

Drew：所以我今天想和你談談一個特定的問題，那就是使用現成的用戶界面框架的主題。 現在你是一名用戶體驗設計師，你與許多不同的客戶一起工作，你的工作是通過製作高度可用的用戶界面來幫助這些客戶創造最佳的用戶體驗。 因此，能夠使用一套現成的工具來做到這一點的想法對我來說似乎有點牽強。 您在工作中經常看到 UI 框架的使用嗎？

斯蒂芬妮：是的，這是我經常看到的事情，尤其是在過去的幾年裡，因為我開始在一家機構工作，現在我在公司工作。 所以在那些超級大的 IT 技術團隊中，是的，目前有很多框架 UI，比如我看到最多的是 Material-UI，基本上 Material design 是一種穀歌設計的指導方針和東西，而 Material -UI 是來自 Angular 的團隊，也是來自 React 的團隊。 他們使用來自 Google 的 Material Design 的外觀和感覺創建了自己的框架。 但這與穀歌無關。 就像他們一樣，我不知道，我認為他們喜歡這種外觀和感覺。 所以目前，這是我使用的兩個主要 UI 框架。 還有一種叫做 Ant Design 的東西，它變得非常流行。

Stephanie：這是一個 React 框架。 我不知道他們是否也有 Angular。 我認為它是由中國的一個團隊製作的。 這很有趣，因為它不僅提供了組件，React 中的所有東西，而且如果你訪問他們的網站，你還會得到草稿文件，這實際上很有趣，因為它可以激勵或幫助設計師構建或塑造該框架使用的 UI 組件的接口。 所以是的，我經常看到這種情況，尤其是在大型 IT 團隊中，因為大多數時候這些團隊都沒有設計師。 目前，我基本上是歐洲投資銀行的一個小團隊中的一個 UX 團隊。 所以我是一名 UX 設計師。 我與一個由開發人員、業務分析師和所有優秀的人組成的團隊一起工作，但仍然是整個項目的一名設計師。

斯蒂芬妮：在我到達之前，沒有設計師。 所以這是一種在很多公司中實施的解決方案，尤其是在內部產品上。 他們通常會說，好吧，我們真的不需要設計師。 我們只需要對我們的內部用戶有用的東西，讓我們只使用一個框架，因為它對開發人員來說很方便。 大多數組件已經存在，並且由於團隊中沒有設計師，所以它有點取代 UI 設計師的角色。 是的，問題在於，好吧，那麼你就有了組件，但 UI 設計師的角色不僅僅是決定按鈕應該是紅色、綠色、橙色、藍色等等。 通常UI設計師的角色是信息架構，了解用戶需求。 所以一切超出了界面。 所以即使你有這種框架來處理整個用戶界面，所以在視覺上你在屏幕上看到的東西。

斯蒂芬妮：在某些時候你仍然需要有人來理解我們在屏幕上放了什麼，它會如何表現？ 當我們點擊這裡時會發生什麼？ 用戶如何實現他們的目標？ 我們如何從 A 點到 B 點？ 因為我們可以使用模型，我們可以使用選項卡，我們可以使用所有組件。 所以這就是為什麼它總是有點複雜和棘手。

Drew：有沒有可能，你認為能夠使用現成的 UI 框架創建一個可用的用戶界面，還是總是需要妥協？

斯蒂芬妮：我有點希望如此。 我有點希望如此，否則我正在構建不可用的接口。 所以這個答案是完全有偏見的，但是是的，我認為是，但這也取決於你願意做出的妥協程度，並且雙方都有妥協。 例如，目前我正在犧牲很多按鈕，因為您在 Material-UI 中有一些非常具體的按鈕，我不太喜歡按鈕上的漣漪效應。 我認為它在移動設備上效果很好，因為在移動設備上，當用戶點擊或觸摸按鈕時，你需要一種很大的反饋。 但是這些步驟是一種連鎖反應，一直在按鈕上。 這有點矯枉過正，尤其是當有很多按鈕時。 但是我們仍然會保留這種連鎖反應，因為移除它會非常複雜，因為它是內置在 React 框架中的。 並且在這個按鈕上有另一個懸停效果，更微妙的東西在這裡不會是這種令人毛骨悚然的東西。 這將是超級複雜的。

斯蒂芬妮：所以這就是你所做的妥協。 但與此同時，我不會在自定義組件的特定事物上妥協。 我以前工作的地方，是一家旅遊和航空公司的當前客戶。 航空公司有一些非常非常特別的需求。 例如，航空公司的日曆，你想放價格，你想放……如果你沒有在特定日期前往這個目的地，你不知道什麼時候放，你有這個出發和到達，大多數這些 UI 框架的基本日曆都沒有提供這些東西。 所以在某些時候你可以說，好吧，我們將只使用他們擁有的日曆。 就是這樣。 你需要超越這一點。 所以大部分的妥協基本上都是建立在基礎之上的，我們是不是使用了基礎組件呢？ 我們是否創建了一個適合用戶需求的自定義？ 還是我們將兩者混合？ 例如，在日曆的情況下，我們使用日曆網格，所以我們使用基本組件，然後我們在此之上通過自定義對其進行了增強。 所以那是很多 React 開發。

斯蒂芬妮：是的，所以通常你會做出很多妥協。

德魯：所以聽起來使用用戶界面框架可以讓你獲得一定程度的成功，但要真正擁有一個好的用戶界面，你需要在上面做一些定制嗎？

斯蒂芬妮：通常。 是的。

德魯：這種定制是否超越了主題？

Stephanie：是的，我的開發人員希望它不會超出主題範圍。 尤金 如果你聽我的話。 我想如果我們在每樣東西上改變一些顏色，他會非常高興。 但是，是的，在某些時候你需要超越定制，因為首先，就像 UI 框架一樣，樂高工具是一種工具箱。 所以你在盒子裡有很多不同的組件，但這並沒有建立一個頁面。 你仍然需要一個頁眉，你仍然需要一個頁腳。 您仍然需要框架中沒有的額外內容。 因此，有時您可以將組件調整為您需要的內容。 據我了解，我們正在使用卡片組件來構建模態窗口，但模態窗口的問題是它的行為並不像卡片。

斯蒂芬妮：你有點超出了這個範圍。 你需要一個模糊的背景。 您需要在點擊時觸發它，而通常您的卡已經在界面中。 所以我們使用這個卡片組件是因為它有很多我們需要的東西，比如背景，頂部的標題和標題，底部的一些按鈕。 所以我們有了結構，然後我們稍微調整一下。 但是我們有時會在語義、HTML 方面遇到一些衝突。 因為例如，我想要沒有按鈕形狀的按鈕，所以就像鏈接按鈕一樣，開發人員說，“好的，所以我們使用像你的 href 鏈接這樣的鏈接。” 我說：“不，這不是鏈接。 這是一個按鈕。 當他們單擊它時，它不會打開新頁面。 它清除了表格中的所有內容。”

Stephanie：所以從語義上講，它應該是一個按鈕。 “是的。 但它不存在於框架中。” 我說：“好吧，我知道我們該怎麼辦？” 所以通常你會開始討論這些小事情，因為我真的讓我的開發人員對可訪問性感到厭煩，這是另一個額外的嘗試，以確保我們擁有他們可以很好地工作的基本組件。 而且它們在語義上就像我不想在 gif 中的 gif 中使用帶有 gif 的按鈕。 否則我們最終會有問題。

Drew：我想開始一個將使用 UI 框架的新項目，你可能需要從某種用戶研究開始。

斯蒂芬妮：是的。

德魯：公平嗎？

斯蒂芬妮：你應該。 你需要。 所以是的，通常你可以擁有你想要的所有組件。 您仍然需要知道您的用戶在頁面上需要什麼，他們將如何導航？ 你需要建立一個流程。 所以通常甚至在決定一個框架之前，我們所做的就是去找我們的用戶，我們與他們交談，我們試圖了解他們的需求。 所以目前我很幸運，因為用戶在銀行內部。 所以我們和他們一起做了很多研討會，你必須想像這是一個超級複雜的界面。 我們正在從 10 甚至 15 年前構建的東西遷移到使用 Material-UI React 的全新閃亮的東西。 所以這是一個很大的變化，你必須明白，在這 15 年裡，每個想要東西的人都可以尋求支持，然後他們要求 IT 團隊實施。 因此，目前我的界面就像 400 頁，其中包含表格、表格內、表格內、其他表格以及甚至不應該在表格中的內容。

斯蒂芬妮：就像我們有很多東西只是關鍵價值，關鍵價值，關鍵價值。 所以他們用兩列構建表格。 我想，“不，也許我們可以做得更好。” 所以目前我們正在做的是我們做了一些用戶研究來了解用戶的不同目標。 所以我們確定的是他們對界面所做的事情，他們有一些規劃目標。 他們需要計劃他們的工作。 所以我想知道這個操作將去這個會議，所以我需要在那個時間表上，像這樣的東西。 他們想監控一件事，他們想報告數據。 所以監控就像查看數據並確保一切正常。 報告能夠利用數據，利用數據做一些他們想要分享的事情，並與同事進行協作，所有這些都是我們通過直接與用戶討論而發現的。

Stephanie：我們發現，實際上我們最終計劃遷移的一些事情對於用戶來說是每天最重要的事情。 所以規劃用戶目標是目前最大的一種。 所以我們真的，真的在努力。 所以是的，我們確實使用了面試，現在我們處於超高水平的階段，我們需要構建外殼，我們需要了解導航。 但目前我們並沒有真正檢查所有數據，這就是我們現在要做的。 這很有趣，因為我們有很多表格，我們說我們可以採用一種不聰明的方式，將表格放在新界面中就完成了，或者我們可以說，好吧，讓我們試著理解什麼這些表是，我們的用戶用這個表做什麼？

Stephanie：然後也許一些表格可以顯示為數據可視化，然後你需要了解整個業務，這樣數據才有意義。 所以如果你有一個不錯的框架，你說，好吧，讓我們使用這個圖表……我認為它被稱為圖表 JS 框架。 你有很多東西，你可以有直方圖、餅圖和圖形等等，但在某些時候你仍然需要一個設計師來幫助你做出決定。 好的，這些數據，如果我們將其顯示為圖表是否有意義，或者將其顯示為餅圖更有意義，因為我們想展示整體的一部分，或者我們想比較一個國家在過去 10 年的演變年，那麼直方圖更有趣。 因此，根據用戶想要對數據執行的操作，您將以完全不同的方式顯示它們。

Stephanie：通常這不是開發人員的工作。 我們的開發人員，他們是超級聰明的人。 我很抱歉，但我老實說與男性開發人員一起工作，我希望我有一些女士，但沒有。 他們都不是女性。 所以超級聰明的人，但他們不是超級有資格說，好吧，這個數據應該這樣顯示，那個，那個，那個。 所以最後你仍然需要一些設計師去和用戶交談，了解你可以用數據做什麼，這不僅僅是說，好吧，這應該是一個標籤欄，或者這應該是左邊的導航。

德魯：在根據與用戶交談做出這些決定之後。 您通常會將生成的原型或設計帶回給用戶以再次對其進行測試，以查看他們是否了解您選擇的圖表類型？

斯蒂芬妮：是的，我們實際上做了很多，這真的很好，因為在你知道它會有用和可用之前你不會開發一些東西。 所以這取決於。 如果實際上開發這個東西更快，因為他們已經有了大部分組件，我通常會做非常快速的紙質原型設計，然後我們開發這個東西，因為它很快，即使沒有數據。 如果它是複雜的，非常非常新的東西，需要花費大量時間來開發，那麼我們會說，好吧，我們設計幾個屏幕，然後直接在屏幕上進行一些測試。 所以我們有一個叫做 InVision 的工具，基本上你把所有的設計放在裡面，你可以在不同的部分之間創建鏈接。 問題是它還取決於您要測試的內容。 例如，如果您想測試手機，那麼在 InVision 中測試它們是一場噩夢，因為人們無法真正感受到它們，尤其是在手機上。

斯蒂芬妮：所以它總是有點聰明。 最快和最便宜的方法是什麼？ 只測試設計是否更快、更便宜？ 這夠了嗎？ 通常對於表單，並不是因為您已經自動完成了您在前端實際用戶填寫表單的所有繁重工作，因此對於表單，實際構建表單並對其進行測試可能更有效。 但是對於新事物，是的，我們做了很多設計。 我們去找用戶。 所以目前我們要么做一對一，但我的用戶真的很忙。 這是一家歐洲投資銀行，所以他們沒有那麼多時間。 所以我們通常做的是，如果我們與用戶進行一對一的交流，我們會舉行一些小型會議，更像是焦點小組。 這也很有趣，因為有時你會有一種對抗。 有些人說，“是的，我認為它對我有用，因為我就是那樣工作”，然後會有其他人說，“哦，你那樣工作？ 其實不，我就那樣那樣做。”

Stephanie：所以，讓幾個人在房間裡聽對話，做筆記並說，“哦，也許我們可以這樣做”和“這個組件會更好，基於我剛才的內容，這也很有趣聽到。” 諸如此類的事情。

德魯：如果您正在為您的產品與更廣泛的受眾合作。 所以也許不是像你這樣的內部用戶，而是更多的普通大眾，設計師有沒有廉價的方法可以利用研究？ 如果您不直接知道您的用戶將是誰，是否有更簡單的方法？

Stephanie：你應該知道他們將是誰，否則在構建產品之前它會完成營銷人員的工作。 但是，是的，我們進行了一些游擊用戶測試，例如，您仍然可以使用 InVision。 因此，您可以在 InVision 中構建一些原型，然後您可以通過社交媒體招募用戶。 我正在為一個有幫助的產品工作，叫什麼名字，汽車經銷商修理東西，然後還通知客戶額外的修理，諸如此類。 所以我們在 LinkedIn 和 Facebook 上已經有了一個不斷發展的社區。 所以你能做的就是招募這些人。 您可以進行遠程測試，就像我們在在線工具之類的工具中進行對話一樣。 你可以做一些屏幕共享。 所以我們也為一些項目這樣做了。

Stephanie：我只想給你一個建議是之前測試過這個工具，因為我正在使用它，它被稱為appear.in。 但我認為他們將名稱更改為 Whereby 之類的，但實際上是在瀏覽器中，我說，好吧，這很好，因為用戶不需要安裝任何東西，但用戶不是在真正的計算機上。 他們進入了 VM，進入了 Citrix，而且他們沒有麥克風，所以我們最終做的就像他們使用我的工具來共享屏幕一樣。 他們在點擊原型，同時我讓他們通過電話，就像固定電話一樣，直接與他們交談。 所以總是有，這是一個相當便宜的日子，因為這是招聘的美好一天，我想我們有 10 個用戶或類似的東西。 是的，即使你不能面對面，你也可以做很多事情，我已經直接在 Skype 或類似的東西上做了很多可用性測試。 所以總有一些便宜的方法可以做到這一點。

Drew：在選擇要使用的 UI 框架時，如果這是您要走的路線，那是您將只留給開發人員的事情，還是設計師也應該參與的事情？

斯蒂芬妮：對我來說，你應該讓整個團隊都參與進來。 像設計師、開發人員，如果你有一些架構師，也許還有架構師，因為框架的構建方式也可能會影響這些事情。 不幸的是，大多數時候當他們到達項目時，框架已經確定了。 不，實際上這很有趣，要么已經決定，要么他們要求我驗證他們對框架的選擇，但我沒有做任何評論或研究。 我完全不知道項目中有什麼，因為他們甚至沒有向我展示他們的屏幕。 他們就像，“是的，做你的事。 我們可以使用這個框架。” 我不知道。 好吧，我們有屏幕嗎？ 所以他們最終向你展示了幾個屏幕，這是他們想要遷移到雲中的 Windows 原生應用程序。 他們說：“是的，我們只需要按鈕，而且主要是表格之類的東西。”

Stephanie：但是真的很難說，“是的，選擇這個框架，我們擁有我們需要的所有組件。” 或者像，“如果你不知道你的內容是什麼，導航是什麼，就不要去。” 所以我認為在選擇你的框架之前你仍然應該有一個全局概覽，除非你 100% 確定你擁有所有的組件。 但是我有一種感覺，大多數時候框架的選擇基本上是基於開發者現在喜歡什麼技術，在此之前他們是否有使用框架的經驗？ 我們在一些項目中使用 Ant 只是因為一些開發人員有這方面的經驗，他們真的很喜歡它，而且他們使用 Ant 的效率很高。 對於 Material React UI，它也是一樣的。 這就像因為開發人員已經在以前的項目中使用過它，所以他們使用它很有效率。

Drew：因此，實際上必須在開發人員熟悉的內容、他們所知道的內容、將與他們的技術堆棧一起工作的內容以及產品在創建良好用戶界面方面的要求之間取得平衡。 而且您需要以某種方式平衡這兩者以找到理想的框架。

斯蒂芬妮：是的。 我對某個項目有一種特定的要求，那就是……我在盧森堡，我們有很多歐洲機構之類的東西，所以我們對其中一些有額外的可訪問性要求。 通常在決定框架時，他們並沒有真正檢查框架的可訪問性，然後他們在項目開始幾個月後回來說，“哦，剛剛告訴我們有這項新法律，我們應該可以訪問，但我們不知道該怎麼做。” 是的，現在有點晚了。 所以對我來說，要選擇一個框架，你需要真正了解項目開始時的所有約束，如果可訪問性是其中之一，你需要測試你的組件並確保它們是可訪問的。 但我不是 React 或 Angular 開發人員，但我很確定將不可訪問的 UI 框架變成可訪問的東西是非常複雜的。 我想重建所有組件可能有點複雜，所以就這樣。

Drew：如果您發現自己正在從事的項目尚未進行該過程並且已經選擇了 UI 框架，那麼是否存在用戶界面可能開始受到該框架中已經存在的組件影響的危險，而不是被用戶的需求所驅動？

Stephanie：真的，老實說，我參與的大多數項目最終都會有很多取捨，即使你真的很努力。 所以它主要是關於平衡和與開發人員討論。 所以通常我做的是我們做一些線框，甚至是快速的紙線框，說好的，在這個頁面上我們需要那個那個那個組件，我做的第一件事就是問開發人員我們的目前的框架？ 它是什麼樣子的？ 然後我們一起決定，好吧，這是一個可以完成工作的組件，或者好吧，這不會完成工作。 我們調整它嗎？ 就像我們仍然保留組件但稍微更改它以使其完成工作，還是我們從頭開始構建一些東西？

斯蒂芬妮：當然，最終這將取決於預算。 所以你最終做了權衡。 就像我會接受那些幾乎從未使用過的小組件，如果它們不完美並且幾乎沒有問題。 但是對於主導航，主要結構，例如你一直在屏幕上看到的東西，這真的需要工作。 用戶需要了解他們如何有效地工作，是的，正如您所說，如果您沒有任何框架，您希望獲得的理想體驗與您手頭的內容以及預算以及定時。 如果我們說，好的，對於這些 sprint，功能需要在這個 sprint 結束時完成，然後他們說，好的，但是如果你想要你的組件，我們永遠不會在這個 sprint 結束時完成這個功能，那麼你開始討論，好吧，我們是否在下一個屏幕中完成此功能，我們是否需要更多時間來正確完成？ 通常這真的取決於。

Stephanie：最讓我沮喪的是，當我知道我們使用了裁剪修復組件時，他們對我說，哦不，別擔心。 我們稍後會解決這個問題。 而且我知道，不幸的是，後來的事情可能永遠不會發生。 所以要看團隊。 但過了一段時間你有了經驗，你知道，這會遲到嗎？還是不會？ 是的，這是關於妥協。 當您使用這些工具時。

Drew：作為一名開發人員，我喜歡 UI 框架的一件事是它們通常帶有默認樣式。 所以這意味著我不一定需要一個設計師來幫助我設計所有組件的外觀和感覺。 這是我們應該在項目中依賴的東西嗎？ 只是默認樣式並相信製作框架的人在設計這些組件方面做得非常好？ 或者您會自己設計這些組件的樣式嗎？

斯蒂芬妮：我認為這真的取決於。 例如，Material-UI 的問題是您的網絡應用程序的外觀和感覺基本上是配置的 Google 產品。 因此，如果您實際上不更改字體，更改一些顏色並帶上您自己的品牌標識並這樣做，那麼您將擁有一個看起來就像任何 Google 產品的產品，這可能是一件好事，因為如果您的用戶已經習慣了 Google 產品，這可能有助於他們理解它。 所以通常如果你團隊中沒有設計師，你有什麼選擇嗎？ 就像我見過的許多不同的作品一樣，它們帶有自定義主題，因此至少您可以更改顏色。 我認為您也可以很容易地更改字體。 但同樣，如果你改變顏色並且你不擅長設計甚至可訪問性，也許你將使用的顏色會發生衝突，它們可能會有對比度問題。

Stephanie：例如，我喜歡橙色，但它是最令人討厭的顏色之一，因為要擁有真正易於使用的橙色，例如，作為帶有白色文本的按鈕，它看起來幾乎是棕色的。 如果你想擁有這個真正閃亮的橙色，你需要在它上面加上深色文本以使其可讀，但它會讓你的界面在一天結束時看起來像萬聖節。 是的，我看到你在笑。 但這是真的。 所以它總是關於這些妥協，如果你是一個開發者，你想使用框架，而你沒有設計師，我認為它仍然比沒有任何東西並從頭開始構建它要好然後使用起來超級複雜。 但問題是，僅僅因為您擁有組件並不意味著您將構建一個出色的界面。 就像樂高積木一樣。 如果你有樂高積木，沒關係，但你可以做一個真正好的宇宙飛船，或者你可以做一些不能結合在一起並且會因為你沒有真正的計劃而分崩離析的事情。

Stephanie：所以設計遠不止這些。 設計是關於真正了解屏幕上的內容，它將如何工作。 我認識一些真正有能力做到這一點的開發人員。 所以他們非常擅長可用性指南，並且他們了解很多設計規則，例如。 因此，在選擇組件時，他們真的很擅長。 我知道開發人員不知道要選擇什麼組件並選擇第一個完成這項工作的組件。 但是過一段時間就不行了。 例如，就像選項卡一樣，我們有一個界面，一些開發人員可以在其中選擇選項卡。 我認為一開始只有三個項目是有意義的。 但是然後屏幕上有 12 個項目，然後你有三行選項卡的選項卡，所有這些都是相同的一級選項卡，並且選項卡內有選項卡。 所以他們有了組件，它看起來不錯，因為他們使用了框架，但它並不是真正可用的。

Stephanie：例如，我也有類似的模態窗口。 他們在沒有設計師的情況下構建項目的地方，過了一段時間，我認為客戶要求越來越多的東西進入這個模式。 所以他們最終得到了一個帶有表格的屏幕，當你點擊添加一行時，你打開一個模式，在這個模式中你有兩個選項卡，然後在其中一個選項卡中你甚至還有另一個表格，然後他們想要添加一個額外的東西，我想，好吧，也許我們可以把一個模態放在一個模態之上。 並且在某些時候設計師會回答，好吧，如果你在模態中有這麼多的內容，它不應該是一個模態窗口。 它應該是一個頁面。 因此，即使您擁有組件，您仍然需要某種架構師來製定計劃並確保所有這些組件都能很好地協同工作。

Drew：所以如果作為一名設計師，你被要求改變一些組件的樣式，你會嘗試改變所有的樣式嗎？ 您會自定義所有內容，還是會關注某些領域？

斯蒂芬妮：我認為顏色是你首先看到的東西，顏色實際上可以給你帶來身份。 如果您有一個強大的品牌標識，至少在按鈕或圖標上使用產品的顏色或類似的東西，已經可以幫助您自定義框架。 字體，因為我認為這很容易，如果框架構建良好，通常你會在某個地方更改整個字體系列，然後它應該在網站的其餘部分上層疊。 所以顏色和字體是我認為快速定制框架的兩種簡單方法。 圖標是另一種帶來個性的好方法，但這可能很困難，因為據我所見，大多數框架都帶有自定義圖標或 Font Awesome 或已經內置的庫。所以要替換這些，首先你需要一個很多圖標，如果你想全部替換它們。 所以它可能有點複雜。 我還看到了允許您選擇要使用的圖標包的框架。 比如 Font Awesome、Glyphicons 和其他一些。 所以這是你可以很容易地定制的東西。

Stephanie：然後是外觀和感覺，例如頁眉，通常你有不同類型的頁眉、頁腳。 你如何導航這樣的事情。 因此，您已經可以進行很多小的自定義，使其看起來不像 Material-UI-ish，它更像您的品牌，然後您可以使用例如邊界半徑。 無論您想要完全圓形的按鈕，還是想要方形按鈕，或者您也想要中間的東西，比如陰影。 因此，一些通常很容易定制的小東西，因為大多數框架都將它們放在 CSS 變量中。 除了這些連鎖反應之外，我認為這是您無需付出很多努力就可以自定義的那種小東西。 我討厭那個。 我要與之抗爭。 我有點希望他們最終改變它。

德魯：我想像這樣的事情，看起來很明顯可能看起來就像表面水平效應，你認為這很容易改變，而在這種情況下，事實證明它不容易改變？ Is that just a case of speaking to your developers to find out what's going to be easy to customize and what's not going to be easy?

Stephanie: Yeah, usually, especially if they're used to work with the framework, they know what's easy to change on it. It depends on the developer, I had discussion with one developer and I asked him if we can not have like uppercase buttons, because they are kind of a little bit hard to read, especially in the font we were using, he went into the documentation and say, I don't know if we can customize it because I can't see it in the API. I was like, what API? It's like CSS class, CSS definition. You remove the uppercase from the CSS and it's done. So he was like looking for an API to change just the font, how does the font look like. And I was like, yeah, but if there's no API for that, I think you can change it in CSS.

Stephanie: But then it's complex because if you have to change this in like all of the CSS line. So it's usually kind of a big discussion. It was the same… was like drop downs. So Material-UI, the React version we use, has some customized drop downs. So when you have a select box like form element, the select it opens these custom components and I don't know why but we have a big problem with that on Internet Explorer. We are going to migrate to windows 10 and Edge. I'm looking forward to it, but we are still Internet Explorer 11 at the moment. And what's happened is whenever you use or you open one of those components, it freezes the screen behind it and you have a scroll bar, so it kind of jumps around whenever you want to use one of those.

Stephanie: And at some point we discuss with the developer, is the customizing of that worth the screen jumping around whenever users click on that. And it's like, honestly for me, no, I prefer it not to jump and we use the select in the browser, then it will not look the same if our users have Edge and, no not Edge, IE. Or if some users are using Firefox, okay? So it will not look the same but it will be the native one and it will not make the page jump around every time someone clicks. So it's this kind of discussion also, do we want to customize it but then it's kind of clumsy or do we say, okay we are not going to customize it. We had the same debate with a scroll bar because we had another project we had drop-downs and they were 100 elements at some point in the drop downs. So there's an auto complete but you can still scroll inside the drop down. And the developer said, yeah but this is looking really ugly on IE, the default scroll bar.

Stephanie: And they investigated, they found JavaScript library that would let us have this really small little a scroll down you have on Mac and have it everywhere. Then we said, okay, is it worth investigating? We need to investigate, test it, put it everywhere, test all of the browsers. So we said we are going to do it, but only if it doesn't damage the performance and if he doesn't damage the rest of your experience, otherwise it's perfectly normal that the browser element don't look the same on any browsers. So at the end, don't customize everything.

Drew: I guess it's a collaborative team effort, then? Everyone needs to discuss and balance up again all the different performance factors, ease of customization and where that customization happens. So once you've got your UI framework in place, you've got all your components specified and built out and customized and styled to how you want them. I guess you need to document that in some way to maintain consistency?

Stephanie: So at some point as a designer what we usually do, we already document them in our sketch files. So we have the working files with every single screen and everything. And in the sketch files we have really specific art boards where we put all of the different components. So that if another designer works on the project, they know that the components already exist and they can just drag and drop it in a new page and reuse it afterwards. So we have this system where we document the components also we document the use, like when do you use this component? When do you use that one? Where is this one working better? So all of the different states for instance, like inputs, we have I think 10 of those, like a focus with a placeholder, without a place holder, with content like arrows and things like that. So again, we bring consistency and then the development parts, it really depends on the kind of maturity of the communication of the team. So what we are currently building is basically a library of components and we are also building the tool around it.

Stephanie: So my developer is currently building that and the idea is to build the component first in our kind of a sandbox, document it. Also he builds things where you can change the colors and if have a button for instance, you can change the icon, you can change the text to see if it will still work with longer text, smaller text, things like that. So we are building this sandbox and in the sandbox, you have a 'Read me' tab where you have documentation for how should this look, how should this component be used, when, how is it supposed to behave? Like auto complete for instance, seems to be something really, really easy, But if you start actually designing the flow of the auto complete, what happens when you put the focus in the field? Do you start auto completing or offering suggestion after one character after two, after three? If it's after three, what happens in the meantime?

Stephanie: So there's a lot of different questions about that that we also document, which is really going super deep into that so that if this auto complete gets implemented on another project or gets used by another team, they know exactly how it's supposed to work as well. So we kind of do the same. The two of us, so designers are documenting into the design tools and usually in the design tool we document the colors and shadows and gradients so that the developer don't have to look around and try to remember exactly what the hexadecimal code for this button was and things like that. So in the end it's kind of you have this UI framework that was super generic and you customized it, you made sure that the components you use are actually the ones that are going to help your user accomplish their goals.

Stephanie: Everything you've customized is kind of starting to become your own little design system. So at the end you're building a design system, but instead of building it from scratch, you're basically building it using React, Material or, what was the other one? Ant or something like that. So it's the same constraints.

Drew: Would you go back to user testing at this point after things have actually been built? Would you go back and test things with users again?

Stephanie: We have tests, like real people testing, like regression testing and making sure that everything works. Like when you click it works, when you hover it works, stuff like that. But yes in the end, especially if we didn't do a prototype, if we did the user testing in mockups, we want sometimes to test it again with the real users who have a feeling that everything is still working. So yeah, sometimes we go again into user testing at the end. We do that usually at the end of a few sprints where the features were implemented. So usually what happens is like we do the research, we design the feature into design tools, we do quick testing at the beginning, then it's implemented, we do tests to make sure it works. And then again we go back to the users.

Stephanie: And it's also interesting because we are building a community with the users. So they're actually quite eager to see that. The first testing was a little bit kind of a sneak peek, like, Oh, this is what it might look like. And then they are super curious about how it works and how it looks like at the end. So we go back usually in one-on-one testing for that or if we don't have the time, we do just like panels and also we deploy it. So sometimes we do AB testing also sometimes if we don't have time for the user testing one-on-ones, we deployed it and then we say, okay, it was deployed. If you have any feedback, please come back to us. Also if you see bugs, because sometimes we compete, the team missed a bug or something, so if we don't have time for re testing it, we still try to find and manage to find some ways to gather feedback even after it's deployed.

Drew: And over time, one of the things that might be a concern probably from a technical point of view is that you've built on top of a UI framework and then a new version of that framework comes out and things have changed. Is that a situation that you've experienced where a new version has come, your developers want to update but it might have implications on the design?

Stephanie: Yeah. The thing is we have test environments, so they're really quick and easy thing to do is like, okay, let's put in your version in one of those secure environment and see what is broken. So from when designers most of the time when they do a new version they tell developers, is it going to break? Like is this new version something completely new and it's not compatible with the old version? Or is this new version something that is just an announcement and you might not break that many things. So yeah, obviously sometimes when you put a new version it completely breaks, but this is again, then you have like testing stories and like technical investigation stories to decide if we are going to migrate or not. Also like from what I understand in some of the environment I worked on, they kind of encapsulated those in web components.

Stephanie: So they're already has kind of two different version of Angulars on some components, it was using one version on the other ones it was using the other one and from what I understood it works because then you only encapsulate what you need. So this apparently is also a solution is then you can use whatever version you want, but I'm not a developer but I feel at some point you'll be like, okay, this component is using that version of Angular and this one, this and this maybe kind of becomes super hard to maintain. 你知道嗎？

Drew: Yup.

Stephanie: It does. 好的。 So yeah, you make sure it still works, but I don't have the feeling that Material-UI are like those frameworks, even bootstrap for instance, they don't have any new version every year or something. It's a long lifecycle and in the case of my tool, I think this tool will be here for the next year, so we have eventually to update. But if you're building kind of a online tool, more like a B to B product. Most of the time you revise every three years or something. And usually there is a new technology. I was talking to a friend and they're currently working on a project where they're rebuilding and riffing on React. The first version was built three years ago with another technology. I really don't remember the technology, but they say, okay, we are three years later, they're already rebuilding it. And I think in like three years, they will re-rebuild it. So at some points if you're in like in B to C products, I even wonder if you update your framework or if you are going to change the design and rebuild it anyway in a few years from scratch.

Drew: Is there anything else that we should be considering when building on a UI framework?

Stephanie: I feel we covered a lot of things. Well, the thing is like, there's always a way to do it quick, user research, talk to users or at least do usability testing. Make sure you don't design or build in a silo and try to have other people at least look at what you've created to make sure that the components as a developer, that you used as a developer I really do wonder are going to do the job. And don't ask the designer to put paint on top of the framework at the end of the project because it's kind of already too late to do big infrastructure on changes. It might not work.

Drew: So at Smashing, we have books, we have conferences, and of course, we have Smashing Magazine, a website with loads of articles. We're all about learning. So what is it that you've been learning lately?

Stephanie: I've been taking online introduction to psychology class.

Drew: Tell us a bit about that.

Stephanie: Last lesson was actually super interesting. We were talking about visual illusions and how they work with your brain. So it's really super complex and there's… Apparently not everyone agrees on the explanation of most of those illusions, but it's interesting because I had a small psychology lesson, like I read books on cognitive sciences and things like that. So I already knew kind of the basics, but it's interesting to see like all the different aspects of psychology. So the interesting part of this course is it's an introduction but it explains to you kind have all the branches from say child development psychology to trauma psychology to intercultural psychology. So and then illusions and I think this week it's actually about cognitive psychology and how to apply psychology to interfaces. So all of those really, really interesting topics. And it's nice because it's an online class, so I'm basically learning stuff on my couch with some tea, and yeah, that's really, really cool.

Drew: Oh, that's super interesting. If you, dear listener, would like to hear more from Stephanie. You can follow her on Twitter where she's @WalterStephanie, or find her on the web at stephaniewalter.design. Thanks for joining us today, Stephanie. Do you have any parting words for us?

Stephanie: Thanks for having me. It was a smashing experience.