Deprecate Beautifying the UI program

## Learning and Development

Our continuous learning initiatives are documented in the [UX Department Learning and Development](/handbook/product/ux/learning-and-development/) section.

## Cross-functional Initiatives

### Beautifying our UI

This initiative aims to enhance our product's usability by leveraging the best practices from the "Macro UX" experiment, which paired Product Designers and Engineers to make self-directed improvements. See the [retro issue](https://gitlab.com/gitlab-org/gitlab/-/issues/351288) for details.

Key Elements:

- **Self-directed improvements:** Product Designers and Engineers are empowered to fix usability issues they identify without strict prioritization constraints.

- **No restrictions on product area:** Improvements can be made across any product area, fostering broad collaboration.

- **Work in MRs, not issues:** Direct changes are made through Merge Requests (MRs), with comprehensive documentation and explanations.

- **Length of rotation:** Pairings last 1-3 milestones, depending on what the pairing believes is appropriate. Multiple pairs can be working simultaneously on Beautifying our UI.

- **Prioritization:** Participants coordinate with their managers to balance their involvement with regular responsiblities.

- **Documentation:** All changes must be documentated, adhering to the [Definition of Done](https://docs.gitlab.com/development/contributing/merge_request_workflow/#definition-of-done), and involving [relevant Technical Writers](/handbook/product/ux/technical-writing/#assignments).

#### Volunteering and Participation

To volunteer, Product Designers and Engineers should:

1. Create an MR to add their name to the volunteer table and assign it to their manager for review.

1. Indicate the percentage of capacity dedicated to the initiative.

1. Create an issue and link all related MRs for transparency and tracking.

1. Ensure all changes align with the Pajamas Design System and leverage feature flags where appropriate.

Volunteers:

| Milestone          | Product Designer  | Engineer          |

| ------------------ | ----------------- | ----------------- |

| 17.5               |                   |                   |

| 17.6               |                   |                   |

| 17.7               | Emily Bauman      | Anna Vovchenko    |

| 17.8               |                   |                   |

| 17.9               |                   |                   |

{{% details summary="Previous Volunteers" %}}

| Milestone         | Product Designer  | Engineer          |

| ----------------- | ----------------- | ----------------- |

| [17.1 (2024-05-13)](https://gitlab.com/gitlab-org/gitlab/-/issues/442453) | Veethika M         | Miguel Rincon |

| [16.1 (2023-05-18)](https://gitlab.com/gitlab-org/gitlab/-/issues/394768) | Veethika M         | Payton Burdette |

| [15.11 (2023-03-18)](https://gitlab.com/gitlab-org/gitlab/-/issues/387070)| Annabel Gray       | Phil Hughes     |

| [15.6 (2022-10-18)](https://gitlab.com/gitlab-org/gitlab/-/issues/378259) | Matej Latin        | Deepika Guliani |

| [15.5 (2022-09-18)](https://gitlab.com/gitlab-org/gitlab/-/issues/374580) | Katie Macoy        | Anna Vovchenko  |

| [15.4 (2022-08-18)](https://gitlab.com/gitlab-org/gitlab/-/issues/370364) | Nadia Sotnikova    | Alex Kalderimis |

| [15.2 (2022-06-18)](https://gitlab.com/gitlab-org/gitlab/-/issues/362122) | Emily Bauman       | Jannik Lehmann  |

| [15.1 (2022-05-18)](https://gitlab.com/gitlab-org/gitlab/-/issues/361641) | Sascha Eggenberger | Robert Hunt     |

| [15.0 (2022-04-18)](https://gitlab.com/gitlab-org/gitlab/-/issues/356703) | Annabel Gray       | Phil Hughes     |

{{% /details %}}

#### Measuring Success

Success of the program will be tracked by the total number of MRs merged with the "Beautifying our UI" label.

#### Risks and Considerations

- Time commitment: The time required for these pairings is variable, potentially impacting regular milestone work and OKRs.

- No user research: Focusing on heuristic reviews might introduce new friction points without direct user feedback.

By following these guidelines, GitLab's Product Design team can continue to drive meaningful, user-centric improvements across the platform.

- Is this feature or capability needed or used, or what would happen if it were removed?

- Is everything "in reach," or are users left wandering?

#### Beautifying and "unboxing" the UI

#### "Unboxing" the UI

Two ongoing design efforts align with sophisticated simplicity:

Ongoing design efforts align with sophisticated simplicity:

1. **Beautifying the UI**: Enhance the UI by cleaning up components or entire pages to create more consistency, organization, and aesthetic appeal. Learn more in the [Beautifying our UI](/handbook/product/ux/product-design/#beautifying-our-ui) section of the handbook.

1. **Unboxing the UI**: Reduce the overuse of boxes for conveying hierarchy, organizing content, and dividing pages into section. Explore better alternatives in this video on ["Unboxing" the UI](https://youtu.be/MxpZuWQH-kk).

### Ideate and iterate

Nice to do:

- [Beautifying our UI](/handbook/product/ux/product-design/#beautifying-our-ui).

- Addressing issues labeled [`Seeking community contributions`](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name%5B%5D=Seeking+community+contributions&label_name%5B%5D=UX) or other low-hanging usability problems.

- Issues in future milestones (e.g., next release or [Backlog](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&milestone_title=Backlog&label_name%5B%5D=UX)).

- Popular issues with no milestone (based on comments or upvotes).