Activity: Release review process
  • 31 Jan 2023
  • 1 Minute to read
  • Dark
    Light

Activity: Release review process

  • Dark
    Light

Article Summary

Together with your team put together a versioning review process. This is a process plan for how changes to the system will be reviewed prior to release. This should include the who, what, when, and how often. This doesn’t need to be a rigid process, and there may be exceptions that fall outside this process, but it’s helpful to have an outline in place before the system is largely consumed.

Think through how you will approach each of the following questions as part of your review plan. You can include the answer within DSM, as part of your governance process documentation.

Stakeholders: 

  • Designer
  • Developer

Steps

  1. Review Sessions
    • How will review sessions be run?
    • Is this part of a weekly standup? A separate meeting?
    • Is it done asynchronously throughout the sprint?
  2. Cadence
    • How often will these sessions take place? If you're having a hard time getting started, we recommend one review session per sprint to begin. Adjust accordingly.
  3. Approvals
    • Who is responsible for sign off?
    • Does one individual have to approve changes to the system? Is the entire team responsible? Make sure to have enough people identified that no one individual is a blocker for release.
  4. Acceptance Criteria

What criteria needs to be met? We will walk through a contributor's guide on the next page.

What You Should Know

Open up your review process to the larger organization. This shouldn’t be a secretive or closed-door process. Think about allowing others to join the reviews, having a meeting summary that others may view, or a sharable link that shows where requests are in the review process.

Contributor's Guide

Since adoption is key to success, promote ownership by allowing users to contribute back into the system.

Sample questions to include in the guide:

  • Name role/team of person requesting the change
  • Net new component/documentation or change to existing?
  • Name of the component (and URL if already in DSM)
  • Description of the change/addition
  • If new, why doesn’t a current component fit the need?
  • Is this reusable or for a single use case?
  • Does it pass accessibility rules?
  • (Optional) Visual of the image or an attached Sketch file

Customer Example

How Apartments.com "Kondoed" their design system

component request form example

Additional Resources

Design System Governance Process by Brad Frost


Was this article helpful?