In this post I’ll explain the first phase of creating our Babylon DNA, the design system for Babylon Health, and how we moved the Babylon design team from Sketch to Figma.

在這篇文章中，我將解釋創建巴比倫DNA的第一階段，巴比倫健康的設計系統，以及我們如何將巴比倫的設計團隊從Sketch轉移到Figma。

If you work in the digital design industry, you’ve more than likely read a dozen articles about the big transition from Sketch to Figma, it’s nothing new.

如果您從事數字設計行業，那么您可能已經讀了十幾篇關于從Sketch到Figma的重大過渡的文章，這并不是什么新鮮事。

However, in this post I’ll walk you through the difficulties the team were facing using the previous setup, why we selected Figma, and what we’re still learning.

但是，在這篇文章中，我將向您介紹團隊使用以前的設置所面臨的困難，我們為什么選擇Figma以及我們仍在學習什么。

In July 2019 I joined Babylon with the task of starting to create Babylon DNA — Babylon Health’s new design system. As a new designer in a fast-growing business, it was essential for me to get up to speed quickly and efficiently. To do that, I had to look at the tools being used by the design team, their ways of working, and the condition of the existing design system and pattern libraries.

在2019年7月，我加入了巴比倫，開始創建巴比倫DNA(巴比倫健康的新設計系統)。 作為快速發展的業務領域的新設計師，對我而言，快速高效地起步至關重要。 為此，我必須查看設計團隊使用的工具，它們的工作方式以及現有設計系統和模式庫的狀況。

My main focus was to streamline and improve the native iOS and Android design libraries and the tools the team were using. It was crucial to communicate with the design and engineering teams to understand what was working well, what wasn’t, and to analyse the existing process.

我的主要重點是簡化和改進本機iOS和Android設計庫以及團隊使用的工具。 與設計和工程團隊進行溝通以了解什么有效，什么無效以及分析現有過程至關重要。

設計師面臨的障礙 (The obstacles our designers faced)

After speaking with the existing design team, we identified several areas of concern. The most notable amongst designers was the sheer number of design tools they had to work with.

與現有設計團隊交談后，我們確定了幾個需要關注的領域。 在設計師中最引人注目的是他們必須使用的大量設計工具。

On a day-to-day basis, our designers were reliant on multiple tools including Sketch, Miro, Zeplin, Abstract, Invision, JIRA and other methods of prototyping. Designers using this amount of software is not uncommon, and it was clearly causing issues here at Babylon.

在日常工作中，我們的設計師依賴多種工具，包括Sketch，Miro，Zeplin，Abstract，Invision，JIRA和其他原型制作方法。 使用這種軟件的設計人員并不少見，這顯然在巴比倫引起了問題。

Designers were also working from multiple, unmanaged Sketch libraries. We spent some time observing our designers, watching them try, painstakingly, to use the Sketch set up. We found it took them longer to find components than to design the actual screens. With no ownership over these libraries, they had become extremely difficult to navigate and use.

設計人員還使用多個非托管的Sketch庫進行工作。 我們花了一些時間觀察我們的設計師，辛苦地看著他們嘗試使用Sketch設置。 我們發現查找組件要比設計實際屏幕花費更長的時間。 由于沒有這些庫的所有權，因此它們變得非常難以導航和使用。

Once designs were completed, they were uploaded and split between two design hand-off tools, Abstract and Zeplin. With both being used it was incredibly difficult to know which tool an image had been uploaded to, and where it could be found.

設計完成后，將它們上傳并在兩個設計移交工具(摘要和Zeplin)之間拆分。 兩者都使用時，很難知道圖像已上傳到哪個工具以及在哪里可以找到。

Zeplin had become a dumping ground for design and there was very little management of it within the team. Not all screens were tagged and many designs would sit under ‘untitled’ sections, making it extremely difficult for anyone to navigate.

Zeplin已成為設計的垃圾場，團隊內部對其的管理很少。 并非所有屏幕都帶有標簽，許多設計都位于“無標題”部分下，這使任何人都很難導航。

