There have been many attempts to try to create a design system for AutoGuru. The most recent attempt was quite ambitious, in that we needed to go from one dev stack (Angular) to another (React). We didn’t just want another brand style guide; we needed something that could go beyond that and create components to streamline the design and development process.
It was my job to lead the team and help design and build a usable set of components both in Sketch and React to better leverage our small team. There were two Senior Front-end Developers and one Mid-level Front-end Developer. We worked together for three months to create this.
We started with the understanding that we would be using the metaphor of driving a car that isn't guilty Bill yet. This sentiment allowed us to be agile as well as be clear with one another that things will change.
The first thing that we needed to tackle was understanding what we needed and what we didn't need as a team. We took stock of our current components and added them to the to do list. We also took stock of our design tokens; like spacing, typography, colours, depth and borders.
We then looked at other big companies to see if we could stand on the shoulders of giants and also see if we were missing anything obvious. Most notably, we paid attention to how they were communicating between designers and developers in terms of naming conventions and different modes of communication like code snippets and interactive components.
Starting with a basic and rough outline we put together our design tokens, spacing, colours, typography, depth and borders. From there, we were able to create basic components like inputs and buttons. From those interactive components, we were able to think about animation too.
For the most part, we used the Sketch and Zeplin to communicate design tokens and components. The Front-end Developers would then create the component in React, added in any unit tests and create a story that could then be consumed by Storybook as well as a hook into Chromatic which gave us screenshots of each component and show differences between each pull request. Achieving this meant we were able to get pixel perfection at every step.
After doing this over and over with multiple components, we are able to start creating our first pages that could go live on the site. We needed to make sure that performance was still a key indicator of success. We used tools like Google Chrome's Lighthouse to do an audit of the page and make sure our accessibility of colours, web elements (screen readability, etc), SEO and overall page performance where all above 95%.
This technique, allows myself as the designer and the quality assurance team to not get involved in the process as much. Time and precious human resource is saved both on the component and page level with each pull request as well as saves time from doing full site regression when we want to change the font.
To make sure that we are creating something that was a success in the eyes of the business, we checked against time logs that we had previously made for other projects and we had halved the amount of development and design time required to create pages.
The Devil’s in the details — there are so many interactions that are required in even basic components like an input. To make sure that this looks and feels like an AutoGuru component, we had to do a lot of testing that we initially underestimated.
Dog fooding our own product is the best way forward — by using our components and design tokens we were able to create more components and make changes to design tokens as we needed; keeping it agile throughout the whole project.