Design Systems at Ginkgo

Design systems are a hot topic in Digital Design. Airbnb’s Design Language System and Google’s Material Design are two very well publicized examples, that demonstrate how these organizations build consistent, user centric interfaces and experiences.

A crucial element to this is defining an Atomic System. Developed by Brad Frost in 2013, this is the idea that, just as we are made from combining atoms into molecules, and molecules into an organism, you should build interfaces out of a core set of ‘atomic’ components into ever more complex elements starting with atoms, then molecules, then organisms.

So this means something like a button, or a checkbox can be considered an atomic element. These elements should be considered irreducible (as atoms once were), that is to say taking any part away from them would make them non-functional.

Atomic elements are then combined together to create more complex ‘molecular’ components for example a modal for a success message that combines buttons, copy, a header, and a container element all together into a coherent unit with a defined purpose.

Molecular components are in turn combined together to start to create functional interfaces that allow users to do what they need to do, for example a table displaying information about genetic designs, with a button to send those designs to our biofabrication team, and a modal that tells the user that their request was successful.

Ah! Atoms aren't really irreducible I hear you cry! Well, there are also ideas of protons, neutrons and electrons (though not quarks, gluons etc.etc. just yet). The subatomic elements of atomic design are the colors, typography, border radiuses etc. These things have no inherent functionality in themselves, but are essential to developing a consistent and coherent design system.

At Ginkgo we’re building software for internal use - tools that enable our scientists to design, build and test biological systems. The Ginkgo UX team is developing our own design system, tailored to a world of data intensive software tools, involving a relatively small number of highly skilled users.

We’ve also made one change to how we talk about design systems. We’ve adjusted the metaphor to be more bio-focused - and instead of atoms and molecules, our design system consists of cells, organs and organisms.

Why is a Design System important for Ginkgo Software?

The tools we build are complex, and for expert users. Therefore it’s important for us to make the process of becoming an expert as intuitive as possible. Or put another way, necessary complexity of function should not be exacerbated by unnecessary variety in interaction. Therefore the more consistency we can put behind the interfaces and interactions, the more our users are able to predict how those interfaces will behave.

This means less time learning how to use our software and more time using it to do the amazing science we do at Ginkgo.

Intuition is about looking at something presented in front of you, and knowing how to interact with it. Products in the physical world can have strong affordances, such as the clear shape match of a plug and a socket - it’s almost inbuilt in humans to experiment, and see if those two objects will fit together.

Software struggles to have affordances quite as intuitive as a plug and socket. But, over time distinct patterns have been built up that let you know what you can do with an interface - for example the input box with a magnify glass icon is now ubiquitous with the concept of search. The ideal state for Ginkgo is that once you understand the interactions and patterns of one Ginkgo built tool, you can understand any of them: they are intuitive.

This comes from consistency and predictability, exactly what a design system is intended to do. A simple example that we have is always putting call to action buttons in the same place, with the same styling - allowing the user to build an expectation and understanding about what will happen if they interact with that element.

Well functioning design systems also make it easier for designers to design, and for developers to build. Although our design system is not yet mature, it has shown this in recent times. When we built new software for our labs to manage and test covid samples as part of Concentric, we used and extended our existing design system to build these in extra quick time.

We are still in the early stages of developing our design system to truly unlock the benefits for designers and developers. For example - when there is a one to one relationship between atomic elements in design tools and in code then we are all working with the same tools. This makes communication between designers and developers more efficient - we can speak the same language!

It also empowers everyone to make more efficient and more consistent design choices. Instead of having to think about every element of an interface when designing something new, a design system does some of that work for you, giving you a head start of components and rules for their combination. This means that designers, developers and product managers should have more time to focus on making sure that they have clearly defined and understood the user intent, and less time worrying about button placement or modal design.

A design system takes time to develop, implement and maintain. At Ginkgo we’re in the early stages of this - we see encouraging evidence of its enormous potential - and are working hard to realise that full potential.

What we know though is that this effort is crucial to making our software easier and more efficient to use, giving our team more time to work on what really matters - making biology easier to engineer.

Posted by Simon Hazelwood-Smith

---