Design Language System

Button is a startup and at (good) startups, things move fast. As a result of prioritizing partner launches and new features, our small design team realized that our products’ interfaces and experiences had gotten away from us. Our Dashboard’s submenu sometimes represented progress but at other times it served as a way to access additional features. Sometimes icons were filled and in other places they were single-stroke outlines.

We were all trying to do our best and everybody’s intentions were well-meaning, but it had become unnecessarily hard to create great products. So in August 2016, Button’s design team set out to solve these issues by creating a design language system or DLS.

On the left, our submenu steps the user through a debugging process but on the right, a user goes through steps on the same page with the submenu pointing to different features. Confused yet?

Challenges

Too few constraints

Software design is limitless. What makes it exciting is what also makes it difficult as the infinite opens the product up for disjointed experiences.

Growing team

Button’s team continues to grow every week. More people building and selling the product has introduced new ideas and usages of our product and brand.

Platform parity

Shipping product on a number of platforms introduces repetitive design work.

Evolving product

Our product has evolved but there’s been no system. New pages and features are spun up as “one offs.”

Approach

We started our work on the design language system by taking a step back and evaluating our products, website, and collateral as a whole.

The website wasn’t a big pain point when it came to consistent visuals and experience. This was in large part due to the fact that our website was built and maintained entirely by our design team.

Our Dashboard was a different story. We printed out every page and every state of the interface and hung them on the walls of our war room. Then, with large red sharpies with circled all of the inconsistent UI elements. It was extremely cathartic. After our audit, we brought in our talented front-end engineering team to discuss issues they’ve had when building the Dashboard. This helped us understand why certain decisions were made and showed us the commitment we needed to make to bridge those gaps.

Marketing and sales collateral were all over the place. After sitting with the Business teams, we narrowed in on a few reasons why we’d ended up in this position.

1. It was unclear what’s “on brand.”
2. We’d optimized templates and systems for Keynote but not for other tools like Google Drive.
3. Didn’t know how to make the changes themselves and were hesitant to ask Design for help.

We felt that the design system could help solve for #1 and additional work would fix #2, but the third piece of feedback was more critical. As a team, we took on making Design more approachable at Button as a quarterly goal.

Defining principles

Despite having led the design team at Button for three years, I hadn’t put much thought into defining our principles. However, it made sense to come up with some internal decrees to help us make decisions. We kept it simple with only two principles.

Empower but don’t overwhelm.
Being a partner-centric company, it’s critical that we enable our partners to take control of their business. After all, they’re the ones with millions of users or valuable goods and services to offer those users. Our designs should give them the confidence to be in the driver’s seat but not feel like they’re in rush-hour Midtown traffic.

Obvious over inventive.
If I had to define Button design in one phrase, it’d be obvious over inventive. It’s based on the fantastic writing of Cap Watkins in “The Boring Designer” but extends to almost every facet of our role. We look to use conventional, understandable solutions instead of trying to reinvent everything.

Solution

Styleguide

The most noticeable work to come out of our DLS sprint was a Sketch file that contained styles and symbols aligned with our new vision. This included everything from typography and colors to spacing rules and illustration guides.

When we launched DLS internally, Sketch was still a year or so away from releasing shared libraries. Abstract had yet to launch its awesome “Github for design” product. So, we did the best we could by creating a master file for each product that included the Styleguide page. Our design team would “pull” from this, create a new file for the specific product or feature we were tackling. Upon completion, we’d “merge” that file into the master. What a hassle.

Needless to say, we’re excited that design tools have begun to put an emphasis on how teams scale their design systems.

Dashboard

In many ways the Dashboard was the product that made us recognize the need for a Design Language System. So, it makes sense that it was the first place we looked to improve with the new typography, visual styles, and components.

While it looks and performs much better, the biggest win has come with each successive feature added. The design system has enabled us to move quicker, create a more consistent product, and focus on iteration rather than creation.

Future (Maintenance)

In an effort to maintain our new styles and patterns, we made proposing changes part of our design process. During the 90% review, designers who wanted to tweak something had to provide the team with a clear reason or need and how the change would impact existing designs.

A few new components have come from this including donut graphs and a date picker (designed by Nelle McDade).

Custom date picker designed by Nelle McDade.

Results

Our Design Language System made an even more impressive impact than we anticipated. It’s served as the foundation for all of Button’s web products, website, and sales materials for the last year. Our Dashboard saw the biggest change and went from a product we didn’t love to something we proudly champion.

DLS changed the way our design team works. Instead of worrying about basic styles and interactions, we’re able to focus on the details. Over a year later, it still serves as the framework for everything we design.

DLS also helped our engineering team spin up new internal tools and services that look and feel like Button. All of this done without wasting countless hours in CSS files.

Appreciation

Our Design Language System was a full team effort. Nelle McDade was my partner in crime auditing existing products, simplifying interfaces and experiences, and rolling out the visual changes. Grace Kwan was entirely responsible for creating our React component library with Storybook. During her rotation on the design team, she used her front end engineering experience to build new elements and update the existing system.