API Design
My work with API design in the context of design system components has spanned over six years, beginning with my work on the Marcel design system in 2019 and extending into my entire 5 years working at Spotify as a Design Systems Engineer. Over this time, I gained perspective on the different ways design systems are used, and the tension of adding utility without becoming a bottleneck.
Customization vs. Configuration in Evolving Design Systems
Joining Spotify’s mature system after working on Publicis’ Marcel.ai design system from conception to launch gave me perspective on different API approaches and their impact. I had insight on how a product’s maturity and broader ecosystem can impact its design system’s structure.
An API isn’t just what properties users select when using components—it is our shared understanding of what the system offers.
We must meet the needs of many different use cases within one shared design system.
Working on the Card component was at the upper end of complexity for our components. There are subcomponents, layout considerations, and accessibility behaviors. We want to provide as much utility as we can out of the box while still offering the opportunity to modify some aspects of the component or to construct your own flows out of individual pieces.This article outlines three touch points on the abstraction spectrum which are utilized in the recently released Card component. By offering multiple layers, we can recommend visuals without slowing down more custom usages.
Outcomes
The API strategy is now documented as coding standards for Encore. This was reviewed and accepted by web engineers at Spotify. The multiple layers of abstraction approach was successful in separating out component styles, and has laid the groundwork for our next iteration, which is separating out behaviors.
