Brian Leach

Design Opportunity

Build and scale a design system for Experian’s B2B offerings.

Solution

A brand-compliant library of code, design tooling and usage guidelines for product teams in Experian’s B2B business units.

Content:

01 – Standing up the system

02 – Release + adoption

03 – Scaling

04 – Outcomes

Experian had grown by acquisition, and now had several products with inconsistent UI and UX. Experian had just finished a rebrand when I was hired on to our newly-created design system team. The design system team, alongside our partners in brand, began an effort to address the inconsistencies across Experian's B2B product portfolio.

I started by auditing the existing app landscape, to find areas the system could enhance. I also worked with brand leadership to justify some alterations to the brand color palette. The brand  palette wasn't produced with accessibility concerns in mind. We advocated for stronger color contrast ratios to improve visual accessibility of our components. We added a product-specific subset to the color palette, while remaining brand compliant.

We launched the design system at our internal design conference about a month after I started at Experian.

Our early distribution methods were basic, since we had few users at first. We hosted a .zip file on our internal code site that contained the Sketch library.

With our demo at the design conference, interest grew in our offering. Several teams requested and began using our design tooling in their work.

The increased interest made sharing a static file problematic. Version control and distribution became an issue. I looked at a few different solutions, and chose Sketch Cloud for distribution. Sketch Cloud was already available as part of our software plan, and familiar to our designers:

This worked for a few months, but we continued to onboard more product teams.

We’d reached the point where our team of 3 wasn’t large enough to handle all the onboarding and support for the system. In order to scale it out further, we added another designer and a content writer.

With the additional staff, we began proactively reaching out to product teams to onboard them to the system. We offered up “free design” to many of these product teams, to show them what was possible with the system, and how it allowed for faster results.

There was value to us in offering design help: we were able to stress test the system's components. More than just slapping a new coat of paint on a product, our engagements also helped highlight UX issues. The "free design" work helped us make inroads with other product teams, and raised our visibility at Experian.

Our metric of success was the number of teams we could onboard to the system. Within the first year we had onboarded all the product teams in our own business unit, and begun outreach to others. Several teams outside of our own division were now using the system.

A roadblock to growth was the unexpected rejection of the Web Component framework. Many product teams just wanted “the CSS”. Most of these teams were already deeply invested in a Javascript framework (React, Angular, etc.) and wanted a styling layer only. When we dug in to understand why, we found that these teams felt like moving to Web Components meant throwing away a lot of their previous work. They felt like it could be too costly to adopt the system as a result.

As a team, we discussed some options:

We reworked the system to allow for teams to use just the styling layer. This felt like the best compromise we could make, given our resources. A side benefit of this approach: it became apparent over time that teams could build and maintain their own “distributions” of EDS. We continued our outreach to product teams across Experian.

All of this outreach and onboarding meant that we were often answering the same questions, and providing the same kind of support, repeatedly. Doing so began to consume too much of our team's time. I, along with our content designer, wrote comprehensive usage guidelines for the system components. We launched a publicly-visible domain with these guidelines. This allowed us to continue scaling, by making it possible for teams to self-serve when they had common questions.

Later, I worked with our content writer and lead engineer to create and publish a dedicated set of accessibility guidelines. This was valuable because it (again) addressed common questions from our internal customers.

As the system scaled to many teams, it naturally drove engineering conversations about efficiency and re-use. To date, we had remained agnostic about front-end frameworks of choice. This resulted in several customer implementations, with only the original Web Component framework receiving all the official updates. With many different implementations, deltas began to creep into the system.

The landscape for front-end frameworks at Experian started to naturally coalesce around two common choices (React, Angular). We worked to produce an official version based on React, eventually replacing the Web Components version of the system. React was (by that time) the most popular front-end framework at Experian, and it made sense to embrace it.

I also drove adoption of Figma as our design tool of choice in late 2019, and it became the official source of design truth over 2020 and beyond.