Commit aa315565 authored by Taurie Davis's avatar Taurie Davis
Browse files

Merge branch 'rayana-master-patch-78025' into 'master'

Define UI Polish

See merge request !74354
parents 6078ead4 f34aec1e
Pipeline #255000613 passed with stages
in 9 minutes and 51 seconds
......@@ -95,6 +95,10 @@ When weighting issues, we aim for [velocity over predictibility](/handbook/engin
This section provides an overview of how we work with issues. But it's very important for you to communicate with your PM and EMs early and often about how you should work together. Many teams have different flavors of this process as they have adapted to the needs of that product and that team.
#### UX debt & UI polish
See the definition of [UX debt](/handbook/engineering/workflow/#ux-debt) and [UI polish](/handbook/engineering/workflow/#ui-polish) in the Engineering Workflow page.
#### Triaging UX issues
Every Product Designer in GitLab is empowered to triage issues with "~UX", "~UX debt", and "~UI polish" labels, or should be included for feedback by the responsible PM and EM instead. Use [Priority labels](/handbook/engineering/quality/issue-triage/index.html#priority) to propose the time when the issue should be solved and [Severity labels](/handbook/engineering/quality/issue-triage/index.html#severity) to communicate its impact on users. Always work to align and communicate with your PM and EMs on the labels assigned.
......@@ -561,12 +561,29 @@ For technical debt which might span, or fall in gaps between groups they should
## UX debt
Sometimes features release to production without meeting design and [Pajamas]( specifications. We create UX debt issues to capture these discrepancies. For the same reasons as technical debt, we don't want UX debt to grow faster than our code base.
Sometimes features release to production without meeting design and [Pajamas]( specifications for usability and feature viability standards as defined in agreed-upon design assets. We create UX debt issues to capture these discrepancies. For the same reasons as technical debt, we don't want UX debt to grow faster than our code base.
We apply the `UX debt` label to these issues, and it is prioritized like [other technical decisions](/handbook/engineering/#prioritizing-technical-decisions) in [product groups](/company/team/structure/#product-groups) by [product management](/handbook/product/product-processes/#how-we-prioritize-work). You can see the number of UX debt issues on the [UX Debt dashboard](
As with [technical debt](#technical-debt), UX debt should be brought up for [globally optimized](/handbook/values/#global-optimization) prioritization in [retrospectives](/handbook/engineering/management/team-retrospectives/) or directly with the appropriate member of the [Product Leadership team](/handbook/product/product-leadership/).
## UI polish
UI polish issues are visual improvements to the existing user interface, touching mainly aesthetic aspects of the UI that are guided by [Pajamas]( foundations. UI polish issues generally capture improvements related to color, typography, iconography, and spacing. We apply the `UI polish` label to these issues. UI polish issues don't introduce functionality or behavior changes to a feature.
### Examples of UI polish
- **Aesthetic improvements** ([example]( removing unnecessary borders from a UI, updating the background color of an element, fixing the font size of a heading element.
- **Misalignment of text, buttons, etc** ([example]( although because many times something isn't broken, these improvements are considered UI polish. These could also be considered a bug.
- **Incorrect spacing between UI elements** ([example]( when two interface elements are using inconsistent spacing values, such as 10px instead of 8px. It could also be considered technical debt. Note that if two interface elements have zero space between them, its an obvious bug.
- **Visual inconsistencies across different product areas** ([example]( visual inconsistencies could occur when we have have a series of buttons on a particular view. For example, when 3/4 of them have been migrated to use the Pajamas component, and 1/4 of them are still using a deprecated button, resulting in a visual inconsistency. This is considered a UI polish.
### What is not UI polish
- **Functional inconsistency related to the experience**: for example, using a manual action to add an assignee automatically shows the assignee in the sidebar but using a manual action to add a weight to an issue does not automatically show the weight in the sidebar. This is not currently considered UI polish. It would be considered a UX issue.
- **Improving visibility of system status**: status indicator improvements are experience improvements and are not classified as UI polish.
- Even when updating something that is purely visual, such as a status icon, to improve the meaning the user has of what they are viewing, we are trying to improve the experience of that user.
## Monitor Merge Request Trends
Open merge requests sometimes become idle (not updated by a human in more than a month). Once a month, engineering managers will receive an [`idle MR triage issue`]( that includes all (non-WIP/Draft) MRs for their group and use it to determine if any action should be taken (such as nudging the author/reviewer/maintainer). This assists in getting merge requests merged in a reasonable amount of time (which we track as the metric MTTR: Mean Time to Merge).
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment