Six lessons learned by creating a design system at a fast-moving start-up
Oscar builds digital tools for a range of users, including members, providers, brokers, employers, and a wide array of Oscar employees. Designing all of these digital experiences in parallel, with a small team, has been challenging. Our continued investment in our 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.
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. 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. 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. 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. 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 and sketch symbols are a designer’s best friends.
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 in Sketch 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. Defining these processes has also been a great way to lower the learning curve for new contributors to get involved.
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. Stay tuned for more on Anatomy in the coming months!
