Resin Design System

Hurdles

inconsistent code

implementation of the design system was one of the biggest challenges due to the variety of code bases used to create the products. some were built in win-ui, some in react, and others in languages I had never heard of. this meant I had to work extremely closely with the developers from each product to form a strategy around implementation that caused the least amount of turbulence on their end.

inconsistent ui

not unfamiliar to me, but still a major challenge, was the fact that each product was designed completely differently. not to mention, none of them had usable design libraries or even files since they were historically piecemeal together by Product managers and developers before Henry schein began investing in design in early 2024.

company restructuring

Just as I had settled into the role and begun churning out work product, Henry Schein One underwent a significant restructure. Design leadership was laid off, along with a third of our design team. Designers were then redistributed into their product teams where they would report directly to their Product Managers. Design was no longer a core function and I found myself in a position in which I was the last remaining unifying piece holding the design team together. Not only did this significantly impact moral & bandwidth, but it also complicated my role as a designer for all products and required me to take the place of my former design leadership in advocating for design directly to the executive level.

approach

formulating a strategy

my first few months on the job were spent meeting with every designer, Pm, and engineering lead from each product to get a picture of the full problem landscape. once I had an understanding of the needs & limitations, I formed a structure & roadmap for the forthcoming design system.

- structure -

the complexity of the product landscape resulted in a quite unique structure for a design system. Henry schein one's one platform initiative included two types of products - those that were hosted on premises at dental offices and were built in windows and those that were hosted on the cloud. To accommodate both of these product groups, I decided to create a single design system with two branching interfaces. the design system, called resin, would unify all of the products under the same principles, content, and look & feel, while the interfaces, called veneer & lumineer, would translate those fundamentals into patterns and components that suited their products' needs.

- roadmap -

when creating a design system for long-existing products, the roadmap becomes more complicated. Ultimately I broke up the process into three phases.
Phase 1 would lay the foundations of the resin design system
Phase 2 would audit & standardize the core patterns & components for the two interfaces
Phase 3 would scale the design system by adding custom patterns & components specific to the dental industry

laying the foundations of the design system

once the plan was made, I jumped straight into phase 1 where I defined our design system principles and established a vision for the look & feel of the new interfaces.

- values & principles -

before anything else, I took some time to consider the core foundation of our design system. In doing so, I asked myself two important questions:
- how do we want our users to feel when they use our products? and
- What touchpoints could we come back to time and time again when making design decisions?
After a lot of brainstorming and iteration between myself and the design team, we settled on the product values And from that established the design system principles.

- look & feel -

considering the purpose and context of our products - helping dental practices conduct their business and dental patients coordinate their care - the aim was to establish a refreshing but modest visual identity. coincidentally, Henry schein one's branding team was wrapping up a brand refresh at the same time, so we were able to collaborate with them to quickly determine font, colors, and shapes.

educating the business executives, designers, product managers, & engineers

after my initial conversations with folks across the functions, it was clear that the product department would need to be educated about design systems. I started with the designers, presenting an in-depth explanation & tutorial on design systems, then moved on to the developers, and lastly the product managers. for each presentation, I aimed to speak the language of my audience and provide the information that mattered to them in an attempt to garner enthusiasm, as well as understanding, around an admittedly daunting initiative. after the company restructuring, I had to once again explain design systems & pitch their value, but this time directly to the COO. In the end, I learned a lot about the value of design systems for not only for designers, but also for engineers, product managers, & business stakeholders.

auditing, standardizing, & documenting components

with buy in from all sides, it was time to dive into the meat & potatoes by systematically auditing & standardizing the core components of the two interfaces. When it came to determining the order of things, I used the atomic design framework, starting with the smallest elements and building up to the most complex molecules. To make this process possible, I held design system syncs each week with all of my designers, gathering both requirements for up-next components and feedback on in-process components.

implementing the design system

after completing components and getting sign off from my designers, I worked closely with the developers who were tasked with building the libraries. We had weekly syncs as well as a thorough jira board in order to stay aligned as each component moved separately between the core stages of design, development, & qa.

results

standardized library components

As of today, we are only 2 months into this process, so the libraries are still in their juvenile states. however, we have established good momentum within our process and produced most of the necessary standardized form elements as well as a few molecules & organisms for the pilot design system implementation project.

building a design system in Figma

While most people will only see the end result of the design system in the form of a ui library, none of that is possible without strategic use of design tools. I used a combination of variables, styles, and nested libraries to organize and create the Resin Design System in Figma.

- variables & styles -

By creating multiple base variable collections that feed into a usage variables and styles, I was able to create a clean, scalable system of colors, typography, shapes, & sizes.

- libraries -

In order to achieve a unified design system with two branching interfaces, I created a four tiered system of libraries.

tier 1: helpers library

home to file organizational tools

tier 2: variables, styles, & assets library

provides the necessary building blocks for the component library

tier 3: Resin DS Component Library

home to any components that are shared across the two interfaces

tier 4: Veneer UI Component Library & Lumineer UI Component Library

holds all components needed for designers to do their work, including custom components as well as nested shared components

takeaways

advocating for design systems requires tact

Coming in as the designated person to kickstart the design system initiative at such a large and established organization meant I was the new kid waltzing in and telling everyone they're going to have to change up their work. With the help of my director, I learned to curate my communication around this monumental endeavor to my audience's interests and motivations.

design systems cannot be rushed

This was my first experience truly creating a design system from the ground up and in doing so I learned that taking the time to create a strategic plan and lay the proper foundations is vital to the success of a design system. The execution work of creating and implementing the patterns & libraries tends to happen increasingly more quickly with experience, but the foundations will always be unique to the situation and therefore can never be rushed.