Octopus follows a hybrid model for managing design system contributions. This approach is a combination of:
- a centralised custodianship team (Frontend Foundations: #team-frontend-foundations-requests) dedicated to tooling, systems, and processes for design system management and adoption.
- federated product teams who use and are strongly encouraged to contribute to the design system.
A hybrid model is inclusive, actively promoting contributions from product designers and engineers across the business. Anyone within Octopus can, and is encouraged to, become a champion of the design system.
What is a contribution?
Not every type of participation or interaction with the design system is a contribution. To help make the most out of these guidelines, we define a design system contribution as:
any proposal, design, code, documentation, or design asset of a new feature, enhancement, or fix released through the system for other people to reuse
— Nathan Curtis in Defining Design System Contributions
Here are specific examples to help you decide if your change is a contribution:
|
✅ What is a contribution? |
❌ What is not a contribution? |
|---|---|
|
Components: creating a new component (or a component variant), updating and deprecating a component. Icons: creating new, updating existing or deprecating an icon. UI Patterns: adding new, updating existing or deprecating UI Patterns. Documentation: adding new, updating existing or deprecating any documentation (excluding the Brand section). |
Guidance on which component to use: for advice on which component to choose refer to component documentation or ask a question in #team-frontend-foundations-requests. Questions about specific components: for usage guidelines for a component, refer to component documentation or ask a question in #team-frontend-foundations-requests. Reviewing Design System usage: if you’d like us to provide feedback on how you’re using the design system in your work, let us know in #team-frontend-foundations-requests. |
Contribution size
Contributions vary depending on scope, complexity, and the impact of proposed changes on the broader system. An effective contribution model flexes so teams are empowered to release changes easily. We group contributions into the following size categories:
|
Contribution size |
Contribution description |
Contribution example |
|---|---|---|
|
Fix |
Contribution fixing a defect in design, code or documentation, usually addressed by one person. They happen frequently, are fast and self-directed. |
Addressing improperly defined component in Figma, a browser-specific bug, a typo or lack of clarity in documentation. |
|
Light contribution |
Contribution that doesn’t affect the stability of the design system (a non-breaking change). They happen semi-frequently, and can be fast and self-directed. |
Adding a new state or variant to a component, modifying existing documentation. |
|
Medium contribution |
Contribution extending an existing feature and its capabilities. They often follow the same process as Heavy contributions, might require several participants and design system custodians’ review. |
Adding new functionality to an existing component (e.g.: ability to dismiss an alert), extending existing documentation. |
|
Heavy contribution |
Contribution proposing an entirely new feature, which will include several participants from different disciplines to get completed. They are slower, follow a more rigorous workflow and have higher involvement from design system custodians. |
Adding a new UI component, breaking changes to code, new documentation for patterns and guidelines not covered yet, changes to design systems foundations that are built-in constants in components and code. |
You can also use the following diagram to help you determine the contribution size:
Contribution process
We follow the process outlined below, which might vary depending on the contribution size:
- Request: The first step of a contribution is always an open conversation. In the #team-frontend-foundations-requests, let us know what problem you’re looking to solve. By having a conversation early, we can avoid potentially doubling up on work in the same area and ensure there isn’t an existing design system solution you can use.
- Contribution proposal kick-off: For medium and heavy contributions, we schedule a meeting to talk about your contribution proposal. During this session, we agree on the change's scope and discuss how it’s going to be delivered.
- Collaboration: Once we approve the contribution, we’re here to support you and your team in contributing to design and code. We trust you’re a domain expert in the problem you’re solving, but we’re here to pair if you have questions about design system best practices.
- Review: Before you release the change, we want to ensure it meets Octopus’ standards for design, engineering, and documentation. This guarantees consistency in the user experience and stability of the design system.
- Release: In the last step, your contribution is released in the Figma UI Component Library, the corresponding Component Library npm package and design system documentation (the tools we use). After that’s done, we communicate the change across the company accordingly to Communicating Changes guidelines.
