Introducing the Jacobi Design System and how we got here
Clover Health’s mission is to improve every life. A big part of how we do that is through the Clover Assistant: a tool that breaks down barriers between today’s healthcare silos by delivering real-time, personalized insights to providers, with the aim of supporting better informed clinical decision-making.
But designing for the Clover Assistant requires overcoming the complexity that is inherent to healthcare, and especially Medicare. Patient care teams need to manage holistic treatments while also keeping up with specialized documentation. Clover wants to focus on creating solutions for providers’ hardest problems, and those solutions should demand as little time as possible from our users.
That’s why we created the Jacobi Design System. In the coming weeks, we’ll be publishing a series of posts discussing how we created Jacobi. We’ll assume you know enough about design systems to understand the concepts and why you need one. For now, we’ll introduce you to the different facets of Jacobi and what you can look forward to.
Jacobi: An Overview
Jacobi is the third version of Clover Health’s design system. While Clover’s past design systems were more akin to style guides and component libraries, we wanted Jacobi to enable our product and engineering teams to hit the ground running on each project. That meant upgrading to accessible foundations, a robust component library, and consistent patterns that would allow medical practices to focus on the patient instead of the computer.
Team
The Jacobi effort has been led by two of the biggest design system nerds on earth: myself, a UX designer, and Peter Agar, a UX software engineer.
The series will cover exactly why a relationship between a designer and engineer is so essential to a design systems effort and how we created the processes necessary for smooth cross-functional collaboration.
Foundations
Jacobi features a fully-fledged set of foundations, covering everything from colors and typography to a writing guide that facilitates careful copywriting.
Stay tuned for a post on how we created a color system that enabled AA WCAG compliance without the need for audits or color contrast tools.
Components
Jacobi’s library has grown to cover all components we’ve found more than a single use for. Each exists within our design tooling and our engineering tooling, enabling our team to move as fast and reliably as possible.
Does your team have a usable and accessible calendar picker? That was especially challenging for us, so look out for a post that covers what we did to create one.
Patterns
The Clover Assistant presents a unique problem. Healthcare staff, especially doctors, are tremendously pressed for time with patients, limiting our users’ ability to work with specialized digital tools.
We’ll present how we solved for that by creating patterns that leverage consistency and the mental models of our users, resulting in an interface that patient care teams can pick up and use in a snap.
Documentation
Of course, a design system can’t achieve meaningful impact if nobody knows how to use it. We’ve documented all of Jacobi in our Zeroheight, with links to our Storybook and Figma component libraries.
We’ll cover how we approached documentation, but also the strategies we used to fit documentation into our busy workflows.
Thanks for reading. Follow to stay updated as we publish each deep dive on how we built Jacobi.
