Skip to main content

Governance Process

The Gist

Gist

Full Process
(Note: right click to open in new tab to see the full image)

Process

Happy Path​

Happy Path

1: Product team comes to Design System (DS) to help design and build new work​

Product Teams should default to using the design system’s components to help create new product work.

The best case scenario is that a team comes to the library, finds the component they need and finds that it fulfills all their requirements.

Talk​

Talk

2: What if the design system’s components don’t exist or don’t fulfill requirements?​

If the team comes to the design system and doesn’t find the component they need, if an existing component doesn’t fulfill all the requirements, or if they’re just not sure if the system has what they need, the first step is for the product team to reach out to the design system team via Slack.

The teams will have a conversation to better understand the issue, and then determine whether or not new work needs to happen. Often the design system team can help guide the product team to an existing solution that meets the requirements.

3: When new work is needed, is it a snowflake, a template or a design system component?​

If the teams agree that new work needs to happen, the first thing that needs sorted is whether or not the the work is:

  • A snowflake, which is a component that only really pertains to one specific product or use case.
  • A template, which is a specific composition of design system components (for the most part) that are to be consistently used across a product, but aren’t agnostic enough to live in the design system.
  • A design system component, which is a component or variation that is part of library that serves all products.

The teams will then prioritize the work to be done. If the work is a snowflake, it’s likely that the product team will own and execute the work. But if it includes changes on the design system, it is usually on the team who took the lead on the initial explorations - depends on a number of factors, including priority, urgency, and available resources.

Design & Build​

Design & Build

4: Formal DS design/dev process​

Designers and Developers meet check the requirements and defice the concept to be build. This process involves representing the new component or variation in Figma as well as building the component in the design system’s frontend codebase in a feature branch (for example, feature/primary-button). The component will follow the design system’s code guidelines and will consider reuse, flexibility, composition, accessibility, performance, and other best practices.

5: Test process​

When the component is built, QA tests will ensue across the following areas:

  • Content – can this component or variation handle a variety of content situations (such as lengthy or internationalized text)?
  • Accessibility – does this component meet or exceed accessibility requirements and follow accessibility guidelines?
  • Cross-browser/device – test across supported browsers and devices
  • Responsive – test across the entire resolution spectrum to ensure proper display on any screen size
  • Functionality – unit testing for functionality
  • Internal code review – ensure component code meets design system coding standards
  • Internal design review – ensure work adheres to the design language and meets all design requirements
  • Trial in applications – It may be helpful to collaborate with user devs to test a pre-release of the component in applications to ensure things work properly
  • Any other internal QA and testing

If some issue is found the teams will iterate over until all the requirements are met.

6: Review with product team​

The product team and design system team will meet for a final review. If the product team doesn’t approve the work, iteration will happen and the teams will regroup until the product team signs off on the work.

7: Documentation and stage for release​

Once signoff happens, the component/variation will be documented on figma, code and documentation website will be finalized, the changelog will be updated, and the feature branch is merged into the master branch, which means it is staged for the next release.

Release​

Release

8: New design system release​

When it’s time to create a new release, a new version of the design system is released containing the new work following the semantic versioning guidelines. The design team communicates the new release via all appropriate channels.

Adopt​

Adopt

9: Product team adoption and QA process​

The product team pulls in the new version of the design system into the application codebase and tests the new work. If questions or bugs emerge, follow the support process to handle any questions or issues on the Slack channel #ask-the-wall.

If no bugs are found, the work is staged for the next release of the application and the new component or variation makes its way into the live application!