This page outlines the guidelines for Product Designers when reviewing merge requests (MRs), also called “UX reviews” or “Product Design MR reviews”.
Almost all merge requests (MRs) change the UX in one way or another, but Product Designers are only required to review and approve MRs that include user-facing changes. Per the approval guidelines, “user-facing changes include both visual changes (regardless of how minor) and changes to the rendered DOM that impact how a screen reader may announce the content.”
MRs with only backend changes sometimes affect the UX (for example, performance changes, sorting of lists, etc.), but you are not required to review them unless they fall under the definition of “user-facing changes”.
To help triage, be aware of all MRs in your stage group and ask engineers about which MRs could affect the UX and how. Product Designers often give constructive feedback on any kind of MR, including MRs that seem to not affect the UX, so use your best judgment when deciding which MRs you should review.
If you're asked to review an MR from another stage group and the corresponding Product Designer hasn't been involved yet, remind the author about that Product Designer and request a review from them.
MR review requests are the number one priority for Product Designers. Respond to them per our first-response Service-Level Objective, not only when the request comes from within your stage group, but also when it's a community contribution or another stage group asks for your input.
Balancing MR reviews with other priorities is a challenge, as they can be unpredictable. To avoid disruptions and context-switching, we suggest you block some time every day to review MRs (for example, 30 minutes or 1 hour per day).
If you're struggling with MR reviews, remember to manage expectations with MR authors and let your manager know right away so they can help you.
In general, follow the Code Review guidelines (it's a long document, but please read all of it). Exceptions to those guidelines are noted below.
Always try to preview the MR in a live environment, so that you can experience the changes are users will and review them thoroughly. That said, it's okay to rely on screenshots/videos if they allow you to review everything in the design and UI changes checklist (usually the case for tiny MRs).
| This MR | Expected | |-------------|-------------| | Image/video | Image/video |
UX debt(learn more about this label in how we use labels).
The Product Design merge request (MR) review volume is tracked as a Key Performance Indicator (KPI) of the UX department.