What I like about Design Systems Engineering

7/6/2023

I have been working almost exclusively on Oyster’s Design System for a over a year now. When I first joined the team, I only ever had indirect experience with design systems. Either, I was implementing components as part of a feature. Or, I was informally building a UI library - whereby I would make reusable components and push back on design when their new designs didn’t really make sense with previous designs.

Last year, I chose to work on design systems because I really enjoyed working closely with designers and figuring out how to map design language into code. Today, this is still true. But I’ve also learned more about the systems-side of design. For example, how difficult it can be to introduce a new concept to the existing design language. Or how documentation is just as important for designers as it is for developers.

Besides working with designers, I’ve also really enjoyed working with the wide range of engineers at Oyster. I’ve always been interested in how communication influences people’s ways of thinking and working. I think this is something I picked up when I studied literature at university, or when I worked in PR. I enjoy seeing how people use our APIs (or even how they break them) and how they navigate our documentation (or even if they do at all).

There is a careful balance to be struck between encouraging best practices and allowing for flexibility in the componentry. These best practices tend to be: ensuring users build with accessibility in mind, creating consistency with the components’ APIs and making sure that developers build according to the guidelines of the design system (i.e. visual consistency). A year ago, I found this difficult to grapple; there are so many possibilities to explore when it comes to API design and you will never get it 100% right. In the moment of receiving feedback on how an API could be better, I would worry that I had got it all wrong. But over time, I’ve learned to take on feedback with good spirits. Our users aren’t so much telling us what’s wrong as they are trying to help and support the Design System. Moreover, a single user’s feedback is not necessarily shared by every user. The feedback should be considered in the context of the existing APIs, the rest of the engineers and the particular user’s needs at that moment.

I’ve learned so much about accessibility in the last year than I have ever before. I have loved learning how to use and build tools for screen readers (like router announcers in Single Page Apps), digesting WCAG, or learning about the Web Accessibility Initiative ARIA Patterns. Learning more about accessibility has been a goal of mine for a while and, for anyone interested in learning more, I highly recommend learning about it in the context of a Design System.