And many of the team had come to loathe the combination of Sketch and Abstract, too. It had become painfully slow and frustrating to use, and designers felt it hindered the speed with which they could work. Its consistent ability to lose and failure to commit work had earned it a bad reputation with the design team.

許多團隊也討厭素描和抽象的結合。 它變得非常痛苦，使用緩慢，令人沮喪，設計師感到它阻礙了工作速度。 它一貫的失落和失敗的能力在設計團隊中贏得了良好的聲譽。

A lack of documentation and rules around existing components was causing complications. It was unclear what existing components or patterns were for, or how they should be used. As a result, components were being used incorrectly and implemented in products and scenarios they were never intended for. Designers were calling out for clear documentation and a dedicated design systems team.

缺少有關現有組件的文檔和規則導致了復雜性。 目前尚不清楚什么是現有的組件或模式，或如何使用它們。 結果，組件使用不當，并在原本不希望的產品和方案中實現。 設計師們呼吁提供清晰的文檔和專門的設計系統團隊。

沮喪的工程師 (Frustrated engineers)

Designers weren’t the only ones feeling frustrated. With no access to the Sketch libraries, our native engineers had zero visibility of what our designers were designing from. They were reliant on the files in Zeplin and Abstract being up to date.

并非只有設計師感到沮喪。 由于無法訪問Sketch庫，我們的本機工程師對設計師的設計幾乎沒有任何了解。 他們依賴Zeplin和Abstract中最新的文件。

Design focused on iOS first and then Android, with iOS design patterns often filtering into Android designs. Engineers were not being included in the design process and would only see designs at the hand-off stage. At this point, there was often back and forth, as engineers and designers had to agree a compromise between what had been designed and what could be implemented. This lack of transparency was fundamentally reducing the speed of delivery.

設計首先關注iOS，然后關注Android，而iOS設計模式通常會過濾到Android設計中。 工程師沒有被包括在設計過程中，只能在交接階段看到設計。 在這一點上，經常會來回走動，因為工程師和設計師必須同意在設計內容和可以實施的內容之間做出折衷。 缺乏透明度從根本上降低了交付速度。

We also discovered that our native engineering teams had access to their own extensive UI galleries that our designers were unaware of. Set up by Maxime Mazzone and Sergey Shulga, the galleries contained all the core UI components. These galleries also had ‘unsupported components’ which were not intended for widespread use. The main purpose of these galleries was to provide visibility of all components that had been created.

我們還發現，我們的本機工程團隊可以訪問自己的廣泛的UI畫廊，而我們的設計師對此并不了解。 畫廊由Maxime Mazzone和Sergey Shulga共同建立 ，包含所有核心UI組件。 這些畫廊還具有“不支持的組件”，這些組件不打算廣泛使用。 這些圖庫的主要目的是提供所有已創建組件的可見性。

“We just wanted to list what was available for our engineers. After a few weeks we added the ‘unsupported components’ as a request from Android engineers that wanted to know all the components, not only the official ones.”

“我們只是想列出我們的工程師可以使用的功能。 幾周后，我們根據Android工程師的要求添加了“不受支持的組件”，這些工程師希望了解所有組件，而不僅僅是正式組件。”

Maxime Mazzone, Android Software Engineer

Android軟件工程師Maxime Mazzone

需要什么？ (What was needed?)

Our initial idea was to clean up the existing libraries and hand-off tools. But this still would not have solved problems such as the lack of collaboration, and would not have made our design libraries visible to our engineers.

我們最初的想法是清理現有的庫和切換工具。 但這仍然無法解決諸如缺乏協作之類的問題，也不會使我們的設計庫對我們的工程師可見。

It was clear that we needed a fresh start, and we needed to provide our designers, engineers and squads with a better experience when designing and building healthcare products. Collaboration was key, and we needed to identify a viable tool or process that would encourage this.

顯然，我們需要一個新的起點，我們需要在設計和制造保健產品時為我們的設計師，工程師和班子提供更好的體驗。 協作是關鍵，我們需要確定一個可行的工具或流程來鼓勵這一點。

