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.
Please see the UX Strategy to view the evolving UX vision for GitLab.
The UX Manager is responsible for reviewing epics and applying the ~"Epic UX Approved" label on epics that have met the following criteria:
Contains requirements documentation
Scope for UX discovery has been allotted
Creating and labeling issues
UX label: indicates that UX work is required on this issue.
design artifact label: indicates that the final expected output for this issue is a UX/design solution. The implementation of the final solution will be developed in a subsequent milestone. The UX/design solution is due on the 7th of the month corresponding to the milestone where the 22nd is the release date. (For example, 10.6 was released on March 22nd, 2018. design artifact labeled issues with milestone 10.6 were due on March 7, 2018. This follows the same due date as the feature freeze for engineering.)
UI polish label: indicates the issue covers only visual improvement(s) to the existing user interface
UX debt label: indicates that the issue covers user experience improvement(s) that weren't fully implemented or could be refined after implementation.
Product Managers and UX Designers are very closely related although they might seem different. Both Product Managers and UX Designers work within the problem–solution spectrum in order to better understand the problem that needs to be solved and to determine the most viable solution that addresses that problem. Over-communicate with Product Managers, it's the best way to understand the problem and arrive at a solution.
Before coming up with any solution, discuss the scope with the Product Manager, ask questions, and define what the problem really is (often it's not what people think it is).
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 everyone 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.
Wireframing, mockups, and prototyping all have their own place. You should utilize the best tool for communicating a problem/design/solution.
Proposals don't need to have images. Sometimes words can paint a surprisingly good picture of how an experience should feel, look, and behave.
Frame discussion around the problem being solved, not the designs specifically.
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 department, 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.
If you are proposing a solution that will introduce a new UX paradigm, or change an existing one, please consider the following: Will this pattern be inconsistent with other areas of the application? Will other areas of the application need to be updated to match? Does this new pattern significantly improve the user experience? If you decide that it is worth changing, there are additional steps that must be followed. See the 'Maintain' section below for those steps.
Once your work is complete, 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:
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.
When any of those requests are merged, add an agenda item to the next UX weekly call to inform everyone of those changes.
Requesting UX Research:
Create a new issue using the Research proposal template in the UX research project.
Ensure you answer all questions outlined in the Research proposal template.
UX Researchers review the backlog of issues within the UX Research project every month. If they have the capacity to complete the research request, they will assign themselves to the issue and schedule the work accordingly.
Every month UX Researchers do the following:
In the UX research project, review all issues labeled with Backlog.
In the CE and EE projects, review all issues labeled with Product Vision 2018.
In the CE and EE projects, review all issues labeled with UX Research and design artifact. If the issue does not require UX Research, the UX Research label should be removed.
Self-assign to issues
For issues that you want to work on, assign yourself to the issue. Add the UX Research label (if not already present) and add a Milestone.
Ping UX Manager and the relevant Product Manager in a comment within the issue.
Working on a UX Research issue:
Create a research issue:
Create an issue within the UX research project. There are templates available for surveys, moderated and unmoderated studies which will pre-populate some of the below.
Label the issue with the area of GitLab you’re testing (for example, navigation) and the status of the issue (in progress).
Mark the issue as confidential until the research is completed so it doesn’t influence user behavior.
Assign the issue to yourself.
Every issue should have a progress checklist. This makes it easier for people to understand where the research is up to.
Add research questions, assumptions and the aim of the research to the issue description.
Add related issue numbers.
Conduct the research. Ensure you keep the progress checklist up-to-date.
Document findings within a report.
Update the issue you created in the UX research project:
Add the findings report.
Unmark the issue within the UX research project as confidential. (In some cases the issue may need to remain confidential if sensitive information is shared. If you’re unsure of whether an issue should remain confidential, please check with Sarah O’Donnell @sarahod or Katherine Okpara @katokpara).
Update the status of the issue to done.
Inform people of your research:
Within the issue, encourage discussion between yourself, UX Designers and Product Managers 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. If relevant issues already exist, add your findings to the existing issue description or comments. Always link your findings back to the issue within the UX Research project.