Work

Design System

Does it scale?

At Leanplum, teams are organized into pods that focus on a specific area of the product platform. As of 2019, the Product Design chapter was made up of 5 designers located in Los Angeles, San Francisco, New York City, and Sofia, Bulgaria. Each of those designers served as a full-stack designer for their pod. Although we had weekly design reviews within the chapter, it wasn’t a surefire way to catch every detail since we didn’t have a precise common language or single source of truth—we were set up to design and ship quickly within our immediate scope, which was valid for a period of time. A holistic product consistency was more urgent than ever.

"Versioning"


How many styles is too many? Asking for a friend.

Document, document, document. Somehow we ended up with 12 different styles for a search field. While just over half of these were inherited from legacy when the product was built without a designer, it’s still crazy how we even got to this state. Our decentralized structure had resulted in designers and front-end engineers duplicating work by creating completely new components that served similar functions. 

WHY DO WE HAVE 12 STYLES FOR A SEARCH????


The devil is in the details

As we built out our design system, we got into huge debates to reach pixel-perfect solutions that worked for every situation. Is the design high quality? In what ways would the design break? Did we really explore  all possible options? Is this even necessary? The problems we ran into are not unique, but it was important for us to challenge certain preconceived notions and best practices for ourselves. These are the conversations that need to happen in order to push good design to the next level.


Some long debate topics:

  • Padding
  • # of button styles needed
  • 1px or 1.5px stroke for icons
  • Typography
  • What screen size to design in
  • Color contrast accessibility

Date range picker style guide

Text input style guide

Tooltip and validation style guide


Coming to consensus on process

For a global team, it’s important to get everyone together to discuss and agree on new practices. When everyone has a say in how the future should be, everyone is that much more invested to carry that vision through. In June 2019, the whole design and front-end chapters gathered in Sofia, Bulgaria to talk about how we can best work together to achieve design and front-end excellence.


Some processes that came out of the offsite:

  • New components are to be proposed at weekly design chapter meetings and can be added to the design system if approved
  • Using Abstract as part of the design workflow to reference, collaborate, and review the latest designs
  • Designers and engineers to hold each other accountable if implemented designs do not meet our definition of done


Assigning owners to components

Notes and proposals to reduce and simplify components on the style guide

Slow and steady wins the race

How does one update the product to a new style guide? We learned from a previous brand refresh that updating all the CSS across the product at once is no easy task. We’ve also seen how drastic changes can be unsettling for users. We anticipated it would become deprioritized as soon as engineers had to work on necessary features or bugs for their respective pods. There was also resistance to work on anything related to the legacy product already on the path towards deprecation.


We settled on slowly updating the dashboard on a component-by-component basis and ad-hoc weekly design/front-end tune-ups. When new designs would be implemented, there would be a check if the component already exists. If it didn’t exist, the new component would be created and documented. In ad-hoc tune-ups, a designer and engineer would spend an hour together on a page updating styles and components to the latest version. Although we would have to live with a weird in-between state of conflicting styles, this process ensured steady collaboration, clean code, and a gradual change for the user. If for any reason in the future were we to update styles again, we were now set up to just update it once and it would be reflected throughout the product.

Before Design System: No symbols, reusable components, or variables

After Design System: Designed with symbols, built with reusable components, and variables allow for easy updating


TL;DR

Design and build thoughtfully. Don’t forget to document. Upholding good design is everyone’s job. Hold everyone involved accountable so nothing slips through the cracks.

Learn More