Building an Effective Design System

How I created a company's first design system.

3 minute read



As the product I worked on grew, so too did the challenge of scaling and maintaining its interface design on the front end. With a complex product and new members joining the development team, it was imperative that we created a design platform that would allow the application to blossom.

To comply with my NDA, I have omitted and obfuscated confidential information in this case study.

What I did


Learn from companies that have one in place.

While working on an application that contained many different products, I knew that the front end designs were going to be difficult to maintain. At the time there was a lot of hype around Brad Frost's Atomic Design approach and I was interested to see how it worked.

On our first attempt, we didn't manage to get it into second gear. While a few of the front end devs I worked with had worked as designers previously, not everyone was interested enough to really get behind it. I also made the mistake of alienating people by using the naming conventions Frost set out (molecules, atoms, organisms etc!). I then decided to get away from fad blogs and read some credible literature on the subject before pushing for its adoption. This is when I discovered Alla Kholmatova's Design Systems book on the Smashing Magazine website.

process image

"Design Systems" by Alla Kholmatova. A brilliant book that gave me solid guidance on how to build, communicate and maintain a design system.

Alla's book is very practical and long lasting in nature. It doesn't focus any particular tools or tricks. In a nutshell, the book sheds light on the purpose behind creating and adapting a design system over time and places value on communicating each and every UI component's purpose eg. a trash can icon may change in appearance over time and/or may act differently depending on what device you're on - but its purpose will always remain the same.

Communicate its benefits to internal stakeholders in order to get buy-in

I'm a big believer in showing rather than telling as a means of persuasion (whether its a presentation, prototype or video). On Fridays we often have a scrum team get together (outside of a sprint) where anyone on the team can present something they feel could benefit our productivity. As part of this, I showed the team a video of how the Dev and Design team at USA Today built a design system.

Define its purpose and principles

I met with our product owners and we put together its purpose and principles. The purpose serves as kind of a mission statement, while the principles act as a consistent soundboard for the design aspects that are most important.

design purpose and principles

We ironed out our top 4 principles in order of priority. If there was a design trade off between consistency and clarity the latter would be given more attention.

Make easily accessible and visible to all

Rather than have the design system documentation buried on the local company drive somewhere, I wanted to make it easily available to the front end developers and everyone else so that it would be used. Therefore I included a nav link to it on the dev version of the application itself.

visibility of screens

Our design system was internally accessible through one of the main navbars in the application.

It was important that everyone had visibility of all the screens too. Unlike the product owners and I, the developers would work on specific products within the application while not necessarily having visibility over the rest of it. It was important for us and for them to have a clear picture (literally) of what was planned for development so that we could identify resuable UI components and patterns. Therefore I printed off all the screens and stuck them on the wall in the product room. This was great for identifying overlapping styles and components and also helped with rationalising some of the design decisions that were made. Engagement here was key. The more everyone was given insight into what was planned, the greater the communication between product people, developers and I.

visibility of screens

Printed out desktop views of the various products within the same application. Initial wireframes and mockups were done for tablet (portrait) and we built out the designs for higher resolutions from there. As each product matured, so to did their level of fidelity.

Document and show samples

Documenting all aspects of the UI, interactions and their purpose was very important. Using consistent terminology terminology specific to the app allowed for more free flowing communication and idea generation on how best to solve a particular issue.

process image

Actual example of a resuable component extracted from the project. Each one was given a purpose, so while the design may change, its purpose would remain the same.

Maintain and adapt the system where required

Through various forms of feedback (both user and test case), the design system would be adjusted and communicated to the rest of the team via the #design-system channel on Slack.

Often I'd assist with the front end by writing sample HTML/CSS code + animations (some jQuery too for demo interaction purposes) on a codepen which the developers would then duplicate or adjust where necessary for production level purposes.

Image extracted from company website

What I learned