A co-worker and I started working on our first attempt at a design system about 3 years ago. It was
based on Brad Frost's Atomic Design System - if you're not familiar with this, follow this link to an article on atomic design.
It all made sense in theory but our initial approach had some shortcomings:
1. We didn't dedicate enough continuous time to it
Establishing a robust design system can take time, involves multiple stakeholders and requires continuous maintenance and effort. Initially we didn't put aside enough
time to accommodate all of this.
2. The terminology alienated other stakeholders
The "Atomic Design" approach as the name suggests, uses
analogous language from chemistry to describe the breakdown of page elements (eg. an "atom" is a an example of a "button"). Reusing this terminology made it a difficult sell to internal stakeholders
who have enough new learning on their respective plates.
However, I know we simply couldn't abandon it because it didn't work the first time around. It required a deeper investigation in order to get full buy in and be effective.
New Approach, New Design System
A brilliant book by Alla Kholmatova on behalf of Smashing Magazine.
I needed to go back to the drawing board after the first attempt. Our application was beginning to grow, new members joined the team and others left - a consistent path
towards UI rollout was critical before it became a real headache.
Here's what I did to ensure the next iteration was more successful.
1. Educate, explain and obtain buy in
I arranged a meeting with all relevant stakeholders where I showed videos of how other companies
were conducting design systems along with some explainer slides. Team members clearly saw the multiple
benefits of establishing one but were also versed on time commitments and how it wasn't going to be
something that could get done overnight - that it would involve continuous maintenance but ultimately
make our lives easier and produce front end designs at a faster pace.
2. Define its purpose and principles
It's tempting to jump in at this point and start building out various pattern libraries and explainer info. as to when certain UI elements or templates should be used. However, a
soundboard is needed to ensure the ultimate goals of the product are not forgotten about.
I therefore consulted internal stakeholders to determine the purpose and principles of our design system. After all, its a shared resource - not just for designer/s and developers. Business goals need to be considered.
Below are the purposes and principles of our new flagship application.
This is a really important step ideally taken before you start building one -
What is the point of a design system? What principles should it have? Doing this ensures design patterns
adhere to the purpose and principles set out - not what's popular to do at any given moment in time.
3. Start small and continuously build it out
A design system is a "living thing" and can take time for it to evolve. My best advice on this would be to start documenting some typical UI patterns such as buttons and lists and build from there.