Building Shareable Components

Introduction

Building solid Figma components does not require reading every document. The key is using recognisable patterns across the component library. Reusing patterns leads to a lower learning curve for other squad members and faster workflow.

Getting started

Before creating a new Figma file, spend time reviewing the built live or annotated component. This provides an overview of the component structure that should be used. 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 that things can change in development
• Play with the live component and understand how it works. Use the two sources above as a reference point

Points of Reference

As the component library builds up, similar patterns appear in multiple components.

Working through the research phase above makes it easy to identify existing components that have parts of the requirements needed. Keep them open as a point of reference when building.

As highlighted in the introduction, using patterns in components makes them more familiar to users.

Set up your File

When creating a new component, review how the rest of that particular library is set up. If the library creates a file per component, start with a new file. If components are combined, create a branch and start a new file.

If the component is an update or change to an existing component, create a new branch. For more information, refer to the Compound branches documentation or the official Figma help pages.

Breaking ground

Start building around the same time the development squad requests an initial review of a component 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 the Figma component.

Work becomes easier when something is on the page. There are two approaches for starting a new component.

The kitchen sink

Fire up Figma and try to build the most complex variation of the component you have identified.

This 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 their properties as needed.

Start small

For smaller, more atomic components (such as lists, buttons, and form elements), start small with a single element, for example, a list item.

These smaller components are usually used in variations of the same elements. When testing, group them according to how they will be applied to test for defects more realistically.

Remember the guides

This is a small snapshot of the component review checklist. Working with these guidelines during build makes final reviews much easier.

• Follow the naming conventions for layers and do not leave things as the default "Frame"
• Use the semantic colour tokens, for example, Base/Heading
• Use the dimension tokens for spacing, padding and radius where possible. Use custom sizes only if essential
• Keep files clear of clutter
• Ensure variants follow the component property guidelines
• Always review the checklist document

Structuring Components

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

• Use True/False for all properties that use a switch
• Organise states and variants as outlined in the documentation
• Ensure the most common usage of a component is the default instance
• Use frames to group related components, allowing them to be organised 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 therefore not publish them for reuse.

A good example of this is the Tabs component, where Effect styles are used in each variant. However, these styles are not published in the global style.

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 identifying when a single Compound component needs to be split into separate Figma components.

A common sign to break a component into multiple components is if they require different variant properties, as the card example illustrates.

Testing

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

When testing, use real data and some extreme cases. Samples should exist in the annotation or documentation if they have been created properly.

The process asks for two reviewers and their input is invaluable. It allows testing from another viewpoint and is likely to pick up what was missed.

For complex components, test the kitchen sink before starting to break out the variations and variants.

Library Alignment

With the component built and tested, it is time for the final polish. Always run through the component checklist before requesting a review from the squad.

Start drafting the supporting written documents in the component docs. Writing out how components are expected to function can often identify additional tests to run on components, such as wrapping text or creating broader or narrower variants.

Reviews

Whether creating a new file or a branch, request a peer review before publishing the file. If the file is new, share the file link with two other squad members. If the file is a branch, use the merge branch to request a review.

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

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

Publishing

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

When the file is ready to publish, 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, enable access 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 squad. Whilst aiming to follow development, prioritise ways to make things easier for designers to achieve their goals
• Use as few nested layers as possible, as they make drilling into the content difficult
• Follow the existing guidelines for building component files and variant naming conventions
• When the component is approved, it is ready to publish
• Add a save point in the version history of the master file and publish the component
• If it is a new component, enable it for the wider squad
• Do not get stressed, components rarely succeed the first time