Creating a Design System
Step by step guide to creating a design system in your organization
Introduction
I am going to skip a lot of the normal introduction explaining why design systems are important and what they are used for and instead assume that you are already convinced that this is something that your company needs in order to be more efficient and scalable. What I am going to do in this article is outline the steps you need to take to get a design system off the ground and then how to maintain it moving forward.
Over the past two and a half years, Glassdoor has developed our design system, Prism. It has been very successful in creating efficiencies, allowing our designers to focus on the experience rather than designing individual parts, and helping us to grow at scale. We are going to discuss how we started this massive task, the steps we took to get to a usable system, and options your team may want to take.
Step 1: Developing partnerships and getting buy-in
To start, Glassdoor Product Design partnered with our Front End Engineering team to establish that this was a project we wanted to take on and the reasoning behind it. We then worked through the full plan approach, including the expected outcomes.
Once that plan had been developed and agreed upon by the two teams, we looked for buy-in from two organizations within the company. The first organization we approached was our product teams (including both the Chief Product Officer and the Chief Technology Officer). We did this because building a design system takes time and effort away from regular product development. Budget would have to be allocated and roadmap timing adjusted as designers and engineers would have to work through pattern library needs and design.
One point of interest here is that we took the approach of not building a specific team to work through the design system. We decided that there would be more adoption and connection to it if we had all the members of the design and Front End teams contribute rather than have something that is dropped in their laps. This meant more connection and understanding of the system by the whole team. To that end, our plan had the work spread out and delegated throughout all the product teams, which also meant minimal impact to the product roadmaps.
The second team we approached for buy-in was the marketing team. The product is an extension and continuation of the brand and to that end, we wanted to ensure tight communication and collaboration. Sitting down with the Chief Marketing Officer meant that their brand needs could be developed with a systems approach.
Now, every company is structured differently and there are different players, personalities, and needs, which will dictate how you approach partnerships and buy-in. The important thing is to think of the design system as a product. You are developing this product with the same approach as you would any other. Because of this, the product design team also worked with Product Management for planning and prioritization on the roadmaps, as well as Engineering for outcomes and use.
Step 2: Deciding on an approach
The reality of design systems is that each one should be different based on the needs of the organization you are designing for — but in reality, there are two typical approaches to implementation: a full redesign of the current design or a slow takeover of that current system.
Full Redesign: For most teams, this is often the approach. The old design has become too cumbersome or out of date. Potentially, there is a new branding approach and the product needs to reflect that identity. Regardless of the reason, the idea here is that you’re deprecating an old design and moving to a new one. In this approach, you are going to be adhering to harder deadlines and the pace of development will be dictated by many more outside factors.
Slow Takeover: For Glassdoor, we were not starting from scratch. We had just done a brand refresh of the site and in reality, we were looking to establish a more consistent product across the board, as well as clean up the ten years of design debt that happens in fast-moving organizations. On the Engineering side, we were moving over to React, meaning half of our site was on one tech stack and the other on something new. The idea here is to get the system to a point you are comfortable with and then draw a line in the sand. Everything from this point on will be designed on the new system, from page updates to the release of a new product. There are advantages and disadvantages to this approach, which I could write a whole article on, but the reality is that this is easier for everyone to digest when we are getting buy-in. It also allowed us to A/B test the system over time to ensure what we were creating helped both the user and the business.
Step 3: Creating Goals and KPIs
With any product development, you do your research first, then develop, test, and finally release the product to the market. The design system is no different. To start, we did research on our users with a variety of usability tests and an overall analytical review in order to establish what we wanted to tackle. The outcome of that work was a list of goals that were developed with the Product Management, Design, and Engineering teams to guide the system development and future usage Below is an example of some of the goals that were created:
“The goal for the design system is to create a more consistent and accessible design language. Our design should be unified platforms that drive greater efficiency through well-defined and reusable components.
Glassdoor’s design system should be:
Unified: Each piece is part of a greater whole and should contribute positively to the system at scale. There should be no isolated features or outliers.
Universal: Glassdoor is used around the world by a wide global community. Our products and visual language should be welcoming and accessible.
Iconic: We are focused when it comes to both design and functionality. Our work should speak to our vision and clearly articulate what Glassdoor is and what it means.”
Along with this were KPIs (key performance indicators) that the teams had to adhere to. We wanted to know where the design system was at its most successful. The KPIs were broken into two categories:
Organizational KPIs — How the system helped Glassdoor develop products. These included things like reductions in time to market, number of usability tests performed per month, etc.
Product KPIs — These would be focused on our business metrics, such as time to delivery (how fast someone found a job) or apply starts (how many people applied to positions on our site).
These KPIs were essential in establishing how our designs and developments were affecting Glassdoor as a whole.
Step 3: Design System Creation
The very first thing we did was audit the existing site. This was a huge task that we divided amongst various team members. In the end, we actually created a war room and printed pages of the site to mark with stickies and sharpies. Printing was beneficial because the reality of our site is that it’s large and there are a lot of legacy sections. We also have four distinct sections from the main B2C site to a B2B product and a marketing page as well as a mobile app. From here, we were able to identify inconsistencies, take note of current stylings and themes, and develop some priorities to tackle first. This also allowed us to work with the Marketing team on overall site aesthetics and branding initiatives.
This was by far the heaviest lift for the design team, as we wanted to ensure that nothing was missed. By bringing the whole team together to see all parts of the product, the audit really showed the need for the system and aligned our team’s direction and needs.
Start with Foundations
As we began to look at how to tackle the design system overall, two things emerged that we needed to focus on. First, was the need to ensure accessibility of all the components and second, we wanted to focus more on the mobile portion of our designs. This included the responsiveness of our site. To that end, we focused on three foundational components that I believe should be the starting point of every system:
Grid: Working with the engineering team, we reestablished our grid to solve a lot of specific needs in order to allow our site to render for any browser width. Grids aren’t the only way to solve layout problems in a design and many great designs exist without a grid in place, but they have several benefits that make them a very useful design tool for developing a layout. As a general rule, grids help you order information more efficiently with or without other designers while also creating consistency, proportion, rhythm, and harmony across any design that uses the same grid system. This exercise allowed us to align with our development team and establish breakpoints that we could all understand and work with both on the design and engineering side.
Typography: Typography is used to create clear hierarchies within our content and align our products to our branding style. Our type sizes sit on a Minor Third Scale to help us better establish hierarchy and provide a better vertical rhythm and spacing system. Each step up or down our type scale is based off of a ratio of 1.2 of the previous size for a more harmonious, purposeful type set. With this new typography, line-heights are divisible by 4 to sit on a proper baseline grid and play nicely with our spacing.
Colors: Our original color palate had a few limitations. To start, it was developed through a branding exercise and was not optimized for the web. This meant it had a high saturation and that contrast restricted use. It had no range for different states and presented a lot of accessibility issues when applied to our site. To this end, we worked through the saturation and contrast using the current colors as a baseline and developed a more robust color scheme that had a lot more flexibility for accessibility and things like data visualization.
Building
With a massive list of parts to build, we distributed the identified priority items to the team. We had two lead designers who reviewed completed work and maintained a formative style guide so the visual elements were cohesive. To be honest, it started small then built into something large. At this point, we were using Sketch to house the system and Zeplin to share the designs with the Engineering team. We were also documenting the system on Zeroheight at the same time. Once our team became larger, we looked at more advanced ways to maintain version control and increase collaboration on the design. To that end, we switched over to Abstract. Now that our team is larger and working from a variety of locations, (Bay Area, Chicago, Brazil, etc) it really makes a difference to collaborate as a distributed team. This became even more important as we are all working from home currently. It was no small task switching over to Abstract but worth it.
The important thing to remember when you start building your system is that it will never be truly done. You need to establish processes and procedures to allow for evolving or adding components. This will vary depending on how your team builds and reviews product, but we wanted to ensure that every component was tested both from a usability standpoint and through an A/B testing approach. This is time-intensive and may not be feasible for your company.
In Parallel: Pattern Library
As we were designing the components, the Engineering team was developing them into our Pattern Library. For that library, we are using Storybook, which enables developers to create components independently and showcase them interactively in an isolated development environment. Storybook runs outside of the main app so our team could develop UI objects in isolation without worrying about app-specific dependencies and requirements. When a new design was completed, it would be integrated into a page update or a project. We would then add some estimation time to that project so the engineer could build that component into the Library, while at the same time working on the current project. Once developed and live, that component would be A/B tested with the project it was deployed on. This process was slow on the development side, however, and we ended up designing components quicker than they were being deployed so to speed things up, we ended up carving off some front end engineers to focus a quarter on just completing components for the library.
Today we have established that the system works and is a more efficient way of building and maintaining our product. We are looking at building a dedicated team of designers and developers who will take over the design system and work with all the distributed teams. To ensure that this team is hooked into the visual direction of Glassdoor, we are looking to build this team in the brand department, ensuring that there is tight collaboration with the marketing teams as well.
Future of Design Systems
We are continually looking to create a more efficient process around how we develop products and how we use our design system as part of this. Developing a design system has really allowed our designers to focus on the site experience versus the individual design elements and components. Our next step is to design directly using the pattern library elements. Designing in code, if you will. The hope is that we can take our pattern library React code and jam it into a design tool like Framer X and then design directly to the prototype. This will allow us to get to testing done quicker and have a much smoother handoff from designer to engineer. We are very close to this and are currently working through how to ensure that the versions on Storybook and Framer X are synchronized.
