Building Shareable Components

Overview

You don’t need to have have read every document to build solid Figma components. The key is sticking to recognisable patterns across the component library. Reusing patterns leads to a lower learning curve for other members of the team and perceived speed increase.

Getting started

Before firing up a new Figma file, it is best to spend time going back to the built live or annotated component. This will provide an overview of what the component structure should be. Figma components should align as much as possible with the Compound component or live code.

• Review the component documentation and note the goals and variations of the component.
• Use the annotation of the component as a blueprint but be aware things can change in development.
• Finally, it is important to play with the live component and get an understanding of how it works. You can use the two sources above as a reference point.

Points of Reference

As the component library builds up you will see similar patterns are used in one component or another.

Working through the research phase above, it will be easy to identify existing components that have parts of the requirements you need. It’s always useful to have them open as a point of reference as you build.

As highlighted in the overview, sticking to patterns in your components will make it more familiar to users.

Setup your File

If you are creating a new component you should look at how the rest of that particular library is set up. If the library creates a file per component then start with a new file, if the the components are combined then create a branch and start a new file.

If your component is an update or change to an existing component then create a new branch. You can find out more with the internal working in branches documentation or the official Figma help pages.

Breaking ground

You can start to build things out around the same time the Development team is requesting an initial review of a component they have in build. By this point the documentation and specification should be almost complete and provide a reference point for both checking the component in build and creating your Figma component.

Things are easier to work with when you get something down on the page. There are two approaches for starting a new component.

The kitchen sink

Fire up Figma and try and build the most complex variation (aka the Kitchen sink) of the component you have identified.

The kitchen sink approach is the best way to start for components that are a composition or nest other components. From there it is easier to deconstruct the variations and variant properties as you need.

Start small

For smaller, more atomic components; lists, buttons, form elements, it is best to start small on a single element e.g a list item.

These smaller components are usually used in variations of the same elements. When it comes to testing it makes sense to group them how they will be applied so you can test for defects more realistically.

Remember the guides

This is a small snapshot of the file review checklist, working with these guidelines as you build will make the final reviews much easier.

1. Follow the naming conventions for layers and don’t leave things as the default “Frame”.
2. Use the semantic tokens for colours e.g. Base/Heading
3. Use the dimension tokens for spacing, padding and radius where possible, custom sizes can be used if essential
4. Keep files clear of clutter.
5. Make sure variants follow our guidelines.
6. Always review the checklist document, this will be updated with the most recent guidelines.

Structuring Components

Every component will be different but there are common practices to follow for consistency.

• Use True/False for all properties that use a switch
• Organise states and variants as outlined in the documentation.
• Make sure the most common usage of a component is the default instance. This makes if faster for other team members to use.
• Use frames to group components that are related so that they are grouped together in the asset panel. This example shows how form components are grouped together.

Private Components & Styles

Figma allows components and styles to be specific to a file, and therefor not publish them for a reuse. A good example of this is the Tabs component where Effect styles are used in each variant, however, these styles are not published into our global style.

In Compound we use the “.” notation in front of the component or style name to make them private, the “_” prefix should not be used.

Development & Design Differences

Building out the kitchen sink is the quickest way to identify where the limitations are between Figma and the coded components.

A common diversion here is that a separate Figma component may be required to create some functionality. The cards component is a great reference point for where a single Compound component needed to be split into separate Figma component. A common sign to break a component into multiple components is if they require different variant properties, as the card example illustrates.

Testing

It’s always useful to set up a component early and drag an instance alongside it early in the process. Think of this as a workbench as you can quickly see how changes will affect components almost in real-time. The beauty of variants is that you can have many test instances with the properties set.

When testing it is always a good idea to use real data and some extreme cases. Samples should exist in the annotation or documentation if they have been created properly.

Our process asks for two reviewers and their input is invaluable. It allows testing from another viewpoint and is likely to pick up what you didn’t spot.

For complex components, it is useful to test the kitchen sink before your start taking the time to break out the variations and variants.

Library Alignment

With your component build and tested it is time for the final polish. You should always run through the component checklist before asking your team for a review.

Make sure that you have started to draught the supporting written documents in our component docs. Writing out how you expect your components to function can often throw up some additional tests you think to run on your components e.g. wrapping text, wider/narrower variants etc.

Reviews

Whether you have created a new file or a branch you must request a peer review before a file can be published. If the file is new, share the file link with two other team members. If the file is a branch you can use the merge branch to request a review.

The reviewing team members should use the component checklist and provide any feedback and bugs.

Once the review is complete you can progress to merging and then publishing the file.

Publishing

Before publishing your component always save the file with the 💾 so there is a key milestone in the version history.

When the file is ready to publish then simply click on the assets tab (1) and then publish the assets (2) that have been updated. Always include a message of the changes to give other users context of what has been updated.

New Component Access

When a new component that requires a new file is added to the library then the access must be enabled for other users. A user with an admin level role is required to activate this in the admin panel/

• Design - Component is only visible in Figma
• FigJam - Component is only available in FigJam
• All Files (Recommended) - Component is available in both Figma and FigJam

Final Tips

• Remember that Figma is a tool for the design team. Whilst we aim to follow development if there are ways to make things easier for designers to achieve their goals that should be prioritised.
• Use as few nested layers as possible, they make drilling too content difficult.
• In component variants you can add or remove layers as needed in your layouts, all variants do not need to have a consistent structure.
• Remember to follow the existing guidelines for building components files and variant naming conventions.
• When your component is approved you are ready to publish
• Add a save point in the version history of the master file and published the component
• If it is a new component remember to enable it for the wider team
• Don’t get stressed, we never get it right first time