Our Process
Components Request Process
The Design System team strongly encourages Watermarkers to propose candidates for new components or variations to current components. Ideal candidates will be used frequently and consistently in one or more products.
- Begin the conversation by reaching out to the team either by Slack or email with as much information as possible and include a Ripple severity scale rating.
- Once we reach an understanding, we will create a story in our backlog and prioritize it.
- Every candidate will go through design, specification and coding stages. Requesters should be prepared to answer questions in the design and specification phases to ensure that we set the proper acceptance criteria.
- Once the design phase is complete and the story is committed to by the Components team, the team will share the expected release date as part of the Components Rollout Process below.
- Specifications will be sent to the #designsystem Opens a new window Slack channel, and approval is required from the requester before the coding phase begins.
- Once coding is complete, the team will get approval from our Watermark Director of Accessibility Program and the requester, and release the component in a new version of the components library and rollout as described below.
Components Rollout Process
The Watermark Components Library is a part of the Ripple Design System and, as such, is created by the Design System team. Because it is intended for use by all Watermark products, they are not typically product-specific, and anyone can suggest candidates for a component. Product teams are considered to be integral partners in the rollout process as end users and quality assurance testers.
During regularly scheduled meetings at the beginning of a Design System sprint, the Team will announce new components or iterations to existing components expected to be introduced in the next release. Currently, those meetings are the PO Sync meeting, and meetings with representative front end developers for the products currently using the components. If a specific team knows that they will be greatly affected by the upcoming release, this would be the time to plan for testing.
Once released, the Ripple Design website will have a more detailed list of changes on the Versions page, and the necessary documentation will be added/updated. We will send an announcement to a number of Slack channels consisting of a very broad spectrum of interested parties. The front end developers for each product will then implement and test the new version of the component (in the first sprint of their next release cycle if the components release happens to be too close to the end of the product's current sprint). They will report any defects to the Design System team for a prompt resolution.
Teams should prioritize rollout conversion to component usage where appropriate within two releases, which happens every three weeks.
Global Change Process
Occasionally, the Design System team will make changes to the global stylesheet that may affect the design or layout of existing page elements.
At the beginning of a Design System sprint, the Team will announce the style changes expected to be introduced for testing with the next release.
- For products using the global styles from our Watermark CDN, the team will provide a URL for a release candidate for testing.
- For products that import the styles as a Git submodule, the team will provide a Git branch name for testing.
Global style changes are intended to unify layout and design patterns across Watermark products. As such, testers should not only pay attention to where the changes result in an undesirable appearance, but also where product styles might be overriding the desired change.