The Process
Our process is divided into four collaborative phases with both product and design system team members.
- Kickoff: You will submit the proposal via our form, and we will validate it.
- Design: Focus on creating and refining the design in Figma. A design system team member will prepare a branch in the relevant library.
- Engineering: Focus on technical development and implementation. A design system team member will review the work in GitHub.
- Final touches: Depending on the contribution scope (core or team-specific), either the design system or product team will finalize the contribution by documenting it.
Roles
Product Team’s Role
- Submit a request via our form after confirming your idea is a good match.
- Once validated, begin the creation phase using the optional design and engineering toolkits.
- Schedule a review call (design) or submit for review (engineering).
- Publish (design) or merge (engineering) after the review.
- For team-specific components, document in Confluence.
Before starting
You can ensure your contribution is a good match by:
- Reviewing our documentation and libraries.
- Checking for similar components.
- Understanding our validation criteria.
- Considering its potential use in 3 or more unique cases or for both B2B and GX teams.
Still not sure? Contact us at #rnd-designsytem-support.
Submitting
Understand how to complete our contribution form (pinned in our #rnd-designsytem-support channel) and what each field means.
- Requestor: Select your name so we know who you are.
- Component or pattern name: Name your contribution idea.
- Description: Describe your idea and explain why it’s a valuable addition or improvement. You can include relevant links to support your proposal, like Figma files.
- Type: Specify if it’s a new component, update, replacement, or related to an existing one.
- Scope: Specify if this contribution is team-specific (B2B or GX only) or a core component.
- Complexity: Select light, medium, or heavy.
- Priority: Select low, medium, or high.
Terms and Definitions
- New: Creating an entirely new component.
- Update: Enhancing an existing component or its properties.
- Replacement: Replacing an existing component with one that offers better functionality.
- Related: Creating a component similar to an existing one if adding it as a variant is too complex.
- Core: Suitable for both B2B and GX products, impacting the entire system.
- Team-specific: Benefits 3+ specific use cases within either B2B or GX, but not both.
Light
Adding a new variant to a component. Adding a new property that won’t change current functionalities.
Ex: Adding a new corner radius or size. Adding a new icon.
- Effort: 1 day.
- Validation: Low bar.
- Type: Update.
-
Criteria: Clear business justification. It won’t change any existing property functionality.
Medium
Creating a new component or pattern.
Ex: Calendar with header and footer. Tree list.
- Effort: 2-4 weeks.
- Validation: Medium bar.
- Types: New, Related.
- Criteria: Clear business justification. No existing component can be used. It should fit 3 or more use cases (product-specific) or both B2B and GX. Adding it as a variant would be too complex. Communication with other teams.
Heavy
Adding or changing foundations. Enhancing an existing component. Replacing a whole component.
Ex: Replacing the Select component.
- Effort: Multiple weeks/months.
- Validation: High bar - as it affects the system.
- Types: Update, Replacement.
- Criteria: Clear business justification. It should fit 3 or more use cases (product-specific) or both B2B and GX. Clear validation (user test, feedback, metrics). It passed any experimenting phase. Communication with other teams.
- High: An urgent fix is needed as it affects the current product.
- Medium: Implementation is already planned. Needed in the next 6 weeks/quarter.
- Low: Nice to have but not needed in the current development cycle.
Validation Criteria
After submission, the design system team will respond within 48 hours with an approval, rejection, or a request for more information. We consider the following criteria, with the first three being mandatory:
- Clear business justification.
- There’s no existing component that can be used or adapted.
- Fits 3 or more use cases (product-specific) or both B2B and GX.
- Communication and collaboration with other teams.
- Adding it as a variant would be too complex.
- Clear validation (e.g., user tests, feedback, metrics).
- Completion of any necessary experimentation phases.
- There is no impact on the functionality of existing components or properties.
✅ Approved Proposals
Once the proposal is validated, the design system team will get in contact with the requestor.
- If design is involved: The design system team will create a branch in Figma in the relevant library (core or team-specific).
- If it’s an engineering-only contribution: The product engineer can start working on the component.
❌ Rejected Proposals
If the proposal doesn't meet the criteria, we will mark it as "Won't Do" and contact the requestor with an explanation.
- If a suitable existing component is available, we will suggest it as an alternative.
- If no existing component fits the need, the requestor should keep it in their local file.
Build
Once validated, the requestor can officially begin working on the contribution, starting with the design or engineering phases. If only one phase is needed, the other can be skipped.
Review required
Before publishing, both phases need an official design system review to ensure consistency in structure, naming, and overall quality.
Final touches
The final touches are handled depending on whether the contribution scope is core or team-specific.
- Core contribution: The design system team will document it in mews.design and announce it on Slack.
- Team-specific: The product team will be responsible for documenting it in Confluence.