Component contribution

Add to or upgrade our component library by following the component contribution process.

Compound component criteria

Instead of rebuilding components for every project, Compound's goal is to create a shared single compontent that is reused and continually improved by the wider team. Compound has a number of levels of component libraries but they fit the same basic criteria.

☑️  If it does, it should be progressed through as a component proposal

❌  If it doesn’t, it should remain as a component local to your projects

Component pre-check

Components are products in themselves and they require the same high-level thought process as any other product design, as they require effort in creation and ongoing maintenance.

Before creating a component, it's worth running through this checklist:

  • Can the same outcome be achieved using existing components?
  • Will this component or update benefit the wider design system, or is it specific to my project?
  • Which other teams would this benefit, and have I reached out to them to discuss their needs?

Building components

Component design ideation

When proposing a new component or component update, it's best to start with visual designs. Working through variations, like those needed in an annotation, really help foster discussion around edge cases.

Collaboration

It's beneficial to take these concepts to a review with teammates to check for crossover or alignment. Remember, components should benefit more than one team.

Work in boundaries

Although tempting to think further ahead, it's better practice to work out what component(s) are required for immediate work.

Using this as a baseline, you can work through the variations that'll be changing using just those properties (for example, toggling images or buttons).

Remember, components can be improved and ideated and the first release does not have to be the final answer.

Preparing a component proposal

A proposal is the first step to moving things forward. The proposal doesn’t have to be the final design – that's for specification and annotation.

The proposal should be a high-level summary that's shared to the Team UX channel for wider discussion and feedback.

Despite working through the design ideations with colleagues, 99% of the time the viewpoint of a developer or product owner will highlight other requirements.

Here's what should be in the proposal:

  1. A brief summary of what you're proposing to create or update
  2. Figma file of ideas and research
  3. An explanation of why this can’t be achieved with existing work
  4. An example to support your proposal – this can be a mockup or from another system or site (Codepen.io, DesignSystem.io and Design Systems Repo are some good resources)
  5. An explanation of what needs the new component fits for you and the other team(s) you've discussed it with
  6. A short video overview of the above can help give further context to the team

It is worth sharing ideas early in the #team-show-share channel to give the wider team time to review and provide feedback.

Proposal ideation files

Getting feedback from the wider team on your thoughts or an idea is a great way to collaborate and build a solid proposal.

As this is ideation, these files should be created in the Compound > Proposals project so it's clear they're at the ideation phase.

Create a new Figma or FigJam file within this project with a clear title of component or update.

 

Proposals project in Compound

Proposals project in Compound

Creating a specification

Following your proposal and discussion with the wider team, it's likely an agreed scope of work is required along with initial needs.

This should be moved forward into a more detailed specification that can be used by the product teams to build and deliver.

The specification should include:

  • A specification document - A refined guide on what you hope to build – this is likely to be captured in a Jira ticket as a central source for the development teams
  • Figma annotation - Create a detailed annotation to support your specification using the template and guidelines
  • Component documentation - This will be ongoing as you work with developers to create a delivered component (by the time a component is ready for releasing, a document should be added or updated to match that component)

Figma components

At the point a component is ready to be released, the corresponding Figma component should be created following our guidelines and checks.

This should be complementary to the component documentation and annotations.

What if a component isn’t required?

After sharing your proposal or initial ideas, it may be that only you have this requirement, and an existing solution doesn’t exist.

Your team still can – and should – create a component specific to your requirements. It may be that a future project arises and this could serve as a starting point to ideate on.