Commit 27bbb06d authored by Christie Lenneville's avatar Christie Lenneville Committed by Jacki Bauer

Rework info architecture of UX handbook

parent a0e34f54
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# How the UX department works
The UX Department works alongside the community, Product Managers (PMs), Frontend engineers (FE), and Backend engineers (BE). PMs are responsible for kicking-off initiatives, taking action, and setting the direction of the product. PMs don't own the product; they gather feedback and give GitLab team members and the wider community space to suggest and create.
UX should assist in driving the [product vision](/direction/product-vision/) early in the process. We inform the vision by conducting generative research, as well as facilitating discussion with community members, customers, PM, FE, and BE. We are **elevated** above just the transactional workflow and **generative** in creating work rather than just executing tasks.
## Everyone can contribute
The UX department is not solely responsible for the user experience of GitLab. Everyone is encouraged to contribute their thoughts on how we can make GitLab better by opening an issue. You can use just words or include images. These images can take a variety of forms; here are just a few examples:
* Drawings or sketches to convey your idea
* Wireframes made using a software of your choosing (Balsamiq, Sketch, etc.)
* High-fidelity mockups made using the [Pajamas Design System][pajamas]
* Screenshots of changes to our UI, made by manipulating the DOM in the browser
If you are creating high-fidelity designs, please make sure to let others know that this is a proposal and needs UX review. You can ping anyone on the UX team for assistance.
## Proactive and reactive UX
We'll always have responsibility for reactive tasks that help "keep the lights on," such as bug fixes and minor UX enhancements. But we also must carve out some portion of our time for proactive work that identifies existing pain points, redefines how we approach problems, and uncovers actionable innovation and improvement opportunities. This proactive UX work enables us to create the most complete, competitive, and resilient solutions.
It isn’t always easy to find the space for proactive UX work, but the challenge is worth it, because it's how we create a best-in-class product experience. And it's not just the UX team's responsibility; it requires a coordinated effort from Leadership, Product, and Engineering, too.
We're currently working to find the right balance between proactive and reactive UX work. While we don't have a prescriptive ratio, we also don't allot 100% of our available work time to reactive efforts. Before and at the start of each milestone, UXers should work with their managers to define the appropriate ratio, based on our active OKRs and stage group requirements. When there are questions about priority or scope, or when a UXer is concerned about meeting a deadline, they should immediately reach out to their manager to help them resolve any concerns. Comunicate early and often!
### Expectations
Every UXer:
* Make sure discipline peers are aware of proactive UX work and what we need from them to succeed.
* Let your manager know right away, if you believe you're not trending to complete your work. The sooner your manager knows, the higher the likelihood they can resolve the issue and manage expectations.
* Account for time off (both yours and others) as best you can.
* Work efficiently. Lean UX and design reuse allow us to do more with less. Ask yourself, "What's the least we can do to solve and implement this issue *well*?" Start lo-fi, and only increase fidelity as design confidence grows and implementation requires. Leverage the design system, and cross-share learnings and assets.
Managers:
* Set a baseline capacity for proactive/reactive work each milestone; for example, 30%/70% respectively. Teams can use this information to balance work and manage expectations.
* Quantify strategy work with clear time-to-complete (TTC) expectations, measurable goals, and deadlines.
* Resolve team questions, concerns, and blockers quickly.
* Make sure cross-functional partners are aware of UX OKRs and their associated dependencies.
### Examples of proactive UX
One example of proactive UX work is our [Experience Baselines and Recommendations](https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations) initiative. Another example is the generative research that our UX Researchers lead (while inviting cross-functional partners to participate). Yet another example is the ongoing effort to beautify our UI, both through [small, tactical changes](https://gitlab.com/groups/gitlab-org/-/epics/989) and through our [Pajamas Design System][pajamas].
**Experience Baselines and Recommendations** <br>
Designers use [Experience Baselines](https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations) to benchmark common user tasks. In many cases, tasks involve multiple stages of the product, giving designers visibility into how users traverse across stages. Designers follow with [Experience Recommendations](https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations) for how to improve the experience in upcoming milestones.
## Iteration
Here at GitLab, iteration means making the [smallest thing possible and getting it out as quickly as possible](/handbook/values/#iteration). Working like this allows us to reduce cycle time and get feedback from users faster, so we can continue to improve quickly and efficiently.
Iteration isn't just one of GitLab’s six founding values, [C.R.E.D.I.T](/handbook/values/#credit), it is one of the [foundational concepts in design thinking and user experience](https://www.interaction-design.org/literature/article/design-iteration-brings-powerful-results-so-do-it-again-designer). Planning too far ahead without real-world feedback can cause you to build something that doesn't meet user needs.
Iteration is especially vital in an open-source community. Keeping changes small and iterative makes it easy for anyone to contribute. Here are some examples of how we are embracing the power of iteration and using it to build GitLab:
* We aggressively break issues down into the smallest scope possible. If an effort is too big to be completed in one milestone, then it is too big. [Epics](/handbook/product/#how-to-use-epics) allow us to maintain a holistic view of an area, while breaking the work down into an MVC.
* We keep a list of improvement issues that are actively seeking contributions from the community. They are small in scope, allowing the community to contribute designs or code to the issues. You can learn more about it in the [Community Contributions](/handbook/engineering/ux/ux-department-workflow/#community-contributions) section of this handbook. You can also [view the list of issues that need UX work](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&label_name[]=UX).
* You may notice that our [Design System](https://gitlab.com/gitlab-org/design.gitlab.com) has a lot of "to-do" items. Rather than try to tackle everything at once, we are gradually populating our component library and incrementally rolling those components out to production.
## Stable counterparts
Every Product Designer is aligned with a PM and is responsible for the same features their PM oversees.
Technical Writers each support multiple stage groups and at least one complete stage (up to four) with the goal of supporting only one stage per writer by the end of FY-2020 per the current hiring plan. UX Researchers support multiple PMs from across one or more stages.
UXers work alongside PMs and engineering at each stage of the process: planning, discovery, implementation, and further iteration. The area a Product Designer or Technical Writer is responsible for is part of their title; for example, "Product Designer, Plan." You can see which area of the product each Product Designer or Technical Writer is aligned with in the [team org chart](/company/team/org-chart/).
Product Designers and Technical Writers may also serve as a "backup" for other areas of the product. This area will be listed on the [team page](/company/team/) under their title as an expertise; for example, "Plan expert." UX backups should be just that&mdash;backups. They are there to conduct UX reviews on MRs when the assigned UXer for that area is out. The UX lead for a given area should coordinate with the PM and their backup during scheduling for any work that is critical. Critical UX work is defined as any work that addresses an outage, a broken feature with no workaround, or the current workaround is unacceptable.
### Headcount planning
In the spirit of having "stable counterparts," we plan headcount as follows:
* **One Product Designer for every stage group**
* 1:1 ratio of Product Designers to Product Managers
* Approximately a 1:7 ratio of Product Designers to Engineers
* **One Technical Writer for up to four stage groups**
* 1:3 ratio of Technical Writers to stage groups
* Approximately a 1:21 ratio of Technical Writers to Engineers
* **One UX Researcher for every stage**
* Approximately a 1:5 ratio of UX Researchers to Product Managers
* Approximately a 1:35 ratio of UX Researchers to Engineers
## Collaboration model
Coming soon!
\ No newline at end of file
......@@ -10,13 +10,66 @@ title: "UX Department"
- TOC
{:toc}
# UX Department
## Introduction
We make a software product that is easy to use, enables everyone to contribute, and is built for a diverse, global community. To achieve this vision, the UX department actively works with the wider GitLab community to understand user behaviors, needs, and motivations. And as a skilled team of UX practitioners, we go far beyond the basics of UI design (that's only a part of what we do), proactively helping to shape the product experience through generative user research, strategic UX initiatives, and useful technical documentation.
To meet our goals, the UX Department works cross functionally with internal teams and community contributors. We believe in iterative, valuable, and proactive improvements. When we get things wrong, we quickly strive to make them right. We're passionate about the GitLab product, and we strive to become subject-matter experts both in our specific stage groups and across the whole product.
## UX Vision
## More reading about UX
* [How we work](/handbook/engineering/ux/how-we-work): Learn how we work within our department and with cross-functional partners
* [Pajamas design system](pajamas)
* [UX resources](/handbook/engineering/ux/ux-resources): Helpful information and links
## UX vision
We're striving to make GitLab the most usable DevOps tool on the market, so that teams of all kinds can build better products, faster.
We don't support just a single user type&mdash;whether that's across roles, industries, or company size. Instead, we actively solicit feedback from the wider GitLab community to understand:
- How cross-functional product teams work together in a variety of industries and environments
- When and how the needs of different roles converge and diverge
- How users spend their time at work and what success means in their job
- What's working well for them today and what they wish was easier (both in our tool and in other DevOps tools they may use)
To achieve a shared vision, we partner with Product Management on product discovery, proactively identify opportunities for UX improvements, measure our success through KPIs, and continuously optimize how we work—both within our department and with cross-functional partners.
### Holistic UX
Though we structure our work around individual stages of the product (Plan, Manage, Create, etc.), we can't separate look, feel and process from what a user is trying to accomplish. We must maintain a focus on what the user needs to get done and how to deliver that in the most effective manner possible, including how users flow from one stage of the product to another. Maintaining a holistic overview of the path a user may take allows us to see the possible twists and turns along the way. With this knowledge, we can optimize the user experience.
It is the responsibility of each [Product Designer](https://about.gitlab.com/job-families/engineering/product-designer/) and [UX Researcher](https://about.gitlab.com/job-families/engineering/ux-researcher/) to understand how users may flow in and out of their assigned stage group(s). This means that everyone must understand the broader product, how stage groups relate, and the work that is planned and in process outside of their own focus area(s).
### Easy UX
GitLab solves complex problems, but that doesn't mean our product experience needs to be complicated. We always strive to design solutions that are easy to use, but without oversimplifying the product.
We acknowledge we're building a product that must support skilled power users, while still making it [easy for less experienced users](https://imposter-syndrome.lol/posts/a-few-thoughts-on-ember/#the-issues-with-learning-ember) and [non-developers](https://about.gitlab.com/handbook/product/#enabling-collaboration) to learn. Within each stage group, the learning curve must be at least comparable to our best-in-class competitors, with clear, cohesive workflows, a highly usable interface, and comprehensive documentation.
## Stage group UX vision
While we strive to create a seamless experience across product workflows, our model is organized into stage groups that work as cross-functional teams. For each stage group, the UX department is creating a UX strategy based on industry best practices and customer research.
You can see the in-process strategy work here:
* Development
* Manage: Coming soon! {::comment}[Manage](/handbook/engineering/ux/stage-group-ux-strategy/manage){:/comment}
* Plan: Coming soon! {::comment}[Plan](/handbook/engineering/ux/stage-group-ux-strategy/plan){:/comment}
* Create: Coming soon! {::comment}[Create](/handbook/engineering/ux/stage-group-ux-strategy/create){:/comment}
* CI/CD
* Verify: Coming soon! {::comment}[Verify](/handbook/engineering/ux/stage-group-ux-strategy/verify){:/comment}
* Package: Coming soon! {::comment}[Package](/handbook/engineering/ux/stage-group-ux-strategy/package){:/comment}
* Release: Coming soon! {::comment}[Release](/handbook/engineering/ux/stage-group-ux-strategy/release){:/comment}
* Ops
* Configure: Coming soon! {::comment}[Configure](/handbook/engineering/ux/stage-group-ux-strategy/configure){:/comment}
* Monitor: Coming soon! {::comment}[Monitor](/handbook/engineering/ux/stage-group-ux-strategy/monitor){:/comment}
* Secure
* Secure: Coming soon! {::comment}[Secure](/handbook/engineering/ux/stage-group-ux-strategy/secure){:/comment}
* Growth
* Fulfillment: Coming soon! {::comment}[Fulfillment](/handbook/engineering/ux/stage-group-ux-strategy/fulfillment){:/comment}
## UX principles
Our principles are that GitLab should be **[productive](#productive), [minimal](#minimal), and [human](#human)**. We want to [*design*](https://library.gv.com/everyone-is-a-designer-get-over-it-501cc9a2f434) the most complete, uncomplicated, and adaptable DevOps tool on the market, enabling our users to spend more time adding business value in their own jobs.
......@@ -67,97 +120,7 @@ Our principles are that GitLab should be **[productive](#productive), [minimal](
* Assist the community in making an impact on our product.
* Steer the user in the right direction if they end up in a “bad” place (without blaming them), and recognize their efforts and accomplishments!
## How we work
The UX Department works alongside the community, Product Managers (PMs), Frontend engineers (FE), and Backend engineers (BE). PMs are responsible for kicking-off initiatives, taking action, and setting the direction of the product. PMs don't own the product; they gather feedback and give GitLab team members and the wider community space to suggest and create.
UX should assist in driving the [product vision](/direction/product-vision/) early in the process. We inform the vision by conducting generative research, as well as facilitating discussion with community members, customers, PM, FE, and BE. We are **elevated** above just the transactional workflow and **generative** in creating work rather than just executing tasks.
### Proactive and reactive UX
We'll always have responsibility for reactive tasks that help "keep the lights on," such as bug fixes and minor UX enhancements. But we also must carve out some portion of our time for proactive work that identifies existing pain points, redefines how we approach problems, and uncovers actionable innovation and improvement opportunities. This proactive UX work enables us to create the most complete, competitive, and resilient solutions.
It isn’t always easy to find the space for proactive UX work, but the challenge is worth it, because it's how we create a best-in-class product experience. And it's not just the UX team's responsibility; it requires a coordinated effort from Leadership, Product, and Engineering, too.
We're currently working to find the right balance between proactive and reactive UX work. While we don't have a prescriptive ratio, we also don't allot 100% of our available work time to reactive efforts. Before and at the start of each milestone, UXers should work with their managers to define the appropriate ratio, based on our active OKRs and stage group requirements. When there are questions about priority or scope, or when a UXer is concerned about meeting a deadline, they should immediately reach out to their manager to help them resolve any concerns. Comunicate early and often!
#### Expectations
Every UXer:
* Make sure discipline peers are aware of proactive UX work and what we need from them to succeed.
* Let your manager know right away, if you believe you're not trending to complete your work. The sooner your manager knows, the higher the likelihood they can resolve the issue and manage expectations.
* Account for time off (both yours and others) as best you can.
* Work efficiently. Lean UX and design reuse allow us to do more with less. Ask yourself, "What's the least we can do to solve and implement this issue *well*?" Start lo-fi, and only increase fidelity as design confidence grows and implementation requires. Leverage the design system, and cross-share learnings and assets.
Managers:
* Set a baseline capacity for proactive/reactive work each milestone; for example, 30%/70% respectively. Teams can use this information to balance work and manage expectations.
* Quantify strategy work with clear time-to-complete (TTC) expectations, measurable goals, and deadlines.
* Resolve team questions, concerns, and blockers quickly.
* Make sure cross-functional partners are aware of UX OKRs and their associated dependencies.
#### Examples of proactive UX
One example of proactive UX work is our [Experience Baselines and Recommendations](https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations) initiative. Another example is the generative research that our UX Researchers lead (while inviting cross-functional partners to participate). Yet another example is the ongoing effort to beautify our UI, both through [small, tactical changes](https://gitlab.com/groups/gitlab-org/-/epics/989) and through our [Pajamas Design System][pajamas].
**Experience Baselines and Recommendations** <br>
Designers use [Experience Baselines](https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations) to benchmark common user tasks. In many cases, tasks involve multiple stages of the product, giving designers visibility into how users traverse across stages. Designers follow with [Experience Recommendations](https://about.gitlab.com/handbook/engineering/ux/experience-baseline-recommendations) for how to improve the experience in upcoming milestones.
### Holistic UX
Though we structure our work around individual stages of the product (Plan, Manage, Create, etc.), we can't separate look, feel and process from what a user is trying to accomplish. We must maintain a focus on what the user needs to get done and how to deliver that in the most effective manner possible, including how users flow from one stage of the product to another. Maintaining a holistic overview of the path a user may take allows us to see the possible twists and turns along the way. With this knowledge, we can optimize the user experience.
It is the responsibility of each [Product Designer](https://about.gitlab.com/job-families/engineering/product-designer/) and [UX Researcher](https://about.gitlab.com/job-families/engineering/ux-researcher/) to understand how users may flow in and out of their assigned stage group(s). This means that everyone must understand the broader product, how stage groups relate, and the work that is planned and in process outside of their own focus area(s).
### Easy UX
GitLab solves complex problems, but that doesn't mean our product experience needs to be complicated. We always strive to design solutions that are easy to use, but without oversimplifying the product.
We acknowledge we're building a product that must support skilled power users, while still making it [easy for less experienced users](https://imposter-syndrome.lol/posts/a-few-thoughts-on-ember/#the-issues-with-learning-ember) and [non-developers](https://about.gitlab.com/handbook/product/#enabling-collaboration) to learn. Within each stage group, the learning curve must be at least comparable to our best-in-class competitors, with clear, cohesive workflows, a highly usable interface, and comprehensive documentation.
### Stable counterparts
Every Product Designer is aligned with a PM and is responsible for the same features their PM oversees.
Technical Writers each support multiple stage groups and at least one complete stage (up to four) with the goal of supporting only one stage per writer by the end of FY-2020 per the current hiring plan. UX Researchers support multiple PMs from across one or more stages.
UXers work alongside PMs and engineering at each stage of the process: planning, discovery, implementation, and further iteration. The area a Product Designer or Technical Writer is responsible for is part of their title; for example, "Product Designer, Plan." You can see which area of the product each Product Designer or Technical Writer is aligned with in the [team org chart](/company/team/org-chart/).
Product Designers and Technical Writers may also serve as a "backup" for other areas of the product. This area will be listed on the [team page](/company/team/) under their title as an expertise; for example, "Plan expert." UX backups should be just that&mdash;backups. They are there to conduct UX reviews on MRs when the assigned UXer for that area is out. The UX lead for a given area should coordinate with the PM and their backup during scheduling for any work that is critical. Critical UX work is defined as any work that addresses an outage, a broken feature with no workaround, or the current workaround is unacceptable.
#### Headcount planning
In the spirit of having "stable counterparts," we plan headcount as follows:
* **One Product Designer for every stage group**
* 1:1 ratio of Product Designers to Product Managers
* Approximately a 1:7 ratio of Product Designers to Engineers
* **One Technical Writer for up to four stage groups**
* 1:3 ratio of Technical Writers to stage groups
* Approximately a 1:21 ratio of Technical Writers to Engineers
* **One UX Researcher for every stage**
* Approximately a 1:5 ratio of UX Researchers to Product Managers
* Approximately a 1:35 ratio of UX Researchers to Engineers
#### Everyone can contribute
The UX department is not solely responsible for the user experience of GitLab. Everyone is encouraged to contribute their thoughts on how we can make GitLab better by opening an issue. You can use just words or include images. These images can take a variety of forms; here are just a few examples:
* Drawings or sketches to convey your idea
* Wireframes made using a software of your choosing (Balsamiq, Sketch, etc.)
* High-fidelity mockups made using the [Pajamas Design System][pajamas]
* Screenshots of changes to our UI, made by manipulating the DOM in the browser
If you are creating high-fidelity designs, please make sure to let others know that this is a proposal and needs UX review. You can ping anyone on the UX team for assistance.
### Iteration
Here at GitLab, iteration means making the [smallest thing possible and getting it out as quickly as possible](/handbook/values/#iteration). Working like this allows us to reduce cycle time and get feedback from users faster, so we can continue to improve quickly and efficiently.
Iteration isn't just one of GitLab’s six founding values, [C.R.E.D.I.T](/handbook/values/#credit), it is one of the [foundational concepts in design thinking and user experience](https://www.interaction-design.org/literature/article/design-iteration-brings-powerful-results-so-do-it-again-designer). Planning too far ahead without real-world feedback can cause you to build something that doesn't meet user needs.
Iteration is especially vital in an open-source community. Keeping changes small and iterative makes it easy for anyone to contribute. Here are some examples of how we are embracing the power of iteration and using it to build GitLab:
* We aggressively break issues down into the smallest scope possible. If an effort is too big to be completed in one milestone, then it is too big. [Epics](/handbook/product/#how-to-use-epics) allow us to maintain a holistic view of an area, while breaking the work down into an MVC.
* We keep a list of improvement issues that are actively seeking contributions from the community. They are small in scope, allowing the community to contribute designs or code to the issues. You can learn more about it in the [Community Contributions](/handbook/engineering/ux/ux-department-workflow/#community-contributions) section of this handbook. You can also [view the list of issues that need UX work](https://gitlab.com/groups/gitlab-org/-/issues?state=opened&label_name[]=Accepting+merge+requests&label_name[]=UX).
* You may notice that our [Design System](https://gitlab.com/gitlab-org/design.gitlab.com) has a lot of "to-do" items. Rather than try to tackle everything at once, we are gradually populating our component library and incrementally rolling those components out to production.
### Design culture
## Design culture
The culture of the design department is characterized by the following:
* We're independent, autonomous, and not hierarchical.
* We have a high level of commitment and reliability to our team.
......@@ -170,9 +133,9 @@ The culture of the design department is characterized by the following:
## UX on social media
It is encouraged to share UX designs and insight on social media platforms such as Twitter.
We encourage UXers to share UX designs and research insights on social media platforms such as Twitter and Dribbble.
### Twitter
#### Twitter
You can contribute design-related posts to our [@GitLab Twitter account](https://twitter.com/gitlab) by adding your tweet to our [UX Design Twitter spreadsheet][twitter-sheet].
......@@ -181,9 +144,14 @@ You can contribute design-related posts to our [@GitLab Twitter account](https:/
1. The UX Lead will check the spreadsheet at the beginning of each week and schedule any tweets on Tweetdeck.
1. Once a tweet is scheduled, the tweet will be moved to the "Scheduled" tab of the spreadsheet.
## UX Resources
#### Dribbble
GitLab has a Dribbble team account where you can add work in progress, coming soon, and recently released works.
Find information and helpful links in our [UX resources](/handbook/engineering/ux/ux-resources).
* If a Dribbble post has a corresponding open issue, link to the issue so designers can contribute on GitLab.
* Add the Dribbble post to our [UX Design Twitter spreadsheet](https://docs.google.com/spreadsheets/d/1GDAUNujD1-eRYxAj4FIYbCyy8ltCwwIWqVTd9-gf4wA/edit), along with a link to the corresponding open issue if applicable.
* If you’re not a member of the GitLab Dribbble team and would like to be, contact the UX Lead to grant you membership.
* [View the GitLab Dribbble team page](https://dribbble.com/GitLab)
## About our team
......
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
---
layout: markdown_page
title: "UX Department"
---
### On this page
{:.no_toc}
- TOC
{:toc}
# Content coming soon!
\ No newline at end of file
......@@ -53,15 +53,6 @@ Coming soon.
Coming soon.
### Dribbble
GitLab has a Dribbble team account where you can add work in progress, coming soon, and recently released works.
* If a Dribbble post has a corresponding open issue, link to the issue so designers can contribute on GitLab.
* Add the Dribbble post to our [UX Design Twitter spreadsheet](https://docs.google.com/spreadsheets/d/1GDAUNujD1-eRYxAj4FIYbCyy8ltCwwIWqVTd9-gf4wA/edit), along with a link to the corresponding open issue if applicable.
* If you’re not a member of the GitLab Dribbble team and would like to be, contact the UX Lead to grant you membership.
* [View the GitLab Dribbble team page](https://dribbble.com/GitLab)
## Research
### UX research project
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment