How to build a component library / style guide with Figma
Why have a component library / style guide?
In any fast moving startup it is inevitable that the platform will end up with a whole range of inconsistencies throughout the product. There’s always a trade off between shipping and investing in design / technical debt. In an ideal world this would be avoided by the mythical rockstar designer with God like foresight. Of course in the real world this is not always possible.
A simple example of this is in the number of colour definitions we have within our stylesheets; 88 unique text colours and 60 unique background colours. It seems appropriate 50 shades of grey is now a byword for sadomasochism.
Consider this is only one part of the many styling parameters present. On top of this you have text styling, padding, shadowing, rounding, line height etc. To stop things from spiralling out of control a set of guidelines is required, a bridge between developers and fellow designers to make sure everyone is building towards the same end product.
Now perhaps I’m just a terrible designer, judging from my colleagues comments, it’s probably a safe assumption to make. However, I’m sure I’m not the only one who has a sneaky habit of taking something and tweaking the font size and moving things a few pixels here and there. Purely because, for some inexplicable reason, it looks better to me at the time.
Using components, there are a natural set of restrictions that discourage making smaller tweaks. Want to change the size of an icon in a list? Go for it, but it will affect every single screen, across every document (team library) that uses the row component. Consistency is king.
Components naturally require a bit of setup time, however once in place the design process is much more streamlined. The upshot of this is faster mock-ups and in a lot of cases being able to jump straight from paper to hi-fi mock-ups.
Lastly, having a clearly defined set of components empowers developers to (in some cases) skip the designer completely and re-use components. Giving you more time to tend to the important things, like Medium, Reddit and staring out the window pretending to look busy.
Prerequisites
This article required a basic understanding of Figma Team Libraries.
Starting your library; Building blocks + Components
There’s many design systems that exist, for example Atomic Design. Now whatever you want to call it Atoms, Molecules, Organisms; or sand, bricks, walls. Fundamentally, the idea is the same. Blocks come in different shapes and sizes, which are combined to build something new. Sometimes 2 blocks are needed to create a new shape, and sometimes 2 of the new shape are combined to create a new new shape. Get it? Probably not with that terrible description.
Here’s an example component from our library.
The first thing to note is that every element that makes up this component, is it’s own component. If I change the colour of the Platform Card component, this will not only update the background of this component, it will also affect input fields and cards we use anywhere in our designs.
The tick is an instance of the tick component (which lives in the team library). Unlike Sketch (probably possible with some trickery), any component styles can be overwritten.
In the scenario below, we have overwritten the fill style for this single instance. This means, if the base component is updated to another tick icon, the red will remain for this instance.
Lastly, the Social Logo component. To begin with our platform was able to share content to the main social platforms, Facebook, YouTube and Twitter. Over time we added support for a whole range of integration platforms.
Traditionally, this would have meant then going through particular screens and having to paste the Spredfast logo in the relevant place. Using a single Social Logos component allows us to add a new integration icon and simply hide / show layers on any Social Logos instance.
You know, building blocks upon building blocks upon building blocks. Hope that makes more sense now. Probably not.
Responsive design
Figma isn’t quite at the level of relative positioning between objects, however in most cases anchoring to a frame (like a frame) provides just enough flexibility (especially when you can have components within components, within frames).
Whenever a component is built be sure to expand the frame, make it smaller and see what the effects are. It’s usually straight-forward to make the component responsive using the constraints panel, occasionally you might need to engage in a bit of trial and error.
Colours
A defined colour palette or swatch is nothing new, however with Figma you can define a colour palette, which is then available to everyone in the team. This helps to keep designers aligned and puts a stop to the shades of grey issue. Should a designer want to add another colour they can add it to the team colour palette.
What to publish
To keep your component library streamlined it’s important to share the right things. Taking the example of a button, we use a red primary button and a dark blue secondary button. On top of this, either variation can have an icon on the right hand side of the button. One option is to share 4 different button components (there are other ways too). This would work, but what if, half way through you decide you want to use the secondary button style instead of the primary button style you started with?
In this setup you would have to delete the primary button, add in the secondary button, resize and potentially re-apply responsive constraints.
The second option, the approach we use, is to create the four button styles and then merge them into a master button component. This master button component then makes it as easy as hiding / showing layers to switch between the button types.
This master component is made up of 4 sub components (primary button, primary button with icon, secondary button, secondary button with icon). What you don’t want is a designer using one of the sub components, again because it’s a ballache to then switch between a primary and secondary CTA. To prevent this, only the master button component should be published to the team library. The other upshot of doing this is it minimises the size of your shared library which can get messy quickly.
Organisation / Team Libraries
Team Libraries are a store of components that can be used by any of the designers in your organisation. A shared library gets its components from a master document, whenever this master document is updated the changes are reflected through all documents using the shared components.
With Figma’s release of Team Libraries V1 there is now the option to add grouping for components. Simply draw a frame around the group of elements and they will be grouped in the Team Library. It’s a simple change that makes your library a lot easier to navigate.
Laying it all out
The component library serves two sets of users; developers and designers.
We do not have the luxury of having a living (coded) component library, meaning this is effectively the single point of reference. For this reason it is important to show all components, in all of their states. Anything built should match the specs laid out here, at the same time it is important to update components based on the live components. Co-operation.
Secondly, we need to cater for our fellow designers. This is a bit trickier, rather than just seeing the components, designers need to be able to modify the building blocks. For the sake of ease, where possible, below the component states we layout the building blocks. The building blocks are not shared to the team library. This allows designers to easily see how the component is constructed and make any updates.
Final word…
This is a set of guidelines, based on our implementation of a style guide / component library. This may not translate directly for you, and is only one possible solution.
Whilst this article covers the technical considerations of building a component library, it is important that the team is fully onboard. This requires working closely with the front end development team, ensuring they are onboard. It is tempting to try and retrospectively fix the whole platform immediately, however the pressures of a real working environment do not (usually) allow for this.
Our approach has been to try and stick to the defined standards on any new work carried out. This means pushing the front-end team to refer to the component library / style guide. Just as importantly, front end devs should be encouraged to push back on any designs that stray away from the set the standards.
The quickest way to lose buy in is trying to push through consistency without working in tandem with the whole team.
