Yieldmo Design System

Yieldmo Design System

In 2016, Yieldmo had a number of internal and external products, with several more in active development. The design work for these projects was done by different teams and at different times, resulting in an overall lack of design cohesion.  Applications quickly appeared outdated, and new user interface elements were forced into legacy designs that were built using different frameworks.


Developing a new Design System was the first step toward creating consistency in our design, applications and brand. It would prove to increase engineering efficiency, and bridge the design gap between our applications.

The challenge

  • Create the Design System in parallel with with a new tool that would utilize it.

  • Design many components ahead of clear product uses cases.

  • Support multiple use cases for single UI components.

  • Allow for a variety of component styles across applications.

  • Alignment with engineering team to ensure quick and easy adoption.



Due to tight deadlines, we didn’t have enough time to build something from scratch, so we decided to choose an establish product as a starting point. We ultimately chose Google’s Material Design, since we knew that it was a solid foundation that would help us build and iterate our tools quickly.


We first decoupled the main components that were used by most of our applications, so that we could understand what patterns were already established, and support them in the Design System. We were also building another product at the same time (Ad Builder 2.0), so we wanted to quickly identify and support the component requirements of that tool. We started by creating a checklist of components we needed create.


We collaborated with designers working on other products in order to learn their component needs as well, and created a checklist of components that needed to be designed, or modified. We wanted to understand if use cases in different applications could be solved by similar components.

Once we were satisfied with a component’s interactions, we styled the UI to work with our branding and iterated the look and feel with the use cases we collected. We then presented options to the entire design team for feedback and acceptance. We wanted to be sure that a component would work in multiple applications and address all uses cases, before adding it to the Design System.


What We Learned

  • There were many use cases that we didn’t learn about until collaborating with the rest of the design team.

  • We needed to iterate constantly on the components to make sure that they were aligned to the branding.

  • The Design System was never going to be “final”. There would always be new components to be added, and existing components to redesign.

  • The Design System simplified development for the engineering team. They could pull components from a repository of common components, rather than building from scratch.

After creating the Design System, we received questions from the engineering team about how to incorporate the new components in their work. The designer to engineer ratio was low, so we needed a way to help the engineers understand how and when to use the components, in a way that didn’t require constant involvement from design.


Our solution was to create an internally hosted web style guide, which included sections about how to use each component, as well as brand style guides and other resources to assist stakeholders across the company in using the new system.