Cooperative Design
Part 2: Implementing a Shared Vision for the Gale Design System

| By Gabe & the User Experience Team |

In our last post, we illustrated the problem of having products with different experiences and how the UX team started the conversation towards fixing that problem. Our solution was to create a comprehensive design system for all Gale products to follow. Now, we move on in Part 2 to how we created our design system. In particular, we’ll look at the tools we used to build it, how it’s impacted our design, and provide a preview of the design system itself.

Selecting the right tool for the job

To review, a design system is a collection of standardized, reusable user interface (UI) components and interaction guidelines to be used across the organization’s products. Typically, designers create the initial design system, but ultimately it’s the full team, including product managers and developers, that are responsible for updating, implementing and maintaining the design system in support of the unified user experience.

Designers have a wide selection of tools available when it comes to visually defining UI patterns and we chose Sketch. We liked Sketch’s vector-based illustration capabilities, ability to create reusable component libraries, and version control functionality (through a plugin). Now let’s take a close look at each of these features and how it helps us.

Vector-Scalable Images

Vector-scalable images allow us to create graphics and icons at one size and easily re-scale them without losing quality. These images can be used in place of standard image formats like PNG or JPEG which don’t scale well. The benefit is that we create the images once and then the developers can make it any size or color they need through code.

Reusable Component Libraries

Libraries are perhaps the most valuable feature in Sketch for the purpose of creating a design system. In Sketch, designers can create a UI component – let’s say a button – and then mark it as a symbol. This creates a master copy of the button that can then be placed in design mockups. The real magic is that if the button styling changes, it only needs to be updated in the master copy and then those changes automatically appear in all of the mockups. With these reusable components, the UX team can build out a complete library of UI components that can all be updated from a single place. This means we don’t have to make changes to every single button any time a font or color is changed and saves us a lot of extra work.

Version Control

Finally, with a plugin for version control called Plant, each member of the UX team can make changes to the design system simultaneously. This means everyone can contribute without fear of affecting each other’s work and, if by chance two people work on the same part, the version control helps sort it all out.

Bridging the gap between design and development

After the UX team designs each component, it’s up to the development team to create the reusable code. The UX team worked with the developers to select React as the JavaScript library we’d use to implement the components. Since Gale has so many products, any significant change in the development process raises questions about whether existing code will need to be rewritten. React is especially attractive in this respect because it can be integrated seamlessly to existing applications, allowing developers to implement new components without disturbing features not yet written with React.

At first, we ran small experiments with simple components like buttons and lists in a test environment. After developing a better understanding of how React fit into our codebase, we incorporated five React components into live product. One of the main benefits of React that became immediately apparent was the ability to separate our presentation layer (HTML & CSS) from our logic layer (JavaScript). React made these changes efficient and allowed for easy reuse of design components.

Having the design system in place now makes it easy to know what to do when we encounter a non-conforming component. One of three things can happen:

1. Developers swap in the design system code for that component
2. If the code isn’t there, developers build the component to match the design
3. If the component isn’t part of the design system yet, the UX team designs the component for developers to implement

Get a first look!

After so much discussion of why and how we have built a design system, it’s time for a preview of what we’ve made so far. We will share screenshots from our files showing some examples of buttons, form controls, and icons that illustrate different types of content found in our products. The images shown here make up some of the components that we designed and tested in early development phases.

Keeping Momentum

The design system is now a living piece of our design and development process. We’ll continue to both expand the pieces in our design system and get them implemented in product. While the UX team leads the effort, the entire organization makes it possible. Our system has been in use for the past six months and it’s already become part of everyday development. It’s taken a lot of time and effort, but the benefits are already clear and the vision of what lies ahead is even better.

Up Next: In Part III, the UX team will give a complete overview of the design system as it stands now, focusing on the reasoning behind our designs and how they benefit the user.

sneakers