Contribution

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, while also determining whether existing guidelines, components, or assets can meet a need.

Compound strives to be lean with a low learning curve, so whilst Compound welcomes contributions, it is a balance between benefit and 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 ideations with colleagues, the viewpoint of a developer or product owner 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 the feedback channels or meetings to give the wider team 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 taken into account.

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 a single project?
• Which other teams would this benefit, and have additional requirements been captured?
• Are there platform (Web, iOS and Android) differences that should be considered?
• Are there accessibility guidelines that should be considered?

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 helps foster discussion around 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 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 component proposal is more complex due to the presence of 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. A short video overview of the above can help give further context to the team

It is worth sharing ideas early in the squad and the Compound channel to give the wider 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.

Creating a specification

If it is agreed that a new component or update to an existing component is required, then 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.

The specification should include:

• A specification document - A refined guide on what is proposed to build – this is likely to be captured in a backlog ticket as a central source for the development teams
• 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

At the point a component is ready to be released, the corresponding Figma component should be created following 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 an existing solution doesn’t exist.

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.