Someone needed to own this work, too. Teams across Babylon needed a central point of contact for libraries, components and the design system.

也需要有人擁有這項工作。 巴比倫各地的團隊需要圖書館，組件和設計系統的中心聯系點。

Moving away from Sketch was our starting point.

遠離Sketch是我們的出發點。

實驗Figma (Experimenting with Figma)

To begin with, we considered 2 options; Figma or Framer. We feared that Framer would involve too much upskilling and we needed the team to adapt quickly and efficiently. So me, Daniel Souza, Chris Clarke, Ed Russel, Romi Fellows and Joao Araujo experimented with Figma.

首先，我們考慮了2個選項： Figma或成幀器。 我們擔心Framer會涉及過多的技能提升，因此我們需要團隊快速有效地適應。 所以我， 丹尼爾·索扎 ( Daniel Souza) ， 克里斯·克拉克 ( Chris Clarke) ， 埃德·羅素 ( Ed Russel) ， 羅米 ·費洛斯 ( Romi Fellows)和喬奧·阿勞霍 ( Joao Araujo)對Figma進行了試驗。

We listed the pros and cons of our current set up and used that as a benchmark to see if Figma could work for us. The pros eclipsed any cons we could find.

我們列出了當前設置的優缺點，并以此為基準來查看Figma是否可以為我們工作。 優點使我們找不到任何缺點。

Here are just a few of the benefits we identified:

以下是我們確定的一些好處：

• By virtue of being browser based, Figma allows access to files anywhere with an internet connection; perfect for working remotely, our international teams, and sharing files throughout the business
  通過基于瀏覽器，Figma允許通過互聯網連接到任何地方訪問文件； 非常適合遠程工作，我們的國際團隊和在整個企業中共享文件
• Multiple users can work on the same file, all with different access requirements
  多個用戶可以處理同一個文件，所有文件都具有不同的訪問要求
• It offers a commenting and tagging feature
  它提供了注釋和標記功能
• It lets you add descriptions to components
  它使您可以向組件添加描述
• Figma’s speed and performance is significantly better than Sketch
  Figma的速度和性能明顯優于Sketch
• Existing Sketch files can be uploaded
  可以上傳現有的草圖文件
• Lots of useful library features, like version control
  許多有用的庫功能，例如版本控制
• Figma is set up in a similar way to Sketch, so in theory the move could be straightforward and would only require a small amount of upskilling.
  Figma的設置與Sketch相似，因此從理論上講，此舉很簡單，只需要少量的技能培訓即可。
• Built in analytics tools let us see how people are using the libraries
  內置的分析工具可讓我們了解人們如何使用圖書館

After experimenting and using the list of pros and cons, our decision was made: we were going to move to Figma.

經過試驗并使用了利弊清單后，我們做出了決定：我們將移至Figma。

使用Figma重新創建UI畫廊 (Recreating the UI galleries with Figma)

Initially we decided to focus on creating the component libraries for Android and iOS.

最初，我們決定專注于為Android和iOS創建組件庫。

We could have simply uploaded the existing Sketch libraries into Figma and continued from there, but we wanted to test Figma in its entirety. We agreed to bypass existing files from Sketch, Zeplin and Abstract and start again using what was in our coded native UI galleries.

我們可以簡單地將現有的Sketch庫上載到Figma中并從那里繼續，但是我們想對Figma進行整體測試。 我們同意繞過Sketch，Zeplin和Abstract中的現有文件，并再次開始使用編碼的本機UI畫廊中的內容。

Working with Maxime and Sergey, it was crucial the master components in our new Figma library matched what was in the UI galleries already built. The master component would live within the library, and designers would be using a copy of the component in their designs.

與Maxime和Sergey一起工作，至關重要的是，我們新的Figma庫中的主組件必須與已經建立的UI庫中的組件相匹配。 主組件將位于庫中，而設計人員將在設計中使用該組件的副本。

Using Figma’s sharing and comments feature ensured that everyone had visibility of progress, and that we could provide direct feedback on a component if it was incorrect. I also introduced a post-it note component to highlight important aspects that needed to be addressed. The fact that Figma is browser-based allowed us all to interact and participate in the file at the same time, which was invaluable as Maxime works remotely in a different part of the UK.

