Building a design system to bring consistency to a suite of complex, enterprise products

Role: Manager of Product Design & UX Development
Company: Epsilon
Timeframe: 2017-2021
Goal: Build a design system from the ground up to make Epsilon’s suite of enterprise products more consistent, accessible and easy to use.

Beginning with a product suite that is outdated, inconsistent, and challenging to use

Epsilon is a global, data-driven advertising and technology company. Clients include the world’s top brands, agencies, and publishers across industries such as auto, retail, hospitality, financial services, and more.

• 8,000 employees worldwide

• $1.7 billion annual revenue

• 250 million verified U.S. consumers

• 6 award-winning products, called PeopleCloud

Epsilon had a suite of products that had been built independently of one another and their usage was growing rapidly. The suite was made up of products such as Messaging, a multichannel digital messaging SaaS product, and Loyalty, an enterprise-level loyalty solution used by customers including Walgreens, Sally Beauty and Dunkin’.

The products had been built without designers, and were very complicated and difficult to use. There was a need for major usability enhancements and consistency across the product suite. Engineering teams on all products were duplicating features and writing the same code over and over again. We had 300+ engineers not using any common patterns or styles - each product had its own look and feel. There were plans to start adding new products to the product suite soon, and if there weren’t existing patterns or front-end architecture guidelines for engineering to start with, another inconsistent product would be built.

It was also time for the product suite to get a facelift. Epsilon was losing RFPs to more visually-appealing products, even though all the functionality was present. There was continuous feedback about the outdated appearance.

I was given the opportunity to build out a team of designers in 2017, so I began hiring designers to help with the daunting task of making these separate products feel like they were part of a suite.

Interface inventory

We began by conducting an interface inventory of everything that currently existed in the product suite. We took screenshots and loosely categorized all the components that made up our interfaces. We captured navigation, buttons, typography, icons, tables, etc. We had 30+ shades of gray and 15+ visually disparate dropdowns in one product alone - see below. All of these inconsistencies had been increasing the cognitive load on our users, which made it difficult for them to perform simple actions like saving their work, or closing a window.

What should stay, what should go

Once we uncovered all of our inconsistencies, we began to translate the interface inventory into a living pattern library. We figured out what patterns should stay, what should be removed, and which ones should be merged together. We completed usability testing on different patterns to get some data on what was easier to use.

We came up with a new color palette and created a master design file where all the new patterns would live. Each time a new pattern entered the master design file, we would discuss naming and any relevant design guidelines. We deliberately worked our way through typography, form elements, navigation, tables, and so on. Our master design file became an organized system of components that allowed us to produce better work in a shorter amount of time. I led a fun, exploratory design workshop to find a name for our new design system and we landed on Blueprint, because this new library would act as the blueprint for new products to come.

We routinely met with internal users to ask “How do you use this?” or “How often do you do this task?” or “What do you think of this?” These conversations helped us validate the new naming conventions we were adopting, and helped us determine which patterns were commonly used, or never used at all.

Continuously collaborating with engineering

As the leader of the design team, I consistently worked with engineering leadership to make sure they understood what we were doing and felt engrained in the process. We needed to understand why things were currently built the way they were, and what restrictions there would be moving forward. For example, there was styling being inherited from a third-party library on certain screens, so we needed to understand which third-party libraries were deprecated, which one would better align with our new visual styling, etc. There were restrictions to how objects could be saved because of existing APIs, so we needed to understand how the APIs worked and what could be changed, if anything.

Our design principles and goals

In order to keep our values front and center in our design process, we defined and documented our design principles. These four principles would point us in the right direction when a design decision needed to be made in the future:

Next, we defined what our goals would be. We knew that building Blueprint would be a marathon, not a sprint, and we needed objectives to keep us on track. We set ambitious goals that would help us track our progress in a measurable way.

• Eliminate inconsistencies that had crept into the products over time by establishing consistent language, styles and patterns to use going forward

• Create a cohesive and streamlined experience for our users across the product suite

• Reduce learning curve for new users by increasing usability and learnability

• Create a central place where designers and engineers can go for guidance

• Empower everyone in the organization to be as consistent, efficient, and autonomous as possible

• Build out components to speed up development, avoid rework, and reduce delivery lead time

• Build a future-friendly foundation so we can modify and improve the suite over time

• Release Blueprint initially via Zeplin to make it accessible to engineers quickly, and once we were able to hire UX Developers, build a living library

Partnering with Engineering to bring our design system to life

Once the intital leg work was done and Blueprint was ready to be utilized, we needed a way to share it with engineering. Zeplin allowed us to get something in the hands of engineers immediately, and all 300+ engineers would be able to access it without individual licenses. We used artboards to group our patterns, and exported the artboards to Zeplin - see below. All engineers in the organization were added to the Zeplin project and they were able to see the patterns and read the design guidelines.

