Oscar Health is a tech-driven insurance company that interacts with a wide range of users and stakeholders. Oscar builds digital tools for our members, providers, brokers, employers, and our own internal employees.
As a small design team, designing each of these digital experiences in parallel can be a challenge, but our continued investment in our own design system, Anatomy, has helped us rise to meet these challenges. For those not familiar, a design system defines a brand’s core UI/UX. This includes everything from typography, to form fields, to entire page layouts.
We based our approach on Atomic Design, a principle that describes the smallest of UI elements or components as atoms (e.g., text, color, or spacing) and increasingly larger components as molecules composed of atoms (e.g., a text input, a button, or a modal). The idea is that as an atomic design system develops, it will lead to increasingly more complex and grouped components (organisms), and eventually to entire layouts, pages, or templates.
Related: Each screen isn’t a special snowflake—Brad Frost on design systems
Since starting work on Anatomy in 2016, the design team has implemented the system in nearly every web experience Oscar has created since. Over the past two years we’ve learned a few lessons on how to successfully communicate, create, and organize a team to build a design system.
1. Communicate early how a good design system can contribute to scalability
At an ambitious startup like Oscar, designers have multiple responsibilities. We have to be lean and iterative. This takes time, resources, planning, and thoughtful prioritization. To help our team understand the importance of Anatomy, we made a conscious decision to share our design system work, early and often.
“The sooner a design system initiative is allocated hard resources and time, the sooner and more smoothly it will come together.”
We educated other designers, product managers, engineers, even business partners about what Anatomy is, why it is important, and how it’s helping to contribute to Oscar’s scalability. The sooner a design system initiative is allocated hard resources and time, the sooner and more smoothly it will come together.
2. Keep it simple with just a dash of customizability
Figuring out how to balance flexibility in a component was one of the harder lessons we learned while building Anatomy. Beyond theming options (e.g., colors and sizes), some components have shared layouts, functionality, and interaction patterns. Should those be built into the component? How much definition is too much? A component that’s too well-defined could be limiting, but too much flexibility might be inviting a zoo of inconsistency.
Related: Introducing Design System Manager
Ultimately, we make this decision on a component-by-component basis, but we have discovered some general rules to live by. For example, we found it’s best not to build any customizability preemptively. While customization can be added, it’s harder to disentangle from existing components. Additionally, building inner content modules for some components has been an effective way to govern specific layouts while still offering an escape hatch for special cases.
3. It’s never too early to build for scale
We initially built Anatomy across two web products: the member web app and the provider web app. Since then, Anatomy’s usage has more than doubled, across a multitude of internal tools (including provider data management, claims processing, and the web tools used by our Concierge teams) as well as Oscar for Business. Additionally, it’s developed a feedback loop with Mobile Anatomy, Oscar’s React Native design system for our mobile apps. Although there are many overlaps in the needs, each app differs wildly in its users, use cases, and flows.
“It’s never too early to build for scale.”
Earlier in March, we got to a point where, when we did want to change a component, we were hesitant about rolling out the change to every instance of the component. To address this, we recently enabled feature flagging to gate certain features and updates in a component instead of an all-or-nothing ecosystem. This flexibility has already proven to be useful for things like A/B testing, and slow roll-outs for larger changes.
4. No decision is permanent. Anything can be changed.
Sometimes the decisions we make about how a component looks or is built feel all too permanent as they sit in the codebase for weeks, months, and then years, slowly accruing more and more instances as time goes on. “I want to change it… but, how could I change it now? Everyone’s already using it. It’s everywhere.”
Sound familiar? Stop it. It’s changeable.
It’s always better to address any issues sooner than later, before they’ve been further dispersed into a product’s ecosystem.
Up until a few months ago, all of Anatomy’s form fields (inputs, selects, autocomplete fields, etc.) were first generation components made before learning some best practices and based on designs from legacy code. The previous form fields came in nonsensical sizing, and inconsistent theme/size support. The set of components was globally permeated across all our apps, but last February we committed to launching our second generation form fields.
“It’s always better to address any issues sooner than later, before they’ve been further dispersed into a product’s ecosystem.”
Fast-forward a few months, and many of our web apps have already started reaping the rewards of higher consistency, better code quality, and more accessible design.
5. Documentation is a designer’s best friend
On a small team, it may be relatively easy to maintain consistency in how each designer is using specific components and UI patterns. But as teams grow, the specifics and nuances of how and when to use individual components may become lost.
This is why it’s incredibly important to maintain up-to-date and accessible documentation on all components both in design patterns and in code. Additionally, maintaining a symbol library has proven to be very useful for improving design efficiency, visual consistency, and simply acting as an irrefutable source of truth for the team. With up-to-date documentation to reference, and a symbol library to pull from, new designers joining or even non-designers who want make something rough can do so without worrying about details such as color and spacing.
6. Set up a process for building, growing, and contributing
When we first started working on our design system, time to work on it was hard to come by and our approach was unpolished. However, as Anatomy grew, both the engineering team and the design team began developing their own workflows around how to contribute to Anatomy.
For design, exercises like talking to relevant stakeholders, proper use case auditing, and explicit thought towards accessibility and responsiveness have helped immensely in ensuring a component’s success in our library. In addition to an established design process, standardizing tasks such as documentation, hand-off, code review, and QA has been helpful in making Anatomy more familiar for anyone who is curious.
“InVision has genuinely been a big help with ironing out some processes, as many of their tools have helped us communicate more efficiently amongst design and across departments.”
Defining these processes has also been a great way to lower the learning curve for new contributors to get involved. InVision has genuinely been a big help with ironing out some of these processes as many of their tools have helped us communicate more efficiently amongst design and across departments.
The beauty and frustration of working on Anatomy is that, as a living design system, the work is never truly complete. Over the course of the last year, nearly every one of Anatomy’s components has been tweaked or redesigned. As we head towards building our first few organism-level components into Anatomy, we’ve been taking a moment to reassess and make sure we are building on a solid foundation.
In the coming months, our team will continue to refresh our atom-level components with a focus on accessibility before moving on to more complicated layout components.
In the meantime, we will continue to grow our library scope, both in terms of UI components, as well as supported features, flexibility, and scalability.
This article was originally published on Medium.
Get Design System Manager
InVision Design System Manager (DSM) is a platform that provides a simple, unified way to design at scale by helping teams create, maintain, and evolve a powerful design system. The DSM platform includes a Sketch plugin, a web view, and a set of APIs—everything a company needs for a powerful design system, including the potential for multiple libraries. DSM serves as home base for the design team—a shared structure housing the collective knowledge of thoughtful design decisions.
Don’t have a DSM account yet? Be sure to sign up today. Current DSM users, sign in below to try out some of our newest features.
Senior Product Designer at Oscar Health. Previously in the agency world, working with clients such as TED, Chase, Comcast, Loblaws, and Google. While not designing, you'll find me traveling the world looking for great sights and hikes, gorging on all the amazing food in New York, or just YouTubing on my couch. Follow me on Twitter