使用Figma的共享和評論功能可以確保每個人都可以看到進度，并且如果組件不正確，我們可以提供直接反饋。 我還介紹了便利貼組件，以突出需要解決的重要方面。 Figma基于瀏覽器，這一事實使我們所有人都可以同時互動和參與該文件，這對Maxime來說是無價的，因為Maxime在英國的其他地區進行遠程工作。

我們的Figma設置 (Our Figma setup)

Our setup consists of four core libraries; 00 Global, 01 Web, 02 iOS and 03 Android. Owned by the design system squad, only certain users have access to edit to the master components.

我們的設置包括四個核心庫。 00 Global，01 Web，02 iOS和03 Android。 由設計系統小組擁有，只有某些用戶有權編輯主組件。

The 00 Global library is arguably our most important library. It hosts the foundations of our products including colours, icons and will soon contain illustrations. 00 Global feeds our iOS and Android libraries, any alterations we make here then filter down into the libraries that are linked to it. Approaching it this way reduces any unwanted potential rebranding, colour or iconography updates to the component libraries.

00 Global庫可以說是我們最重要的庫。 它包含了我們產品的基礎，包括顏色，圖標，并將很快包含插圖。 00 Global提供了我們的iOS和Android庫，我們在這里進行的任何更改都將過濾到與其鏈接的庫中。 以這種方式進行處理可減少對組件庫的任何不必要的潛在品牌重塑，顏色或圖標更新。

We had to add our text styles to each of the specific platform libraries. Currently we use different fonts; Roboto for Android, San Francisco (SF) for iOS and Visuelt for Web. Ideally we would use one type style across all platforms, and host this within the 00 Global library.

我們必須將文本樣式添加到每個特定的平臺庫中。 當前，我們使用不同的字體。 適用于Android的Roboto，適用于iOS的San Francisco(SF)和適用于Web的Visuelt。 理想情況下，我們將在所有平臺上使用一種字體樣式，并將其托管在00 Global庫中。

For our native libraries we included larger type sizes, so that designers can see how their designs work if a user has larger accessible sizes selected. This is similar to what I did in a previous role, instead of just text we included components with larger text sizes to illustrate the importance of accessibility when designing layouts.

對于我們的本機庫，我們包括了較大的字體大小，以便設計人員可以查看如果用戶選擇了較大的可訪問大小的設計工作。 這與我上一個職位的工作類似，而不僅僅是文本，我們包括了具有較大文本大小的組件，以說明設計布局時可訪問性的重要性。

We consciously avoided the popular atomic model in the setup of our component libraries. We needed to highlight the vast number of components we already had available to use. It also meant we could organize our components more effectively by displaying and naming them by function, like app bar, banner or bottom navigation, making them easier for designers to find.

在組件庫的設置中，我們有意識地避免了流行的原子模型 。 我們需要強調我們已經可以使用的大量組件。 這也意味著我們可以通過按功能顯示和命名組件(例如應用欄，橫幅或底部導航)來更有效地組織組件，從而使設計師更容易找到它們。

All components are organised within frames. Each frame acts as the grouping for that particular component — containing any variants and applications — as well as making it easier to scan and identify components. Organising within frames also lets us include lightweight documentation and examples of components to show how they should be used — for example, highlighting the different rules for using separators on iOS and Android.

所有組件都組織在框架中。 每個框架都是該特定組件的分組-包含所有變體和應用程序-并使掃描和識別組件更加容易。 在框架內進行組織還可以使我們包括輕量級文檔和組件示例，以顯示應如何使用它們-例如，突出顯示在iOS和Android上使用分隔符的不同規則。

At a component level we applied and set up the correct constraints so that we could define how components react when they’re resized. This allows designs to be tested across varying screen sizes.

在組件級別，我們應用并設置了正確的約束，以便我們可以定義調整大小后組件的React方式。 這樣可以在不同的屏幕尺寸上測試設計。

