Contribution

Compound is open to contribution from all squad members. Share ideas for new components, pattern improvements, or documentation updates that benefit multiple teams

Contribution Criteria

Compound has a single rule to determine whether a suggestion should be progressed to the proposal stage. It is a quick but effective way to determine if a change brings benefits.

Does this change benefit more than one squad?

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

❌  If it doesn’t, it should remain as a local to a squad’s projects

Proposals

Proposal steps are designed to help the contributor communicate an idea and determine whether existing guidelines, components, or assets can meet that need.

Compound strives to be lean with a low learning curve, so whilst Compound welcomes contributions, it is a balance between benefit and the risk of too many guidelines.

Component proposals and guideline proposals follow different processes.

Guidelines, tokens and patterns

A design system is a combination of various parts, not only component libraries. Squads can contribute to everything documented in our guidelines, from new design tokens to changes in patterns and styles.

Changes should still have a broader benefit than only one squad or project. Therefore, it is essential to prepare a proposal that considers existing options and the potential impact of changes.

Preparing a 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 with the squads and the Compound team for broader discussion and feedback.

Despite working through design ideas with colleagues, a developer or product owner's perspective often highlights additional requirements.

Here's what the proposal should include:

  1. A summary of the guideline or pattern that requires a change or addition
  2. Figma file of ideas and research, if relevant
  3. An explanation of the need for the change
  4. Examples to support the proposal, if relevant
  5. An explanation of what the new component fits for you and the other team(s) you've discussed it with

It is worth sharing ideas early in feedback channels or meetings so the wider team has time to review and provide feedback.

Components

Compound includes component libraries built for the Web and React Native. Each component library adheres to the Compound guidelines, with platform-specific differences accounted for.

Component pre-check

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

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

  • Can the same outcome be achieved using existing components?
  • What are the accessibility guidelines that should be considered?
  • Will this component or update benefit the wider design system, or is it specific to a single project?
  • Which other teams would this benefit, and have additional requirements been captured?
  • Are there platform-specific differences (Web, iOS, and Android) that should be considered?

Component design ideation

When proposing a new component or an update to an existing one, it's best to start with the visual design. Working through variations, such as those needed in an annotation, really helps foster discussion of edge cases.

Collaboration

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

Work within boundaries

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

Using this as a baseline, you can work through the variations that'll change using only those properties (for example, by 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 component proposal is more complex due to additional external factors.

Here's what should be in the proposal:

  1. A summary of what you're proposing to create or update
  2. Figma/FigJam file of ideas and research
  3. An explanation of why this can’t be achieved with existing work
  4. An example to support the 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 how the new component solves the issue that squads are facing
  6. Although not essential, a short video overview of the above can help give further context to the team

Share ideas early in show-and-tell calls and in the Compound channel to give the team time to review and provide feedback.

Proposal ideation files

Getting feedback from the broader team on initial thoughts is a great way to collaborate and build a solid proposal.

As this is an ideation phase, create a separate branch of the main component file.

Proposals project in Compound

Proposals project in Compound

Creating a specification

If a new component or an update to an existing component is required, a detailed specification should be created. This should be captured in the product backlog of the appropriate component library.

This should move this forward into a more detailed specification that the product teams can use to build and deliver the product.

Delivery

When a component has been created or updated, the final delivery should include the following.

  • Figma annotation - Create a detailed annotation to support your specification using the template and guidelines
  • Storybook Story - Where possible, add a story with the new component, props and supporting documentation
  • Component documentation - This should align with the delivered component and be captured in this documentation

Figma components

When a component is ready for release, the corresponding Figma component should be created in accordance with our guidelines and checks.

This should complement the component documentation and annotations.

What if a proposal isn’t adopted?

After sharing a proposal or initial ideas, it may be that only one squad has this requirement and that no existing solution exists.

The squad can still – and should – create a component or make a specific one tailored to their requirements. However, through carrying out a proposal process, it is hoped that an existing approach or component will provide a solution.

Proposals will not be wasted; a future proposal may arise, and this serves as a starting point for inclusion in the ideation phase.