The UX Guide documents our principles, approach, and perspective to the experience of GitLab. Help keep this document up to date and correct by creating merge requests.
The vision of GitLab is far from finished and there are a lot of emergent properties that will allow us to simplify. We believe in iterative improvements and value aggressive change. We will get some things wrong and quickly strive to make them right. We have a long way to go, that is why we are taking big steps.
If UX work is required, add the UX label to the issue. If the issue covers small user interface refinements, consider adding the UI polish label as well.
Working on issues
Filter by the UX label and then choose in the following order:
Has the current release's milestone
Has the next release's milestone
Has milestone Next 2-3 months
Has milestone Next 3-6 months
Has milestone Backlog
Popular or with high community involvement (number of comments or upvotes)
Before committing to issues, check if another UX Designer has already participated. If their latest activity on that issue was within two months and you’d still like to work on it, ask them what the status is and if you can pick it up for them. If their latest activity on that issue was more than two months ago, just let them know that you’ll be picking it up for them.
Define the scope:
UX issues have a tendency to expand in scope. Aggressively split off new issues, ideas, and concepts into their own issues. Large issues become really challenging to drive decisions in and make progress on. If you’re ever unsure how to split apart large issues, work with the UX Lead.
Developers should be able to ship a product within one life cycle. If a feature is too large to ship within one release, work together to determine the best way of splitting the feature into smaller segments.
Bring developers into the conversation early. Ask for feedback on how to split up features while still maintaining the integrity of the UX.
When breaking up features into smaller parts, make sure that the end design goal is known. Giving the team the full picture will help developers write code aimed at achieving that goal in the future.
Keep the issue description updated with the agreed scope, even if doesn’t impact your work. This is everyone’s responsibility. The issue description must be the Single Source Of Truth (SSOT), not the discussion or individual comments.
Add comments with your proposals. Propose one solution, not multiple alternative solutions for others to pick, as this undermines your position as a UX expert and leads to a design by committee situation. If you have a good reason to propose multiple alternative solutions make sure to explain why.
Anticipate questions that others might have and try to answer them in your proposal comments. You don’t have to explain everything, but try to communicate a bit of your rationale every time you propose something. This is particularly important when proposing changes or challenging the status quo. This reduces the feedback loop and time spent on unnecessary discussions while contributing to the credibility of the UX team, who deal with a lot of seemingly subjective issues.
Keep the SSOT updated with what’s already agreed upon so that everyone can know where to look. This includes images or links to your design work.
If you’re working with design files, follow the instructions in the GitLab Design project and regularly commit them.
Before you hand off the work, make sure that the SSOT is updated. This is where you should direct people when they have questions about what should be done and how.
If applicable, commit all design assets and files according to the instructions in the GitLab Design project.
Once UX work is completed and all feedback is addressed, remove the UX label, add the UX ready label, and:
If the issue is scheduled for a milestone, add the next workflow label needed to progress the issue. Typically, this is the Frontend label.
Keep the SSOT in the description updated until the issue is closed. This applies to both text and mockups. Previous content (by a PM, for example) should be removed or archived into a separate section in the description. If the developer working on the issue ever has any questions on what they should implement, they can ask the designer to update the issue description with the design.
If you want to discuss any aspect of the research, you should add comments to the issue you created in step 1.
Add the label backlog to the issue.
If there are any related issues in the GitLab CE or EE project, ensure they have the label of UX Research.
What is the UX researcher workflow?
Work with the UX team to determine what should be researched.
Create a meta issue within the UX research project.
Label the meta issue with the area of GitLab you’re testing (for example, navigation) and the status of the issue (in progress).
Mark the meta issue as confidential until the research is completed so it doesn’t influence user behavior. If there are any associated issues in the UX research project, you’ll also have to mark these as confidential too.
Conduct the research.
Document the findings and recommendations within the meta issue.
Unmark the meta issue and any associated issues within the UX research project as confidential.
Update the status of the meta issue and any associated issues within the UX research project to done.
Within the meta issue, encourage discussion between yourself, UX designers and product owners about which findings should be turned into issues within the GitLab CE or EE project.
Create the agreed, new issues within the GitLab CE or EE project. Link the issues back to the meta issue within the UX Research project. Label the new issues as appropriate.
Close the meta issue and associated issues within the UX Research project.
UX on Social Media
It is encouraged to share UX designs and insight on social media platforms such as Twitter and Dribbble.