Components can be updated using different instances, for example replacing one alert style with another. Instances within a component can also be updated, an example being updating or removing an icon.

可以使用不同的實例來更新組件，例如用一種警報樣式替換另一種警報樣式。 組件內的實例也可以更新，例如更新或刪除圖標。

雪花 (Snowflakes)

These are components that we think are useful, but aren’t quite ready for widespread use in the component library.

這些是我們認為有用的組件，但還沒有準備好在組件庫中廣泛使用。

We adopted the term ‘Snowflake’ based on the article ‘Design Systems: Why Snowflakes Are Counterintuitively Integral’ by Mike Rivera. However, our ‘Snowflakes’ were inspired by the existing work in the Android UI gallery and their non-supported UI area. This area was already acting as a ‘Snowflakes’ section within our coded UI gallery. To provide greater visibility we decided everything would go into our Figma libraries, and created a ‘Snowflakes’ page.

我們根據Mike Rivera的文章“ 設計系統：為什么雪花是反直覺的整體 ”采用了“雪花”一詞。 但是，我們的“ 雪花 ”靈感來自Android UI畫廊及其不支持的UI區域中的現有作品。 該區域已經在我們的編碼UI畫廊中充當“雪花”部分。 為了提供更大的可見性，我們決定將所有內容都放入我們的Figma庫中，并創建了一個“ 雪花 ”頁面。

We wanted to demonstrate that the new libraries would not hamper creativity, and instead show that we actively encourage it.

我們想證明新圖書館不會妨礙創造力，而是表明我們積極鼓勵它。

We still ask creators to add some basic documentation to their Snowflakes though, so it’s clear to everyone what each element is and what it’s being used for.

我們仍然要求創建者在其Snowflakes中添加一些基本文檔，因此每個人都清楚每個元素的含義和用途。

零高度 (Zeroheight)

Whilst creating components in Figma, we synchronized the completed components to Zeroheight; an online platform teams can use to create and maintain design system documentation.

在Figma中創建組件時，我們將完成的組件同步到Zeroheight。 一個在線平臺團隊可以用來創建和維護設計系統文檔。

Zeroheight allowed us to quickly create documentation and share it with the wider team. The tool was extremely impressive and worked well with Figma, making updates easy.

Zeroheight使我們能夠快速創建文檔并與更廣泛的團隊共享。 該工具給人留下了深刻的印象，并且與Figma配合良好，使更新變得容易。

This was an interim solution until we were in a position to share the Figma libraries throughout the business and had a dedicated team to build our own platform, which would give us more flexibility.

這是一個臨時解決方案，直到我們能夠在整個業務中共享Figma庫并擁有一個專門的團隊來構建我們自己的平臺，這將為我們提供更大的靈活性。

發行Figma (Releasing Figma)

During the process of recreating the libraries, a few members of the team had access to test them out, most notably Joao Araujo. Joao tested components, the library and file structures for us, and he even generated a pain and gains file in Figma to share his feedback

在重建庫的過程中，團隊的一些成員可以對其進行測試，其中最著名的是Joao Araujo。 Joao為我們測試了組件，庫和文件結構，他甚至在Figma中生成了一個痛苦和收獲的文件來分享他的反饋

We then started the rollout with one squad using the Figma libraries. The rollout was gradual, with our US team based in Austin being one of the first adopters. We collated feedback from our first set of users, and quickly rectified any inaccuracies or issues with components.

然后，我們使用Figma庫以一個小組開始部署。 部署是逐步進行的，我們位于奧斯丁的美國團隊是最早采用該軟件的人之一。 我們整理了第一批用戶的反饋，并Swift糾正了任何不正確或組件問題。

Moving individual squads over gradually meant we could identify and solve any problems early on. It allowed us to answer and resolve any concerns about the libraries and Figma in smaller batches and in greater detail.

逐步移走各個小隊意味著我們可以及早發現并解決任何問題。 它使我們能夠以較小的批次并更詳細地回答和解決有關庫和Figma的任何問題。

After this, we were confident enough to roll Figma out to each squad ready to use the libraries. Before releasing globally we included a ‘Getting started’ guide for new users to Figma and our libraries, which explained how the libraries worked, the file structure used, and who to contact for support.

