0 to 1: Oscar's Design system journey

Throughout this post we’ll explore how Oscar’s design system Anatomy came to be, how it has evolved over the years, and how its been formalized into the fully supported product it is today. Anatomy has changed hands over the years so I, Trevor Murphy, will take you through the origins of our system, and then Antonio Lee, our newest lead designer on Anatomy, will pick up and walk you through where we’re headed next. As we share our story, we’ll also call out the key takeaways and learnings from the process.

2016: Starting from scratch

Years ago, when React was in its early days, two engineers and a designer saw a need for front end consistency across our products and put their heads together to solve it. While transitioning to React, this small team at Oscar wanted to experiment with building a component library to help speed up development and standardize design decision making. Lead engineers Stephen Kalmakis and Wyatt Anderson paired with designer Josh Long and built an initial proof of concept. It wasn’t long before other designers and engineers across the company – Anthony Zhang, Joseph Botros, and Will Strasser to name a few – started to take notice and began volunteering their time to help contribute new components and grow the system. This community effort was integral to getting Anatomy off the ground and getting teams across the organization to begin adopting shared components.

Fairly quickly, the team learned that not just anything could be added to the system and that there needed to be guidance to help ensure only the best quality components were being designed and developed. This community based effort began to self organize and set up recurring time for everything Anatomy related, from new component pitches by designers to code reviews for diffs engineers wanted to contribute to the project. These sessions set a high quality bar for Anatomy and laid the foundation for the process we still use today. With a process in place on how contributing to Anatomy would work, the team was off to a great start.

Just get started. Don’t let perfect be the enemy of good and don’t let having an entire system be the enemy of having a few good reusable components. In the beginning, accepting that you won’t initially have everything can often be the biggest barrier to starting at all.

2019: A step toward formalization

The grassroots Anatomy team worked well for a few years, but as the teams at Oscar grew and as the number of applications Anatomy supported increased, it became obvious that this community driven model wouldn’t be able to keep up with the demand. In addition, aligning on the most valuable items to add, when capacity was limited, became increasingly difficult.

Queue team formalization - well sort of. At this point we started to see the first steps toward what would eventually become a fully staffed pod. The design systems leads got leadership approval to more formally staff the pod with an engineer at 50% capacity. What this really meant though was that there was officially a decision maker in the team's midst. This person was now responsible for understanding all of the open requests, identifying who could contribute and how much time they could spare, and ultimately helping to prioritize the most impactful things. Initiatives like increasing accessibility compliance across components began to hit the roadmap which helped Oscar deliver a more accessible experience to its users and also hit WCAG AA compliance for our expansion into the Medicare Advantage market. Anatomy was starting to deliver real tangible business value.

Having a decision maker in the room helps with alignment and speeds up progress towards your long term direction. Community involvement is very important, but an accountable party helps to ensure the changes being committed are the largest benefit to the business and the system itself, vs just a particular team or part of the organization.

Over time, we learned that having a partially staffed engineer to this effort was not enough to meet the demand of our growing team and requests. Community engineers wanted to make updates, but at scale there was too much for one person to do. It might seem like the logical next step would be a full time commitment and maybe even an entire team, but it wasn’t that easy. To staff a team you need funding, and to get funding you need to have a clear picture on what a team would do and how much value they would add to the Tech organization.

We put our heads down and started documenting the value we knew Anatomy was providing. From understanding adoption to building out a future roadmap, we put together everything we thought we’d need to show the value Anatomy was providing currently and could provide in the future. In the end we found that Oscars product and engineering leadership was most interested in seeing an informed direction for the types of work Anatomy would take on and what value it would drive going forward as we looked toward expanding our business.

In the end, our team grew from one part time engineer to a pod of two engineers and a dedicated designer who together own the roadmap and work with our active community to ensure alignment and delivery of assets.

Show, don’t tell. Design systems, for the uninitiated, may sound like a lot of work and not a lot of value. Understanding where you’re at is half the battle and thoughtful roadmapping will take you a long way when beginning to have conversations about staffing a team.

Hello! I’m Antonio Lee, design lead on the Anatomy team. From what’s been said by Trevor, it might seem like the story of Anatomy is nearing the end. We created a design system, formed a dedicated team and all lived happily ever after–right? Well not exactly… While we’ve accomplished a lot, we still have a long way to go.

We’ve created assets to streamline the design and development process. Our robust component library is widely adopted and integrated into both design and engineering teams. Every application built at Oscar uses Anatomy. We have a reference site, documentation, a component library and UI kit– wow! But not everything is bunnies and meadows. Since the early days of our design system, tools and technologies have changed and core contributors have come and gone. Formalizing a community driven design system has put us into an interesting position; our design system team is new but our design system isn’t.

We’re in a stage now where it’s a balancing act of trying to make progress for the future while tending to problems of the past. Different designers contributing part time, going through a rebrand and transitioning from Sketch to Figma has led to a fair amount of design debt.   For example, we’d like to have more consistent styles and naming conventions, build out our UI kit to be fully in-sync with our component library and improve our component documentation. While we have all the ingredients to design and build different applications, we see a need to improve our processes and guidelines to help our users create cohesive experiences and contribute to the evolution of Anatomy. Speaking of evolution, we also have ambitious goals like migrating our component library to Storybook and creating a multi-platform design system that supports both web and mobile. The list of improvements we’d like to make can go on-and-on and it’s easy to feel overwhelmed. So let’s take a step back.

“A design system is the smallest set of components and guidelines needed to make digital products better.” - Dan Mall

I like to refer to Dan Mall’s definition of design systems to ground myself and the team. Although we haven’t reached our fairytale ending yet, we’re headed in the right direction. There’s a lot to do, and that’s okay. With a thorough understanding of our current state, we have a better idea of what problems we need to solve in order to get there.

Design systems are marathons, not sprints. When documenting the current state of your design system, it’s easy to get overwhelmed. Communicate with your team to get feedback and data points to prioritize work that provides the highest value.

We’re currently focusing on formalizing processes and creating workflows to enable sustainable growth and momentum. These projects range from creating standards for component documentation, defining processes for component/feature requests, and documenting guidelines on how to contribute to Anatomy and work with the core team.

Creating design systems is a balance between craft and stewardship. As a designer, focusing on the craft portion is very enticing and identifying areas of opportunity are abundant. However team workflow, maintenance, governance and organizational involvement are key areas that deserve equal attention. We’ve come a long way since our humble beginnings. It takes a collective effort to build a design system and Anatomy would not be where it is today without the help from our community. Starting from a grassroots effort to now formalizing a core team, it’s an exciting time to be working on Anatomy.

---

Lastly, we wanted to share a special shoutout to Stephen Kalmakis and Will Strasser for digging through their memory archives to help us write this article!