Turn Car Design System 1.0
Project Intro
As a member of the team in AutoGravity tasked with building a brand new product, I had the amazing opportunity to work together with my manager and Sr. UI Designer to create a design system from the ground up for the new product.
This design system was a priority for our team while we were creating an MVP for a new product as we had learned from experience just how scaling without a design system may end up being a costly tradeoff in the long term.
The Opportunity
Without a design system, we faced past issues such as inconsistency with font sizes, colors, or component styles and inefficiency with designing itself if we couldn’t easily locate those components.
Similarly, the lack of a design system was also a challenge that the engineers faced since it was difficult to set up accurate stylesheets and discover inconsistencies or redundancies without a clear design system communicated.
The most convincing reason to consider implementing a design system was the fact that the lack of one had previously negatively affected the loading performance and unified look and feel of another product.
Having experienced these problems before, we were determined to seize the opportunity this time around to build a strong foundation for both design and engineering to kick off with for the new product.
My Role
My manager, a Sr. UI Designer, and I shared equal responsibilities to research design systems, collaborate with other stakeholders, create the system itself, and manage and communicate the system.
PICTURED: An example of one issue we faced in the past with moving fast without a design system through a mockup of a fictional product I created. Small things like unintentional inconsistent border radius, border color, and shadows on cards unknowingly added up into a later greater need to scrape and update to make the product feel more unified. This one issue combined with additional issues called for serious design system considerations.
Kicking Off the Project
Before we could get to creating the design system, we knew that there were some important action items we needed to complete to make sure that the system would be integrated into the workflow across the entire product and development team and not just the design team.
These action items included communicating the idea to appropriate stakeholders, including managers, C-levels, and engineers, sharing the process, and discussing how we might successfully integrate the design system throughout the multidisciplinary team.
Understanding the Needs
Like with designing a consumer product, we needed to understand just exactly what the users of this design system needed.
Besides from ourselves, the engineers would be another major user of the system.
So after defining some of our own needs of what needed to be included in the design system, we chatted with engineers of all the platforms to learn if there were any overlapping or different needs from their perspectives as well.
Additionally, we discussed together which tools were the most appropriate to use for creating, documenting, and sharing the design system.
PICTURED: Brad Frost’s atomic design methodology uses chemistry as an analogy to how interfaces can be set up and designed in a similar building block fashion.
Designing the Design System
To structure the design system, we decided to follow Brad Frost’s atomic design methodology because of its ability to allow for easy future evolution and similar technicalities to how the developers are able to set up their own stylesheets.
On top of using atomic design as the basis for the structuring, we further organized the system by platform (iOS, Android, or web) as needed to account for how some components may vary depending on the different operating systems’ own native behaviors and patterns.
We also used online resources such as UXPin’s Adele, a repository of public design systems from different companies, to research how other teams designed their systems to get a better idea of what might make sense for our own unique system.
PICTURED: An example of how we applied the atomic design methodology to creating our own UI components.
Allowing for Evolution
An important acknowledgment we made at the beginning of the design system discussions was that it was to be a living being that should allow for growth and change as needed.
Although we strived to include enough components that we knew we for sure needed from the get go, we agreed with the engineers that since the product was to continuously grow, the system should also be flexible enough to evolve right alongside it.
As we designed new product features and enhanced previous features, we assessed the design system along the way – adding or changing as needed.
The biggest perk was that since the system users were all in-house, we constantly had rich testing data to make improvements to the system off of.
Reflections
Some of the biggest takeaways with building, maintaining, and implementing design systems that I got from experiencing and contributing to this process firsthand were:
Communicate early and often.
A design system, despite its name, is not only for designers.
It’s a shared resource for multidisciplinary members of the team, and so it’s extremely vital that those members are aware of it and involved throughout the process as needed.
Engineering involvement is especially critical for success.
In order for the design system to bear fruit, engineering should be a major player in the creation of the design system.
The success of the design system heavily relies on its abilities to positively affect the actual end product and operations of both design and engineering. So if engineering is unaware and uninvolved, it’s unlikely for the design system to successfully bear its fruit.
Test, evaluate, and improve continuously.
Like mentioned previously, as users of the system ourselves, we’re lucky to have the opportunity to constantly make the system better so long as we stay vigilant of how we’re using the system in our workflows, how the engineers are using it, and how it is affecting the product.
What’s working? What’s not working? Is it positively reflecting within the product? Now how can we use those insights to improve the system so that it can better achieve its goals?
These are helpful questions to ask even after you’ve finished v1.0.0 of the design system and a good reminder is to remember that the system is a living, breathing being so let’s help it age gracefully.
Have Questions?
Of course, this summary is just the tip of the iceberg for a peek into the behind the scenes of this project.
If you’d like to chat more about it, send me a note and I’d be happy to discuss further!