此后，我們有足夠的信心將Figma推廣到每個準備使用庫的小組。 在全球發布之前，我們包括了一個供Figma和我們的庫的新用戶使用的“入門指南”，其中解釋了庫的工作方式，使用的文件結構以及與誰聯系以獲得支持。

Figma自動版式 (Figma Auto Layout)

Figma also released a new feature just before launch, Auto Layout. Auto Layout ‘allows you to create dynamic Frames that respond to their contents’. In simple terms, if your content needs to grow, then Auto Layout will respond and grow with it.

Figma還在發布前發布了一項新功能，即自動版式。 自動布局“允許您創建動態框架以響應其內容”。 簡而言之，如果您的內容需要增長，則自動版式將響應并隨之增長。

For now, we’ve only added this to a few components, as including this in every one effectively would mean completely refactoring the libraries. The absence of Auto Layout isn’t currently blocking anyone, and for the moment, it’s vital we have visibility in every instance available.

目前，我們僅將其添加到了幾個組件中，因為將其有效地包含在每個組件中將意味著完全重構庫。 目前，沒有自動版圖功能并沒有阻止任何人，目前，至關重要的是我們對每個可用實例具有可見性。

團隊的React (The team’s reaction)

After releasing Figma we had to gauge how our teams were adapting to the move. We asked several members of the team how they found the initial transition.

發布Figma之后，我們必須評估我們的團隊如何適應這一舉動。 我們詢問了團隊中的幾位成員，他們是如何找到最初的過渡的。

“The biggest benefit has been sharing. Loads of other little features are nice (autolayout etc.) but I used to have to spend ages exporting things, putting them in Miro, or in Drive, sending people screenshots for feedback. Don’t have to anymore and it has saved me a lot of my sanity.”

“最大的好處就是分享。 其他小功能的負載也不錯(自動布局等)，但是我過去不得不花很多時間來導出東西，將它們放到Miro或Drive中，向人們發送屏幕截圖以獲取反饋。 不必再這樣做了，它為我節省了很多理智。”

Ed Russel, Product Designer

產品設計師Ed Russel

“Having everything available and not just a list of screenshots, compared to Zeplin, is really useful.”

“與Zeplin相比，擁有所有可用功能，而不僅僅是屏幕快照列表，真的很有用。”

Maxime Mazzone, Senior Android Developer

高級Android開發人員Maxime Mazzone

“Some of the biggest benefits have been not having to use Zeplin, not having to use Abstract and being able to collaborate with content in one space. My main pain now is not being able to link screens in a flow easily. Sometimes I’ll still use Miro but then it means exporting it and managing a second lot of screens. Overall though it’s definitely been positive. Also positive for the speed of my computer!”

“一些最大的好處就是不必使用Zeplin，不必使用Abstract以及能夠在一個空間中與內容進行協作。 我現在的主要痛苦是無法輕松地以順暢的方式鏈接屏幕。 有時我仍然會使用Miro，但是這意味著將其導出并管理第二批屏幕。 總體來說，這肯定是積極的。 對我的計算機速度也很滿意！”

Georgia Kent-Braham, Product Designer

產品設計師Georgia Kent-Braham

“Moving to Figma has made life easier as I can now collaborate and iterate much quicker. It helps me try out ideas, layouts and hierarchies in context and share these with designers or stakeholders, without having to worry about merge conflicts.”

“遷移到Figma使生活變得更輕松，因為我現在可以進行協作并更快地進行迭代。 它幫助我在上下文中試用想法，布局和層次結構，并與設計者或利益相關者共享這些概念，布局和層次結構，而不必擔心合并沖突。”

Nick Cowan, Lead UX Writer

UX首席作家Nick Cowan

“I like that everything is linked and you can go and see master components. I also like being able to extract icons myself.”

“我喜歡一切都鏈接在一起，并且您可以去查看主要組件。 我也喜歡自己提取圖標。”

Sergey Shulga, Senior iOS Developer

Sergey Shulga，高級iOS開發人員

