Creating a Design System in Figma

A design system is a set of rules, guides, and components that can be reused in a digital product to build interfaces ensuring consistency and speed. Having a well-established design system can increase not only productivity but also the overall quality of a product. This makes the design and engineering teams focus more on the product's logic and flow instead of consistency.

By having all the UI elements already defined – like buttons, typography, rules for margins and paddings, layout, etc.…– it is easier to communicate between teams when something is needed or missing. For instance, we need to add a new button that opens a modal on a specific page. Instead of going through an entire design process – visual design > prototype > front-end – we can have a talk in our daily meeting and discuss the user story with the front-end engineer who will be working on this and just give the reference of what we need to do.

Building a design system is an iterative task constantly in motion. Either adding new required UI elements, rules, and templates or simply auditing the current ones. It’s necessary to have an updated library and work with the latest version of UI components. Tools like Storybooks connected to a component library in Figma can help us to design and maintain an elements library.

Companies like Google – with Material Design –, Apple, Microsoft, Uber, and IBM have vast experience building design systems. They have large design teams who can tackle individual tasks, prioritize and run multiple projects at a time. They also have the budget to iterate, research, and QA teams, but how can we, as a one-person design team startup, define our own design system while keeping pace with the current projects, design support, and new features? – It sounds like a lot of work, huh?–

Usually, small teams communicate better. There is less friction, nodes, and hierarchy in a small startup. Also, principles like ownership and being proactive are key parts of this process, so we need to take advantage of this.

Creating the design system

One year ago, back in 2021, we had a big consistency problem that led us to duplicate UI elements and code. Back in the day, we did not have any design system defined or using an existing one. This second option was not possible since we wanted to give a unique personality to our product.

We started by taking the branding elements and converting them into design tokens – colors and typography were our base foundations – then, we defined rules for spacing. We are using the 8pt Grid Guide as a reference and continued with buttons, radio, inputs, and checks. Then, with the modules, components, navigation, layout, and pages and views.

Now, we keep building our design system on-demand, which means we design new UI components as needed while we keep designing new features. For us, this is a good approach since we can iterate faster just on the components needed instead of design elements that we probably don’t need at the time. After every iteration, each engineer provides a Vercel URL with the feature worked – or bug fixed – for the design team to review before going to staging. This is a good opportunity to spot differences between the design and the implementation.

Maintaining the design system

An important part of iteration is to spot problems that can lead to bad UX or product flaws. Aside from the regular QA checks from product and design, we run weekly full platform tests to identify not only bugs but areas to improve our UI/UX, including our Codiga design system. The key point is to prioritize the improvement and try to tackle them from the most important to the ones that have less impact on the user experience.

Iterations over design system components are now easier, and we can split tasks between new features and maintain the design system, ensuring consistency while all instances are connected to the UI library.

Scaling the design system

Adding new elements to the design system is crucial to keep this iterative task ongoing. These are usually presented as proposals with states and a prototype during our stand-ups or having a group talk on Slack to define the addition to the design system and avoid duplicates.

Designing and implementing a design system is not a single task or just a ticket on Jira, instead is a whole operation that needs to be an intrinsic part of the design process, and here at Codiga we take productivity very seriously. We want to share how we are moving faster and inspire you to do the same.