Nitro – a multi-tenant design system for MotoCommerce customizable for any automotive brand.

Motoinsight
Year:
2020 – present

Confidential information has been omitted in this case study.
The information below is my own and does not necessarily reflect the views of Motoinsight.

MotoCommerce is Motoinsight's digital retailing platform that enables car manufacturers and dealers to launch consumer-facing online car buying experiences. MotoCommerce provides a full end-to-end experience for both sides of the purchase process, the car buyer and the dealer, and is used by major automotive brands across over a 1000 dealerships in North America.

As car manufacturing clients were looking to launch car buying experiences that seamlessly integrated with their existing digital assets, MotoCommerce needed to support flexible visual customization to conform to client strict brand guidelines.

I worked with the product team to deliver a solution that would enable us to make visual changes without creating additional work for the engineering team with every new client launch.

My role

Identifying the status quo and gaining buy-in from team leaders

I worked with product and engineering teams to identify how the existing design system was built and used, compare potential approaches to introducing customizations to the product and helped sell the solution from the bottom up to team owners and leadership as well as across the design team.

Reworking individual components for customization support and accessibility

I led the audit of existing UI to identify which components needed to support customizations and take note of any gaps, such as components not being properly used or not complying with accessibility standards.

Facilitating implementation and redefining design processes

I collaborated with engineers to implement all customizations as variables in the codebase enabling designers to change the look of any component to match a brand's guideline through simple CSS declarations.

I also rebuilt the design files to reflect introduced customizations and created a library structure that allowed designers to switch between visual styles and apply a new client's brand in a few clicks.

The challenge of multi-tenant platform design

Originally the team approached every project with an automotive brand as a custom solution. The team gathered requirements, created custom designs and user flows and rebuilt the product for each manufacturer client. While this resulted in bespoke solutions, such approach took time and effort. At the same time dealership clients, which typically have less customization requests, made use of a platform solution that was easy, smooth and efficient to roll out.

With the demand from manufacturers growing the company made a decision to move away from custom solutions to a platform product that would be built around a single roadmap allowing all clients to benefit from the platform improvements and increasing scalability of the solution.

The team was facing a challenge of how to support the level of visual flexibility enough for us to render car buying experiences that would fit seamlessly with existing assets of a major car brand.

With each car manufacturer having their own unique brand how do we approach the design of a product that could be tailored to any of them?

Choosing the design system path

Design systems typically come into play when a company decides to unify its designs around certain principles and vision, communicate its own brand and make sure repeatable designs aren't rebuilt over and over from scratch.

With the objective of being able to communicate any brand in our product designs I saw a benefit in using the design system to define guiding principles, component layouts and patterns that ensured we could implement the best experience for the end customers.

We would complement this by implementation of design tokens, or variables, that would define detailed visual styles and variations required to conform to the brand guidelines of our clients.

MotoCommerce was already partially using a design system, but the team debated whether it should be decommissioned in favor of existing well-developed libraries, such as Material. The major pros and cons of the argument at that point were revolving around the code efficiency.

The idea of creating a coded library of components and patterns that would rely on variables to enable easy visual customization of the experience shifted the conversation towards scalability, ease of maintenance and design efficiency.

Having a design system that relied on design tokens for component styling would allow us to design and code interfaces only once and customize them for each brand at the product configuration level.

Taking the UI apart and putting it back together*

*without anyone noticing

To start I did an audit of the existing UI and validated our components against branding guidelines of the potential clients to identify which components to rework and which customizations to support.

Every spot where a customization was required was documented as a design token starting from the foundational visual styles, such as colors and typography, to individual component attributes, such as border widths and icon SVG codes.

I also used this opportunity to audit existing components for accessibility and identified missing states. These states were added to the library along with the logic to alternate between colors based on contrast where possible. This helped ensure that even if brand guidelines of a specific client didn't account for accessibility our product would follow WCAG.

Because hundreds of live clients were already using the platform we faced an additional challenge of replacing the "old" non-customizable UI with new components in a way that would go unnoticed in production. To do this, together with product owners and engineers, we defined a concept of a theme – a set of custom values of design tokens for a brand.

To ensure nothing would visually change for the live clients once components are swapped we now simply needed to create a default theme that set all design tokens to use the original visual styles.

Themes created a possibility to style our product for a new client by simply defining the set of values for the design tokens that differed from the default design. These values could be stored in a simple CSS file meaning customizing our product to fit a client's brand became a matter of specifying relevant values and uploading the theming file to the product configurator.

Default
Theme
Brand A
‍Theme
Brand B
Theme
Brand C
Theme
Brand D
Theme
Brand E
Theme

Putting design into the hands of designers

At this point we transformed the originally complex task of customizing our product for a client's visual style into a simple process of typing up a list of custom values for design tokens in a text editor. The simplicity of this process enabled designers to own the theming component of the product implementation and kept designers in control of the end customer experience.

The design team was now able to gather customization requirements from the clients, set up the themes and deploy a product with custom styling, all without involving engineers. This has increased the quality of design output, shaved time off the delivery of customized product demos and allowed developers to focus on delivering features rather than design.

Results

Before
19 components
3 customizable attributes
2 weeks to create a fully branded product demo
Over a month to deploy a fully branded product
After
27 components
632 customizable attributes
4 days to create a fully branded product demo
Three clicks to deploy a fully branded product

Next Project: Amazon Marketplace

USER RESEARCH, UX DESIGN, INFORMATION ARCHITECTURE DESIGN