As a lead/solo designer, working with a dev team of 7, and a QA team of 3, I led the development of a design language system. Previously, UI components were all coded from scratch and design and tech debt were at a critical mass.

After 6 months of working on this during hack days and weaving it into existing stories, we had a DLS, Storybook documentation, and full stakeholder-to-QA buy in. Our bug counts and story points went down too!

Role

Lead/Solo UX working with stakeholders, dev team, and QA team.

Client

A desktop email client, that had been around for 3 years, and accrued massive tech/design debt.

Most Proud Of

Reducing bugs and dev time per story, and hearing the team and stakeholders champion the outcomes.

Phase 1 - Define the need and ROI


After 4 months of sprints and feature development, we could articulate the exact amount of time wasted, the headaches and heartaches, and number of ping-pongs in and out of QA. We knew as a team that we needed a codified system. We identified a library that had every component we needed, and started estimating story points with and without leveraging that library. In the meantime, I built speculative files showing the holistic views of each feature, should we incorporate that library. It helped immensely that our VP of product meticulously tracked our burn rate and velocity.

Phase 2 - System Audit

Audit of code structure

Audit of color

Audit of individual affordances

Audit of all elements

As each story came up, we audited the UI components used. From a design perspective, how holistic were they? From a dev perspective, how easy were they to replicate? We didn't have time or resources to dedicate sprints or teams to this, so we took an iterative approach.

Phase 3 - Design holistically, implement iteratively

One component at a time


Our first component

Focusing on one of the most-complained about states of the app – our warning messaging & confirmation messaging, we built out our new design in as many places as we could within one sprint.

Phase 4 - A source of truth

Storybook

We had stakeholder buy-in, we had quantified ROI, we had holistic designs to look forward to, and we had researched our technical approach. We settled on the idea of taking a hybrid approach - partly leveraging an existing library, partly refactoring our own code. In terms of implementation roadmap, we decided to spend 1 sprint implementing the basics of the ant design library, as well as creating a Storybook.

What we learned...

The most important aspect of a DLS is to have team and stakeholder buy-in, to measure the ROI, and to have one source of truth.

To be realistic with our time, we had to be comfortable with not being able to sunset every component we wanted. We had to maintain a cohesive vision, yet live with an app that showcased old and new designs.