“It’s made content/designer collaboration much easier, and particularly asynchronous collaboration. There are still some things I don’t love about it — particularly in comments, which I find hard to organise and sometimes don’t seem to show up; and navigation. But overall it’s a beautiful tool.”

“這使內容/設計人員的協作更加容易，尤其是異步協作。 我還有一些我不喜歡的東西-特別是在評論中，我發現這些評論很難整理，有時似乎沒有出現； 和導航。 但總體而言，這是一個漂亮的工具。”

Kevin Telfer, Lead UX Writer

用戶體驗首席作家Kevin Telfer

“Well I haven’t really used Abstract/Sketch at Babylon because I joined as we switched, but based on using abstract/sketch at my previous place the biggest thing would be Shareability. Being able to send someone a link so that they can leave comments is great, and it means you can collaborate between engineers and design much easier because there’s instant visibility. Also in my previous company opening a Sketch file via Abstract could take 10/15 minutes so even if you were just trying to show someone something on your own screen it was hard to share/reference a selection of files.”

“我在巴比倫時并沒有真正使用過Abstract / Sketch，因為我是在切換時加入的，但是基于在我之前的位置使用Abstract / Sketch的最大考慮就是共享性。 能夠向某人發送鏈接以便他們發表評論是很棒的，這意味著您可以在工程師之間進行協作并更輕松地進行設計，因為它具有即時可見性。 同樣在我以前的公司中，通過Abstract打開一個Sketch文件可能需要10/15分鐘，因此，即使您只是想在自己的屏幕上向某人顯示某些內容，也很難共享/引用選擇的文件。”

Sarah Benson, Product Designer

產品設計師Sarah Benson

So far the move to Figma has proven to be a wholly positive experience and a welcome move by the team. However, there is more we can do to improve the set up for everyone.

到目前為止，事實證明，轉入Figma是一種完全積極的經歷，也是車隊可喜的舉動。 但是，我們還有很多工作可以改善每個人的設置。

接下來是什么？ (What next?)

分析工具 (Analytics)

Using the built-in analytics feature, we plan on identifying which components are being detached from the library and why. This will help us understand how the libraries are being used and which areas to focus on improving. We can also investigate components that are not being adopted by teams. We’ll ask why they’re not being used and can archive them if necessary, to make sure the libraries only contain what they need to.

使用內置的分析功能，我們計劃確定從庫中分離出哪些組件以及原因。 這將幫助我們了解庫的使用方式以及需要改進的領域。 我們還可以調查團隊未采用的組件。 我們將詢問為什么不使用它們，并可以在必要時對其進行歸檔，以確保這些庫僅包含它們需要的內容。

輔助功能改進 (Accessibility Improvements)

Not all of our components passed WCAG 2.1 AA accessibility criteria when we began this work. Now that the libraries are visible to everyone in the business, we can begin to roll out fundamental accessibility changes and improvements. Any changes we make to components can be updated across all files linked to the libraries.

當我們開始這項工作時，并不是我們所有的組件都通過了WCAG 2.1 AA可訪問性標準。 現在，庫對于企業中的每個人都是可見的，我們可以開始進行基本的可訪問性更改和改進。 我們對組件所做的任何更改都可以在鏈接到庫的所有文件中進行更新。

貢獻 (Contribution)

Creating contribution guidelines is one of our biggest upcoming areas to focus on. We need to learn the best way to help teams contribute new components to the design system and our Figma libraries. It’s important that the design system team doesn’t become a bottleneck and that the process is clear, obvious and accessible for everyone and something they can easily follow.

制定貢獻準則是我們即將關注的最大領域之一。 我們需要學習幫助團隊為設計系統和Figma庫貢獻新組件的最佳方法。 重要的是，設計系統團隊不要成為瓶頸，并且過程對于每個人來說都是清晰，明顯和可訪問的，并且他們可以輕松地遵循。

網頁 (Web)

