Development time reduced by reusing design components that were already serving the same purpose
elsewhere in the application.
Much smoother workflow between product people and development.
Maintainability and scalability of the front end design has become much less burdensome.
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
Learned though failure (cliche I know!) and educated the team on its benefits and how one would work.
Systematically designed the various products the application had by identifying reusable elements
Updated the documentation as it evolved over time.
Worked with developers on identiying UI "win-wins".
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.
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.
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.
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.
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.
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
Design systems are crucial for all applications but the nature of how they are
built will depend massively on product type and team size.
Be practical - definitely learn from other organisations but don't have
a dogmatic approach to the system's implementation unless it works within the context of your team.
Keep enhancing it - the design system began with some basic patterns (buttons etc.) but the more
it grows the more harmonious the work has become. Routine problems are more or less done
and dusted, allowing you to focus on more niche areas such as product voice, motion and