How to organise and run a working group review
We hold a working group review when:
- we develop a new component or pattern
- we make a significant iteration to an existing component or pattern
- we make a change that will affect when users should use a component
- we add or update content that will affect how users make services and meet the Service Standard
When to hold a working group review
Most new components and patterns have two working group reviews. The first review is at the proposal stage to assess if the new addition is useful and unique. The second review is at the development stage when a prototype has been built and tested. However there is flexibility with this model and not all components and patterns may need two working group reviews, for example, upstreaming a robust and fully tested component from another library.
When making an iteration to an existing component or pattern, making an operational change or adding new content, only one working group review will be required (at the development stage).
How to organise a working group review
Firstly identify your timescales. Most working group reviews run for two weeks, with a playback session in the week after the review has completed. At this stage, it’s helpful to give the working group a heads up on their Slack channel so they can begin planning. At this stage you can also work with the group to identify a suitable date for the playback session (you can use a polling tool such as Doodle to do this).
We provide information for the working group to review on a Google Sheet. You can make a copy of the template here.
Once the spreadsheet has been completed (ensuring sharing permissions are updated), it’s ready to be shared with the working group. You can find the email addresses of current working group members here. In the email, make sure you include links to the review spreadsheet and contribution criteria, the deadline for the review, the date of the playback session (if already arranged) and a method to get in touch with the team if they have any questions. We also encourage the working group to speak to colleagues in their department as part of the feedback process.
Please also BCC the Design System team email address into the email so there is visibility of the review.
Throughout the review process, it’s helpful to keep checking the spreadsheet for responses to help you gauge whether you need to send reminder emails.
How to prepare for and run the feedback session
Once an appropriate date for the playback session has been identified, create a Google Meet and send an invitation to working group members.
It’s useful for the squad to review the feedback before the playback session, pulling out any interesting topics or points of conflict which are worth discussing in the playback session. The playback session shouldn’t be any longer than an hour so selecting the topics you want to discuss further in advance will help with timekeeping.
You can start the session by asking each working group member for a brief summary of their feedback, dipping into the context of their organisation. You can then start discussing the points of interest you have previously agreed.
You’ll need to select a facilitator of the session, and ensure you have subject matter experts available to answer any questions which arise. It’s also helpful to assign a notetaker to record any actions.
After the working group review has completed
After the working group review has finished and you have run the playback session with the group, you’ll need to decide what changes you want to make based on the feedback provided. Once decided, let the working group know, either via Slack or email.
We also usually publish a summary of the working group review and decisions on the relevant item on the community backlog.