Rippleresources
Our Process
Here we outline our process for building and iterating on Ripple and provide a guide on how to work with us to meet your product needs. The Ripple Design System is intended for use by all Watermark products and anyone can suggest candidates for a component or pattern. Product teams are considered to be integral partners in the rollout process as end users and quality assurance testers.
Ripple Mindset
Ripple is developed by the Design System team and we are here to help you achieve our company-wide objective of having a suite of products that share the same visual language. Think of Ripple as a living, evolving system. It is the embodiment of the designs and workflows in all Watermark products. We are happy to continuously iterate the design patterns and components as you communicate your changing needs.
Evolution Through Collaboration
Ripple is open to any opportunities that allow for growth and adaptation. If you encounter any discrepancies between Ripple and your design needs, either regarding an existing part of Ripple or where the system falls short, we want to hear them!
Help us help you
Every conversation helps the development of the system in a number of possible ways. Every time you inform us of your changing needs is an opportunity for us to make Ripple better for you. Iterating on patterns, adding new components, clarifying usage, or being aware of emerging patterns, are just some of the great things we get from you.
Request Process
The Design System team strongly encourages Watermarkers to propose candidates for new components, patterns, or variations to current components. Ideal candidates will be used frequently and consistently in one or more products.
Identify and Communicate
Identifying new components or updates can come from product designers, product owners, or developers. Begin the conversation by discussing the request with the product designer on your product, then reach out to the team either by Slack or email with as much information as possible including a Ripple severity scale rating.
Discuss and Prioritize
In this step of the process we will determine if the requested component or pattern can be reused with other use cases and products.
If it is something too custom for the specific use case, it will not continue through the process. If this is the case, the Design System’s designer will work with the product designer to find an alternative pattern or plan for a future component for another date.
If it is a good candidate for a reusable component or pattern, we will thoroughly discuss the need with the product designer and create a story in our backlog and prioritize it.
Design and Review
The Design System’s designer will begin the design and specification stages. Requesters should be prepared to answer questions throughout this process to ensure that we set the proper acceptance criteria.
Communicate Timeline
After the design phase has been completed and the Design System team has committed to the story, the team will share the expected release date.
Final Approval
Specifications will be sent to the #designsystem Slack channel, and approval is required from the requester before the development phase begins.
Development and QA
After approval, the Design System team’s engineer will begin development, and the update will be thoroughly QA’d by Engineering and Design.
Update Released
After development is complete, the team will get approval from the requester and release the update. If the update includes a new component, it will be released in the new version of the components library following the components rollout process.
Components Rollout Process
Communicate
At the start of the Design System sprint, the Design System team will announce new components or iterations to existing components expected to be introduced in the next release. This occurs in PO Sync meetings 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.
Release & Announce
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.
Implement & Test
The front end developers for each product will then implement and test the new version of the component. They will report any defects to the Design System team for a prompt resolution.
- If the component’s release happens to be too close to the end of the product's current sprint, implementation and testing will occur in the first sprint of their next release cycle.
- 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.
Communicate
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.
Implement & Test
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.
