We follow the Product Designer workflows and UX Researcher workflows described in the Product Design section of the handbook. As Growth designers, we relentlessly measure the impact of our design changes following the experimentation workflow. In addition:
We use the Product Development Flow to help move issues through the product lifecycle. For the design phase to being, the following are important:
The template can also be copied into the main issue that is the SSOT.
|Type||% of Milestone||Description|
|Deliverable||65%||business priorities, includes design and solution validation|
|Proactive UX and Measurement||25%||research and ideation for future improvements, CM Scorecards, competitive evaluation fixes|
|UX Department Priorities||5%||Pajamas, UX OKRs, professional development|
|Other||5%||designer picks, attending company wide meetings, administrative tasks, professional development|
There is a lot of overlap between Fulfillment groups, so we work very closely. To keep things simple and clear, we follow GitLab internal communication guidelines. In addition the following tips will make it easier to collaborate with Product Designers who span multiple groups:
We collaborate with each other on issues across different Fulfillment Groups. On our monthly planning issues, each designer should indicate high priority or time consuming issues from other groups. A link to the other planning issue is fine too, just so it's easy for the Product Design Manager and Product Managers to navigate to this information.
The engineering team applies the
UX label to any MR that introduces a visual, interaction or flow change. These MRs can be related to new issues, bugs, followups, or any type of MR. If the engineer isn't sure whether the MR needs UX, they should consult the designer who worked on the related issue, and/or the designer assigned to that stage group, or the Product Design Manager.
Live reviews are desired for any MR with the
UX label. When the MR is in
workflow::In review, the engineer assigns the MR to the designer for a review using the reviewer functionality in the sidebar. This can happen in parallel with the maintainer review. Designers should prioritize these reviews to complete them as quickly as possible.
There are times when it isn't possible or practical for a Product Designer to complete their review via their local environment. At these times, the Product Designer can review screenshots and videos in the MR description or coordinate a demo with the Engineer. Another option for more complicated changes is keeping the change behind a feature flag and reviewing the change on staging after the MR has been merged. This is up to each Product Designer's discretion.