What we learnt at Figma's Schema Conference | Byte Orbit
Back to blogs

What we learnt at Figma's Schema Conference

Written by: Brento

02 November 2021

Design

Scroll

What we learnt at Figma's Schema Conference

 “A design system is basically the story of how an organisation builds a digital product”

~ Brad Frost

 

We recently attended the Figma Schema Conference and wanted to share some of the key takeaways with you. Read on to find out what we learnt! 

 

Component libraries aren't design systems.

Don't let your design system become a dumping ground for once-off elements. Make sure that the components you are adding to your design system have a specific role and purpose that can be adapted for a number of platforms. Less is more when it comes to starting up your design system.


Freeform & Structured Design

This was quite an exciting confirmation on our own ways of work within Figma. We have a minimum of two design files, one for freeform design and the other for structured design. Our Freeform designs are there to inspire new ideas, and to be experimented with, while our Structured designs are pixel perfect and utilise our design system components consistently, allowing for a smooth handover to development.

 

Freeform design is incredibly important to allow designers to be creative, experiment with concepts and ideas without the constraints of a structured design file.

 

A method for making components easier to find

Finding the right component from a design system library can sometimes be a challenge for team members who may not be too familiar with the structure of the design system.

 

To make finding components easier for the entire team you can bake in metadata. For example, if you have a ‘heart’ icon, some designers may not identify the icon as a heart, so adding metadata such as ‘like’, ‘love’, ‘fav’ etc. will help everyone locate a particular component in a language that is more familiar to them.

 

 

Maintainability VS usability?

There are essentially two distinct ways you can set up your design system:

 

1. Setting it up for maintainability (to be maintained by the design system designer)

 

2. Setting it up for usability (to be used frequently by other members of your team ie. UI designers, product designers and so on.)



 

Setting up your design system for maintainability tends to feel like the better way to do things as it allows multiple updates to be done with less time and effort, however you may begin to see members of your team using the components incorrectly or breaking them because they don’t understand how they are constructed.

 

Setting your design system up for usability will make updating and maintaining your component library more time-consuming, but can better ensure that anyone using your design system understands how to use it properly with minimal input from the core design system team. This method is great if you are working with separate design or development teams from other companies.

 

There are a lot of differences between these two methods but one key factor is whether or not to use base components in your variants.

 

 

The pros and cons of using base components

Pros: Base components can give you a centralised definition of your component and allow changes to be made to multiple variants at once.

 

Cons: If a team member is unfamiliar with your design language or how the components are built, they can easily hide layers, make unpredictable overrides and essentially break the component if not used properly. This can cause a lot of issues in the long run and make the team lose momentum as more and more time is spent on fixing broken components.

 

Our take: We like to focus on maintainability, although this method would create some extra work when educating the team on how components are built up, it doesn’t allow much room for inconsistencies and broken components to make their way into our final product.

 

 

Design tokens

Design tokens are all the values needed to construct and maintain a design system — spacing, colour, typography, object styles, animation, etc. — represented as data. (Source: Adobe) Design tokens allow product teams to better collaborate and ensure brand consistency across any platform.

 

Here is an example of a utopian design token workflow:

 

1) The designer would update a color in the design tool.

2) The design tool updates design token files according to a targeted platform. (XML, JSON, SASS etc.)

3) Developers only have to retrieve or “pull” updated files and use it in their project.
(Source: Design Tokens for Dummies - UX Collective)  

 

This would save a lot of time for developers and ensure consistency in design making designers and product-owners happy. To go even further, this link between our design and development tools would allow design teams to update core styles in their design tool and see the result automatically synchronised in the design system.


Final thoughts and some resources

Design systems are evolving like never before, tools like Figma are giving designers the freedom to be creative and structured seamlessly, in a language that everyone in the team can easily understand and use in their daily projects. It is no doubt a great time to be a designer.

 

Here are some awesome resources that were shared during the conference. Enjoy!

 

Expressive Design System Book

Design System - What How Why

Leonardocolor.io - Generates consistent and accessible color pallets