My design team held quarterly webinars to share Blueprint progress, show teams how to use Zeplin, and answer questions about the library we were building. Meanwhile, we continued to work with Product Management on new features and functionality. We used existing Blueprint patterns whenever we could and only designed something new if it was absolutely necessary. For a new feature, we supplied the engineering team with a feature-specific prototype, as well as links to specific patterns and specs in Zeplin.

For a while, the Zeplin approach worked for the engineering organization. Engineering teams were able to get what they needed and they became familiar with the new design patterns. But as both the products and the engineering organization grew, we ran into new problems. Many of the engineers in the organization had no front-end experience and they were asking us for HTML & CSS. They were copying old, outdated code from other areas of the products. They were looking to borrow code from other applications where certain features were already implemented, but those applications used different technologies so the code was not reusable. There were tight deadlines so engineers were hacking together the front-end, making it very hard to update later, and the final user interface rarely matched the prototypes provided.

It was clear that the front-end architecture of our products needed help and it was time to define an ideal technology stack to be used going forward. We had products in .NET, Angular, and React - so even though the Blueprint patterns existed, we still had work being done repetitively in multiple places.

Living library and website

Hiring UX Developers

In 2018, I made a case for adding UX Developers to my team - explaining their potential value by highlighting the current pain points and it’s negative impact on the product suite. Once approved, I worked with my trusted partners in Engineering who had a vested interest and began hiring. Since the organization had not hired for engineers with a focus on HTML, CSS, accessibility and user experience before, I created a new process to make sure we were finding the right people. I created a code challenge that allowed us to quickly and effectively measure a candidates front-end and user experience skillset. To respect our candidates time, we instructed them to spend no more than 2 to 4 hours and always provided constructive feedback. I created a scoring system to evaluate code challenges submissions by grading the code with a series of true or false questions which generated a score.

I was able to hire 2 amazing UX Developers, one senior-level and one entry-level developer. The following summer we added 2 UX Developer interns to the team, which led to successful internships and full time offers.

Technology stack

We immediately got to work defining the technology stack to be used going forward and building out living components. I worked on persuading leadership to prioritize cleaning up the code base. We conducted a tech stack assessment across the product suite. There was a mix of technologies in use, but the majority of the newer products were using Angular. This made Angular the clear choice for our component library and documentation site. Many products also had deprecated dependencies, multiple CSS frameworks, and even multiple versions of the same CSS framework installed. We created a new product setup guide that included a recommended product architecture and outlined what JavaScript framework, CSS preprocessor, linters, and dependencies to install - and this became the standard for all new products.

I was constantly creating and sharing materials, like the one below, to make sure everyone was on the same page.

We adjusted our quarterly webinars to focus on educating the engineering teams, sharing front-end best practices, and the importance of reusable, clean and WCAG-compliant code. We established a process for front-end code reviews across the products and participated in pair programming sessions. We wrote front-end code standards which outlined the guidelines and best practices for front-end web development at Epsilon. We added linters - a tool that analyzes source code to flag errors, bugs, stylistic errors, and suspicious constructs - to the product suite. The linters picked up on simple errors and kept a uniform coding style across the suite while allowing UX Developers to focus on giving high-level feedback.

We knew that our engineering teams needed more support, so with a UX team now comprised of both designers and developers, we began building the Blueprint package. The package contained the Blueprint living components and would be installed directly into the products. Each time we made a change to a component, a product would see the change in their interface once they updated to the newest version of Blueprint.

Next, we created an accompanying website that outlined the living components and explained how to use them. This would be a place for both designers and developers to get the information they needed.

As more products were being added to the product suite - we knew it was crucial that they felt cohesive. We defined what the voice and tone of our products was, and gave guidelines on grammar, punctuation, content and accessibility.

You can view the website here.

Achievements

The road to Blueprint was long and winding, but we were able to deliver big wins for the organization:

• Built a living component library and design system that is used by 300+ engineers on 24+ development teams across 6+ products (Now called PeopleCloud)

• New products can get up to speed much quicker because teams are supplied with a common application architecture

• New users can jump in and start working quicker because the interface is easy to use - meaning fewer calls to support and less of a need for training videos

• New features are rolled out quickly because the teams can quickly stitch together components

• Visual styles can be quickly changed across the product suite because Blueprint uses color variables that are easily updatable (for example, when Epsilon was acquired by Publicis Groupe in 2020)

• Designers are able to focus on the holistic experience of the product suite, instead of obsessing over pixels and creating repetitive deliverables

• Designers are able to build high fidelity mockups very quickly

• Engineers are able to focus on automation, instead of writing repeatable code

• Epsilon’s product suite is competitive in the market, and is now ranked as a leader in email marketing and loyalty by Forrester

  • The Forrester Wave: Loyalty Service Providers, Q3 2019

  • The Forrester Wave: Email Marketing Service Providers, Q2 2020

  • The Forrester Wave: Loyalty Technology Solutions, Q1 2023

Positive feedback