Codacy Design System Development

Design systems are typically adopted by large-scale organizations to increase productivity, speed of delivery, and ensure consistency across design. When I joined Codacy, I was the only designer on the team, and we did not have dedicated frontends, so this was not a priority for a long time. Inconsistencies piled up, and the complexity of the frontend code started to grow.

It was only in 2018, when we decided to scale the team and adopt React, a more modern frontend technology, that the need became clear to the whole organization. We wanted to ensure the design and frontend teams could collaborate smoothly, we wanted to deliver quickly, and provide an experience that overall felt modern and professional.

As we researched other design systems and started building our own, we realized that we did not want to create consistency and we did not want to constrain the creative process.

We wanted to stop doing repetitive tasks and, most importantly, we wanted to create unity: Codacy should always feel like Codacy. We wanted our system to be flexible, rules could be broken if the designer felt like it was appropriate, as long as the language was the same.

Accessibility at core - We were committed to accessibility. As we were designing and improving components, we ensured these followed accessibility guidelines. Document (when possible) - Ideally, documentation would be a requirement. This was our tradeoff due to the lack of designers and time. When time allowed, we would go back to components in our system and we would document usage, best practices, and format specs.

There are three stages to the design system: first is to design it; the second is to code it; third is to adopt it. Designers and frontend developers could not simply stop their day-to-day tasks to be fully dedicated to designing and adopting the system, so we had to squeeze it in, and adoption would have to be incremental.

Me and the other product designer started by creating components on Figma that we were 100% sure we would use: typography, colors, buttons, and so on. As we were working on other product initiatives that required design improvements, along with the developers we would look at which components needed to be coded and we would use them on the newly implemented designs.

The design system allowed our React adoption to run smoother. The design team was spread thin, busy with other product initiatives, and developers would be able to move forward, migrating parts of our application using the new components.

This was not the design team's design system. This was Codacy design system. As the system matured, developers would suggest and push improvements to it - not just stylistic improvements but accessibility improvements as well.