Contribution

Our contribution model allows product designers and engineers to add or enhance components, variants, and patterns in our design system.

The Engineering Phase

Once you have the design assets or your engineering-only request is validated, you're ready to start the engineering phase. Product engineers should develop the component in GitHub and request a review from a design system team member.

  • Talk to your designer: Ensure the design is approved by MDS before starting a PR.
  • Implement: Think about API and functionality and build the component with the related story.
  • Test: Check if the story covers everything.
  • Pull request: Submit a draft PR, mark it as "Ready for review" once tests pass, and notify the DS engineer.
  • Merge: Merge the pull request in GitHub.

Contact us at #rnd-designsystem-support if you have any questions or need assistance.

 


Engineering checklist

We recommend following this checklist to ensure standardized quality for all MDS components.

  • The component is implemented strictly according to the design system. Its API does not allow extra variants or behavior that is not documented.
  • The implemented component is modular and follows the separation of concerns principle. Every component has a clear purpose and should contain logic, styles, and types regarding it.
  • The component is fully accessible (WCAG 2.2 Level AA compliance).
  • There are no 3rd party libraries used. We want to keep the implementation as light and independent as possible. This is especially concerning lodash and fp-ts.
  • The component is covered with an accessibility test and all complex functions are covered with unit tests.
  • All fundamental values (spacings, colors, elevations, …) are connected to design tokens.
  • There's a storybook story defined according to our guide for every component:
    • covering the fundamental use cases with just the needed stories
    • following the recommended techniques
    • offering some component API documentation by adding comments to the TS interface, as explained in the Confluence page
    • ensuring the story itself has no A11y problems
    • ensuring the Storybook UI is robust and can not be broken using the available controls in the story
  • Technical documentation is written and published on mews.design.