Release UX: Splitting up design resources
Description
The Release Stage has gone through a team split, mainly on the Frontend, Backend, and Product Management so there is more focus for specific areas of the stage. We are currently 2 designers sharing responsibilities for both Progressive Delivery and Release Management groups, and we are considering a similar split within the stage to give each designer an area to focus on and a sub-group to be the main contact for.
How might we support the Release stage now that there is a sub-group split, multiple overlapping categories per sub-group, and multiple functionalities overlapping in the ci/cd department?
Goals
- Decide whether an interstage split is the right decision.
- Decide what the split should look like and the responsibilities of each area are.
- Align on what it means to be responsible for a group.
- Discuss how to best communicate the split.
- Discuss how we might operationalize this.
- Pilot the split during 1-2 milestones.
Current issues
- Difficult prioritization of workload with counterparts (PM/Eng).
- Designers spend too much time in meetings covering for 2 stage groups at the same time.
- No clear guidance for counterparts on which Product Designer is responsible for what group.
- Too much context switching for work between Product Designers.
- Risk of UX work being compromised when someone goes out of office.
Current strategy
It's difficult to divide the stage based on the categories we have today and how those align a set of features for a designer to be responsible for. Our current UX Structure is defined below:
Progressive Delivery group | Dedicated Designer | Release Management group | Dedicated Designer |
---|---|---|---|
Continuous Delivery (CD) | Rayana Verissimo | Release Orchestration | Rayana Verissimo |
Incremental Rollout | Mike Nichols | Release Governance | Rayana Verissimo |
Review apps | Shared | Pages | Mike Nichols |
Feature Flags | Mike Nichols | Secrets Management | Mike Nichols |
New strategy
We will Pilot the split during 1-2 milestones (12.8 being the set up phase, and 12.9 the kick-off), and assign each designer to be the UX DRI one specific stage group. The split is not clean when it comes to the overlapping areas though -- we want to stay included in the overall Release vision and strategy.
In the first phase of the Pilot, we want to make sure we build rapport and share knowledge before moving towards a split. For that, we will commit to walk each other through what's coming up on the areas we don't know about. This step is important since we want to be sure the PM/Eng teams will be minimally impacted by our decision to split the ux resources.
What it means to be the UX DRI for a stage group (job description)
- Has end-to-end understanding of technical and user experience of stage group.
- Drives discovery/ux research of stage group.
- Actively includes UX CI/CD teams in the design process of shared capabilities.
- Communicate results companywide (team, ux ci/cd, ux team).
- Lead design reviews.
Goals of the pilot
- Focus on knowledge sharing: prepare each other to the formal split.
- We will chose 1 topic per UX sync (or 1:1) and go over its vision, current maturity state, and upcoming items.
- We can also chose to ping each other on issues, to shadow UX activities.
- Update handbook with shared ux areas in Release so that we build a common vision.
- Make a decision on final split.
- Document our process and iterate.
How we've divided the Release stage
- Have shared understanding of overlapping items and run JTBD as a team. Those items should be the drivers of our syncs and 1:1s.
- If an issue touches the shared items, it should be communicated to the ux ci/cd team. everyone gets notified.
- Stage group ux designer is still the DRI but whole team can participate.
Through this network graph, we have identified the the following shared UX areas within Release:
- gitlab-ci.yml
- Environments
- Environments variables
- Environment dashboard
- Merge requests
- Issues
- Project settings
- User settings
- Kubernetes
- Runner
- Audit log
Note: This list is incomplete and should be updated as the categories move up on the maturity level.
Release UX designers will be DRI of the split items, sharing responsibility in the overall vision, goals, and research initiatives related to those. We will commit to stay aligned with the engineering groups as much as possible, being the conversation drivers with product managers and other counterparts.
We will communicate that an item/issue is overlapping with both a label and a note in the issue for awareness.
Note: It is clear that the split items also overlap with other CI/CD areas (Verify, Package).
We want to make sure other designers are also part of the conversation, and we plan to bring the shared items to the UX CI/CD calls.
UX Workflow adjustments
We will create a label for overlapping Release (CI/CD) capabilities, to help us identify which group a particular issue falls into and which designer should be the DRI. The label should also help us stay on top of the discussion as a group.
For the sake of this Pilot, we will use the label only for Release (CD) items.
- New label:
CI/CD UX::Shared
- Examples: AWS environment variables, Improve visual indexing of CI/CD Variables.
- Who to ping: The designer DRI of the stage group (see labels ~"group::progressive delivery" and ~"group::release management"). The other designer should be pinged to (potentially) groom the scope and review any design proposals.
Note: The label is only to be used when UX support is required.
They do not need to be applied to issues that are solely engineering based.
Grooming, planning, and assignments
Release UX will meet after the stage grooming session to go over the milestone and discuss overlapping items. During grooming, we will add the proper label to all issues requiring UX support and assign DRIs.
Meetings
- For now, there will continue to be 1 UX Release meeting where we discuss all things UX + Research + Release.
- We keep only 1 PM/UX Sync during. The agenda will be set around the overlapping items.
- We will keep communicating broader design items during the UX CI/CD weekly call.
Engineering group meetings:
- The assigned designer will attend (sync or a-sync) their associated engineering groups meetings.
- It's the designers' responsibility to communicate with one another in the case that something is discussed that may impact the other designer's work.
Next phase
- PMs, Engineering managers and engineers will have an assigned go-to designer for you to reach out to based on the engineering group you belong to.
- Release UX will be able to oversee an entire stage group, while staying on top of shared ci/cd design efforts.
How do we want to communicate the final split
-
Handbook update release, release ux. -
Update team page with your stage group @mnichols1 @rayana . -
Update profile with your stage group. -
Update both Release teams during the weekly calls, on slack. Update the UX team during the weekly call. -
Success metric: when the team learns who's the DRI of each stage group
Links
We're already discussing how we want to have productive meetings with stakeholders and counterparts #605 (closed)