Now that we’ve completed the first phase of work on our iOS and Android components, we’re moving our attention to the web. We’ve got our work cut out for us, as there’s a lot more variation across our web platforms than in native. Once we’ve completed the transition of our web library, we can then take our final steps of sunsetting programs such as Sketch, Zeplin, Abstract and Zeroheight.

現在，我們已經完成了有關iOS和Android組件的第一階段工作，現在我們將注意力轉移到了Web上。 我們已經為我們完成了工作，因為我們的Web平臺上的變化要比原生平臺多得多。 一旦我們完成了網絡庫的轉換，我們就可以完成日落程序的最后步驟，例如Sketch，Zeplin，Abstract和Zeroheight。

The move to Figma and updating our libraries is just the first step in our design system journey. The process wasn’t perfect and it took time to get it to where it is now. Most importantly, we’re still learning.

遷移到Figma并更新我們的庫只是我們設計系統旅程的第一步。 這個過程并不完美，需要花費一些時間才能達到現在的水平。 最重要的是，我們仍在學習。

How can we continue to collaboratively build our libraries?

我們如何繼續合作建立圖書館？

How can we help our designers follow a consistent file structure?

我們如何幫助設計師遵循一致的文件結構？

How can we better support contribution?

我們如何更好地支持捐款？

Our team is working tirelessly to find answers to these questions, as well as continuing to grow our design system. One thing is for certain, the move to Figma was a good one, and our teams are reaping the rewards of collaboration.

我們的團隊正在不懈地努力尋找這些問題的答案，并繼續發展我們的設計系統。 可以肯定的是，遷移到Figma是一個很好的選擇，我們的團隊正在收獲合作的回報。

COVID-19和Figma (COVID-19 and Figma)

With the outbreak of COVID-19, Babylon has moved swiftly to generate a Coronavirus care plan. The goal was to provide a self-isolation care plan for patients that contained information, and symptom tracking. This was for patients that had been directed to self-isolate by a clinician due to a possible case of COVID-19.

隨著COVID-19的爆發，巴比倫Swift采取行動，制定了冠狀病毒護理計劃。 目的是為包含信息和癥狀追蹤的患者提供自我隔離護理計劃。 這是針對可能由于COVID-19的情況而被臨床醫生指示自行隔離的患者。

With the outbreak of COVID-19 the team had to work remotely and deliver this critical piece of work.

隨著COVID-19的爆發，團隊不得不進行遠程工作并交付這項關鍵工作。

“We had to work collaboratively for an entire weekend, that would have been impossible with Sketch. Copywriters, designers and stakeholders all got directed to Figma to review and work in the same file.

“我們必須在整個周末進行協作，而使用Sketch不可能做到。 撰稿人，設計師和利益相關者都被引導到Figma進行審閱并在同一文件中工作。

We did have some issues when we had more than 20 viewers in the file. But that gives you an idea of how many people were involved and needed to be in the file. ?? Figma.”

當文件中有20個以上的查看器時，我們確實遇到了一些問題。 但這使您了解文件中涉及并需要多少人。 ??Figma。”

Adrian Lopez, Lead Product Designer Health Management Tribe

健康管理部首席產品設計師Adrian Lopez

“The Babylon DNA design system was instrumental in allowing us to put our new COVID flows in production quickly and easily, to experiment and iterate — focusing on nailing the content only, while relying on a robust design library. It’s also allowed us to prototype concepts really fast, for the next phase of COVID Care Assistant.”

“巴比倫DNA設計系統有助于我們快速輕松地將新的COVID流程投入生產，進行實驗和迭代-僅關注內容，同時依賴可靠的設計庫。 它還使我們能夠為下一階段的COVID Care AssistantSwift地原型化概念。”

Catarina Afonso, Design Manager

Catarina Afonso，設計經理

This work demonstrated the brilliance of Figmas collaboration features. It allowed the team to deliver rapidly under pressure, and in uncertain times. With the whole team having to work remotely, this speed of delivery would have been impossible under the previous work flow.

這項工作證明了Figmas協作功能的輝煌。 它使團隊能夠在壓力和不確定的時間內Swift交付。 由于整個團隊都必須遠程工作，因此在以前的工作流程下，這種交付速度是不可能的。