Design systems can solve lots of problems for organizations in the realms of technical efficiency, user experience, and scalability. Our UX team did some research to define the “problem.”

We took stock of Adaptive’s current software systems.

We met with Product Owners across the company, and across the lines of business. They gave us demos of the software, and did their best to dumb-down this highly scientific subject matter to our lean UX team. We were new to the world of immune medicine, afterall. We collected screen captures and video recordings. We gathered business goals for the software programs.

Various themes were surfaced to me: there were scores of data tables, hundreds of detailed task flows, and cluttered arrays of technical fields.

To start to envision the design system, I conducted a one month audit of successful design systems.

I dove deep into the contemporary challenges and solutions. My research led me here:

• I downloaded Figma files of existing design systems; I carefully explored data tables, theming, and grids.
• I read articles and listened to podcasts on design systems’ purposes and scalability.
• I sat down for consultations with industry experts, namely Brad Frost and Dan Mall.

We discovered that the problems addressed by design systems often contradicted each other:

In the end, our lean UX team landed on the decision to adopt and modify IBM’s Carbon Design System.

I found that Carbon was ideally suited because of its robust dashboarding capabilities, computational biology data requirements, and open-source data tables. It was also designed with emphasis on the larger screen devices, rather than mobile first. These things made it a superior fit over other systems like Google’s Material Design.

A breakdown of the ‘wins’ that Carbon could offer us:

• Ease of launch and adoption (open source)
• Robust library of components
• Flexibility
• Appropriate for a suite of systems
• Data table excellence
• Accessibility excellence
• Code base, Storybook, and IBM support

We were warned of the risks of not designing our own design system. However, we were a small design team, so we felt very cautious about building our own. Design systems require a constant governance and maintenance. Running product design and UX research would have us bursting at the seams over the next two years.

I came to learn that the open source nature of Carbon pointed to the perfect solution. With the Figma libraries and code base ready to access off the shelf, we’d be able to focus more of our energy on the tricky execution phase (read on to learn more).

Carbon was thoughtfully and beautifully designed. All the components were there – beautifully crafted with Atomic design foundations (color, typography, and an 8 pixel grid).

Carbon was designed in such a way that, in a single design system, it offered robustness and was appropriate for multiple different systems. In particular, the variety of “grid modes” impressed me with their varied, hard-working layouts.

Carbon’s four themes were a huge bonus to the whole package. Two themes, White and Gray 10, provided light interfaces, while another two, Gray 90 and Gray 100, provided dark interfaces.

This was an exciting opportunity for us to leverage themes to make distinctions between software systems.

(For example: What if we applied light mode to the laboratory and leadership systems, and applied dark mode for computational biology and immunology systems? And when all was said and done, they’d still look and feel as family?)

Carbon’s data tables were more robust than those of the other design systems I had audited. The data table would be the cornerstone component to all the biotech systems at our company.

Carbon was also baked in with the current accessibility standards, both in the code, and in the Figma libraries.

IBM had a Github repo for ongoing support of Carbon. They also published a Storybook site. These assets were ones that I realized we’d need to lean on heavily for supporting our team of engineers.

My role in our design system adoption and execution was:

1. To present my findings on Carbon’s advantages to these technical stakeholders.
2. To act as the design system thought leader: I presented a series of 10 “brown bag lunch sessions” to the engineers and UX contractors. In this series, I educated the participants in detail about technical aspects like Carbon’s grid modes, component library, design tokens, micro-animations, and more.

Here are some screen captures from my presentations.

The engineering team arrived at a consensus, with the guidance of our leadership team, about how to start the adoption of Carbon.

Engineering and UX leadership chose a software project, the rebuild of the company’s proprietary Order Management System, as the starting place for the introduction of Carbon. And so began the 12 month investment in our new design system. You can read more about the design in my other case study, here.

Our UX team was committed to bringing efficiency gains and enhanced user experiences via the adoption of a design system. It was my role to conduct thorough research of our company’s needs and of existing design systems and their offerings. Ultimately, the UX manager and I concluded that IBM’s Carbon was the best option to support Adaptive’s various digital products.

It was also my role to act as a design system thought leader for our company, and to educate the engineering team on the technical usage of Carbon. Through this, I gained a detailed level of knowledge that I’m still grateful to possess. My role in educating our technical teams paid off in spades when it came time to work on designs for our first project, the Order Management System. I was able to effectively govern our team’s use of Carbon, and our contribution of new patterns that we needed for Order Management.

IBM’s Carbon design system became an invaluable tool for Adaptives engineering team at large. In particular, its robust data table library, its active Github support, and its thoughtful incorporation of design tokens all made for an effective choice for Adaptive.

I’m delighted to have had a central role in learning about and onboarding a design system to a biotech organization.