Things I’ve learned working as a developer on a design system
I’ve been working as a Software Engineer on Design Systems at Sainsbury’s Tech for a little over 3 years. In this time we’ve created whole raft of design, code and documentation.
Working on a design system is much more than maintaining a component library
There’s much more work that goes into a design system than the end product that developers and designers regularly use. To achieve consistency, every element needs to be carefully crafted, including the:
Design token library — This is the spine of the design system, by implementing design tokens, we have been able to change from just a Sainsbury’s design system, to be multi-brand (Argos, Tu, Habitat, Sainsburys bank).
Examples and Starter kits — Easy to follow examples and starter kits hugely reduce the time for setting up new projects across all of our brands.
UX Design, copy and component usage guidelines — The Luna guidelines website was created to provide clear guidelines about how the look, feel and tone of voice for the different brands.
Accessibility tooling — accessibility is key to support our customers, within the design system we have documentation on how to build in an accessible way and provide starter kits for accessibility testing that can be adapted for use across the digital estate
Support and feedback loops — having an open communication channel with our customers (other developers and designers) is key. We have a slack channel that we use to support people that need additional support, alert people of any changes coming up and encourage people from across the teams to contribute ideas and changes that could improve the design system.
Understanding usage is important for making a better product
Design Systems at Sainsbury’s started with Designers and Developers working part-time on creating our UI Kits and Component Libraries. As momentum grew we only had a rough idea who was using our work. Through using Figma we’ve been able to see more detailed analytics on how designers are using the design system.
On the developer side we’ve had to be more inventive to find the reach of the Design System.
We now understand how many developers are using it and the different versions of the packages that are being used across the digital estate. Analytics on our documentation has proven to be a real eye opener, we now understand which components people spend the most time reading the documentation for, based on this we can then deep dive into why this is and gain feedback in specific areas from our developer community.
Communication is key
When I initially joined the Luna design system team I didn’t expect to be on a stage presenting the benefits of the shared component library to a room of 60 people. We found that some areas of the business were skeptical on using an internal library and we had to do a lot of workshops with teams so they could understand the benefits of embracing the tooling we were creating.
We showed people how to get started with the library and in turn we started to understand the barriers to usage and we opened up a vital feedback loop which have us insight into the engineering problems we could help with.
Documentation
One constant piece of feedback was documentation, in particular we got a lot of feedback around documentation.
We now spend a lot more time writing detailed change logs, release notes and usage guidance. Tools like JSDoc are a life saver and to be able to have documentation next to the code really helps those developers who love to dive straight into the codebase.
To be able to distill the features or changes added in to a release in a concise way is crucial for communication and adoption among developers. I now see our change log as an elevator pitch to a developer, particularly when we are looking for everyone to upgrade their packages!
Versioning
Having a solid versioning strategy really helps us release at pace to so many teams. Using Conventional Commits and Semantic Versioning within out CI/CD process means we can easily pickup a bug and ship a patch release in the same day. We’ve had examples when we’ve been able to improve accessibility within one of our components in the morning and then release a new patch version, for it to be picked up within a release into production on the same day.
I’ve learned so much in the past few years working at Sainsbury’s Tech on Design Systems. The code has evolved into something which originally was solely used by the Sainsbury’s brand into something which is widely used across Sainsbury’s, Argos, Tu, Habitat, Nectar and also the hundreds of internal applications built to support the thousands of colleagues across the business.
Beverley Sullivan gave me the idea for this article as they originally wrote as the article, Five things I’ve learnt about design systems since I started this gig. It’s a great insight into Design Systems management from the point of view of the Sainsbury’s Customer Experiences team.
