Welcome to the GitLab CI/CD UX team handbook page. We're comprised of three stage groups that support designing and building the GitLab DevOps product: Verify, Package, Deploy, and SaaS Platforms stages.
| GitLab.com | @gitlab-com/gitlab-ux/cicd-ux |
| Slack channel | #ux_ci-cd (internal only) |
| Youtube playlists | CI/CD UX - Team Meetings |
| CI/CD UX Team - Design Reviews | |
| Ops Section page | Ops handbook |
Our mission is to design and create simple, clean ways to make GitLab the tool of choice for deploying software where, when, and how users want.
Our design team works to ensure the best experience for users of all knowledge levels, allowing them to successfully apply the continuous methods (Continuous Integration, Delivery, and Deployment) to their software with no third-party application or integration needed.
TBA
TBA
TBA
TBA
Our product design team is working to uncover customers' core needs and streamlining their workflows by being the conversation drivers with product managers, developers and other counterparts across stage groups. We contribute to the UX Department Direction, Ops Product Section Direction and SaaS Platforms Direction in the following ways:
TBA
Different user types are considered in our experience design effort. Even when a user has the same title, their responsibilities may vary by organization size, department, organization structure, and role. Some of the people we are serving are:
TBA
TBA
Apart from GitLab's 360 Feedback and annual Talent Assessment, our team uses a number of approaches to identify opportunities to develop their skills and knowledge. At least once a year, each Product Designer should have a career development conversation with their manager to set the tone and direction of their yearly growth and development plans. An Individual Growth Plan (IGP) is created to outline professional goals and steps to accomplish them. Finally, a conversation is followed up with monthly/quarterly checkpoints and frequents 1:1s where team members and manager talk about the IGP plan, accomplishments, and iterations of the goals.
Use the following issue templates to plan and prepare for career conversations with your manager:
We follow the workflows outlined in the UX section of the handbook. In addition, we do the following:
Our team meets every two weeks to discuss our work, processes, talk about user research activities, share knowledge, and raise questions to each other. We are also using session for team retrospectives, as well as sharing useful resources around design and DevOps domains. You can watch the CI/CD UX Team Meeting videos on Unfiltered.
The UX DoD lists the activities a Product Designer is responsible for in the Product Development Flow. This list can be applied to an epic/issue, and serves as a tool for describing and tracking the expected UX deliverables, objectives, and the approval process.
To keep the process efficient, depending on the scope of a problem, a Product Designer might not need to check off all of the items in the UX DoD while working through the Product Development Flow.
You can add the following checklist to an issue description to help illustrate the "completeness" of a design proposal:
### UX Definition of Done
1️⃣ **VALIDATION TRACK**
**Problem Validation Phase**
- [ ] Problem is well understood and has been validated
- [ ] JTBD is well understood and has been validated
- [ ] PM has communicated the opportunity canvas to stable counterparts and group stakeholders, including the Product Designer and Product Design Manager
**Design Phase**
- [ ] Document the JTBD and UX goal in the issue/epic description
- [ ] Explore multiple different approaches as a team
- [ ] Discuss the technical implications with Engineering
- [ ] Identify any potential cross-team dependencies and include the DRIs in the discussions
- [ ] Identify a small set of options to validate
- [ ] Document the user story(ies) for the MVC
- [ ] Consider edge cases for each user story
- [ ] Create prototypes or mockups for each user story
- [ ] [Pajamas component lifecyle](https://design.gitlab.com/get-started/lifecycle)
- [ ] Identify component design or pattern update/creation
- [ ] Discuss the technical implications with Engineering
- [ ] Pajamas issue is created (within the scope of the MVC)
- [ ] Update issues/epic descriptions
- [ ] The appropriate [labels](https://about.gitlab.com/handbook/product/ux/ux-department-workflow/#how-we-use-labels) were applied
- [ ] If changes involve copy, add the ~"Technical Writing" and ~"UI text" labels
- [ ] Proposed solution(s) identified and documented in the issue/epic description
**Solution Validation Phase**
- [ ] Validate the solution to increase confidence in the proposed solution
- [ ] Document the solution validation learnings
- [ ] Product Designer has communicated the solution validation learnings to stable counterparts and group stakeholders, including the Product Design Manager
- [ ] Update the MVC proposal with relevant insights from the solution validation
- [ ] Discuss the technical implications with Engineering
- [ ] Update issue/epic description to contain or link to the findings
2️⃣ **BUILD TRACK**
[**Plan Phase**](https://about.gitlab.com/handbook/product-development-flow/#build-phase-1-plan)
- [ ] Proposal is ready to be broken down and prioritized by PM for development
**Develop & Test Phase**
- [ ] Product Designer reviewed MRs that include user-facing changes, as per the [Code Review Guidelines](https://docs.gitlab.com/ee/development/code_review.html)
- [ ] UX Debt issues have been identified and assigned to a milestone
We use the geekbot Slack plugin to automate our async weekly retrospective called This Week I Learned. Participation is optional but encouraged. Every Friday at 9am on each team memeber's local time zone, geekbot asks "What did you learn this week?", "What's something you're looking forward to in the next week?", "Is there something puzzling you? If so, who can support you?". Answers are posted in the #ux_ci-cd Slack channel.