Summary

Alloy is the design system for Copper’s customer-facing products, created to speed up the design and development process. It was my job to lead the direction and design of the design system, and it’s guideline documentation while also acting as product manager for the design systems team.

Company

Copper CRM Inc.

Duration

Aug 2018—Jan 2019

Role

Design Lead

Design Direction

Product Management

Copper is a customer relationship management tool that helps businesses and teams thrive in the relationship era.

The Problem

Copper was rapidly growing, adding increasingly more front-end engineers and product designers, causing a spike in different patterns and styles used throughout Copper’s products with every new team member that joined the company. Developers began quickly outnumbering designers, causing them to struggle to try and keep up with the amount of work to be done, creating a bottleneck within the product teams.

The Goal

Our goal was to create a set of tools for teams to create a more cohesive experience for users while increasing the capacity of work that the existing design team could achieve. We measured our success in achieving this goal based on the adoption of any newly minted design system components

Step 1: Discovery

When approaching what should be considered to add to Copper’s design system, the design systems team first completed a review to see how frequently a pattern or component was being used throughout Copper’s products. To complete the review we meticulously went through all of Copper’s products screen by screen as well as combing through the code to screenshot and identify every use of a pattern or component. This process was painstaking but necessary to get a more holistic view of what patterns or components already existed and how often they were used.

Once we had finished the review, we would also complete research on the user experience and best practices of a component as well as competitive analysis, using several different products and design systems to understand how other products made use of them, and reverse-engineer why different products used a component or pattern the way they did.

What is a pattern?

A pattern is a global solution to a common design problem, such that you could use the solution many times and never quite use it the same way twice - Nathan Curtis

What is a component?

Components are portions of reusable code within your system that serve as the building blocks of your application’s interface. - Design Systems Handbook

Step 2: Review

Once we’d completed our audits and research, we set out to review each of our components to identify any similarities or differences in their usage and would then consolidate as many usage patterns as made sense, helping us simplify and clarify the usage of each component.

A prime example of this was during our product rebrand where we discovered that we had about 200 individual colors in use in our products when our original color palette only consisted of about 10. So, we worked to consolidate or remove some of these colors and ended up reducing the number of colors used in the product by 78%

Step 3: Design

With a few identified uses for a component, we started drafting some basic usage guidelines for them to provide us with some direction while we moved on with creating concepts by drawing out ideas and trying different things in Sketch to understand what the component might look or how it might behave.

Step 4: Guides

It was after Step 3 that I began writing drafts of detailed guidelines for the usage of a component. Because the guidelines were meant for both designers and developers to use I relied on Dropbox Paper for writing their drafts because it allowed me to quickly iterate on the guidelines while allowing me to collaborate with the people I was writing them for. This created a short feedback loop that helped me discover important details about a component so designers and developers could effectively use them. Important details such as the purpose of a component, variants of it, and placement guides. These drafts would later be finalized and published on our internal design system site, where designers and developers could visit to quickly learn when and how to use a component or pattern for their project.

4.1: Get Feedback

At this point, we would work with several other designers and engineers to review the concepts and guides we’d written to find uses we may have missed or get suggestions on changes we could make to improve them.

With some solid guidelines and direction for a component we began building a rough version of it before putting it through a round of feedback from other front-end developers, the people who’d be using it. Completing this engineer-based review helped us define what properties we may want to consider building into the component, see how easy it was for the developers to understand, and make changes if needed.

Step 5: Build

Now that we had a direction and design, we began building for both internal designers and developers. While I helped implementation of the design system components for internal developers with our team, it was also my responsibility to build components for internal design team members as well.

Building out our Design System for other designers meant building a library of components for designing alongside the documentation for usage that would be available to both them and developers alike.

Our Tools

Because our design organization relied so heavily on Sketch and Abstract for their workflows, we built the design system components for designers in Sketch, relying on the use of Sketch’s symbols and libraries.

Building for Responsiveness

Copper’s products were all responsive, meaning we needed to ensure any components in Alloy were also responsive. However, on the design systems team, one of our philosophy’s was bringing together the world of design and development as closely as we could. This way everyone was using the same language, making communication stronger between teams. We couldn’t only build components for responsive components for developers; they needed a responsive design counterpart in Sketch.

States

No digital products are static. Everything built or designed for such a medium is interactive in some form or another, and our design system needed to provide designers with the ability to reflect that. To do that, we made sure that we built states into every Sketch component, providing designers with the means to quickly and easily communicate interactivity with any of their team members or stakeholders.

Step 6: Publish

Once we had a stable component built and guidelines written, we worked to make the components available to designers via Abstract Libraries and engineers via Github, after adding guidelines to the design system website. All of these updates and changes would get sent out to the entire product organization via team email & monthly team meetings.

To capture feedback after a release, we relied on Github “issues” to gather any feedback from our front-end engineering teams and Abstract comments to gather feedback from other designers so that we could quickly make any future changes or updates. Besides this, we would also routinely update and check our makeshift adoption dashboard in Google sheets to understand if a component was successful, if changes needed to be made for wider spread adoption, or what we needed to prioritize next.