Nitro - A design system for a growing company
Motoinsight’s product suite is quite large, from rates data reporting to auto ecommerce and lead generation, the number of tools we have in the market span from B2B and B2C. Oftentimes these products were custom built for specific brands, inheriting their corporate brand standards.
As the company matured we shifted our development goals away from custom projects. We set out to build a white labelled version of our e-commerce tool. At this point, with a mature design team and an upcoming version of our product that would require a new level of consistency, I began the mission to build out a proper design system for Motoinsight. We called our system Nitro.
Design Audit
It goes without saying that one of the main strengths a design system could provide is consistency. The first order of business would be to look across all our tools and find all of our inconsistencies, in both UI and the UX of simillar components.
From loading states, to buttons, breadcrumbs to progression components, we found a lot of different design styles for many simillar components.
Replacing all of these wouldn’t be realistic, as many of these styles were taken directly from client brand standards. We would use this excercise to help us find exsiting UI components that we could later adopt for the design system.
We shared this visual audit with the larger delivery team. We wanted to show our partners in product and engineering the issues of inconsistency that we had, but more over get their buy in to build the system. We needed to help them understand that Nitro would help us finally move away from custom UI for every project, and into a faster and more scalable front end.
This was not a hard sell, as both product and engineering understood the value of having a library of reusable components.
A pilot project.
Since we knew overhauling an existing deployment in production would be impossible, we decided to start small. Internally we had workflows and admin tools that were not scaling with the needs of some of our operations teams. As a company we wanted to cut our implementation time down from 30+days to 15 or less. But to realistically get there we would have to build a new admin for the team to execute their ideal workflow.
This gave us the perfect window to start building the design system components, and apply them to a functioning product. Because the product was an internal tool, it gave us the freedom to test our new components before we tried to release them to our customer facing deployments.
Buttons, fields, dropdowns, checkboxes, radio selections, toggles and tabs would be the first pass for our new system. We would continue to add to the component list as new UX requirements for the internal tool were needed. Icon libraries, progression bars and tables were designed and built... slowly but surely the first version of Nitro was beginning to take shape.
Bringing product and brand closer.
Beyond creating operational efficiencies for the delivery teams, one of the things we wanted out of the system was a more unified visual consistency with our marketing materials, and a closer tie to the company brand and values.
It would be important to set some foundational principles for Nitro to help guide the design team, and ensure that we were building the system with the right vision in mind.
Working closely with our lead visual designer I made sure our style decisions and baseline colour themes would match the brand. The hope was to deliver a consistent experience to our customers, from lead generation form all the way through to implementation and setup.
Deployment.
Once the internal product had been released, we began the work of readying the component library for use in our customer facing products. There were a lot of moving pieces involved here, from choosing the right team model, to selecting the tools for hosting and documentation.
The first version of the system would adopt a centralized team model, consisting of the design team, some front end engineers and a product manager to help track releases, versioning and coordination.
We would use Storybook to host the library, and Zeroheight to begin the documentation.
The early releases of Nitro were static UI elements but over time, we would iterate and evolve them to include animated feedback and more customization options.
To see Nitro in action follow this link