This page outlines detailed guidelines for different ways of reviewing merge requests (MRs) for “UX reviews” or “Product Design MR reviews”. For step by step guidance of the full process go to the Product Design MR reviews page.
There are several methods for you to review, test, and contribute changes to the app, user documentation, Pajamas, GitLab UI or company handbook.
We encourage MR authors to add screenshots or videos of their changes. However as they don’t cover all review aspects (for example, hover states, small viewports, accessibility, and so on.), you cannot rely on them exclusively and should always review the MR in a live environment.
The most common methods to review the MR in a live environment are:
|Gitpod (cloud)||GDK (local)||Review App||Sync with author|
|First start*||🏃♀️ Fast (<5 min)||🐢 Very slow (30+ min)||GitLab (>30 min)
Docs (>20 min)
Pajamas (~10 min)
Handbook (~10 min)
|🏃♀️ Fast (few mins)|
|Restarts||🏃♀️ Fast (<2 min)||🤷 Depends†||🚀 Very fast (secs)||🏃♀️ Fast (few mins)|
|Toggle feature flags||✅||✅||✅||✅|
*: The time needed to preview changes for the first time. Depending on the
method it includes steps like installation, build, deployment, etc.
†: When using a local GDK, the time it takes to restart it depends heavily on your local machine specifications.
§: Ability to save the current environment state, including its data, license information, feature flags (if applicable), etc.
¶: Only applicable for GitLab instances. Test data includes pre-created users, projects, branches, issues, merge requests, epics, etc.
GitLab is a complex platform that helps teams shorten cycle times, reduce costs, stregthen security, and increase developer productivity. In order to make the DevOps lifecycle more approachable for all users, it is essential that each member of the Product Design department has general knowledge of Git and DevOps flows by frequently using the various features across the product.
The Product Design department builds confidence in these areas by using the product in a live environment and contributing small fixes to the various projects that make up GitLab, including the app, user documentation, Pajamas, and GitLab UI. Designers are not expected to be full stack developers, but we do expect designers to grow their basic development skills to build empathy and understanding for the workflows our users experience on a daily basis.
Additionally, building these skills has the added benefit of empowering designers to directly make small, meaningful changes to the product. Migrating components or updating UI copy, for example, improves the consistency, visual design, and accessibility of the app.
To use Gitpod you must create a Gitpod account (free) and connect it to your GitLab account. If you launch Gitpod from any project on GitLab.com your accounts are automatically connected (see links below). If for some reason that doesn't work, see how to manually connect your GitLab.com account.
You can enable a feature flag by sending an API request to the review app using a tool such as
curl or Postman.
If you get stuck using any of these methods, follow the tips below in order. Don't struggle on your own and, when in doubt, ping a UX member to facilitate finding the right help.