[{"data":1,"prerenderedAt":1800},["ShallowReactive",2],{"/en-us/blog/tags/design/":3,"navigation-en-us":19,"banner-en-us":437,"footer-en-us":452,"design-tag-page-en-us":663},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":10,"_id":12,"_type":13,"title":14,"_source":15,"_file":16,"_stem":17,"_extension":18},"/en-us/blog/tags/design","tags",false,"",{"tag":9,"tagSlug":9},"design",{"template":11},"BlogTag","content:en-us:blog:tags:design.yml","yaml","Design","content","en-us/blog/tags/design.yml","en-us/blog/tags/design","yml",{"_path":20,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":22,"_id":433,"_type":13,"title":434,"_source":15,"_file":435,"_stem":436,"_extension":18},"/shared/en-us/main-navigation","en-us",{"logo":23,"freeTrial":28,"sales":33,"login":38,"items":43,"search":374,"minimal":405,"duo":424},{"config":24},{"href":25,"dataGaName":26,"dataGaLocation":27},"/","gitlab logo","header",{"text":29,"config":30},"Get free trial",{"href":31,"dataGaName":32,"dataGaLocation":27},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":34,"config":35},"Talk to sales",{"href":36,"dataGaName":37,"dataGaLocation":27},"/sales/","sales",{"text":39,"config":40},"Sign in",{"href":41,"dataGaName":42,"dataGaLocation":27},"https://gitlab.com/users/sign_in/","sign in",[44,88,184,189,295,355],{"text":45,"config":46,"cards":48,"footer":71},"Platform",{"dataNavLevelOne":47},"platform",[49,55,63],{"title":45,"description":50,"link":51},"The most comprehensive AI-powered DevSecOps Platform",{"text":52,"config":53},"Explore our Platform",{"href":54,"dataGaName":47,"dataGaLocation":27},"/platform/",{"title":56,"description":57,"link":58},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":59,"config":60},"Meet GitLab Duo",{"href":61,"dataGaName":62,"dataGaLocation":27},"/gitlab-duo/","gitlab duo ai",{"title":64,"description":65,"link":66},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":67,"config":68},"Learn more",{"href":69,"dataGaName":70,"dataGaLocation":27},"/why-gitlab/","why gitlab",{"title":72,"items":73},"Get started with",[74,79,84],{"text":75,"config":76},"Platform Engineering",{"href":77,"dataGaName":78,"dataGaLocation":27},"/solutions/platform-engineering/","platform engineering",{"text":80,"config":81},"Developer Experience",{"href":82,"dataGaName":83,"dataGaLocation":27},"/developer-experience/","Developer experience",{"text":85,"config":86},"MLOps",{"href":87,"dataGaName":85,"dataGaLocation":27},"/topics/devops/the-role-of-ai-in-devops/",{"text":89,"left":90,"config":91,"link":93,"lists":97,"footer":166},"Product",true,{"dataNavLevelOne":92},"solutions",{"text":94,"config":95},"View all Solutions",{"href":96,"dataGaName":92,"dataGaLocation":27},"/solutions/",[98,123,145],{"title":99,"description":100,"link":101,"items":106},"Automation","CI/CD and automation to accelerate deployment",{"config":102},{"icon":103,"href":104,"dataGaName":105,"dataGaLocation":27},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[107,111,115,119],{"text":108,"config":109},"CI/CD",{"href":110,"dataGaLocation":27,"dataGaName":108},"/solutions/continuous-integration/",{"text":112,"config":113},"AI-Assisted Development",{"href":61,"dataGaLocation":27,"dataGaName":114},"AI assisted development",{"text":116,"config":117},"Source Code Management",{"href":118,"dataGaLocation":27,"dataGaName":116},"/solutions/source-code-management/",{"text":120,"config":121},"Automated Software Delivery",{"href":104,"dataGaLocation":27,"dataGaName":122},"Automated software delivery",{"title":124,"description":125,"link":126,"items":131},"Security","Deliver code faster without compromising security",{"config":127},{"href":128,"dataGaName":129,"dataGaLocation":27,"icon":130},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[132,135,140],{"text":133,"config":134},"Security & Compliance",{"href":128,"dataGaLocation":27,"dataGaName":133},{"text":136,"config":137},"Software Supply Chain Security",{"href":138,"dataGaLocation":27,"dataGaName":139},"/solutions/supply-chain/","Software supply chain security",{"text":141,"config":142},"Compliance & Governance",{"href":143,"dataGaLocation":27,"dataGaName":144},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":146,"link":147,"items":152},"Measurement",{"config":148},{"icon":149,"href":150,"dataGaName":151,"dataGaLocation":27},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[153,157,161],{"text":154,"config":155},"Visibility & Measurement",{"href":150,"dataGaLocation":27,"dataGaName":156},"Visibility and Measurement",{"text":158,"config":159},"Value Stream Management",{"href":160,"dataGaLocation":27,"dataGaName":158},"/solutions/value-stream-management/",{"text":162,"config":163},"Analytics & Insights",{"href":164,"dataGaLocation":27,"dataGaName":165},"/solutions/analytics-and-insights/","Analytics and insights",{"title":167,"items":168},"GitLab for",[169,174,179],{"text":170,"config":171},"Enterprise",{"href":172,"dataGaLocation":27,"dataGaName":173},"/enterprise/","enterprise",{"text":175,"config":176},"Small Business",{"href":177,"dataGaLocation":27,"dataGaName":178},"/small-business/","small business",{"text":180,"config":181},"Public Sector",{"href":182,"dataGaLocation":27,"dataGaName":183},"/solutions/public-sector/","public sector",{"text":185,"config":186},"Pricing",{"href":187,"dataGaName":188,"dataGaLocation":27,"dataNavLevelOne":188},"/pricing/","pricing",{"text":190,"config":191,"link":193,"lists":197,"feature":282},"Resources",{"dataNavLevelOne":192},"resources",{"text":194,"config":195},"View all resources",{"href":196,"dataGaName":192,"dataGaLocation":27},"/resources/",[198,231,254],{"title":199,"items":200},"Getting started",[201,206,211,216,221,226],{"text":202,"config":203},"Install",{"href":204,"dataGaName":205,"dataGaLocation":27},"/install/","install",{"text":207,"config":208},"Quick start guides",{"href":209,"dataGaName":210,"dataGaLocation":27},"/get-started/","quick setup checklists",{"text":212,"config":213},"Learn",{"href":214,"dataGaLocation":27,"dataGaName":215},"https://university.gitlab.com/","learn",{"text":217,"config":218},"Product documentation",{"href":219,"dataGaName":220,"dataGaLocation":27},"https://docs.gitlab.com/","product documentation",{"text":222,"config":223},"Best practice videos",{"href":224,"dataGaName":225,"dataGaLocation":27},"/getting-started-videos/","best practice videos",{"text":227,"config":228},"Integrations",{"href":229,"dataGaName":230,"dataGaLocation":27},"/integrations/","integrations",{"title":232,"items":233},"Discover",[234,239,244,249],{"text":235,"config":236},"Customer success stories",{"href":237,"dataGaName":238,"dataGaLocation":27},"/customers/","customer success stories",{"text":240,"config":241},"Blog",{"href":242,"dataGaName":243,"dataGaLocation":27},"/blog/","blog",{"text":245,"config":246},"Remote",{"href":247,"dataGaName":248,"dataGaLocation":27},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":250,"config":251},"TeamOps",{"href":252,"dataGaName":253,"dataGaLocation":27},"/teamops/","teamops",{"title":255,"items":256},"Connect",[257,262,267,272,277],{"text":258,"config":259},"GitLab Services",{"href":260,"dataGaName":261,"dataGaLocation":27},"/services/","services",{"text":263,"config":264},"Community",{"href":265,"dataGaName":266,"dataGaLocation":27},"/community/","community",{"text":268,"config":269},"Forum",{"href":270,"dataGaName":271,"dataGaLocation":27},"https://forum.gitlab.com/","forum",{"text":273,"config":274},"Events",{"href":275,"dataGaName":276,"dataGaLocation":27},"/events/","events",{"text":278,"config":279},"Partners",{"href":280,"dataGaName":281,"dataGaLocation":27},"/partners/","partners",{"backgroundColor":283,"textColor":284,"text":285,"image":286,"link":290},"#2f2a6b","#fff","Insights for the future of software development",{"altText":287,"config":288},"the source promo card",{"src":289},"/images/navigation/the-source-promo-card.svg",{"text":291,"config":292},"Read the latest",{"href":293,"dataGaName":294,"dataGaLocation":27},"/the-source/","the source",{"text":296,"config":297,"lists":299},"Company",{"dataNavLevelOne":298},"company",[300],{"items":301},[302,307,313,315,320,325,330,335,340,345,350],{"text":303,"config":304},"About",{"href":305,"dataGaName":306,"dataGaLocation":27},"/company/","about",{"text":308,"config":309,"footerGa":312},"Jobs",{"href":310,"dataGaName":311,"dataGaLocation":27},"/jobs/","jobs",{"dataGaName":311},{"text":273,"config":314},{"href":275,"dataGaName":276,"dataGaLocation":27},{"text":316,"config":317},"Leadership",{"href":318,"dataGaName":319,"dataGaLocation":27},"/company/team/e-group/","leadership",{"text":321,"config":322},"Team",{"href":323,"dataGaName":324,"dataGaLocation":27},"/company/team/","team",{"text":326,"config":327},"Handbook",{"href":328,"dataGaName":329,"dataGaLocation":27},"https://handbook.gitlab.com/","handbook",{"text":331,"config":332},"Investor relations",{"href":333,"dataGaName":334,"dataGaLocation":27},"https://ir.gitlab.com/","investor relations",{"text":336,"config":337},"Trust Center",{"href":338,"dataGaName":339,"dataGaLocation":27},"/security/","trust center",{"text":341,"config":342},"AI Transparency Center",{"href":343,"dataGaName":344,"dataGaLocation":27},"/ai-transparency-center/","ai transparency center",{"text":346,"config":347},"Newsletter",{"href":348,"dataGaName":349,"dataGaLocation":27},"/company/contact/","newsletter",{"text":351,"config":352},"Press",{"href":353,"dataGaName":354,"dataGaLocation":27},"/press/","press",{"text":356,"config":357,"lists":358},"Contact us",{"dataNavLevelOne":298},[359],{"items":360},[361,364,369],{"text":34,"config":362},{"href":36,"dataGaName":363,"dataGaLocation":27},"talk to sales",{"text":365,"config":366},"Get help",{"href":367,"dataGaName":368,"dataGaLocation":27},"/support/","get help",{"text":370,"config":371},"Customer portal",{"href":372,"dataGaName":373,"dataGaLocation":27},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":375,"login":376,"suggestions":383},"Close",{"text":377,"link":378},"To search repositories and projects, login to",{"text":379,"config":380},"gitlab.com",{"href":41,"dataGaName":381,"dataGaLocation":382},"search login","search",{"text":384,"default":385},"Suggestions",[386,388,392,394,398,402],{"text":56,"config":387},{"href":61,"dataGaName":56,"dataGaLocation":382},{"text":389,"config":390},"Code Suggestions (AI)",{"href":391,"dataGaName":389,"dataGaLocation":382},"/solutions/code-suggestions/",{"text":108,"config":393},{"href":110,"dataGaName":108,"dataGaLocation":382},{"text":395,"config":396},"GitLab on AWS",{"href":397,"dataGaName":395,"dataGaLocation":382},"/partners/technology-partners/aws/",{"text":399,"config":400},"GitLab on Google Cloud",{"href":401,"dataGaName":399,"dataGaLocation":382},"/partners/technology-partners/google-cloud-platform/",{"text":403,"config":404},"Why GitLab?",{"href":69,"dataGaName":403,"dataGaLocation":382},{"freeTrial":406,"mobileIcon":411,"desktopIcon":416,"secondaryButton":419},{"text":407,"config":408},"Start free trial",{"href":409,"dataGaName":32,"dataGaLocation":410},"https://gitlab.com/-/trials/new/","nav",{"altText":412,"config":413},"Gitlab Icon",{"src":414,"dataGaName":415,"dataGaLocation":410},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":412,"config":417},{"src":418,"dataGaName":415,"dataGaLocation":410},"/images/brand/gitlab-logo-type.svg",{"text":420,"config":421},"Get Started",{"href":422,"dataGaName":423,"dataGaLocation":410},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":425,"mobileIcon":429,"desktopIcon":431},{"text":426,"config":427},"Learn more about GitLab Duo",{"href":61,"dataGaName":428,"dataGaLocation":410},"gitlab duo",{"altText":412,"config":430},{"src":414,"dataGaName":415,"dataGaLocation":410},{"altText":412,"config":432},{"src":418,"dataGaName":415,"dataGaLocation":410},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":438,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"title":439,"button":440,"image":444,"config":447,"_id":449,"_type":13,"_source":15,"_file":450,"_stem":451,"_extension":18},"/shared/en-us/banner","is now in public beta!",{"text":67,"config":441},{"href":442,"dataGaName":443,"dataGaLocation":27},"/gitlab-duo/agent-platform/","duo banner",{"config":445},{"src":446},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":448},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":453,"_dir":21,"_draft":6,"_partial":6,"_locale":7,"data":454,"_id":659,"_type":13,"title":660,"_source":15,"_file":661,"_stem":662,"_extension":18},"/shared/en-us/main-footer",{"text":455,"source":456,"edit":462,"contribute":467,"config":472,"items":477,"minimal":651},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":457,"config":458},"View page source",{"href":459,"dataGaName":460,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":463,"config":464},"Edit this page",{"href":465,"dataGaName":466,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":468,"config":469},"Please contribute",{"href":470,"dataGaName":471,"dataGaLocation":461},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":473,"facebook":474,"youtube":475,"linkedin":476},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[478,501,558,587,621],{"title":45,"links":479,"subMenu":484},[480],{"text":481,"config":482},"DevSecOps platform",{"href":54,"dataGaName":483,"dataGaLocation":461},"devsecops platform",[485],{"title":185,"links":486},[487,491,496],{"text":488,"config":489},"View plans",{"href":187,"dataGaName":490,"dataGaLocation":461},"view plans",{"text":492,"config":493},"Why Premium?",{"href":494,"dataGaName":495,"dataGaLocation":461},"/pricing/premium/","why premium",{"text":497,"config":498},"Why Ultimate?",{"href":499,"dataGaName":500,"dataGaLocation":461},"/pricing/ultimate/","why ultimate",{"title":502,"links":503},"Solutions",[504,509,512,514,519,524,528,531,535,540,542,545,548,553],{"text":505,"config":506},"Digital transformation",{"href":507,"dataGaName":508,"dataGaLocation":461},"/topics/digital-transformation/","digital transformation",{"text":133,"config":510},{"href":128,"dataGaName":511,"dataGaLocation":461},"security & compliance",{"text":122,"config":513},{"href":104,"dataGaName":105,"dataGaLocation":461},{"text":515,"config":516},"Agile development",{"href":517,"dataGaName":518,"dataGaLocation":461},"/solutions/agile-delivery/","agile delivery",{"text":520,"config":521},"Cloud transformation",{"href":522,"dataGaName":523,"dataGaLocation":461},"/topics/cloud-native/","cloud transformation",{"text":525,"config":526},"SCM",{"href":118,"dataGaName":527,"dataGaLocation":461},"source code management",{"text":108,"config":529},{"href":110,"dataGaName":530,"dataGaLocation":461},"continuous integration & delivery",{"text":532,"config":533},"Value stream management",{"href":160,"dataGaName":534,"dataGaLocation":461},"value stream management",{"text":536,"config":537},"GitOps",{"href":538,"dataGaName":539,"dataGaLocation":461},"/solutions/gitops/","gitops",{"text":170,"config":541},{"href":172,"dataGaName":173,"dataGaLocation":461},{"text":543,"config":544},"Small business",{"href":177,"dataGaName":178,"dataGaLocation":461},{"text":546,"config":547},"Public sector",{"href":182,"dataGaName":183,"dataGaLocation":461},{"text":549,"config":550},"Education",{"href":551,"dataGaName":552,"dataGaLocation":461},"/solutions/education/","education",{"text":554,"config":555},"Financial services",{"href":556,"dataGaName":557,"dataGaLocation":461},"/solutions/finance/","financial services",{"title":190,"links":559},[560,562,564,566,569,571,573,575,577,579,581,583,585],{"text":202,"config":561},{"href":204,"dataGaName":205,"dataGaLocation":461},{"text":207,"config":563},{"href":209,"dataGaName":210,"dataGaLocation":461},{"text":212,"config":565},{"href":214,"dataGaName":215,"dataGaLocation":461},{"text":217,"config":567},{"href":219,"dataGaName":568,"dataGaLocation":461},"docs",{"text":240,"config":570},{"href":242,"dataGaName":243,"dataGaLocation":461},{"text":235,"config":572},{"href":237,"dataGaName":238,"dataGaLocation":461},{"text":245,"config":574},{"href":247,"dataGaName":248,"dataGaLocation":461},{"text":258,"config":576},{"href":260,"dataGaName":261,"dataGaLocation":461},{"text":250,"config":578},{"href":252,"dataGaName":253,"dataGaLocation":461},{"text":263,"config":580},{"href":265,"dataGaName":266,"dataGaLocation":461},{"text":268,"config":582},{"href":270,"dataGaName":271,"dataGaLocation":461},{"text":273,"config":584},{"href":275,"dataGaName":276,"dataGaLocation":461},{"text":278,"config":586},{"href":280,"dataGaName":281,"dataGaLocation":461},{"title":296,"links":588},[589,591,593,595,597,599,601,605,610,612,614,616],{"text":303,"config":590},{"href":305,"dataGaName":298,"dataGaLocation":461},{"text":308,"config":592},{"href":310,"dataGaName":311,"dataGaLocation":461},{"text":316,"config":594},{"href":318,"dataGaName":319,"dataGaLocation":461},{"text":321,"config":596},{"href":323,"dataGaName":324,"dataGaLocation":461},{"text":326,"config":598},{"href":328,"dataGaName":329,"dataGaLocation":461},{"text":331,"config":600},{"href":333,"dataGaName":334,"dataGaLocation":461},{"text":602,"config":603},"Sustainability",{"href":604,"dataGaName":602,"dataGaLocation":461},"/sustainability/",{"text":606,"config":607},"Diversity, inclusion and belonging (DIB)",{"href":608,"dataGaName":609,"dataGaLocation":461},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":336,"config":611},{"href":338,"dataGaName":339,"dataGaLocation":461},{"text":346,"config":613},{"href":348,"dataGaName":349,"dataGaLocation":461},{"text":351,"config":615},{"href":353,"dataGaName":354,"dataGaLocation":461},{"text":617,"config":618},"Modern Slavery Transparency Statement",{"href":619,"dataGaName":620,"dataGaLocation":461},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":622,"links":623},"Contact Us",[624,627,629,631,636,641,646],{"text":625,"config":626},"Contact an expert",{"href":36,"dataGaName":37,"dataGaLocation":461},{"text":365,"config":628},{"href":367,"dataGaName":368,"dataGaLocation":461},{"text":370,"config":630},{"href":372,"dataGaName":373,"dataGaLocation":461},{"text":632,"config":633},"Status",{"href":634,"dataGaName":635,"dataGaLocation":461},"https://status.gitlab.com/","status",{"text":637,"config":638},"Terms of use",{"href":639,"dataGaName":640,"dataGaLocation":461},"/terms/","terms of use",{"text":642,"config":643},"Privacy statement",{"href":644,"dataGaName":645,"dataGaLocation":461},"/privacy/","privacy statement",{"text":647,"config":648},"Cookie preferences",{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":90},"cookie preferences","ot-sdk-btn",{"items":652},[653,655,657],{"text":637,"config":654},{"href":639,"dataGaName":640,"dataGaLocation":461},{"text":642,"config":656},{"href":644,"dataGaName":645,"dataGaLocation":461},{"text":647,"config":658},{"dataGaName":649,"dataGaLocation":461,"id":650,"isOneTrustButton":90},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":664,"featuredPost":1778,"totalPagesCount":1798,"initialPosts":1799},[665,691,710,732,752,774,795,818,839,862,883,902,921,941,961,982,1003,1023,1044,1063,1085,1104,1124,1143,1164,1183,1203,1224,1244,1264,1283,1303,1322,1341,1362,1384,1404,1425,1450,1470,1489,1507,1524,1545,1563,1583,1602,1621,1640,1659,1680,1700,1719,1739,1758],{"_path":666,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":667,"content":675,"config":684,"_id":687,"_type":13,"title":688,"_source":15,"_file":689,"_stem":690,"_extension":18},"/en-us/blog/avoiding-burnout-as-product-designers",{"title":668,"description":669,"ogTitle":668,"ogDescription":669,"noIndex":6,"ogImage":670,"ogUrl":671,"ogSiteName":672,"ogType":673,"canonicalUrls":671,"schema":674},"Tips to avoid burnout for product designers","Effective prioritization and boundary setting are critical to product designers' growth.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670082/Blog/Hero%20Images/productdesign.jpg","https://about.gitlab.com/blog/avoiding-burnout-as-product-designers","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Tips to avoid burnout for product designers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2023-03-28\",\n      }",{"title":668,"description":669,"authors":676,"heroImage":670,"date":678,"body":679,"category":680,"tags":681},[677],"Veethika Mishra","2023-03-28","\n\nProduct designers often choose to become a designer because of the hard-to-beat and attractive promise that accompanies it: improving the lives of people by adding value through design. Being a designer, I can vouch for how fulfilling and rewarding it can be to see a bud of an idea grow into a feature that is enjoyed by users. However, the demands of product designers can quickly become overwhelming as roles, products, and teams evolve - if left unchecked, this can result in burnout. In this blog, I will discuss how to avoid burnout by being intentional about time management and communication.\n\n## What is a product designer’s scope?\nAt GitLab, similar to many other software companies, [product designer responsibilities](https://handbook.gitlab.com/job-families/product/product-designer/) span designing thoughtfully crafted experiences, playing a central role in the overall business contributions, and everyday collaboration with key product stakeholders. The spectrum has grown over time, leading to a general misconception among designers that they are required to overreach their potential to prove their pedigree. Instead, taking up the right responsibility at the right time and doing it well often produces better results.\n\n## Define your own frame\nEach product designer envisions growth differently. In the pursuit of growth, to demonstrate specific expertise or leadership qualities, each designer may have a unique goal in mind in terms of the means you want to employ or the results you seek from that goal. Also, this implies that you cannot trust a generic template approach to map your priorities. The lens you use to distinguish important responsibilities and tasks from the rest are unique and your planning and rituals should be as well. \n\n## Establish an availability baseline\nA couple years ago, my manager, [Rayana Verissimo](https://gitlab.com/rayana), gave me a task of writing down an approximate estimation of how much time I plan to dedicate to each of the major responsibilities in my role. The math seemed simple at first: I work 40 hours a week and I had a list of about eight responsibilities. I had an idea in mind on how to divide up those responsibilities. What could go wrong? \n\nAs they say, life happens while we’re busy making other plans. I was preparing to move between countries and, in that same timeframe, our team was onboarding a new product manager. Without realizing it, I began spending a considerable amount of time at work on admin-related tasks and getting my processes in sync with my new product manager. These shifts were unannounced and unavoidable. Such surprise challenges are a part of all of our lives, though the form may vary. But when they happen, it is best to be accepting of them and keep some wiggle room in your time allotment estimation to accommodate them without disturbing the rest of your plan. \n\nThere are different ways to understand and manage your capacity. [Sunjung Park](https://gitlab.com/sunjungp), a product designer at GitLab, relies on the [UX issue weights](/handbook/product/ux/product-designer/#ux-issue-weights) framework to maintain a closer to accurate predictability of her tasks for a release cycle. I personally like to use the same and communicate my capacity for the release cycle to the team using a [planning issue](https://gitlab.com/gitlab-org/gitlab/-/issues/386189).\n\n## Assess the importance of a task to you \nDespite the evident benefits, [McKinsey Design Index](https://www.mckinsey.com/capabilities/mckinsey-design/our-insights/the-business-value-of-design) proved to be the very sign that the tech and other industries had always been looking for to validate the correlation between design and financial performance of an organization. Realizing how it can help them differentiate in the industry and directly impact revenue streams, organizations now expect designers to make some business-critical decisions, thereby expanding their responsibilities to be more cross-functional.\n\nThis evolution has led product designers to jump at every opportunity and request. However, if you do not take a moment to assess the “why” of the opportunity or request, you’re merely setting yourself up for failure. Product designers can ask some questions to help decide whether to take on the project:\n- Does the project require my expertise and skills, or help me develop one that aligns with my personal goals?\n- Does the project contribute to the business' goals?\n- Is this project something that someone else can do better than I can - while I invest my time doing something that I can do more confidently? \n- Am I on the same page with the requestor in terms of expectations and time commitment?\n- Will my delivery plan get impacted if I commit to this project? If so, what trade-offs can or need to be made?\n\n## Build trust and communicate transparently\nThe urge to say “yes” is an instinct of human behavior. However, when you say yes to every request from our peers/colleagues, you feed the [cycle of responsiveness](https://hbr.org/2012/05/are-you-sleeping-with-your-sma) to become more intense, to a point where you no longer can respond to the demand. This overwhelming wave of expectations puts you in a position where you stop exercising your creative muscles out of exhaustion and merely keep working more and more, driving down the quality of results. Making it a false victory, if one at all. Ironically, this, in turn, impacts the very relationship that you said “yes” to in the first place.\n\nI have already talked about how to decide if an opportunity or request is aligned to your goals. If the answer to that is “it isn’t,” the next thing you need to do is communicate that clearly to the requester. \n\nA plain “no” can easily be perceived as rude, but kindly communicating an honest and straightforward reason will have a higher chance of building trust with your peers than saying yes and delivering substandard results. The GitLab sub-value [Directness](https://handbook.gitlab.com/handbook/values/#directness) emphasizes the importance of transparent communication with colleagues. Another method a few members of my team, including me, use for maintaining transparency in everyday priorities is [documenting them publicly](https://gitlab.com/veethikaa/veethika-planner/-/blob/master/Weekly%20Priorities/weekly-priorities.md) in a GitLab project and keeping them visible to the team and our counterparts. \n\n## A checklist to avoid burnout\nIf you're looking to continue to enjoy your work as a product designer while also growing in your job, the following tips can help:\n\n- Take a step back and try to understand your own drives and motivations so you can more effectively plan your path ahead.\n- Be realistic about your capacity and potential trade-offs, and communicate the same to your team transparently.\n- Be discerning while taking up a new opportunity, ensure it aligns with your goals, and be comfortable passing it along to a colleague that is better suited if it doesn't.\n- Keep your communication honest, humble, and non-ambiguous to avoid miscalculated commitments that can harm relationships with your peers.\n\nMindfully and intentionally assessing a new opportunity rather than reacting by impulse can play a major role in setting yourself, and your colleagues, up for success, resulting in a happier, more impactful, and less stressful work environment.\n\n_Cover image by \u003Ca href=\"https://unsplash.com/@freestocks?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">freestocks\u003C/a> on \u003Ca href=\"https://unsplash.com/photos/vcPtHBqHnKk?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText\">Unsplash\u003C/a>_\n","insights",[682,9,683],"UX","remote work",{"slug":685,"featured":6,"template":686},"avoiding-burnout-as-product-designers","BlogPost","content:en-us:blog:avoiding-burnout-as-product-designers.yml","Avoiding Burnout As Product Designers","en-us/blog/avoiding-burnout-as-product-designers.yml","en-us/blog/avoiding-burnout-as-product-designers",{"_path":692,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":693,"content":699,"config":704,"_id":706,"_type":13,"title":707,"_source":15,"_file":708,"_stem":709,"_extension":18},"/en-us/blog/beautifying-of-our-ui",{"title":694,"description":695,"ogTitle":694,"ogDescription":695,"noIndex":6,"ogImage":696,"ogUrl":697,"ogSiteName":672,"ogType":673,"canonicalUrls":697,"schema":698},"Beautifying our UI: Giving GitLab build features a fresh look","Get an inside look at how we are improving the usability of GitLab build features with multiple visual design improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682807/Blog/Hero%20Images/beautify.jpg","https://about.gitlab.com/blog/beautifying-of-our-ui","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Beautifying our UI: Giving GitLab build features a fresh look\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2023-07-05\",\n      }",{"title":694,"description":695,"authors":700,"heroImage":696,"date":701,"body":702,"category":680,"tags":703},[677],"2023-07-05","\n\nThe current technical landscape is completely different from what it was this time last year. As the software development industry is busy evolving its understanding of _automating early and often_ in the presence of new AI capabilities, we have been focused on feature work. However, it's equally important to make sure we are adapting our UI to match up to the experience and addressing, where necessary, the misalignment between the two. \n\nIn a scaling product, where issues are competing to be prioritized, it might feel convenient to tackle the next feature issue as opposed to focusing on small visual design improvements. Advocating for the value that a small visual design change in isolation brings to the product is never easy for all the practical reasons, and this is where [the \"Beautifying our UI\" initiative](https://about.gitlab.com/handbook/product/ux/product-design/#beautifying-our-ui) becomes useful at GitLab. It allows a product designer and a frontend engineer to voluntarily pair up, like we did, and make self-directed improvements to the usability of GitLab.\n\nWe collaborated on many pipeline-related features in the past three years. As our responsibilities pulled us in different directions, we had to put many of our aspirational plans for improving the presentation of CI/CD features in GitLab on hold in favor of other more important things.\n\nHowever, once those were addressed, we decided to volunteer for a session of Beautifying our UI in the 16.1 milestone. To make the most of a single milestone, we began preparing a couple months in advance, soliciting ideas from team members and getting the design proposals ready in [an issue](https://gitlab.com/gitlab-org/gitlab/-/issues/394768/). After a quick prioritization exercise to understand which of the suggested improvements would be most meaningful to our users, we made a number of contributions to the product.\n\nHere are some of those contributions:\n\n### Improvement to pipeline detail page\nIn the process of troubleshooting a failing pipeline, users often have to visit their detail page for better insight into what's causing the failure. The top of the page previously had a table with all the metadata around that pipeline. Over the years, a lot of information was added to this table but the layout was never optimized to accommodate that information, which in return impacted the usability of the page. The page headers were also very different from other examples found in GitLab. \n\nBy critically looking at every piece of information displayed on the page, we made informed decisions using the qualitative insights and the usage data at hand to completely redesign the pipeline header.\n\n![image of pipeline detail page before](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/pipeline-detail-before.png)\nBefore\n{: .note.text-center}\n\n![image of pipeline detail page after making changes](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/pipeline-detail-after.png)\nAfter\n{: .note.text-center}\n\nThis work was substantial and while we did our best to avoid any negative impact to our users, we realize there might be a few issues. Please share your comments in this [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/414756) about the redesign and we'll prioritize addressing them.\n\nRedesigning the pipeline header came with a few technical challenges because a lot of the code was a mix between HAML and Vue. We had to slowly refactor the pipeline header over to Vue/GraphQL to allow our code to be more performant and maintainable. It’s pretty much like building a completely new feature — we had to get creative with passing data to the Vue app from Rails.\n\n### Harmonizing badges and link styles on pipeline list view\nThe pipeline index page (list view) is one of the most visited pages in GitLab because users need to make sure any failing pipelines are identified quickly for troubleshooting. Since there's a lot going on on this page, it is critical that the UI leads users' attention to the right areas. Previously, almost every link presented in the pipeline column had a different visual treatment, which made the page visually noisy and harmed the usability and scannability of the information. Our goal was to remove anything that isn't required and harmonize the visual language so it is easy for CI/CD users to perform their jobs effectively. \n\n![image of pipeline detail page before](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/pipeline-index-page-before.png)\nBefore\n{: .note.text-center}\n\n\n![image of pipeline detail page after making changes](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/pipeline-index-page-after.png)\nAfter\n{: .note.text-center}\n\n### Linking runner number to runner admin page\nTo allow easy management of runners across an instance, we've now provided easy access to the runner admin page right from the job detail page. Previously a static test, now the runner number can directly take users with the runner admin page where they can make changes to the specific runner's configuration.\n\n![image of cancel pipeline label](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/runner-link-from-job-logs.png)\nLinking runner admin page from job logs page\n{: .note.text-center}\n\n### Improving tooltips and button text\nThe tooltips on the jobs list view were using native browser tooltips. We've changed those to use a design-system-compliant tooltip for consistency and better readability.  \n\nWe gathered some useful feedback on the usability of the button labels and took this as an opportunity to improve a few of them. Here's one example where we changed the label text for the button for canceling a running pipeline from **Cancel running** to **Cancel pipeline** and added an appropriate tooltip to clearly communicate the action. \n\n![image of cancel pipeline label](https://about.gitlab.com/images/blogimages/Beautifying-of-our-ui-16-1/cancel-pipeline-label.png)\nButton with new label text\n{: .note.text-center}\n\n## More to come\nWe are not stopping with this list! We will continue our partnership to bring in more visual and usability improvements to the continuous integration area in the coming months. If you are interested in taking a look at the complete list of changes we have made and the ones we still plan to make, [you can find the issue here](https://gitlab.com/gitlab-org/gitlab/-/issues/394768/). \n\n\n",[682,9],{"slug":705,"featured":6,"template":686},"beautifying-of-our-ui","content:en-us:blog:beautifying-of-our-ui.yml","Beautifying Of Our Ui","en-us/blog/beautifying-of-our-ui.yml","en-us/blog/beautifying-of-our-ui",{"_path":711,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":712,"content":718,"config":726,"_id":728,"_type":13,"title":729,"_source":15,"_file":730,"_stem":731,"_extension":18},"/en-us/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience",{"title":713,"description":714,"ogTitle":713,"ogDescription":714,"noIndex":6,"ogImage":715,"ogUrl":716,"ogSiteName":672,"ogType":673,"canonicalUrls":716,"schema":717},"Beautifying our UI: Enhancing GitLab's deployment experience","Go inside our innovative approach to improving our user interface, including pairing product designers and frontend engineers to make usability improvements across the platform.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097783/Blog/Hero%20Images/Blog/Hero%20Images/blog-image-template-1800x945%20%288%29_5KLUrr4DkY2u0JTMA12FVm_1750097783460.png","https://about.gitlab.com/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Beautifying our UI: Enhancing GitLab's deployment experience\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily Bauman\"}],\n        \"datePublished\": \"2025-03-06\",\n      }",{"title":713,"description":714,"authors":719,"heroImage":715,"date":721,"body":722,"category":723,"tags":724},[720],"Emily Bauman","2025-03-06","At GitLab, we’ve implemented an innovative approach to improving our experience called [Beautifying our UI](https://handbook.gitlab.com/handbook/product/ux/product-design/#beautifying-our-ui). This unique initiative pairs one product designer with a frontend engineer for a milestone or two, and empowers them to make self-directed usability improvements across the platform. Ultimately, this helps build a more polished product experience, as these pairs can quickly address pain points, refine interactions, and deliver thoughtful improvements that make the platform more efficient and enjoyable to use.\n\nIn this iteration, [Anna Vovchenko](https://gitlab.com/anna_vovchenko) and I decided to focus on the continuous deployment ([CD](https://about.gitlab.com/topics/ci-cd/#what-is-continuous-deployment)) area of the product. Here is how we did it and what we learned.\n\n## Trying something new\n\nAs this was our second round going through the process, we wanted to make several small adjustments that in the end helped us deliver even more quality improvements to the product. These process improvements included: \n\n* **Extended timeline:** We decided this time around we wanted to extend the initiative to span two milestones. This gave us the time to tackle more complex problems, but also gave us space for additional planning at the start. \n* **Structured planning:** While it was encouraged in the past to work directly in merge requests, we found it helped to use the initial issue as a place to plan and seek out problems ahead of time. Rather than purely focusing on the ad-hoc, we incorporated a planning phase similar to milestone planning, helping the partnership identify and prioritize potential improvements beforehand.\n* **Product manager integration:** As we focused on one area for this round of the project, we also decided to involve the product manager of the team more actively in the process. This ensured alignment on larger changes, reduced surprises when MRs were merged and allowed us to gather valuable feedback throughout the implementation.\n* **Engaging the community:** We expanded our improvement efforts by inviting contributions from community members, accelerating our ability to implement fixes and enhancements across the platform.\n* **Strategic timing:** We chose to run this iteration during a traditionally slower period, allowing teams to focus more deeply on these improvements without competing priorities.\n\nThese refinements maintained the initiative's core strength of direct designer-engineer collaboration, while adding structure that helped our pair work more effectively.\n\n## What were the main improvements?\n\nDuring the two milestones, our pairing implemented several significant improvements that enhance the user experience across the CD space. Here's a look at what we accomplished:\n\n### Enhanced environment list view\n\nOne of the larger changes made during this cycle of \"Beautifying our UI\" was a redesigned Environment List page to make deployment information more accessible. Previously, users had to click through collapsible sections to view crucial deployment details, and viewing important details at a glance was difficult. Now, this information is immediately visible, bringing the most important deployment information to the forefront where users need it.\n\n![Beautifying UI - Environments page before](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Before_Environments_Page_aHR0cHM6_1750097793301.png)\n\n**Before:** The original design relied on collapsible sections, requiring users to click to reveal deployment information. This meant that users couldn't immediately see the status of their deployments, making it harder to quickly assess the state of their environments.\n\n![Beautifying UI - Environments page after](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/After_Environments_Page_aHR0cHM6_1750097793301.png)\n\n**After:** The new design surfaces critical deployment information directly in the list view, including:\n\n* Deployment status with clear visual indicators\n* Who triggered the deployment along with timestamps\n* Commit information and version tags\n* Actions to take on the environment\n* Latest deployment indicators\n\nThis redesign eliminates the need for extra clicks and gives users immediate visibility into their deployment and environment statuses. The new layout maintains a clean interface while presenting more actionable information upfront.\n\n### Improved deploy keys filtering\n\nAnother larger enhancement was made to our deploy keys interface to improve searchability while maintaining performance. This change addresses a critical user need for quickly finding specific deploy keys in large repositories, which was broken when pagination was introduced earlier last year.\n\n![Beautifying UI - Deploy key before](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Deploy_Key_Before_aHR0cHM6_1750097793303.png)\n\n**Before:** The previous interface displayed deploy keys in a paginated list without a dedicated search function. While pagination helped with performance when handling thousands of keys, users had lost the ability to quickly search through their deploy keys using the browser search functionality, forcing them to manually scan through multiple pages.\n\n![Beautifying UI - Deploy key after](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Deploy_Key_After_aHR0cHM6_1750097793306.png)\n\n**After:** The new design introduces a dedicated search field at the top of the deploy keys list, allowing users to:\n\n* Quickly filter deploy keys by name or SHA\n* Maintain the performance benefits of pagination\n* Find specific keys without browsing through multiple pages\n\nThis improvement strikes the right balance between performance and usability, especially beneficial for teams managing numerous deploy keys across multiple projects.\n\n### Better Kubernetes agent management\n\nWe made significant improvements to the Kubernetes agent experience by simplifying the registration process and providing better visibility into agent status. These enhancements work together to create a smoother onboarding experience for teams getting started.\n\nOur first area of focus was streamlining how users register agents when they have configuration files ready to use. Previously, this process had several pain points that we wanted to address.\n\n![Beautifying UI - Agent before](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Agent_Before_aHR0cHM6_1750097793309.png)\n\n**Before:**\n\n* Only showed connected and previously connected agents\n* Connection status was limited to \"Never connected\" or \"Not connected\"\n* No clear path to register new agents\n\n![Beautifying UI - Agent after](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Agent_After_aHR0cHM6_1750097793310.png)\n\n**After:**\n\n* Added a new Available configurations tab showing all potential agent configurations\n* Clear \"Register an agent\" call-to-action button for each available configuration\n\nNext, we turned our attention to making the agent registration modal more intuitive. The previous design created some confusion that we wanted to resolve.\n\n![Beautifying UI - Registration before](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Registration_Before_aHR0cHM6_1750097793311.png)\n\n**Before:**\n\n* Users faced a confusing dual-purpose search box that both found existing agents and created new ones\n* The workflow had too many decision points instead of a clear path forward\n* The process for creating vs. selecting an agent wasn't clearly separated\n\n![Beautifying UI - Registration after](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750097793/Blog/Content%20Images/Blog/Content%20Images/Registration_After_aHR0cHM6_1750097793312.png)\n\n**After:**\n\n* Separated the interface into two clear options: bootstrap with Flux or create an agent through the UI\n* Streamlined the workflow into a more linear process\n* Made the distinction between creating new agents and selecting existing ones more obvious\n* Added a success message that clearly shows where to create the optional config file\n\nThese improvements make it immediately clear which agents need attention and provide a straightforward path to register new agents. The reorganized interface better supports both new users setting up their first agent and experienced users managing multiple agents.\n\n## Additional usability enhancements\n\nWhile working on major interface improvements, we also addressed several focused usability issues that significantly improve the day-to-day experience:\n\n* **Enhanced Kubernetes pod search:** Added search functionality for Kubernetes pods on the environment page, making it easier to locate specific pods in large deployments. This was showcased in the [GitLab 17.8 release post](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#search-for-pods-on-the-dashboard-for-kubernetes).\n* **Improved Flux status visibility:** Added a \"stopped\" badge to the dashboard view when Flux sync is stopped, providing immediate visibility into sync status. This was also showcased in the [GitLab 17.8 release post](https://about.gitlab.com/releases/2025/01/16/gitlab-17-8-released/#view-paused-flux-reconciliations-on-the-dashboard-for-kubernetes). \n* **Better release information:** Implemented a clear view of deployments related to a release, improving deployment tracking and visibility.\n* **Streamlined environment search:** Fixed an issue where users couldn't effectively search the Environments page, improving navigation in large environment lists.\n* **Enhanced error message display:** Resolved issues with viewing Flux details when long error messages were present, making troubleshooting more straightforward.\n\n## Looking forward\n\nThe success of these improvements demonstrates the value of empowering our teams to make direct, meaningful changes to our experience. Beyond the product enhancements, one of the most valuable outcomes has been the strengthened relationship between our Frontend and Design teams. Working together closely on these improvements has fostered better understanding of each other's perspectives, workflows, and constraints, leading to more effective collaboration.\n\nThis deepened partnership has created a foundation for even better collaboration in our regular workflow, as team members now have stronger working relationships and shared understanding of each other's domains. We're excited to continue this initiative in future iterations, not just for the product improvements it generates, but also for its role in building stronger, more cohesive teams.\n\n> [Follow along with the \"Beautifying our UI\" project](https://handbook.gitlab.com/handbook/product/ux/product-design/#beautifying-our-ui) as we continue to make improvements to GitLab.\n\n## Read more\n\n- [How we overhauled GitLab navigation](https://about.gitlab.com/blog/navigation-research-blog-post/)\n- [GitLab dark mode is getting a new look](https://about.gitlab.com/blog/gitlab-dark-mode-is-getting-a-new-look/)\n- [Beautifying our UI: Giving GitLab build features a fresh look](https://about.gitlab.com/blog/beautifying-of-our-ui/)","product",[9,682,725,723,481],"UI",{"slug":727,"featured":6,"template":686},"beautifying-our-ui-enhancing-gitlabs-deployment-experience","content:en-us:blog:beautifying-our-ui-enhancing-gitlabs-deployment-experience.yml","Beautifying Our Ui Enhancing Gitlabs Deployment Experience","en-us/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience.yml","en-us/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience",{"_path":733,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":734,"content":740,"config":746,"_id":748,"_type":13,"title":749,"_source":15,"_file":750,"_stem":751,"_extension":18},"/en-us/blog/beautifying-our-ui",{"title":735,"description":736,"ogTitle":735,"ogDescription":736,"noIndex":6,"ogImage":737,"ogUrl":738,"ogSiteName":672,"ogType":673,"canonicalUrls":738,"schema":739},"What we're doing to beautify our UI","We’re actively working to make our UI more aesthetically pleasing. Learn how we started with a UX spike and where we’re going next.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680648/Blog/Hero%20Images/UXpost.jpg","https://about.gitlab.com/blog/beautifying-our-ui","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What we're doing to beautify our UI\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2019-07-02\",\n      }",{"title":735,"description":736,"authors":741,"heroImage":737,"date":743,"body":744,"category":298,"tags":745},[742],"Christie Lenneville","2019-07-02","\n\nDesigners like to create beautiful UIs. That’s no surprise.\n\nBut visual design can be really difficult to maintain in an open source product like GitLab, where we have thousands of contributors and a strikingly fast feature velocity.\n\n## Why it’s hard\n\nWe deliberately keep the contribution barrier for GitLab as low as possible, which means small UI bugs tend to slip into the product. We’ve also had a historical tendency to focus our efforts more on value-added delivery than visual refinement.\n\nVelocity and feature delivery are really important, so this mindset isn’t a bad thing. But, aesthetics are important, too. They have a real and meaningful impact on usability and credibility, both of which are key concerns for GitLab’s UX team.\n\n## What we’re doing about it\n\nWe’re working hard to make GitLab the most usable DevOps tool on the market. Part of that effort is making our UI as visually pleasing as we can without sacrificing speed. At a high level our plan is to:\n\n### 1. Focus on tactical fixes that can happen right away\n\nThis blog post includes some examples of what we’ve already accomplished and shows you where to find what we’re doing next.\n\n### 2. Update our visual design strategy\n\nVisual design trends evolve at a pretty rapid clip, and we’re due for an update. That’s why we’re so pleased to have [Jeremy Elder](/company/team/#jeremyelder) join our team as a senior product designer with a dedicated focus on visual design. Along with being an [excellent visual designer](https://dribbble.com/jeremyelder), Jeremy brings a deep background in illustration and design systems. He’s already jumped in to help refine a number of UI issues (after only one month of being on the team). We can’t wait to see where he takes us!\n\n### 3. Build out our design system\n\nToday, [Pajamas](https://design.gitlab.com/) is more of an idea than a reality, but not for much longer. We’re aggressively designing, documenting, and building out reusable components that will bring refinement and consistency to our UI and enable our product designers and frontend engineers to move much faster. That only means good things for our future velocity!\n\n## More about tactical fixes\n\nIn June 2019, a small team of GitLab product designers, [Annabel Gray](/company/team/#annabeldunstone), [Marcel van Remmerden](/company/team/#mvremmerden), and [Jarek Ostrowski](/company/team/#jaaaaarek), went heads down for almost three weeks on a UX spike. During this period, they rapidly closed 43 issues in our [Beautifying our UI](https://gitlab.com/groups/gitlab-org/-/epics/989) epic (take a look to see what we’re still planning to do).\n\nThey addressed a lot of issues during the UX spike, but I’d like to highlight a few that are especially exciting:\n\n### New threaded discussion design\n\nOur previous design for threaded discussions included a lot of boxes and borders, making it difficult to quickly scan the page to find related content. Marcel removed some of the visual cruft and used subtle background colors to help users distinguish between components more easily.\n\nWhile we have other long-term changes we’d like to make to discussions, this was a great start.\n\n![Before](https://about.gitlab.com/images/blogimages/beautifying-our-ui/discussion-before.jpg){: .shadow.center.medium}\nBefore\n{: .note.text-center}\n\n![After](https://about.gitlab.com/images/blogimages/beautifying-our-ui/discussion-after.jpg){: .shadow.center.medium}\nAfter\n{: .note.text-center}\n\nWe're happy to see that members of the wider GitLab community noticed the effort on this change and responded positively.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n  \u003Cblockquote class=\"twitter-tweet\" data-lang=\"en\">\u003Cp lang=\"en\" dir=\"ltr\">Thanks \u003Ca href=\"https://twitter.com/gitlab?ref_src=twsrc%5Etfw\">@gitlab\u003C/a> for quick/easy upgrade to GitLab 12.0, glad to see discussions UI design cleaned up \u003Ca href=\"https://t.co/Va28ssb20Y\">https://t.co/Va28ssb20Y\u003C/a>\u003C/p>— David Puplava (@DavidPuplava) \u003Ca href=\"https://twitter.com/DavidPuplava/status/1143010489460514821?ref_src=twsrc%5Etfw\">June 24, 2019\u003C/a>\u003C/blockquote>\n  \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\n### Prioritized merge request “changes” in the content hierarchy\n\nIn a merge request, **Changes** is one of the most-clicked tabs. Unfortunately, at certain breakpoints, the tab was hidden, requiring users to scroll to see it (or sometimes they were even forced to resize their window).\n\nAnnabel fixed the tab component throughout the product, accounting for all breakpoints, whether or not one or both sidebars are open, and whether or not the tab bar includes buttons. This ensures that the **resolved discussions** component wraps to the next line on smaller screen sizes, leaving more room for **Changes** to always display correctly.\n\n![Before](https://about.gitlab.com/images/blogimages/beautifying-our-ui/breakpoints-before.jpg){: .shadow.center.medium}\nBefore\n{: .note.text-center}\n\n![After](https://about.gitlab.com/images/blogimages/beautifying-our-ui/breakpoints-after.jpg){: .shadow.center.medium}\nAfter\n{: .note.text-center}\n\n### Align merge request icons\n\nAs a final example, Jarek focused on correctly aligning the icons on the merge request page. It’s a subtle change that refines the visual design and makes the page easier to scan (scheduled for release in 12.1).\n\n![Before](https://about.gitlab.com/images/blogimages/beautifying-our-ui/mricons-before.jpg){: .shadow.center.medium}\nBefore\n{: .note.text-center}\n\n![After](https://about.gitlab.com/images/blogimages/beautifying-our-ui/mricons-after.jpg){: .shadow.center.medium}\nAfter\n{: .note.text-center}\n\n### We’re excited to do more\n\nThis recent spike was a great start, but we’re all excited to make more improvements to GitLab's UI. We’re currently exploring how we could [make the UI for our discussions easier to understand](https://gitlab.com/gitlab-org/gitlab-design/issues/437) and the best ways to [display threads](https://gitlab.com/gitlab-org/gitlab-ce/issues/53937). We’re also in the process of creating [new default avatars](https://gitlab.com/gitlab-org/gitlab-ce/issues/62185).\n\nIf any of these topics interest you or if you have some feedback on our ideas, please chime in and let us know what you think of the UI as it evolves, we would love to hear from you!\n\nPhoto by [Martin Reisch](https://unsplash.com/@safesolvent?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/@safesolvent?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText).\n",[682,725,9],{"slug":747,"featured":6,"template":686},"beautifying-our-ui","content:en-us:blog:beautifying-our-ui.yml","Beautifying Our Ui","en-us/blog/beautifying-our-ui.yml","en-us/blog/beautifying-our-ui",{"_path":753,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":754,"content":759,"config":769,"_id":771,"_type":13,"title":755,"_source":15,"_file":772,"_stem":773,"_extension":18},"/en-us/blog/being-a-better-ally",{"title":755,"description":755,"ogTitle":755,"ogDescription":755,"noIndex":6,"ogImage":756,"ogUrl":757,"ogSiteName":672,"ogType":673,"canonicalUrls":757,"schema":758},"Being A Better Ally","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679611/Blog/Hero%20Images/cook-county-blog-unsplash.jpg","https://about.gitlab.com/blog/being-a-better-ally","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Being A Better Ally\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"David O'Regan\"}],\n        \"datePublished\": \"2020-09-09\",\n      }",{"title":755,"description":755,"authors":760,"heroImage":756,"date":762,"body":763,"category":764,"tags":765},[761],"David O'Regan","2020-09-09","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nI’ve been at GitLab five months now - with every merge request committed and milestone met, GitLab team members collaborate on innovative and efficient methods of delivering some of the world's best software. Besides this, I’ve also noticed that GitLab team members do a superb job of creating an environment that allows each of our peers to contribute, be heard, and bring their whole selves to work. Once you’ve gotten a taste of being part of that kind of community you get to see how much it matters in writing good code - talented and inclusive teams are more creative, efficient, and happier in the workplace.\n\nThe Gitlab Handbook offers amazing explanations about our values and resources for living them to your best ability. One of our values ‘Diversity, Inclusion, and Belonging’ has the following note on this value that I really appreciate:\n\n> “... Diversity is having a seat at the table, Inclusion is having a voice and feeling empowered to use it, and Belonging is acknowledgement of your voice being heard along with creating an environment where team members feel secure to be themselves...”\n\nAnyone can, and everyone should strive to nurture these values. For myself, as a person with intersecting levels of privilege who is not a member of an underrepresented group, allyship is a fantastic way to help build a better working environment. Though, being honest, if you asked me 6 months ago what allyship meant, I couldn't have told you. Going over the Handbook was a great start and I highly encourage it, as was working through my own [diversity training](https://gitlab.com/gitlab-com/diversity-and-inclusion/-/issues/127) but I also wanted to put together a small piece for anyone else getting started on their journey in allyship. Something my old bodybuilding coach [Blue Shinners](https://www.independent.ie/lifestyle/big-and-beautiful-26331156.html) used to tell me came to mind when I started the learning process;\n\n> It's not complicated, but that doesn't make it easy - Blue Shinners\n\nFor context on this piece, I want to let you know the following:\nI am a white, cisgender male (pronouns: he|him|his). I also have a lot of privilege along other lines of intersectionality (e.g. heterosexual, neurotypical, a citizen of an affluent, peaceful nation, etc).\n\nI am far from an expert in the field of allyship or building inclusive work environments, so I’m relying on my lived experiences and what I’ve learned from reading and listening to others. Regarding scope, I am committed to using my position within GitLab to help foster an inclusive and diverse environment aligned with GitLab’s core values.\n\nI’ve got to say - for me, becoming a better ally looks a lot more like a patchwork of small bursts of reading, learning little bits in social interactions, being corrected here and there, apologizing, and using what I’ve learned to do better. It isn’t always tidy, but if I were to lay my journey out in general steps, it would look a little something like this:\nGetting excited about learning and listening, making space, and making spaces inclusive. Contributing to a better culture, where and how you can. If you see something, (and it’s safe for you to do so,) say something. Though most of all accept that you will make mistakes, and strive for course correction.\n\nI personally make a lot of mistakes. The uncomfortable truth about making mistakes is they are part of lifeand more part of living honestly. Alan Watts very famously said that you do not know where your choices come from when you live honestly, and this can cause you to fumble as you explore like a toddler taking their first steps. One of the most difficult things I have ever done is to honestly level the question at myself;\n\n> If you make mistakes in all other areas of life, is it possible you also make mistakes in this area?\n\nThe natural instinct is to pull back in ~~anger~~(fear), claiming you are a good person and would never intentionally set out to treat people differently based on something as shallow as how they look or present themseleves. Regardless of how you feel, making mistakes is inevitable purely due to the fact that without a well thought out dose of empathy, you simply cannot assume someone else's situation nor experience.\n\n### Getting excited about learning and listening\n\nSearch for answers - you don’t have to know everything about the historical and cultural basis of social injustice, but I know that even a few articles or YouTube videos here and there have made the difference in giving me a better foundation for understanding, open-mindedness, kindness, and better conduct.\n\nListen to your peers, partners, and colleagues when they share their experiences or important pieces of news with you - and be willing to share yours, if asked.\n\nKnow your [‘-isms’](https://en.wikipedia.org/wiki/-ism) and learn about unconscious biases - especially your own. If you haven’t experienced certain kinds of prejudice or discrimination it may be while until you learn about them or how you unconsciously maintain them. Knowing about them lets you make an active choice in reducing toxic behaviors in shared spaces.\n\nIf you can’t find what you’re looking for in your research, don’t be afraid to ask for help. When possible, ask the appropriate person for help, like your team supervisor, or even ask in the GitLab diversity slack channel (I personally learn a lot from this channel each day).\n\nWhen the context is more specific, ask your peers - but leave room for individuals to say no or for groups to leave anonymous feedback.\n\nKnowledge is necessary to good allyship. And it’s sufficient when paired with inclusive, affirming actions. Like with any good piece of code, go for the minimum viable product - learn more, incorporate it into your daily actions, be willing to keep adding to that knowledge base and growing.\n\n### Making space, and making spaces inclusive\n\nLearn about the space you’re in and space you occupy - for myself, this journey meant coming through the understanding that software companies are overwhelmingly composed of people that look just like me. Learning more about how and why some groups are underrepresented, even in companies like GitLab, is another important step in allyship.\n\nLooking at GitLab’s values, we’re encouraged to see others succeed and help where we can. Good allyship is about doing my best to ensure that underrepresented voices are given at least as much space as my own, both by letting people know you want their contribution with affirming and inclusive language and by showing your appreciation for those contributions by giving credit and offering praise centered on their hard work.\n\nUse common sense and be kind in your interactions with your colleagues. Don’t make assumptions. Be flexible and open-minded. Be respectful of others’ privacy and get excited about what they’re willing to share with you, from their quirks to their life story and family album. These interactions create the bond GitLab team memebers share and makes this all-remote team that you love to work with.\n\n### Contribute to a better culture, where and how you can\n\nImproving the work we do at GitLab is often about your contributions, but it’s also about how good a job we do as allies to ensure that all of our ideas and contributions receive time, consideration, and credit. As a good ally, this means remembering to uplift and make space for the most marginal voices.\n\nCelebrate intersectional as well as cross-functional collaboration by considering paired-programming or mentorship with someone new. The benefit of working at GitLab is that it is teeming with talented developers from all backgrounds. When you issue or consider a request for paired programming or mentorship, center the goals and timeline to confirm you both have the time and skills to get it all in. Be willing to meet the other person where they’re at: be flexible, respectful, and accommodating of their needs in the workplace, ask them about their experiences, be willing to share yours.\n\nShare your time and your love of code with your local community - hundreds of cities worldwide have organizations and education programs that promote programming for marginalized groups and youth. Even if it’s during traditional working hours, at GitLab, we have the flexibility of working things out with our supervisor to support the events and people that won’t wait until ‘after work’. A great example of this is the [Vue Vixens](https://www.vuevixens.org/) which are one of my personal favorites.\n\nDonate to an organization or cause that is able to do the work you can’t on your own. Did you know that GitLab has a pretty great [donation matching program proposal in the makes?](https://gitlab.com/gitlab-com/diversity-and-inclusion/-/issues/91) It’s nice to know they’ll back you up on the causes you support.\n\nIf you see something (and it’s safe for you to do so), say something. Call out discrimination - address the behavior, without labeling the person. This comes back to empathy in the workplace. Be in the shoes of the person or group experiencing the discriminatory behaviour, and be in the shoes of the person behind the behaviour. Support the marginalized person or group, to reinforce the equal value of everyone of GitLab. Addressing someone’s discriminatory behaviour and holding them accountable gives them an opportunity to adopt, adapt, and improve.\n\nWe have a lot of options in how we respond to discriminatory behavior. I go into all interactions with my team assuming good intent, and keep in mind that we are each more than our work or individual actions. I also keep in mind that while discriminatory behavior can be addressed directly and in the moment or context, it can also be addressed indirectly, or in a 1-on-1 afterwards, which can offer a more approachable context for difficult feedback.\n\nI recognize that in an ideal world, everyone would feel comfortable calling out discriminatory behavior, but it isn’t always safe for everyone to do so - especially members of the groups being discriminated against. That’s where ally’s like myself come in - inclusive spaces are about shared work, and I have more opportunities than many to help build that.\n\nAccept that you will make mistakes, and strive for course correction in all areas.\n\n“Many would-be allies fear making mistakes that could have them labeled as “-ist” or “-ic” (racist, sexist, transphobic, homophobic, etc). But as an ally, you’re also affected by a system of oppression. This means that as an ally, there is much to unlearn and learn—mistakes are expected. You need to own this as fact and should be willing to embrace the daily work of doing better.”\n\nI’ve mentioned before that this is a core takeaway for developers and team leaders alike. Whether we’re creating a merge request, bringing our true selves to work, or becoming a better ally, we should do so with a low sense of shame and no ego.\n\nYou will make mistakes. I promise. We all will. But when it comes to allyship, it won’t just be a blow to the ego. It will be to the part of ourselves that loves GitLab for the people we get to work with every day and hates the idea of hurting anyone here.\n\nSo here are some notes for getting through those sticky occasions, and iterating better when someone calls out that you haven’t been the best ally:\n\n> In simple terms: say thank you, say sorry, iterate and do better.\n\nDon't:\n\n- center around yourself\n- prioritize your intention above the impact of your actions\n- deny the other person’s lived experience, derail or deflect from the issue in your apology\n- avoid arguing semantics on how the issue was brought to your attention\n- ask that person to accept inequality or microaggressions as a fact of life\n- blame them or their actions for what happened\n- retaliate against the person either actively or passively\n\nDo:\n\n- ask if they’re okay and center their experience\n- listen to what they have to say, acknowledge what happened and your role in it\n- apologize as gracefully as possible\n- understand and learn from what happened, do your homework\n- stop the behavior and modify the pattern that led to it.\n\nKeep in mind that it’s okay to ask for the person’s feedback on what you can do to be a better ally or for a clarification on what happened was problematic, but remember to center their experience and leave the other person space to refuse (fixing the behaviour is contribution you make to a more inclusive space going forward). Where I come from, it’s mandatory to add that your owe the person a pint of Guiness down at the pub after a workplace chat... maybe a coffee chat is a better call for an all-remote company though.\n\nRemember that we are more than our work or our individual behaviors. But over time, we do become associated with a track record comprising both of those things. When our colleagues do code review or call us out, it’s an opportunity for us to grow and build better habits. And as long as we continue to iterate better, our contributions to GitLab will be more meaningful and people will see us in the light of the changes we’ve made (not the small slips along the way).\n\nTL;DR\n\nBeing an ally is an ongoing journey where we have many opportunities to contribute, collaborate, learn, get feedback, and iterate better... so pretty much the same as everything else we do at GitLab. And with this one, we grow better interactions with some of the most talented developers we’ll ever get to work with.\n\nAs with every other post, this is also a collaboration... so whether it’s further resources, suggested additions, punctuation edits, or even a few callouts that I should look out for, it’s all very welcome. It's how we all grow, it’s how I hope I am becoming a better ally.\n\nCover image by [Element5 Digital](https://unsplash.com/@element5digital) on [Unsplash](https://unsplash.com)\n{: .note}\n\n[Join us](/jobs/) at GitLab! Or consider [trying us out](/free-trial/) for free.\n\n","unfiltered",[536,766,9,767,768],"security","releases","agile",{"slug":770,"featured":6,"template":686},"being-a-better-ally","content:en-us:blog:being-a-better-ally.yml","en-us/blog/being-a-better-ally.yml","en-us/blog/being-a-better-ally",{"_path":775,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":776,"content":782,"config":789,"_id":791,"_type":13,"title":792,"_source":15,"_file":793,"_stem":794,"_extension":18},"/en-us/blog/building-a-ux-research-insights-repository",{"title":777,"description":778,"ogTitle":777,"ogDescription":778,"noIndex":6,"ogImage":779,"ogUrl":780,"ogSiteName":672,"ogType":673,"canonicalUrls":780,"schema":781},"Why we built a UX Research Insights repository","One of the biggest challenges faced by UX researchers is organizing and storing user research effectively, so that anyone can find and use insights.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678561/Blog/Hero%20Images/open-course-environment.jpg","https://about.gitlab.com/blog/building-a-ux-research-insights-repository","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we built a UX Research Insights repository\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah O’Donnell\"}],\n        \"datePublished\": \"2019-07-10\",\n      }",{"title":777,"description":778,"authors":783,"heroImage":779,"date":785,"body":786,"category":787,"tags":788},[784],"Sarah O’Donnell","2019-07-10","\nI joined GitLab around two and a half years ago. At the time, I was GitLab’s first and only UX researcher. I’d hunt out issues in the [GitLab CE](https://gitlab.com/gitlab-org/gitlab-ce/) project where I felt I could add value. Usually, a member of the Product or UX/Product Design team would open the issue, which was often sparked by user feedback from social media, during a customer meeting, or even in response to a prior issue. It was my responsibility to help the teams determine how we could best address user needs, motivations, and pain points, or if the request was an edge case. I documented my research questions and insights in the associated issues living in the CE project. However, this approach had some problems:\n\nBack then, the formatting options available for issues was in its infancy. It was difficult to structure and share data in a clear and concise way. Like most good researchers, I’d always learn more than what I intended to during a study. I created new issues for the insights we weren’t previously aware of and didn’t have documented. Epics didn’t exist yet, so there was no way to collectively group issues from the same study. I could label issues, but we discovered (maybe ironically) with UX research that GitLab’s search functionality needed improvements. The GitLab CE project contains more than 50,000 issues, so trying to find and action an insight was like trying to find a needle in a haystack.\n\nEnter the [UX Research repository](https://gitlab.com/gitlab-org/ux-research) and research reports. As the Product and UX/Product Design teams grew, so did the demand for UX research. Product managers and UX/product designers needed greater visibility into what I was working on so they had a sense of my availability for projects, and I needed a way to manage incoming research requests. We had success by creating a dedicated repository for UX Research requests and then using checklists within issues to track my progress against each request. However, I still had my original problem of needing to store and disseminate research insights. I resorted to Google Docs and began producing reports of my insights. This worked well for a little while, but then the cracks started to show.\n\n## The problem with reports\n\n### They are not searchable\nWhenever anybody asked me if I had witnessed users experiencing a particular problem, I’d rack my brain trying to work out which research report might contain the answer. I’d sift through multiple reports, scanning everything I had previously written. The situation became worse when we added new UX researchers to the team who began producing their own reports. I had a vague idea of what was in my own reports, but I didn't know where to start with reports produced by other UX researchers.\n\n### They create research silos\nAs I searched through dozens of reports, I realized research findings were inaccessible. UX researchers were spending a large part of their days searching through past insights, when their time would be better spent speaking with users and uncovering new insights. Everybody should be able to find research swiftly and easily without needing a researcher to find it for them.\n\n### They are not actionable\nAt GitLab, we use issues to solve problems, develop ideas, and collaborate. [One of our values is iteration](\n/handbook/values/#iteration): We do the smallest thing possible and get it out as quickly as possible. UX research reports were not small; they often contained many insights. Just one insight could lead to multiple, iterative changes to the user interface. We ended up copying parts of our reports into issues, which felt like a duplication of effort.\n\n### They quickly become outdated\nOur research reports directly addressed the research questions formed with the Product and UX/Product Design teams and were extremely focused on a topic or feature. GitLab is a rapidly growing product; consequently, our research reports became outdated very quickly. Reports that felt ‘old’ or ‘stale’ were rarely revisited, but the reports contained insights that could be triangulated with more recent research. Reports didn’t provide an easy way to access this important data in the future.\n\n## Finding a solution\nI wanted to confirm whether people outside of the UX Research team also felt these problems. I set up 1:1 interviews with every product manager at GitLab. In these interviews, I learned reports weren’t working for our product managers either. If something requires their attention, they want it in an issue.\n\nI read (lots) of articles on [Atomic Research](https://medium.com/@tsharon/foundations-of-atomic-research-a937d5da5fbb) and realized we could use a similar approach for managing our insights. Better yet, I felt we could [dogfood](https://handbook.gitlab.com/handbook/values/#dogfooding) our approach.\n\n## Introducing the UXR Insights repository\n\nThe [UXR Insights repository](https://gitlab.com/gitlab-org/uxr_insights) is the new single source of truth for all user insights discovered by GitLab’s UX researchers and UX/product designers. Instead of reports, we use issues to document key findings from research studies.\n\nYou may be wondering why we reverted to issues, given the problems of a couple of years ago. GitLab’s [issue functionality](https://docs.gitlab.com/ee/user/project/issues/#issues) has improved immensely since then. There’s now a range of formatting options for issues, and our [search functionality](https://docs.gitlab.com/ee/user/search/#issues-and-merge-requests-per-project) includes the ability to search by labels.\n\nWe use labels to tag and organize insights. This allows anyone to quickly search and filter through issues to find the insights they need. Unlike in a report, insights are continually added. This means that you’ll receive a dynamic list of results when searching through the repository.\n\nWe use [epics](https://docs.gitlab.com/ee/user/group/epics/) and GitLab’s [related issues functionality](https://docs.gitlab.com/ee/user/project/issues/related_issues.html) to track issues from the same research study. The epic description usually contains our research methodology and any background information about users.\n\nOpen issues and epics indicate that the research study is still in progress and the UX researcher and/or UX/product designer is still adding insights to the repository. Closed issues and epics indicate that the research study is finished.\n\nEach insight is supported with evidence, typically in the form of a video clip or statistical data. Unlike the atomic research approach, some lightweight research synthesis takes place before insights are added to the repository (which is why we also call them ‘insights’ rather than ‘nuggets’ or ‘observations’). While every issue within the repository contains a single insight on a particular topic, the insight can relate to multiple users.\n\nFor example: We’re conducting some usability testing. Four out of the five users we tested with experienced the same problem. Rather than open four separate issues, we’ll create one issue, but we’ll include four supporting pieces of evidence (four video clips – one for each user) in the single issue.\n\nWe’re also experimenting with using the UXR Insights repository for quantitative forms of research, such as surveys. Each survey insight focuses on a key theme/question (for example: mobile usage) and is supported by data derived from the survey results.\n\n## Challenges and what the future holds\n\nOur biggest challenge was transferring all our research reports into the [UXR Insights repository](https://gitlab.com/gitlab-org/uxr_insights). The team has collected a lot of data over the years, so it was a mammoth task. We never envisioned moving our research to an insights repository when we originally wrote and formatted our reports. Retrospectively adding insights means we’ve had to make some compromises; we haven’t always been able to use the insight structure that we want to use going forward.\n\nA second challenge is training new and existing members of the UX department how to use the insights repository. We believe [everyone can contribute](\n/company/mission/#mission). The UX Research team are not gatekeepers to research. We want everyone to be able to conduct research effectively and to be able to accurately add their findings to the insights repository. As a starting point, we’ve added [templates](https://docs.gitlab.com/ee/user/project/description_templates.html) to the repository that guide users through the process of adding insights.\n\nWe decided to keep our insights separate from the GitLab CE and EE projects, which is where our Product and UX/Product Design teams typically work. Not all of our insights are necessarily actionable right away – sometimes more evidence is required (especially with the gems we unintentionally discover during our studies). We needed a place where we could store and share these insights, while continuing to discuss and research them. The UXR Insights repository is within the [GitLab.org group](https://gitlab.com/gitlab-org), meaning that product managers who create [issue boards at a group level](https://docs.gitlab.com/ee/user/project/issue_board.html#group-issue-boards) to manage their workflow can simply add an insight to their board when they are ready to act on it. Or they can [cross-link](https://docs.gitlab.com/ee/user/project/issues/crosslinking_issues.html#crosslinking-issues) to the insight in a supporting issue or epic.\n\nThis is our first iteration of the UXR Insights repository. We expect improvements will be required along the way, and the UX team is planning to review how the repository is working after 90 days. However, early signs indicate that (unsurprisingly) no UX researchers are missing writing reports!\n\nCover image by [chuttersnap](https://unsplash.com/photos/Y94yKEyNjVw) on [Unsplash](https://unsplash.com)\n{: .note}\n","engineering",[682,9],{"slug":790,"featured":6,"template":686},"building-a-ux-research-insights-repository","content:en-us:blog:building-a-ux-research-insights-repository.yml","Building A Ux Research Insights Repository","en-us/blog/building-a-ux-research-insights-repository.yml","en-us/blog/building-a-ux-research-insights-repository",{"_path":796,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":797,"content":803,"config":812,"_id":814,"_type":13,"title":815,"_source":15,"_file":816,"_stem":817,"_extension":18},"/en-us/blog/collaboration-in-product-planning",{"title":798,"description":799,"ogTitle":798,"ogDescription":799,"noIndex":6,"ogImage":800,"ogUrl":801,"ogSiteName":672,"ogType":673,"canonicalUrls":801,"schema":802},"Successful collaboration approaches in product planning","Collaboration can be hard, but we've found a few tips and tricks that help us succeed here at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","https://about.gitlab.com/blog/collaboration-in-product-planning","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Successful approaches for team collaboration between Design, Product, Engineering, and Quality\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jason Yavorska\"}],\n        \"datePublished\": \"2020-06-03\",\n      }",{"title":804,"description":799,"authors":805,"heroImage":800,"date":807,"body":808,"category":764,"tags":809},"Successful approaches for team collaboration between Design, Product, Engineering, and Quality",[806],"Jason Yavorska","2020-06-03","\nWithin the CI/CD sub-department here at GitLab we've been focusing on improving collaboration between each of the internal teams that contribute to our success as we move through our [product process](/handbook/product-development-flow/): Design, Product, Writing, Quality, and Engineering. We've noticed a few key points that really seem to make a big difference: \n\n## Team collaboration: Understand the problem you're trying to solve early\n\nTry to recognize early when you don't understand the problem to solve, or if there's disagreement. And even when you think you have the solution, test it out a bit and explore some edge cases (or you'll have to loop back around again). As an important benefit, a good understanding of the problem to solve will help you come up with the [smallest but valuable iteration](https://handbook.gitlab.com/handbook/values/#iteration).\n\n### Don't make it one person's job to lead the way or get things started\n\nWe expect an active contribution from everyone on the team around defining the problem and coming up with the solution for it. Everyone has an [important role to play](/handbook/product/product-processes/#pm-em-ux-and-set-quad-dris) - Product Manager, Product Designer, Quality, and Engineering. \n\nWhile Product Managers should be able to clearly articulate why something is prioritized, they should not be seen as the only facilitator of product advancement. It's a team effort, and everyone at GitLab is expected to be a [manager of one](https://handbook.gitlab.com/handbook/values/#managers-of-one). \n\n### Take advantage of everyone's different expertise\n\nSometimes, a bit of research will really align to one area of expertise. Maybe there's a business opportunity for the Product Manager, a complex visualization of data for the designer, or a hard technical challenge for the engineer - each of these can cause that person to go off and lead the way for that aspect. But they should have the support of the rest of the group. In all other cases, understanding the problem and coming up with a solution (whether using the product validation flow or just informally in an issue) is a team effort, and everyone is equally important.\n\nFollowing these principles will help your team both build trust and learn to recognize when more analysis is needed instead of pushing ahead too early. It will also help you to achieve more than any one person can do on their own.\n",[9,723,810,766,811],"testing","collaboration",{"slug":813,"featured":6,"template":686},"collaboration-in-product-planning","content:en-us:blog:collaboration-in-product-planning.yml","Collaboration In Product Planning","en-us/blog/collaboration-in-product-planning.yml","en-us/blog/collaboration-in-product-planning",{"_path":819,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":820,"content":826,"config":833,"_id":835,"_type":13,"title":836,"_source":15,"_file":837,"_stem":838,"_extension":18},"/en-us/blog/collaboration-techniques-for-distributed-teams",{"title":821,"description":822,"ogTitle":821,"ogDescription":822,"noIndex":6,"ogImage":823,"ogUrl":824,"ogSiteName":672,"ogType":673,"canonicalUrls":824,"schema":825},"Synchronous collaboration for async distributed teams","The strategic exercise supported meaningful reflection as well as alignment in setting goals.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682962/Blog/Hero%20Images/collaboration-techniques-blog-post.jpg","https://about.gitlab.com/blog/collaboration-techniques-for-distributed-teams","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How a Lightning Decision Jam helped our asynch, distributed team collaborate synchronously\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amelia Bauerly\"}],\n        \"datePublished\": \"2022-01-19\",\n      }",{"title":827,"description":822,"authors":828,"heroImage":823,"date":830,"body":831,"category":680,"tags":832},"How a Lightning Decision Jam helped our asynch, distributed team collaborate synchronously",[829],"Amelia Bauerly","2022-01-19","\nIn a remote, asynchronous company, is there ever a time when teams need to collaborate synchronously? \n\nWe recently asked ourselves that question on the Monitor team. It had been three years since we started thinking about how to build out Incident Management as a team, and a lot had happened in that time. We’d built out a range of new features and created the broad outlines for a complete incident management workflow with GitLab. We’d achieved a lot.\n\nWe had also been through a number of changes as a team, and we had several possible paths ahead of us. It felt like an appropriate moment to step back and take stock of where we’ve been, what we’ve done, and where we still need to go. However, given our team's geographical distribution, we realized we needed to think creatively about how best to create space for reflection as a team.\n\n## Opting for a Lightning Decision Jam\n\nOutside of regularly scheduled team meetings, our team adheres to the standard GitLab practice of prioritizing [asynchronous communication](/handbook/communication/asynchronous-communication). Because our team is distributed around the world, this model usually works great for us. But, given the amount of time that had passed since we had all gathered together, this time around, we decided it might actually be nice to gather synchronously.\n\nOwing to the time zone differences we'd face, we wouldn’t have a lot of time together. We needed to find a structure that would allow us to do some reflection as a team in a limited amount of time. \n\nEnter: [Lightning Decision Jam](https://uxplanet.org/lightning-decision-jam-a-workshop-to-solve-any-problem-65bb42af41dc). \n\nA Lightning Decision Jam (LDJ) is a quick way for teams to come together to collaboratively identify problems and challenges, and then work together to ideate on solutions for those challenges – all in one hour. This format would give us space to check in with each other as a team about the work that we’ve been doing, while keeping those discussions constrained in a way that would (hopefully) respect the fact we’d all be gathering at different times in our days. \n\n## How the LDJ worked?\n\nWe hosted the session on [Zoom](https://zoom.us), and a majority of our team members were able to join the call synchronously. We met with the team members unable to join prior to the main LDJ session so they could participate as well. We also recorded the session so they could review the larger discussion afterward. We used [Mural](https://www.mural.co/) to collaborate during the session. \n\nThe session itself involved a series of time-boxed, individual brainstorming exercises, where each team member generated sticky notes in response to a prompt. Some of the brainstorming exercises included questions like:\n\n- What is moving us forward?\n- What’s gone well?\n- What are the challenges that are holding us back?\n- How might we address those challenges?\n\nAfter each person generated their sticky notes, the ideas were shared with the group. After all the ideas were shared, we used [dot voting](https://www.nngroup.com/articles/dot-voting/) to surface the ideas that had the most traction within the group. \n\n## What the LDJ taught us\n\nThere were a few things we observed as we conducted this exercise as a team. \n\nAt GitLab, we work in a monthly cadence. We have a large backlog of features to implement, and an ever-growing list of things to improve. All of these factors, taken together, can make it easy to focus on the things that aren’t yet where we'd like them to be, or that still need to be done.\n\nThat being the case, simply taking some time to reflect on what we’ve done well was a worthwhile exercise. Holistically thinking about what we’ve built over the past few years and taking a moment to pause and celebrate the things that we’d achieved as a team was a beneficial thing for us to do together. \n\nSpending time thinking about the main challenges we face as we move forward was also a useful exercise. Importantly, though, we didn't just focus on the challenges; we also spent time ideating on solutions and voting together, as a team, on which solutions seemed the most meaningful to action. These additional steps helped us to re-align and re-focus on the path ahead.\n\nOf course, we could have done some reflection on these topics outside of an in-person, synchronous session. The benefit of doing this as part of the LDJ was that we all got to spend some time together as a team, brainstorming and collaborating in real-time. Especially now, due to the global circumstances and the pandemic more generally, being able to see, hear, and spend time with each other has a certain intrinsic value, especially in terms of team cohesion. Furthermore, the strict structures of the LDJ meant that we could spend some time discussing these topics in a focused way. While we didn’t get to discuss everything as thoroughly as we would have liked, it at least gave us space and the opportunity to start the conversation.\n\n## What’s next? \n\nThe result of the LDJ was a set of GitLab issues that outline the opportunities we identified. These issues already have ideas attached to them that have been vetted by the team, so they are immediately actionable. The hope is that we can start experimenting with the ideas we've generated in upcoming milestones, and that these ideas will help us address our larger goal of increasing the number of people using our features.\n\nWe also conducted an asynchronous [plus-delta exercise](https://www.lucidmeetings.com/glossary/plus-delta) to identify opportunities for improving similar sessions in the future. In particular, there was interest in conducting the entire LDJ asynchronously, so everyone can participate at their leisure, perhaps having team members spend 5-10 minutes on five consecutive days to complete all of the exercises independently. This may also give people the room to reflect on the questions more deeply than we can do in a live, in-person session.\n\nMy hope, though, is that this is just the first of these kinds of collaborative workshops that we can do as a team. Experimenting with different ways of thinking about problems, and different ways of interacting, should help keep us feeling aligned and engaged with the path ahead. It also gives everyone a chance to have a voice in what we do, which, for me, may well be the most important thing.\n\nCover image by [MaxBender](https://unsplash.com/photos/iF5odYWB_nQ) on [Unsplash](https://unsplash.com)\n",[9,811,683],{"slug":834,"featured":6,"template":686},"collaboration-techniques-for-distributed-teams","content:en-us:blog:collaboration-techniques-for-distributed-teams.yml","Collaboration Techniques For Distributed Teams","en-us/blog/collaboration-techniques-for-distributed-teams.yml","en-us/blog/collaboration-techniques-for-distributed-teams",{"_path":840,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":841,"content":847,"config":856,"_id":858,"_type":13,"title":859,"_source":15,"_file":860,"_stem":861,"_extension":18},"/en-us/blog/creating-a-dark-ui-for-gitlabs-web-ide",{"title":842,"description":843,"ogTitle":842,"ogDescription":843,"noIndex":6,"ogImage":844,"ogUrl":845,"ogSiteName":672,"ogType":673,"canonicalUrls":845,"schema":846},"How we created a dark UI for GitLab's Web IDE","The Web IDE now has a Dark Mode, and we've put together a few learnings from a design perspective.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669611/Blog/Hero%20Images/ide-dark-post-banner.png","https://about.gitlab.com/blog/creating-a-dark-ui-for-gitlabs-web-ide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we created a dark UI for GitLab's Web IDE\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Marcel van Remmerden\"},{\"@type\":\"Person\",\"name\":\"Jeremy Elder\"}],\n        \"datePublished\": \"2020-05-20\",\n      }",{"title":842,"description":843,"authors":848,"heroImage":844,"date":851,"body":852,"category":787,"tags":853},[849,850],"Marcel van Remmerden","Jeremy Elder","2020-05-20","\n\nOne of the most popular and exciting feature requests we often hear about from our amazing community is a [dark mode for the entire GitLab UI](https://gitlab.com/gitlab-org/gitlab/-/issues/14531). It's currently the second most upvoted issue for all of GitLab.\n\nNext to being very popular in the design and development world, a dark mode can be incredibly helpful for users with vision impairments. One of our community members posted this comment, that demonstrates very well how valuable it can be to give users the chance to choose between a light and a dark mode:\n\n> It really comes down to website accessibility. I am legally blind and part of my eye condition is something called photophobia (which is poorly named—it's not a \"fear\" of light, it's that direct bright lights, especially sudden direct bright lights, are like having an ice pick shoved into my eyeballs.)\n\nAt GitLab, we believe in small changes and fast iterations. When our Design team was thinking about how we could split this up and tackle it in small steps, we looked for isolated pieces of our UI that we could create a dark mode for, and the feature that stood out was the [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#web-ide).\n\n## What is the Web IDE?\n\nThe Web IDE (Integrated Development Environment) is a code editor in the browser that allows you to change multiple files at once. Afterwards, you can commit their changes to a branch and create merge requests to discuss those changes and eventually merge them.\n\n![GitLab Web IDE](https://about.gitlab.com/images/blogimages/ide-dark-light-mode-browser.png){: .center}\nThe GitLab Web IDE\n{: .note.text-center}\n\nUsers of the Web IDE find it to be helpful for quickly making small changes or easily viewing their files in a familiar context, similar to their appearance in a local editor.\n\n### Syntax highlighting\n\nAfter deciding the Web IDE would be the first feature of the GitLab user interface (UI) to get a dark mode, we faced one fundamental question: How would the dark mode align with syntax highlighting themes already within GitLab? There are several themes that users may choose to display their repository files, snippets, or other code elements in their preferred way.\n\n![User syntax settings](https://about.gitlab.com/images/blogimages/ide-dark-syntax.png){: .center}\nUser syntax highlighting theme settings\n{: .note.text-center}\n\nThe Web IDE exists as a tool within the larger context of GitLab. Similarly, the syntax themes exist within the context of the Web IDE. Our goal was to avoid scenarios where the code area that follows the syntax highlighting theme wouldn't be aligned with the rest of the UI, which could be jarring.\n\nWe made the decision to keep the settings easily consumable, and treat the dark mode for the Web IDE UI as an extension of the dark syntax highlighting theme. From version 13.0 on, you can enable it by selecting the dark syntax highlighting theme, and the rest of the Web IDE will automatically follow. This also gives us the opportunity to later extend other themes and align the rest of the Web IDE UI to their colors.\n\n## The design process\n\n### Light and dark UI vs. themes\n\nInitially, we defined a few concepts to help shape our approach. We refer to light and dark UI in terms of the qualities they have, like brightness, depth, structure, and hierarchy. In GitLab, themes are preferential styles that reside on the UI, and use color to change only the appearance of a few elements.\n\n![UI versus themes](https://about.gitlab.com/images/blogimages/ide-dark-ui-vs-themes.png){: .center}\nThe difference between the UI and themes in GitLab\n{: .note.text-center}\n\n### Working in Figma\n\n#### Figma community\n\nAs soon as we wanted to start experimenting with the UI, we noticed first hand that \"Everyone can contribute\" is not only GitLab's core mission, but also an idea that is very much alive in the Figma community. The amazing designers at Microsoft have open-sourced a [design toolkit for Visual Studio Code](https://www.figma.com/community/file/786632241522687494) that allowed us to easily grab the relevant pieces, plug them into our own design file, and manipulate them.\n\n#### Asynchronous feedback\n\nAnother aspect that's deeply embedded in GitLab's ways of working and the way we build our products is asynchronous collaboration. We are the largest all-remote company in the world, and the two designers working on this feature are located in time zones seven hours apart.\n\nUsing Figma to collaborate and give each other feedback on our ideas enabled us to ship this feature with only having to schedule a single meeting, and the rest of the discussions handled via Figma comments. As these discussions were between designers and purely around visual aspects, we kept the discussion inside of Figma instead of using our own [Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html) features, which came into play later during the discussions with the engineer working on this feature. It also allowed us to easily involve a lot of other team members, and get comments from other designers all over the globe.\n\n![A comment thread in Figma](https://about.gitlab.com/images/blogimages/ide-dark-async-thread.png){: .center}\nAsync design feedback in Figma\n{: .note.text-center}\n\n### Design challenges\n\nThe overarching design challenge was, and continues to be, understanding how the appearance of elements change as they appear in light vs. dark UI. Generally, structural, container-like UI elements decrease brightness, but content works the opposite and is sometimes nearly inverted. The fundamentals of light, shadow, and depth don't change, but the way the elements leverage them does. Similarly, the principles of content legibility, hierarchy, and contrast don't change, but the content does to uphold those principles.\n\nIn the side-by-side example below, we've compared just a few UI elements to demonstrate how they could change between light and dark UI.\n\n![Comparing light and dark UI in the Web IDE](https://about.gitlab.com/images/blogimages/ide-dark-comparison.png){: .center}\nComparing light and dark UI in the Web IDE\n{: .note.text-center}\n\nWhen we map the changes in this small sample, patterns start to emerge. Elements like backgrounds evenly shift darker together to maintain the same sense of depth, while some text content nearly inverts, and the button almost stays the same.\n\n![Colors mapped between light and dark UI](https://about.gitlab.com/images/blogimages/ide-dark-mapping-fade.png){: .center}\nMapping element color in light and dark UI\n{: .note.text-center}\n\nAt face value, it can seem as though many elements are inverted, but that's an oversimplification that leads to an interface looking not quite right. Here's how we're thinking about a few of the specific design challenges we encountered.\n\n#### Stateful elements\n\nIn a light UI, we darken element states to increase contrast, and typically do the opposite in a dark UI. This wasn't the case for tabs and similar elements that have backgrounds more closely integrated into other sections of the UI. And while the borders on the buttons got lighter, the background didn't because we needed to maintain text contrast.\n\n![Button and tab states in light and dark UI](https://about.gitlab.com/images/blogimages/ide-dark-states.png){: .center}\nComparing element states in light and dark UI\n{: .note.text-center}\n\nThis uncovers nuanced differences in the approach between dark and light UI, and we're still ratifying differences and establishing repeatable patterns. Needless to say each element deserves plenty of attention.\n\n#### Visual hierarchy and depth\n\nAs mentioned above, depth in dark mode was generally approached in the same way as in a light UI. Brighter elements are more forward, and darker ones recede. In the case of tabs and the file tree we are using a different approach and making these areas darker to increase contrast, rather than evenly darkening layers. We're learning that depth and contrast can both be effective tools, but they aren't always used the same in dark and light UI.\n\nA quick note on shadows, they shouldn't be replaced with glows — a completely different effect. Shadows are noticeably less effective in dark mode, so we explored more variance in gray backgrounds for neighboring sections.\n\n#### Graphics and illustration\n\nGraphics created for a light UI can seem garish or out of place in a dark UI. Images should be addressed on a case-by-case basis, but illustrations and icons can be addressed as a whole. We're exploring CSS variables and classes for SVG fill and path colors. One example that we had to solve were pipeline status icons. These exist in a couple of places in our product and initially had a white background. As this makes them stand out too much in dark mode, we had to rewrite their SVG code to get them to be transparent instead.\n\n![Icons with and without background fill changes](https://about.gitlab.com/images/blogimages/ide-dark-pipeline-icons.png){: .center}\nEnsuring that graphics, like icons, can be adjusted too\n{: .note.text-center}\n\nWith that in place we could map light and dark palettes. For now we're just ensuring that there aren't backgrounds in SVGs that feel out of place.\n\n#### How to ship in small pieces\n\nOur philosophy is to release changes or features as soon as they can help users. This sometimes leads to us shipping features that are not completely polished, which is in line with this [famous quote by Reid Hoffmann](https://twitter.com/reidhoffman/status/847142924240379904?lang=en), the founder and CEO of LinkedIn:\n\n> If you're not embarrassed by the first version of your product, you've launched too late.\n\nThe first version of this feature we released had only the code area styled with the dark syntax highlighting theme. Even though it felt a bit out of place, we received good feedback, which was evidence we were headed in the right direction.\n\n![MVC dark mode with light file tree](https://about.gitlab.com/images/blogimages/ide-dark-first-version.png){: .center}\nMVC dark mode with light file tree\n{: .note.text-center}\n\nFrom that point on, we sliced the remaining UI into smaller pieces. Every time we finished a piece, we released the newest version to all our users and started working on the next area. This highly iterative approach would not be acceptable in a lot of other companies, but at GitLab we believe in minimal viable changes ([MVC](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc)).\n\nAnother thing we learned was that a dark mode exposed not only structural UI deficiencies, but also inflexible code. Our initial intention was to leave a couple of seldom visited areas unstyled, but we noticed that keeping CSS styles from bleeding over into these areas would cause more problems and effort than fixing it altogether.\n\n#### Effective prototyping\n\nAs demonstrated in the previous paragraphs, one of the toughest challenges when designing a dark mode are elements with multiple states. This is also one of the aspects designers are still struggling with when prototyping, which led to us tackling this problem in a couple of ways:\n\n- Creating a large prototype with many artboards to represent edge cases and states\n- Relying heavily on a well-defined color system\n- Multiple sync calls with an engineer to fix smaller aspects, e.g., animations on the fly\n\nFor the next iteration of the prototype, we are going to investigate whether we can leverage Figma's components in a way that buttons have the same hover/focus/active states on multiple artboards. We have set up a [first small test](https://www.figma.com/proto/SvimjjirW0pkn69TNBztU9/Button-state-example?node-id=1%3A3&scaling=min-zoom) to prove that it would be possible, but haven't used it on a more complex prototype yet.\n\n![Web IDE Figma prototype](https://about.gitlab.com/images/blogimages/ide-dark-prototype-lg.png){: .center}\nWeb IDE prototype in Figma to demonstrate states\n{: .note.text-center}\n\n## What we learned so far\n\n- Answering questions for dark mode leads to many questions about why we're doing things a certain way in a light UI. It creates a great circular effect that challenges how we think about the entire UI, which leads to solid convictions.\n- Even a dark mode can be worked on in small iterations. Over the course of this process, we have created dark versions for all Web IDE specific UI elements, but also for dropdowns and modals, which are global elements. This not only makes it easier for us to think about the design, but also about how the code should be structured for a global dark mode.\n- We are clearly standing on the shoulders of giants. Designing and developing this dark mode at such a fast pace was only possible because we had many great in-depth resources about dark mode available to us. The two that stood out the most are [Apple's Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/dark-mode/) and the dark theme section from [Material Design](https://material.io/design/color/dark-theme.html).\n\n![Web IDE dark mode](https://about.gitlab.com/images/blogimages/ide-dark-loop.gif){: .center}\nWeb IDE dark mode\n{: .note.text-center}\n\n### Next steps\n\n- For the Web IDE as a feature, we're in the process of making our code more easily themable, so that other syntax highlighting themes can be extended more flexibly.\n- We're also planning to clean up the prototype we created, and either create a Web IDE UI Kit, or integrate it into our Pajamas design system, so that others can easily access, modify, and contribute to it.\n\nLastly, you can contribute too! We would especially love to see contributions to extend the other syntax highlighting themes to the rest of our Web IDE UI. If you have anything else in regards to the Web IDE you'd like us to consider, [create a new issue](https://gitlab.com/gitlab-org/gitlab/issues/new) and be sure to tag the GitLab UX Department (@gitlab-com/gitlab-ux). If you'd like to be part of our testing efforts at any level, sign up for our [GitLab First Look](/community/gitlab-first-look/) program. You can also [contribute](https://gitlab.com/gitlab-org/gitlab-design/-/blob/master/CONTRIBUTING-Figma.md) to the design of GitLab by starting with our [Pajamas UI Kit](https://www.figma.com/community/file/781156790581391771) in Figma.\n",[854,682,9,855],"webcast","workflow",{"slug":857,"featured":6,"template":686},"creating-a-dark-ui-for-gitlabs-web-ide","content:en-us:blog:creating-a-dark-ui-for-gitlabs-web-ide.yml","Creating A Dark Ui For Gitlabs Web Ide","en-us/blog/creating-a-dark-ui-for-gitlabs-web-ide.yml","en-us/blog/creating-a-dark-ui-for-gitlabs-web-ide",{"_path":863,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":864,"content":870,"config":877,"_id":879,"_type":13,"title":880,"_source":15,"_file":881,"_stem":882,"_extension":18},"/en-us/blog/deep-dive-into-gitlabs-ux-design-process",{"title":865,"description":866,"ogTitle":865,"ogDescription":866,"noIndex":6,"ogImage":867,"ogUrl":868,"ogSiteName":672,"ogType":673,"canonicalUrls":868,"schema":869},"A deep dive into GitLab's UX design process","The UX team shares how they communicate, plan, share, and tackle improvements one iteration at a time.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678759/Blog/Hero%20Images/designwebcast.jpg","https://about.gitlab.com/blog/deep-dive-into-gitlabs-ux-design-process","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A deep dive into GitLab's UX design process\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-09-05\",\n      }",{"title":865,"description":866,"authors":871,"heroImage":867,"date":873,"body":874,"category":787,"tags":875},[872],"Suri Patel","2018-09-05","\nThe [UX team](/handbook/product/ux/#ux-at-gitlab) recently gathered to share\nhow they collaborate in a fully remote environment. Our team of two UX researchers\nand nine UX designers spans eight countries and six time zones. In this webcast,\nthey discussed UX research, community contributions, and hiring, making it an\nexcellent resource in helping you learn more about\n[GitLab design](https://gitlab.com/gitlab-org/gitlab-design/#gitlab-design).\n\n### Watch the webcast\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/6R64hHkkgtE\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## What we covered\n\nThe UX team generously provided insight into their workflow and projects. Below\nare a few of our favorite takeaways.\n\n### Iteration\n\nAt GitLab, [iteration](https://handbook.gitlab.com/handbook/values/#iteration) means making the smallest\nthing possible and getting it out as quickly as possible, helping us reduce the\ncycle time and rapidly get feedback from users so that we can continue to improve\nquickly and efficiently. Planning too far ahead without getting real-world\nfeedback can cause you to build something that doesn't meet user needs.\n\n### UX Research\n\nThe goal of UX research is to understand the needs and concerns of users, often\nby observing how they interact with a product or by gathering data through\nvarious methods. At GitLab, we often use survey research, feasibility testing,\nuser interviews, and card sorting to understand our users. We discuss the\nresults with product managers to help us prioritize feedback and determine the\nnext steps to implement the findings.\n\n### GitLab Design System\n\nOne of the team's major initiatives last year was  the\n[GitLab Design System](https://design.gitlab.com/), which\nincludes content guidelines, usability patterns, foundational styles, and reusable\ncomponents. The team shifted its focus towards system thinking to create\nconsistency throughout the product and predictability across experiences. The UXers\nhave been working closely with our frontend team to implement our system\niteratively.\n\nEvery designer writes usage guidelines during every milestone and\npicks at least one issue within the issue tracker to contribute to the project.\nThe design system is open source, just like the rest of GitLab, so everyone is\nencouraged to question any of the decisions we've made or contribute by making\nthings clearer or adding missing content.\n\n### How you can contribute to GitLab’s UX designs\n\nAs an open source company, we believe in transparency, so we share almost\neverything we do, including source files, artifacts, deliverables, case studies,\n[UX research](https://gitlab.com/gitlab-org/ux-research#research-archive), and\nour findings. Being open source allows the community to learn from us, and for\nus to learn from the community. There are issues that have been\nlabeled '[Accepting merge requests](https://gitlab.com/gitlab-org/gitlab-ce/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Accepting+merge+requests&label_name[]=UX)'\nand they need some UX work. Most of these are very small issues, making them the\nperfect starting point for first-time contributors. If you have an idea for a UX\nimprovement, we encourage you to create an issue using the feature proposal\ntemplate to describe the problem you're trying to solve and your proposed solution.\n\nOur UX researchers encourage community contributions, so if you're interested\nin exploring a research question, you're welcome to create an issue using a\nsearch proposal template in the\n[UX research project](https://gitlab.com/gitlab-org/ux-research#contributing).\nIf you’d like to help shape the future of GitLab, we’d love to invite you to\njoin [GitLab First Look](/community/gitlab-first-look/).\n\nThe UX team is happy to chat with you about your contribution,\nand we'll try to get back to you as soon as we can.\n\n### Join us!\n\nOur UX team is growing, and we'd love to work with you! We're currently looking\nfor three UX designers with an interest in our products. So, whether that's the\ndevelopment side or the operations side, we have a lot going on, and we have\nsomething for everyone. We're recruiting for specific teams, including Release\nand Verify, Monitor, and Secure teams. If you're interested in working with our\ntalented (and fun!) UX team, we encourage you [to apply](/jobs/)!\n\n[Cover image](https://unsplash.com/photos/MGBgTX1Zmpo) by [Chris Barbalis](https://unsplash.com/@cbarbalis), licensed\nunder [CC X](https://unsplash.com/license).\n{: .note}\n",[876,682,854,9],"inside GitLab",{"slug":878,"featured":6,"template":686},"deep-dive-into-gitlabs-ux-design-process","content:en-us:blog:deep-dive-into-gitlabs-ux-design-process.yml","Deep Dive Into Gitlabs Ux Design Process","en-us/blog/deep-dive-into-gitlabs-ux-design-process.yml","en-us/blog/deep-dive-into-gitlabs-ux-design-process",{"_path":884,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":885,"content":891,"config":896,"_id":898,"_type":13,"title":899,"_source":15,"_file":900,"_stem":901,"_extension":18},"/en-us/blog/designing-alerts-and-incidents",{"title":886,"description":887,"ogTitle":886,"ogDescription":887,"noIndex":6,"ogImage":888,"ogUrl":889,"ogSiteName":672,"ogType":673,"canonicalUrls":889,"schema":890},"Designing an incident management workflow from scratch and where its used","See here how to create a single workflow for triaging alerts and resolving incidents using GitLab's Product Development Flow","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670750/Blog/Hero%20Images/designing-incidents-alerts.jpg","https://about.gitlab.com/blog/designing-alerts-and-incidents","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Designing an incident management workflow from scratch and where its used\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Amelia Bauerly\"}],\n        \"datePublished\": \"2020-11-03\",\n      }",{"title":886,"description":887,"authors":892,"heroImage":888,"date":893,"body":894,"category":764,"tags":895},[829],"2020-11-03","\n{::options parse_block_html=\"true\" /}\n\n\n\nMany companies stitch together multiple tools to handle alerts and incidents, which can be time-consuming and frustrating. Why should teams have to use so many tools for what is, essentially, a single workflow?\n\nWe hear you, and we think we’ve come up with some great new features to help alleviate this problem. \n\nAt GitLab, the Monitor team has been busily working behind the scenes to improve our offerings for [Alerts](https://about.gitlab.com/releases/2020/06/22/gitlab-13-1-released/#manage-it-alerts-in-gitlab) and [Incident Management](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#create-and-manage-it-incidents-in-gitlab). \n\n## What’s changed? \n\nYou can now send alerts from your monitoring tools straight to GitLab, where they will be displayed for you and your team to review. If an alert is serious enough, you can escalate that alert to an incident, a newly defined type of issue crafted specifically for this purpose. Once the incident is created, you can push the fixes immediately: all within a single tool.\n\nWe’re incredibly proud of what we’re creating but, how did we get here? How did we take what was a blank space and turn it into something that people could use? Dare I say, might even _want_ to use? \n\nThe short answer: by working through GitLab’s [Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/), by leaning on our value of [iteration](https://handbook.gitlab.com/handbook/values/#iteration), and collaborating closely with the people who use GitLab every day.\n\n## Validating the problem\n\nThe first thing we needed to do was to ensure we understood what people were struggling with, in their current workflow, with their current tools. We call this [Problem Validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation), and it means asking the following question before getting started with any work: Do we clearly understand the problem(s) end-users have?\n\nAs part of the problem validation process, we reached out to Developers, SREs, and [DevOps](/topics/devops/) engineers. We wanted to better understand what tools they were using, what their current workflows were, and if there were any gaps in their workflows that we could fill within GitLab.\n\nThrough our research, we discovered something that was both a serious pain point  _and_  an opportunity for us at GitLab. Unsurprisingly, it turns out that many Developers are currently stitching together a multitude of tools for monitoring their applications, for creating and sending alerts, and for investigating and resolving the issues that are reported. \n\nStitching together all of these tools can work, but it’s messy for teams to manage. The context switching that’s required is difficult, and it means having to keep track of different pieces of information in multiple places. We heard, again and again, how burdensome and fatiguing this can be. What people need, instead, is an intentionally designed workflow for triaging alerts and responding to incidents. \n\nLuckily for us, GitLab already had many pieces of this workflow in place, in that Developers can currently raise issues, create merge requests, and deploy their code within our product. The opportunity, and what we were missing, was a place to review and triage alerts. \n\nIf we could introduce a single location where all alerts (from multiple tools) can be received, reviewed, resolved, or escalated into incidents, we could create a seamless incident management workflow within GitLab: from the alert being received to the incident being created, all the way through to the code fix being deployed.\n\n## Validating the solution\n\nWith the desired workflow pinned down, we started ideating on designs for triaging and managing alerts. After creating some initial concepts, we wanted to validate them to make sure we were actually solving the problems we had identified. \n\nFollowing our Product Development Flow for [solution validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-4-solution-validation), we wanted to share our designs with the teams we thought would most benefit from using the features we designed. \n\nTo enable us to more quickly connect with the people who would be using our features, we decided to create a Special Interest Group (SIG). We went this route because we wanted to work more collaboratively with a well-defined group of people over a period of time. We felt that this could help us to understand their needs better, and it would mean we could check in with them more often, and on a more regular basis. \n\nThe SIG is composed of GitLab customers who are involved with responding to alerts and incidents within their organizations. To recruit this group, we sent out a survey to our [First Look](https://about.gitlab.com/community/gitlab-first-look/) members. When we had a short list of people who fit our criteria, we scheduled introductory meetings to learn more about them, find out how they worked, and explain a bit more about the SIG. After ensuring they were on board with our experiment, we invited them to join our SIG.\n\nAs we generated designs – first for an alert list, then for an alert detail page – we shared these designs with the SIG members during live, individual feedback sessions. During these sessions, we asked them to take a short usability test where we gave them an imagined scenario and asked them to complete a task. We also asked them for their feedback more generally, to understand if what we were proposing would help improve their current workflow. \n\nWe met with the SIG monthly over a period of several months. Each time they reviewed our designs, we revised them. The feature set we ultimately arrived at owes a great deal to their feedback and their commitment to improving GitLab as a product. \n\n![Alert list in GitLab](https://about.gitlab.com/images/blogimages/Alert-list-page.png){: .shadow.medium.center}\n\nAlert list in GitLab\n{: .note.text-center}\n\nAfter validating our proposals with the SIG members we broke our designs down into what we call a [Minimal Viable Change](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc) (MVC) that, over the course of several months, our engineering team built into GitLab: starting with the alert list, and then adding in the alert detail page. Additional functionality, such as the ability to change the status of an alert from within GitLab, was built on top of those two base elements.\n\n## Introducing dedicated incidents\n\nMany alerts that are sent are not necessarily things that teams need to worry about. Maybe they are expected issues, or maybe they aren't things that need to be immediately addressed. But, what happens when an alert is serious enough to require additional investigation? What happens when the alert needs to become an incident?\n\nFor the [MVC](https://about.gitlab.com/handbook/product/ux/product-designer/#refine-mvc) version of alert management, alerts would be received and, if they were serious enough, the alert could be escalated to a GitLab issue. \n\nWe used our existing issue framework for incidents because it was an easy way for us to complete the larger workflow. From a GitLab issue, people can create an MR to fix whatever is causing the alert in the first place. Then they can push the code that will publish the fix. So, by using issues, we were able to approximate a full incident management workflow: from alert receipt to live code.\n\nHowever, in testing the alerting functionality we had built with our SIG, we learned that there were still many gaps in the experience of investigating and resolving incidents that issues couldn’t really help us fix. \n\nFor example, within incidents, you likely need quick access to various metrics or runbooks. Maybe you also need an incident timeline. There are hacky ways of making GitLab issues work for these purposes, but we wondered, \"Is there a way that we can better surface the information needed for quickly resolving incidents within issues?\"\n\nThese sorts of discussions ultimately resulted in us introducing dedicated incidents in GitLab. Incidents are a special kind of issue where the content displayed is updated to better fit the needs of people actively involved in investigating and resolving incidents. \n\nIn designing incidents, we removed items from our existing issues that were less relevant, replacing them with content that better fits the incident workflow. In both cases, we used feedback from customers to make decisions about what to include – and what to exclude. Our goal was to make sure that only the most relevant information is visible, so that incidents can be resolved as quickly and efficiently as possible.\n\n![An example dedicated incident in GitLab](https://about.gitlab.com/images/blogimages/dedicated-incident.png){: .shadow.medium.center}\n\nAn example dedicated incident in GitLab\n{: .note.text-center}\n\nCreating a dedicated type of issue for incidents hasn’t been a quick process! By relying on our iteration value, we’ve been slowly transforming the GitLab issue into an incident over the course of many months. Now, incidents are finally taking shape, and we are at the point where people have started using them as part of their workflows. **We’ve seen an increase in usage of 4,200%!**\n\nThis is a huge step for incident management at GitLab, and we’re delighted to see how people will use incidents at their organizations.\n\n## Up next: On-call Management\n\nThe final piece of incident management is on-call management: How does your team know that incidents are happening and need to be addressed? \n\nTo tackle this next batch of work, we’re going back to our Product Development Flow’s [Problem Validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation) step. We’re talking to people to ensure we understand their needs. Then we’ll start to think about designs for on-call schedules, escalation policies, and paging. We intend to build and release these features early next year. \n\nOnce these features are introduced, we will have enabled the end-to-end workflow for [incident management within GitLab](https://about.gitlab.com/direction/service_management/incident_management/), from triggered alerts through post-incident review. After that point, we’ll investigate how people are experiencing the features we’ve built and how we can further improve them. \n\nWe look forward to hearing your feedback, so we can continue to make incident management in GitLab even better. What do you want to see us build next? Leave a comment on the [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/271410) if you have any suggestions. Additionally, if you'd like to participate in our customer feedback sessions, consider joining our [First Look](https://about.gitlab.com/community/gitlab-first-look/) panel. We'd love for you to join us!\n\nCover image credit:\n\nCover image by [Kelly Sikkema](https://unsplash.com/@kellysikkema?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n",[682,9,876],{"slug":897,"featured":6,"template":686},"designing-alerts-and-incidents","content:en-us:blog:designing-alerts-and-incidents.yml","Designing Alerts And Incidents","en-us/blog/designing-alerts-and-incidents.yml","en-us/blog/designing-alerts-and-incidents",{"_path":903,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":904,"content":910,"config":915,"_id":917,"_type":13,"title":918,"_source":15,"_file":919,"_stem":920,"_extension":18},"/en-us/blog/designing-for-developers",{"title":905,"description":906,"ogTitle":905,"ogDescription":906,"noIndex":6,"ogImage":907,"ogUrl":908,"ogSiteName":672,"ogType":673,"canonicalUrls":908,"schema":909},"How to design for (and with) developers","UX Manager Sarrah Vesselov shares her thoughts on how to design for a developer audience.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679763/Blog/Hero%20Images/discovering_gitlabs_personas.jpg","https://about.gitlab.com/blog/designing-for-developers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to design for (and with) developers\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-08-17\",\n      }",{"title":905,"description":906,"authors":911,"heroImage":907,"date":912,"body":913,"category":680,"tags":914},[872],"2018-08-17","\n\nDesigners have a challenging task: Solve problems to empower users to do their\nbest work. To understand how designers balance the demands of their roles as\nproblem solvers with the evolving needs of an audience, I chatted with UX Manager\n[Sarrah Vesselov](/company/team/#SVesselov) about the considerations that go into designing for developers.\n\n#### How has designing for developers evolved over time?\n\n>“It has become more complex since developers are using tools to do multiple\nthings rather than a single thing.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/jbbH58ICs5o\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### How do you view developer feedback?\n\n>“Developers are as close to designers as you get. We’re all problem solvers.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/EJlOJurVjFI\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### How has Hacker News feedback changed GitLab’s design?\n\n>“Having a direct line to people who are using our product every day allows us to quickly iterate and make changes.\nWhen I’m talking to people on Hacker News, I link them to issues, and I really value their feedback.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/nfHB8HBEwxs\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### What do you consider when trying to create positive UX experiences for developers?\n\n>“It’s important to understand developers’ goals and motivations and what they’re trying to accomplish.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/I3lfB2yfslw\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### What’s the greatest challenge in designing for developers?\n\n>“Things keep getting more and more complex. Trying to make life easier for someone is a challenge.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/l7yXDXtg_hU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### What advice do you have for other designers who have developers in mind?\n\n>“Make allies out of the developers you work with to better understand the developers you’re designing for.”\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/oUrnGuSnNik\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n#### Interested in joining the UX team?\nOur incredible [UX team](/handbook/product/ux/) is rapidly growing, and we'd love to be your teammate! If\nyou'd like to design for a developer audience, please apply for one of our open\n[positions](/jobs/).\n",[9,682],{"slug":916,"featured":6,"template":686},"designing-for-developers","content:en-us:blog:designing-for-developers.yml","Designing For Developers","en-us/blog/designing-for-developers.yml","en-us/blog/designing-for-developers",{"_path":922,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":923,"content":929,"config":935,"_id":937,"_type":13,"title":938,"_source":15,"_file":939,"_stem":940,"_extension":18},"/en-us/blog/dont-hide-primary-actions",{"title":924,"description":925,"ogTitle":924,"ogDescription":925,"noIndex":6,"ogImage":926,"ogUrl":927,"ogSiteName":672,"ogType":673,"canonicalUrls":927,"schema":928},"Don't hide primary actions","In our testing, we found there was confusion in setting up subgroups with a wide range of research participants. We wanted to reduce confusion in setting up subgroups in GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/dont-hide-primary-actions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Don't hide primary actions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Mora\"}],\n        \"datePublished\": \"2021-04-01\",\n      }",{"title":924,"description":925,"authors":930,"heroImage":926,"date":932,"body":933,"category":764,"tags":934},[931],"Daniel Mora","2021-04-01","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\u003C!-- ![Image of Batman stroking his chin in contemplation](https://media.giphy.com/media/a5viI92PAF89q/giphy.gif){: .shadow.right.wrap-text} -->\nOrganizing your projects into groups within GitLab should be a simple matter for new users. We conducted a Category Maturity Scorecard validation to see how we were correct to assume that it was easy to model your organization in GitLab so that teams could have clear boundaries between other groups. What we found during our initial testing, however, was far off from this assumption.\n\n### Problem\nLooking at this organization chart, we assumed our test participants would have no trouble creating this structure in a test environment.\n\n[![](https://mermaid.ink/img/eyJjb2RlIjoiZ3JhcGggVERcbiAgQVtJbmZvcm1hdGlvbiBUZWNobm9sb2d5IGFuZCBEYXRhIEFuYWx5dGljc10gXG4gIEEgLS0-IEVbSVQgRGlnaXRhbCBTZXJ2aWNlc11cbiAgRSAtLT4gRltEaWdpdGFsIFRyYW5zZm9ybWF0aW9uIEVudmlyb25tZW50XVxuICAgIEYgLS0-IE1bUHJvamVjdCBBbHBoYV1cbiAgICBGIC0tPiBOW1Byb2plY3QgQmV0YV1cbiAgICBGIC0tPiBPW1Byb2plY3QgQ29yZV1cbiAgRSAtLT4gR1tBcHBsaWNhdGlvbiBEYXRhYmFzZSBTZXJ2aWNlc11cbiAgRSAtLT4gSFtCdXNpbmVzcyBQcm9jZXNzIE1hbmFnZW1lbnRdXG4gICBIIC0tPiBQW1Byb2plY3QgWmV0YV1cbiAgIEggLS0-IExbUHJvamVjdCBCbGFua10iLCJtZXJtYWlkIjp7fSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoiZ3JhcGggVERcbiAgQVtJbmZvcm1hdGlvbiBUZWNobm9sb2d5IGFuZCBEYXRhIEFuYWx5dGljc10gXG4gIEEgLS0-IEVbSVQgRGlnaXRhbCBTZXJ2aWNlc11cbiAgRSAtLT4gRltEaWdpdGFsIFRyYW5zZm9ybWF0aW9uIEVudmlyb25tZW50XVxuICAgIEYgLS0-IE1bUHJvamVjdCBBbHBoYV1cbiAgICBGIC0tPiBOW1Byb2plY3QgQmV0YV1cbiAgICBGIC0tPiBPW1Byb2plY3QgQ29yZV1cbiAgRSAtLT4gR1tBcHBsaWNhdGlvbiBEYXRhYmFzZSBTZXJ2aWNlc11cbiAgRSAtLT4gSFtCdXNpbmVzcyBQcm9jZXNzIE1hbmFnZW1lbnRdXG4gICBIIC0tPiBQW1Byb2plY3QgWmV0YV1cbiAgIEggLS0-IExbUHJvamVjdCBCbGFua10iLCJtZXJtYWlkIjp7fSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)\n\nSadly, this was not the case:\n- Five test participants could not complete the task in 30 minutes.\n- One confused the difference between Groups versus Projects but could (inaccurately) recreate the structure in GitLab in approximately 3 minutes.\n- Only one person was able to complete the task accurately in around 3 minutes.\n\n\u003C!-- ![Image of a young woman cringing](https://media.giphy.com/media/3FBwwRCNTSa52/giphy.gif){: .shadow.center} -->\n\n### Observations\nThe primary problem we found was that our participants could not find a way to create a subgroup. Success depended on creating subgroups, but the button to create a new subgroup was not easily discoverable. The participant would have to go into exploratory mode and click to see what was in the 'New project' dropdown to find it. This problem with button dropdowns and primary action discovery also occurred within the [Comment button in Merge Requests](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49614).\n\n![Image of dropdown button](https://about.gitlab.com/images/blogimages/2021-04-15-dropdown-button.png){: .shadow.center}\n\nThe second observation was that the user experience and logic of building an organizational system are not intuitive for new users. \n\nParticipants expected:\n- A more graphical user experience with interactive boxes and lines\n- A way to perform the task through the command line\n- A way to import the org structure from another system\n\nParticipants could not determine the difference between a group or a project or how they were related. There was no visual indicator of what the difference was or what features related to Groups or Projects.\n\n### Solution proposals\nFor an initial recommendation to address the confusion, we wanted to separate the primary dropdown button.\n\n![Image of 3 seperate buttons](https://about.gitlab.com/images/blogimages/2021-04-15-split-button.png){: .shadow.center}\n\nHiding features under dropdowns assumes the users understand they can access additional actions if they click the button's dropdown area. As well, two disparate interface actions shouldn't juxtapose if they have no direct relationship.\n\nWe assumed that we could split up this button into two for an MVC and have better results. After another round of testing, we were able to achieve far better results. Our test participants completed the task of creating the group and project structure quickly and found the task easy to complete.\n\n### This one simple trick\nBy breaking apart the 'New project' and 'New group' buttons, we could make the 'New group' action discoverable. After we made this change, participants had no trouble interpreting the scenario and executing the task within 5 minutes.\n\n\u003C!-- ![image of a young man dancing](https://media.giphy.com/media/3o7abldj0b3rxrZUxW/giphy.gif){: .shadow.center} -->\n\n### Next steps\nCurrently, we are looking at how we can improve sharing groups and features. We want to [remove the barrier between groups and projects](https://gitlab.com/groups/gitlab-org/-/epics/2885). We believe that this will help with some of the problems users have with sharing across groups, and they will be able to take advantage of features that provide them with a more connected set of groups. This change will also improve our information architecture by reducing the confusion around how objects are connected, making navigation and cross-team sharing easier in the future.\n",[9,725],{"slug":936,"featured":6,"template":686},"dont-hide-primary-actions","content:en-us:blog:dont-hide-primary-actions.yml","Dont Hide Primary Actions","en-us/blog/dont-hide-primary-actions.yml","en-us/blog/dont-hide-primary-actions",{"_path":942,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":943,"content":949,"config":955,"_id":957,"_type":13,"title":958,"_source":15,"_file":959,"_stem":960,"_extension":18},"/en-us/blog/e-factor-productivity",{"title":944,"description":945,"ogTitle":944,"ogDescription":945,"noIndex":6,"ogImage":946,"ogUrl":947,"ogSiteName":672,"ogType":673,"canonicalUrls":947,"schema":948},"Improve your productivity by tracking your time and measuring your E-factor","Sharing my personal experience of how tracking my time while working remotely helped me be more productive.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673115/Blog/Hero%20Images/e-factor.jpg","https://about.gitlab.com/blog/e-factor-productivity","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Improve your productivity by tracking your time and measuring your E-factor\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matej Latin\"}],\n        \"datePublished\": \"2019-11-26\",\n      }",{"title":944,"description":945,"authors":950,"heroImage":946,"date":952,"body":953,"category":787,"tags":954},[951],"Matej Latin","2019-11-26","\nBack in the day, when I worked on-site and in open plan offices, I always felt unproductive despite being always busy. It was a paradox that I couldn’t understand. How come I’m rushing to do a lot of things all the time but still feel like I’m producing nothing that is truly valuable? Why do I get more work done in my “work from home day” that I only get every two weeks, than I do in the office?\n\nAfter joining GitLab and reading a couple of books on workplaces and productivity, I now understand why this was the case. Cal Newport’s [Deep Work](https://www.goodreads.com/book/show/25744928-deep-work) was the most illuminating book that I read on productivity. He breaks the types of work into two categories:\n\n**Shallow work**: *Non-cognitively demanding, logistical-style tasks, often performed while distracted. These efforts tend to not create much new value in the world and are easy to replicate.*\n\n**Deep work**: *The ability to focus, be uninterrupted for long stretches of time and fall into a [state of flow](https://en.wikipedia.org/wiki/Flow_(psychology)).*\n\nIn his **Deep Work Hypothesis**, he claims that the ability to focus separates the top performers from the rest:\n\n> The ability to perform deep work is becoming increasingly rare at exactly the same time it’s increasingly valuable in our economy. As a consequence, the few who cultivate this skill and then make it the core of their working life will thrive.\n\nWhile I was doing a lot of different things at the same time, it was mostly reactive work instead of valuable, [proactive](/handbook/product/ux/how-we-work/#proactive-and-reactive-ux) work. Replying to emails, attending meetings, chatting on Slack, and similar work demands a lot of energy but returns very little, if any, value. Taking this all into account, I decided to go back to working remotely because I knew [I could control my working environment better and be more productive](/blog/eliminating-distractions-and-getting-things-done/). That’s why I ended up joining GitLab.\n\n## The E-factor\n\n*Peopleware* by Tom DeMarco and Timothy Lister is another book that is popular with GitLab team members. In the book, the authors introduce a concept called *the E-factor*. To put it simply, the E-factor is about measuring brain time *versus* body time – so how much time a person is working at their full potential *versus* how much time they’re present at the office. The formula to calculate it is the following:\n\n> E-factor = uninterrupted hours / body-present hours\n\nSo when I worked in open plan offices, I was present for about eight hours, but had a maximum of about one or two hours of uninterrupted time. That means that my E-factor ranged from *0.125 to 0.25*. It’s impossible to produce valuable work with such a low E-factor. Switching to working remotely at an all-remote company immediately improved this but I recently decided to take it even further. I measured how I spent my time for two weeks while working at GitLab. The first week was to document how I had already been spending my time and then the second week with the introduction of improvements that would increase my uninterrupted time. Research suggests that intense concentration is only possible for up to four hours per day so I was aiming to get to four hours of uninterrupted time altogether, but ideally in a single block. Here’s how I spent time before the improvements:\n\n![My week before improvements](https://about.gitlab.com/images/blogimages/before-improvements.jpg){: .large.center}\n\nI tracked my time by dividing days into 15-minutes blocks. Light grey is sleep, light blue is family time, and dark blue is work time. Red colors are for shallow work, meetings and email time. The more of the dark blue blocks and the more connected the better.\n{: .note.text-center}\n\n{::options parse_block_html=\"true\" /}\n\n\u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>  \nGet the [Google Spreadsheet template for tracking time](https://docs.google.com/spreadsheets/d/10CnZlCW0fu-GXqGhK7Lysj5QzTGIqYjdv6yrUlbARzo/edit?usp=sharing). Go to *File* > *Make a copy* to get an editable version.\n  \u003Ci class=\"fab fa-gitlab\" style=\"color:rgb(107,79,187); font-size:.85em\" aria-hidden=\"true\">\u003C/i>\n{: .alert .alert-webcast}\n\nBefore introducing the improvements, this is how my usual day looked like:\n\n* I checked my email first thing in the morning, which could cause me to spend up to one hour just replying to other people.\n* I used to study a book or take course lessons in the morning as a part of professional self-improvement. This was usually half an hour. By the time I actually started working it’d be 9:30.\n* I’d work for a couple of hours and stop for a quick snack at 11:30. This was the first stretch of uninterrupted time.\n* After the snack I’d have another similar stretch of time but that was usually just an hour (mostly because I’d get distracted with shallow work).\n\nSo if I put all this together, I had about three hours of uninterrupted time every day. It’s not that bad (and it’s definitely better than what I experienced in on-site roles in the past) but I wanted to do better. I especially wanted to increase the amount of uninterrupted time in a single stretch. So I decided to make the following improvements:\n\n* I started checking my email in the afternoon, after lunch (that’s 3pm for me).\n* I moved the self-improvement activities until after the first snack at 11:30am.\n* I realized I spent an hour and a half showering and eating breakfast in the morning, which was way too much. I reduced this to one hour so I could start working 30 minutes earlier (8am instead of 8:30am).\n\n![My week after improvements](https://about.gitlab.com/images/blogimages/after-improvements.jpg){: .large.center}\nA lot more dark blue, and a lot more of connected dark blue blocks after improvements.\n{: .note.text-center}\n\nWith these improvements, I was able to increase the first stretch of uninterrupted time from two hours to three and a half hours. With an additional one to two hours of uninterrupted time after the snack that can sum up to four and a half to five and a half hours of uninterrupted time each day. My E-factor increased to *0.6875*, that’s a **275% increase** compared to my times in the office! These changes to my workflow help me perform deep work and fall into a state of flow twice a day, and I noticed drastic improvements in my productivity and in my psychological state as well.\n\n## Things that enabled me to introduce these improvements\n\n### Separate room for work\n\nI have a study at home where I can be alone and focus. I think this is a very important thing for all remote workers.\n\n### Strong working routine\n\nAt GitLab, working remotely and asynchronously gives us the [freedom to shape our working schedule as we please](https://handbook.gitlab.com/handbook/values/#managers-of-one) but a strong working routine has lots of benefits. Starting work at the same time in the morning helps with creating more uninterrupted time and productivity.\n\n### Timezone\nI’m based in Europe and most of my colleagues are based in the U.S. This means that I can easily block out time for focused work and eliminate all distractions, including Slack.\n\n### My Slack and email policy\n\nEven when I’m not in my focus time, [I have Slack notifications disabled](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication). I even disabled the small red dots on the app icon in the dock so that nothing has the possibility of distracting me. As for email, I’ll only check my inbox after lunch, that’s well after I had my two blocks of uninterrupted time.\n\n### Writing down tasks\n\nI always write down the things that I need to work on. I have a small notebook on my desk and at the end of each day, I write down the things I need to work on the next day. This way, I can go straight to work in the morning.\n\n### Keeping a journal of tasks\n\nRecently, I also started keeping track of all the things I need to work on in my “tasks journal”. It’s just a project on GitLab where I keep a couple of Markdown files for current tasks that I’m working on and an archive of tasks that I worked on in the past. They’re all divided by weeks. For example, at the time of writing this paragraph, it’s week 33 of this year so my [current tasks](https://gitlab.com/matejlatin/focus/blob/master/Tasks/current.md) are things that I want to work on in this week. At the end of the week, I’ll check the progress and [archive it](https://gitlab.com/matejlatin/focus/tree/master/Tasks) so I can always check back later.\n\nKeeping a task journal adds a stronger sense of continuity and sharp focus to my work. In the spirit of [transparency](https://handbook.gitlab.com/handbook/values/#public-by-default), I share this publicly with all my co-workers so everyone can see what I’m working on and check my availability.\n\n### Working asynchronously\n\nOne of the greatest benefits of working at GitLab is [being encouraged to work asynchronously](/handbook/communication/). Because our team isn't tied to the same working hours, I can block out time for focus without feeling guilty that I’m not available to everyone all the time. It’s interesting how working like this makes you realize that most interruptions aren’t as urgent as we tend to believe.\n\n## Advice for non-remote workers\n\nIf you’re required to work in an office – possibly a working environment full of distractions – implementing these strategies can be a lot more challenging. My advice for non-remote workers is to ask your manager for “work from home” days. Maybe start with one day per week and see how it goes. If your manager doesn't agree, try tracking your time when you work in the office like I did. Present the chart to them and tell them about the deep work and the E-factor. Explain to your manager that you want to increase your uninterrupted time which will help you complete more valuable work. Tell them how working from home will help you achieve this, and how you will change your workflow to be more productive (look for inspiration from my improvements I described in this article). Be committed to producing more meaningful work and be clear that working from home is only a means to an end. Offer to track your time at home to compare with your time spent your in the office, especially if your manager doesn’t seem to be in favor of these changes.\n\nIf working from home is still not an option, consider finding a quiet spot in the office where you’ll be uninterrupted: Perhaps the lounge, the garden, or even the reception area. Try moving to an area away from your teammates and sit with people you don’t know as well. They’re much less likely to disturb you. When I was working from a busy office in central London, I loved going to a coffee shop for an hour or two. I managed to get some work done and enjoyed the short trip to the shop and back. The walk and getting out of the office helped me relax a bit as well.\n\nThese changes to how we work are all about improving productivity and quality of work. In an ideal working environment, everyone would measure their E-factors and they’d brag about their uninterrupted time instead of complaining about how many meetings they have to attend in an effort to perform busyness to their colleagues.\n\nPhoto by [Émile Perron](https://unsplash.com/@emilep?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/productivity?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[876,682,9],{"slug":956,"featured":6,"template":686},"e-factor-productivity","content:en-us:blog:e-factor-productivity.yml","E Factor Productivity","en-us/blog/e-factor-productivity.yml","en-us/blog/e-factor-productivity",{"_path":962,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":963,"content":969,"config":976,"_id":978,"_type":13,"title":979,"_source":15,"_file":980,"_stem":981,"_extension":18},"/en-us/blog/five-signs-you-should-think-bigger",{"title":964,"description":965,"ogTitle":964,"ogDescription":965,"noIndex":6,"ogImage":966,"ogUrl":967,"ogSiteName":672,"ogType":673,"canonicalUrls":967,"schema":968},"Five signs you should think BIGGER!","Are you a designer who is frustrated with only focusing on the next milestone? Do you feel like you have to answer too many questions in every Issue? Do you feel like your product is not making any progress? **Time to Think Bigger!**","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750099620/Blog/Hero%20Images/Blog/Hero%20Images/insights_insights.png_1750099620265.png","https://about.gitlab.com/blog/five-signs-you-should-think-bigger","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Five signs you should think BIGGER!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Iain Camacho\"}],\n        \"datePublished\": \"2021-03-30\",\n      }",{"title":964,"description":965,"authors":970,"heroImage":966,"date":972,"body":973,"category":787,"tags":974},[971],"Iain Camacho","2021-03-30","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAs a designer, it’s difficult to balance the scale of initiatives: Design too small, and nobody is excited or can understand the direction things are going. Start too big and everyone on the team may be too intimidated to start. ThinkBIG is a way of utilizing designers’ natural skillset to balance the iterative nature of engineering with the visionary nature of design.\n\nHere are 5 signals that you should switch up your style and Think Bigger:\n\n### 1) Every milestone is spent only prepping the next\n\n#### Signal\n\nWe’ve all been there. The next milestone planning issue is starting to get filled out and you, the designer, are realizing how many issues need design in order to be ready. As the priorities shift, you know the last two weeks of this milestone will be spent desperately trying to design mockups for engineers to start working on days later. I like to call this “Feeding the sharks”. It describes a certain level of panic some designers feel every milestone: If I don’t deliver enough, I might get chomped!\n\n#### Solution\n\nThinkBIG focuses on creating a larger-scale vision that can be iterated on as we go. This means that each design you put together leads to many independent issues engineers can work on. For a designer, this increases [results](https://handbook.gitlab.com/handbook/values/#results) by delivering one design worth many issues.\n\n### 2) Engineers are asking _a lot_ of questions\n\n#### Signal\n\nHave you ever started a new milestone and as engineers get started, they have a million questions detailing every possible state, permutation, and example that they should account for? This line of questioning means you, the designer, now need to make a myriad of new designs with only minute changes between them. This is not an [efficient](https://handbook.gitlab.com/handbook/values/#efficiency) use of the designer’s time.\n\n#### Solution\n\nFirst off, all these questions are valid and decisions that need to be made. By Thinking Bigger, engineers are better prepared to handle all the edge cases independently because they walk into their work with a fuller context of the impact on users.  This enables empathy-driven engineering, allowing engineers to lead the conversation around edge-cases with solutions in mind, instead of needing it to be defined ahead of time. By pushing the edge cases further down the product development lifecycle, there is also a unique opportunity for product, design, and engineering to [collaborate](https://handbook.gitlab.com/handbook/values/#collaboration) on delivering value to customers while still working iteratively.\n\n### 3) Nobody agrees on what the “MVC” actually is\n\n#### Signal\n\nPicture it: You’ve worked hard for weeks refining and distilling a big feature ask into a nicely designed MVC. It’s small, delivers value, and is beautiful to boot! You’ve convinced your PM to prioritize this beautiful little gem and it’s going onto the planning board. Everything feels amazing until… devastation!\n\nAfter engineering looked at it, they came back and said it was too large and would need to be broken down further. Now you’re at the end of your milestone and you’re swiftly picking away at your beautiful design into a shallow imitation of its former glory.\n\n#### Solution\n\nHowever, there is a simple way to keep this from happening: “[Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is a team sport”. The designer shouldn’t be the only person on the team compromising for the sake of MVC. With ThinkBIG, you have multiple chances to bring engineering into the fold early and with the full vision in mind. This means devs are part of the conversation from the start, able to craft a valuable iteration and your designs become the conversation piece of deciding “What can we do next to deliver an amazing experience to our customers?”\n\n### 4) We’re working so hard but not getting anywhere\n\n#### Signal\n\nWorking iteratively is incredibly powerful and at GitLab, we can see the value of an iterative approach. We’re able to change our priorities at a moment’s notice and the work we actually have to deliver is reasonable and manageable while continuously delivering new value to customers. There is, however, a small drawback: When you’re only focusing on the step immediately in front of you, it’s easy to get lost along the way.\n\n#### Solution\nAs a designer, we have a unique opportunity to be the navigator for our teams. Using the ThinkBIG model, designers are empowered to hold responsibility for the Vision. From here, the Product Manager/Product Designer relationship becomes a balance between the vision and the strategy. Designs based on the large vision are used to keep the team on track for hitting the targets that bring value to customers while allowing for collaboration with the rest of the team on what tiny steps we take to get there.\n\n### 5) Engineers are reworking a lot\n\n#### Signal\n\nMy engineer and I are excited to work on a new effort. I’ve designed the first iteration and successfully passed it to them.  While they’re building, I’m working on the design for the next iteration. A few weeks later the new changes are merged, the next iteration designs are ready, and customers are already seeing value. Your engineer looks at the next iteration and painfully mutters “Well, I’ll have to rewrite what I wrote the last milestone to account for this.”\n\n#### Solution\n\nIn a highly iterative development lifecycle, it’s not uncommon to have to rework things as the product evolves. However, it shouldn’t be happening every time. With ThinkBIG, engineers are informed of the long-term goal as well as the short-term MVC iteration. This extra context allows them to deliver the iteration while architecting their code in an informed way of where it will go.\n\n### Start Thinking BIGGER!\n\nAre some of these signals sounding familiar? Then switching your design style to ThinkBIG may be for you! The simplest way to make this change is to move iteration breakdown to **after** the design phase. It immediately shows engineers where we want to go as a product or feature, opens the implementation breakdown (MVC) conversation to the whole team, and provides incredibly valuable insight to everyone on the team. This model of working helps designers be more efficient, deliver results, and foster a tight collaboration with the broader team. To see this process in action, check out a [Package ThinkBIG around the dependency proxy design and research](https://www.youtube.com/watch?v=LXFu6oDxhsw). For more information, check out the GitLab Handbook on [ThinkBIG](https://about.gitlab.com/handbook/product/ux/thinkbig/) to learn more.\n",[811,9,876,683,975],"AWS",{"slug":977,"featured":6,"template":686},"five-signs-you-should-think-bigger","content:en-us:blog:five-signs-you-should-think-bigger.yml","Five Signs You Should Think Bigger","en-us/blog/five-signs-you-should-think-bigger.yml","en-us/blog/five-signs-you-should-think-bigger",{"_path":983,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":984,"content":990,"config":997,"_id":999,"_type":13,"title":1000,"_source":15,"_file":1001,"_stem":1002,"_extension":18},"/en-us/blog/gitlab-dark-mode-is-getting-a-new-look",{"title":985,"description":986,"ogTitle":985,"ogDescription":986,"noIndex":6,"ogImage":987,"ogUrl":988,"ogSiteName":672,"ogType":673,"canonicalUrls":988,"schema":989},"GitLab dark mode is getting a new look","GitLab is enhancing dark mode for a cleaner, more polished experience, with incremental updates to improve usability and visual consistency. Get a sneak peek at this new design.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098523/Blog/Hero%20Images/Blog/Hero%20Images/hero%20%282%29_7nhIrZ08jWcLxhaH9rfbk1_1750098523498.png","https://about.gitlab.com/blog/gitlab-dark-mode-is-getting-a-new-look","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab dark mode is getting a new look\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sascha Eggenberger\"},{\"@type\":\"Person\",\"name\":\"Chris Micek\"},{\"@type\":\"Person\",\"name\":\"Jeremy Elder\"}],\n        \"datePublished\": \"2024-10-15\",\n      }",{"title":985,"description":986,"authors":991,"heroImage":987,"date":994,"body":995,"category":723,"tags":996},[992,993,850],"Sascha Eggenberger","Chris Micek","2024-10-15","Dark mode has become an essential feature, providing a darker background with lighter content to reduce eye strain, enhance readability, and maintain continuity with system-wide settings. While we currently offer an experimental version of dark mode in GitLab, customers requested some improvements. We’ve taken that feedback seriously and now we’re excited to share our vision for the future of dark mode on the DevSecOps platform, and how we plan to roll this out over the next several months.\n\n## Challenges with the current dark mode\n\nGitLab’s dark mode, launched in 2020, has remained in an alpha state, largely due to its initial approach of algorithmically inverting colors. While this method allowed us to quickly offer a basic dark background with lighter text, there are several issues that require taking a different approach.\n\nThe current dark mode suffers from inconsistent visual hierarchy — some elements, like alerts, stand out too much, while others fade into the background. An overuse of color also makes certain elements, such as alerts and badges, overly saturated, distracting from key content. Additionally, some elements emit too much light, causing visual strain for those using GitLab for long periods of time.\n\nDue to these issues and the complexity of implementing fixes, our experimental dark mode has remained below our standard of quality, with many one-off adjustments adding unnecessary complexity. We know there’s room for improvement, and that’s why we’re committed to enhancing this experience in a way that feels seamless, comfortable, and visually appealing.\n\n## Principles guiding the new direction\n\nTo create a more cohesive dark mode, we’ve developed several design principles that will guide the new iterations. Similar to our work on a [Dark UI for GitLab’s Web IDE](https://about.gitlab.com/blog/creating-a-dark-ui-for-gitlabs-web-ide/), these principles and ideas helped us focus on ensuring the experience is not only aesthetically pleasing but also functional and accessible.\n\nTo see how these principles are applied in practice with examples watch this [walkthrough by Jeremy Elder](https://www.youtube.com/watch?v=QdiV6lRSFpE), a staff product designer working on dark mode.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n\u003Ciframe src=\"https://www.youtube.com/embed/QdiV6lRSFpE?si=kFssresabK0JJrug\" title=\"GitLab Dark Mode\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n### 1. Forward elements are lighter, receding ones are darker\n\nThis mimics natural light behavior: brighter elements come forward, while darker ones recede. In dark mode, brighter elements create depth, ensuring important content stands out without relying heavily on borders or shadows.\n\n![Using surfaces to make important components stand out more.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098534/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098533970.png)\n\u003Ccenter>\u003Ci>Using surfaces to make important components stand out more.\u003C/i>\u003C/center>\n\u003Cbr>\n\n![Applying the new design principles can create a visually better structured and more meaningful UI.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098534/Blog/Content%20Images/Blog/Content%20Images/image4_aHR0cHM6_1750098533970.png)\n\n\u003Ccenter>\u003Ci>Applying the new design principles can create a visually better structured and more meaningful UI.\u003C/i>\u003C/center>\n\n### 2. Reduced color saturation\nIn a dark UI, color naturally stands out more, so we’re reducing the amount of color used. Instead of flooding backgrounds with color, we’re using color more selectively to draw attention where it’s needed.\n\n![Alerts are quieter than before.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098534/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098533971.png)\n\n\u003Ccenter>\u003Ci>Alerts are quieter than before.\u003C/i>\u003C/center>\n\n### 3. Dimmed, not inverted\n\nWe’re approaching dark mode as “dimming the lights” rather than fully inverting the interface. This means we’re making careful decisions about which elements to darken and which to brighten, so the content remains clear while the background recedes appropriately.\n\n![Dark mode subtly dims the background while keeping key content clear and visible instead of inverting colors.](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098534/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098533971.png)\n\n\u003Ccenter>\u003Ci>Dark mode subtly dims the background while keeping key content clear and visible instead of inverting colors.\u003C/i>\u003C/center>\n\n## Iterative implementation\n\nThe new GitLab dark mode won’t be rolled out all at once. Instead, we’re taking an iterative approach, releasing updates incrementally. This process will begin with elements of the Pajamas Design System and gradually expand across the rest of the product. If you’re using the current dark mode, you’ll start to notice subtle changes to colors, contrast, typography, and component styling, all working towards our vision of a more polished, cohesive dark mode. \n\n> Follow our [progress in the dark mode epic](https://gitlab.com/groups/gitlab-org/-/epics/2902) as we continue working towards this vision.\n\n## Read more\n-  [Get to know the new GitLab typefaces](https://about.gitlab.com/blog/new-typefaces-in-gitlab/)\n- [Beautifying our UI: Giving GitLab build features a fresh look](https://about.gitlab.com/blog/beautifying-of-our-ui/)\n- [How visualization improves the GitLab merge train experience](https://about.gitlab.com/blog/how-visualization-improves-the-gitlab-merge-train-experience/)\n",[9,682,723,481],{"slug":998,"featured":90,"template":686},"gitlab-dark-mode-is-getting-a-new-look","content:en-us:blog:gitlab-dark-mode-is-getting-a-new-look.yml","Gitlab Dark Mode Is Getting A New Look","en-us/blog/gitlab-dark-mode-is-getting-a-new-look.yml","en-us/blog/gitlab-dark-mode-is-getting-a-new-look",{"_path":1004,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1005,"content":1011,"config":1017,"_id":1019,"_type":13,"title":1020,"_source":15,"_file":1021,"_stem":1022,"_extension":18},"/en-us/blog/gitlab-design-library",{"title":1006,"description":1007,"ogTitle":1006,"ogDescription":1007,"noIndex":6,"ogImage":1008,"ogUrl":1009,"ogSiteName":672,"ogType":673,"canonicalUrls":1009,"schema":1010},"Scaling design: The start of system thinking","How we began the process of introducing a design system to GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666775/Blog/Hero%20Images/cover.jpg","https://about.gitlab.com/blog/gitlab-design-library","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Scaling design: The start of system thinking\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taurie Davis\"}],\n        \"datePublished\": \"2017-12-12\",\n      }",{"title":1006,"description":1007,"authors":1012,"heroImage":1008,"date":1014,"body":1015,"category":787,"tags":1016},[1013],"Taurie Davis","2017-12-12","\n\nScaling design within an application is a struggle. Design systems help alleviate problems that arise with scaling by making it easier to find inconsistent interactions or conflicting messaging. However, it can be extremely difficult to introduce a new system to teams that are already functioning without one. Here's how we got started.\n\n\u003C!-- more -->\n\nWe took the initial step towards establishing our own system by creating a pattern library of reusable components that can be shared and reused across the application.\n\n## Design as a language\n\nConsistency within the UI and increased iteration speed are clear benefits for using a design library. This helps keep the application [DRY](http://programmer.97things.oreilly.com/wiki/index.php/Don't_Repeat_Yourself) and allows designers to focus their efforts on solving user needs, rather than recreating elements and reinventing solutions. In an effort to create a library that is understood by multiple teams, it's important to begin thinking about design as a language.\n\nYour design language is an integral part of a design system that clearly defines the semantics of your visual designs and allows your team to thoroughly document guidelines. It's important that the team not only understands how the system is built, but also the reasoning behind the choices made. This will ultimately help enable your team to build a library of components that support the semantics you have established.\n\n## Getting started\n\nKnowing where to start can be daunting. We began by first understanding the current state of our application. By auditing current designs that were implemented, we found numerous inconsistencies across our interface and determined that we lacked a solid design language to build from. A search within our variables revealed that we had **82 different gray values defined within the UI**. We also had an undefined type scale that included **at least 30 different values** in pixels, rems, and percentages.\n\nBy understanding the problems our current system had, we were able to start building a solid foundation to work from. We defined and documented our perceptual patterns which included styles that aid in the aesthetic of the brand: typography, icons, colors, and a measurement system.\n\n{: .text-center}\n![Library foundation](https://about.gitlab.com/images/blogimages/gitlab-design-library/library--styles@2x.png){: .shadow}\n\nOnce our perceptual patterns were defined, we started applying them to our components. We took a couple core pieces of our application and mocked them up using our new guidelines to ensure that our new rules were not too rigid and would be flexible enough to still encourage the creation of new ideas and methods while designing new components.\n\nOnce we nailed down our styles, we were able to start identifying functional patterns that needed to be built out using our new guidelines. Functional patterns include global modules that can be reused throughout your application, such as buttons, dropdowns, and tabs.\n\nThere were a few instances where our newly defined styles did not work well in our actual designs. For example, we determined that our 8px measurement system was too strict for right and left padding on horizontal tabs, buttons, and inputs. Although it was not a part of our measurement system, we decided as a team to create a new rule that would allow for a 12px measure in order better align stacked items while giving elements enough room to breathe.\n\n{: .text-center}\n![Library foundation](https://about.gitlab.com/images/blogimages/gitlab-design-library/library--measures@2x.png){: .shadow}\n\nBuilding out these components gave us the opportunity to alter and add to our new perceptual patterns. It is okay to allow some flexibility within your design library, so long as the rules and use cases are clearly defined.\n\n## Structure\n\nWe set up our design library using a [primary sketch file](https://gitlab.com/gitlab-org/gitlab-design/blob/master/production/resources/gitlab-elements.sketch) that includes all the components and styles that have been added to our team library. As we began building out multiple components, it was important to define a structure that would mimic the way components are implemented on the frontend. This would allow the design and frontend teams to work more closely together, ensuring that components were DRY and reusable. We chose to implement [Brad Frost's Atomic Design](http://bradfrost.com/blog/post/atomic-web-design/) principles in order to accomplish this. Atomic design \"break[s] entire interfaces down into fundamental building blocks,\" ensuring that everything is constructed in a methodical way. These building blocks consist of:\n\n**Atoms:** Elements that cannot be broken down further. This can include type styles, buttons, labels, and inputs\n\n**Molecules:** A group of atoms that function as a unit, such as a form.\n\n**Organisms:** A high-level component that consists of several molecules to make up its own structure. This can include a header or a sidebar.\n\nThere has been a lot written on Atomic Design. To learn more I recommend:\n\n- [Atomic Design by Brad Frost](http://atomicdesign.bradfrost.com/)\n- [Atomic Design by Brad Frost - An Event Apart video](https://vimeo.com/179245570)\n- [Pattern Lab](http://patternlab.io/)\n\nFollowing this structure forces the team to think carefully about what each part of a design is made up of, as well as easily define global components. If a modifier consists of atoms that are not used elsewhere, we encourage designers to think about whether a specific atom is necessary for that paradigm or if an existing global component would work in its place.\n\nIn the following example, we've built out our left navigational sidebar. This organism comprises molecules, and these molecules comprise globally used atoms (an avatar, badge, typography, and icons). We also include molecule modifiers, which make it easy to see the different states that a molecule can have. These together build the basis of the sidebar.\n\n{: .text-center}\n![Library foundation](https://about.gitlab.com/images/blogimages/gitlab-design-library/library--atomic@2x.png){: .shadow}\n\nWe use [symbols within Sketch](https://sketchapp.com/docs/symbols/) to create our atoms and molecules, while leaving organisms as groups so that we can easily modify and override specific aspects to fit the design we are working on.\n\n## Tooling\n\nChoosing tools can be an arduous task, especially with the number of options available for designers today. It is easy to get caught up in the latest tool and turn progress into tool churn. At GitLab, we took the time to evaluate multiple tools that would assist in the creation of a team library.\n\nSome of the issues we ran into while evaluating plugins were:\n\n- Slow performance, as well as bugs, when adding, changing, and renaming components\n- Overriding options when adding symbols to a new document were not pulled in or included automatically\n- Text styles weren't being saved or included in symbols that were pulled into a new document\n\nWe eventually decided to move forward using [Brand.ai](https://brand.ai) as a plugin for Sketch. This plugin solved many of the issues we were running into with other tools. However, while this plugin was the best that we found at the time, no tool is perfect:\n\n- Brand. ai limits the organization of components to one level deep\n- While faster and less buggy than other plugins, Brand.ai is still not as fast as we would like :rocket:\n\n{: .text-center}\n![Library foundation](https://about.gitlab.com/images/blogimages/gitlab-design-library/library--brandai@2x.png){: .shadow}\n\nAt GitLab, we don't look at Brand.ai as the answer. It is solely a tool to help aid us in the creation process. Since deciding on using Brand.ai, Sketch has released their own [library feature](https://blog.sketchapp.com/libraries-an-in-depth-look-56b147022e1f), Brand.ai was [acquired by InVision](https://www.invisionapp.com/blog/announcing-invision-design-system-manager/), and Figma has added numerous new features to aid in the creation of a design library. Tools are constantly transforming, but it's important to keep in mind that constantly changing tools may slow progress. Evaluate your tools carefully and decide what is best for your team at this moment. Remember that pattern libraries are only one aspect of a design system that helps make it more effective. The tools and technologies you use to create the library are meant to help your team, not act as the solution.\n\n## Moving forward\n\nConversations around design systems have exploded in recent years. Just over the last few months, Figma has begun sponsoring [Design System Dinners](https://www.designsystems.com/), InVision has created a [Design Systems Handbook](https://www.designbetter.co/design-systems-handbook/introducing-design-systems), and Smashing Magazine released [*Design Systems*](https://www.smashingmagazine.com/design-systems-book/) as their newest book.\n\nAt GitLab, we have only just begun the work on our design system. A design library is only the first part of our overall goal and it is our first step towards ensuring that our design will scale within the growing organization. We have begun thinking about design with a system in mind by creating a design language that captures the visual styles of our brand, as well as creating reusable and robust components. We've chosen tools and technologies that help aid us in this process while remembering that they are always evolving and are not the system itself.\n\nBeyond continuing to build out new paradigms within our design library, our next step is to begin linking our design library with our frontend code. This will allow us to include not only our designs and documentation, but also code snippets that can be used and referenced in our application. We have only just started this process and are in the very early stages of setting up a [repository](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com) to showcase our system.\n\nIf you have any tips, tricks, or lessons that you discovered while building out your own design library or system, we would love to hear from you!\n\n## Resources\n\n- [gitlab-elements.sketch](https://gitlab.com/gitlab-org/gitlab-design/blob/master/production/resources/gitlab-elements.sketch)\n- [GitLab Brand.ai](https://brand.ai/git-lab/primary-brand)\n- [Design Repo](https://gitlab.com/gitlab-org/gitlab-design)\n",[9,682,876],{"slug":1018,"featured":6,"template":686},"gitlab-design-library","content:en-us:blog:gitlab-design-library.yml","Gitlab Design Library","en-us/blog/gitlab-design-library.yml","en-us/blog/gitlab-design-library",{"_path":1024,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1025,"content":1031,"config":1038,"_id":1040,"_type":13,"title":1041,"_source":15,"_file":1042,"_stem":1043,"_extension":18},"/en-us/blog/gitlab-for-designers",{"title":1026,"description":1027,"ogTitle":1026,"ogDescription":1027,"noIndex":6,"ogImage":1028,"ogUrl":1029,"ogSiteName":672,"ogType":673,"canonicalUrls":1029,"schema":1030},"Help us shape the future of design discussion in GitLab","We've identified the need for full integration of user experience design within the DevOps lifecycle, and would love your feedback on how to make that happen.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680008/Blog/Hero%20Images/design-discussion.jpg","https://about.gitlab.com/blog/gitlab-for-designers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Help us shape the future of design discussion in GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarrah Vesselov\"}],\n        \"datePublished\": \"2018-11-08\",\n      }",{"title":1026,"description":1027,"authors":1032,"heroImage":1028,"date":1034,"body":1035,"category":298,"tags":1036},[1033],"Sarrah Vesselov","2018-11-08","\n\nAt GitLab, we do everything using, well, GitLab. Using our product as part of our workflow allows us to experience, firsthand, the limitations and frustrations that may prevent our users (and us) from being able to get work done quickly and efficiently. In the user experience (UX) department, we've found ourselves struggling with some important aspects of our day-to-day work – this is what we've found, and how we hope to address it:\n\n## Design discussions quickly become hard to follow\n\nDesign discussion happens inside of issues at GitLab. Typically, a designer will post a wireframe, mockup, or prototype within a comment on an issue to elicit feedback from others. The transparency is excellent: product managers, engineers, and designers can all come together to talk over the problem and the possible solutions. Problems creep in when conversations get too lengthy, hard to follow, and involve multiple iterations of a design. How can we make design discussion at GitLab more useful and accessible?\n\n## We need version control for design files\n\nWe use Sketch for our day-to-day design work. The UX department's Sketch files live within a [design repository](https://gitlab.com/gitlab-org/gitlab-design) to ensure that all designers have access to current patterns and solutions. However these files are not version controlled within the repository, so designers keep personal folders for work-in-progress designs. How can we version control our files within GitLab and eliminate the need to keep multiple versions of a particular design?\n\n## A competitive analysis of design platforms and applications\n\nTo start looking for solutions to these problems, we conducted a competitive analysis of the other platforms and applications out there tackling design creation, collaboration, and handoff. We wanted to know: What are other design teams doing to address these problems? Are there existing aspects of GitLab we can leverage to solve these problems? If not, what would an [MVC](/handbook/product/product-principles/#the-minimal-viable-change-mvc) look like to integrate designers more efficiently into GitLab?\n\n### Summary of findings\n\nToday's average user is tech savvy, with high expectations for interface usability. Products must be useful and easy to use for users with a wide range of backgrounds, experiences, and expectations. As a result, enterprise-level companies have invested heavily in building UX teams to produce beneficial experiences. These UX teams have distinct requirements for the toolsets they use. Design tools must be able to:\n\n* Improve UX consistency\n* Enable research and testing of designs with users\n* Clarify requirements\n* Facilitate collaboration between teams (Engineering, PM, UX)\n* Version control design files\n* Minimize duplication of work with an SSOT\n* Minimize context switching\n\nThe last requirement, minimize context switching, really stood out. Enterprise designers work on a variety of platforms. The market has exploded over the past decade, with a majority of designers moving from using desktop software to cloud-based platforms. Designers want and need a single-platform approach. They must have the ability to design, collaborate, and share their work with the rest of the organization within one platform.\n\nThis single-platform approach presents a unique opportunity for us. GitLab is the first single application built from the ground up for all stages of the DevOps lifecycle for Product, Development, QA, Security, and Operations teams to work concurrently on the same project. A significant missing piece of this lifecycle is UX design.\n\n### Areas of opportunity for GitLab:\n\n* Review and collaboration\n* Interaction design\n* Version control\n* Developer handoff\n* Design system management\n\nThe total market potential is over US $4 billion and growing. With no clear winners in the design tool space, there is a significant opportunity for an application that can successfully engage developers and design teams in the DevOps lifecycle.\n\nYou can view the [complete competitive analysis here](https://docs.google.com/document/d/12o6h6Fm7bAjhW5AK1r-PNhvn0QrQwZncorYNia12e3Q/edit?usp=sharing).\n\n## What's next?\n\nA logical place to start is by improving discussion within issues. Design proposals are available in issue descriptions, shared and discussed in comments, and it's not always clear which is the latest version. While we have the option to mark and [comment on specific image spots in the blob view and merge requests](https://docs.gitlab.com/ee/user/discussions/#image-discussions), the actual design collaboration happens much earlier in the process.\n\nOne idea is to make design artifacts a first-class citizen by linking to design assets in the side navigation of an issue. We could allow for commenting on images and propagate these comments in the sidebar for focused and cohesive discussion.\n\nWe want to know what you think! You can take a look at and comment on the [design artifacts discovery issue here](https://gitlab.com/gitlab-org/gitlab-ce/issues/53587).\n\n[Photo](https://www.pexels.com/photo/notes-clean-whiteboard-board-7067/) by [Startup Stock Photos](https://www.pexels.com/@startup-stock-photos) on Pexels.\n{: .note}\n",[811,876,682,9,1037],"DevOps",{"slug":1039,"featured":6,"template":686},"gitlab-for-designers","content:en-us:blog:gitlab-for-designers.yml","Gitlab For Designers","en-us/blog/gitlab-for-designers.yml","en-us/blog/gitlab-for-designers",{"_path":1045,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1046,"content":1052,"config":1057,"_id":1059,"_type":13,"title":1060,"_source":15,"_file":1061,"_stem":1062,"_extension":18},"/en-us/blog/gitlab-iconography-where-mvc-meets-visual-design",{"title":1047,"description":1048,"ogTitle":1047,"ogDescription":1048,"noIndex":6,"ogImage":1049,"ogUrl":1050,"ogSiteName":672,"ogType":673,"canonicalUrls":1050,"schema":1051},"GitLab Iconography: MVC meets visual design","A minimum viable change approach for a key UI element","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680884/Blog/Hero%20Images/mvc-icon-banner.png","https://about.gitlab.com/blog/gitlab-iconography-where-mvc-meets-visual-design","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab Iconography: MVC meets visual design\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeremy Elder\"}],\n        \"datePublished\": \"2019-12-02\",\n      }",{"title":1047,"description":1048,"authors":1053,"heroImage":1049,"date":1054,"body":1055,"category":298,"tags":1056},[850],"2019-12-02","\n\nAnyone who uses GitLab knows how extensively we use icons in our product. Because information density is high and screen real estate is at a premium, we use them for everything from indicating status and critical actions to navigation and label clarity. In short, icons have a comparatively large impact for such a visually small UI element.\n\nIn traditional product development, it’s common to incrementally update features and functionality, and then save visual updates for major version bumps or larger brand updates. But we already had a collection of issues (the medium for collaborating on ideas and planning work in GitLab) telling us change was needed, so we wanted to address that without the dependency of a new version or brand update spurring us on.\n\nTrue to GitLab fashion, this meant we could exercise our [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) value with a [minimum viable change](https://handbook.gitlab.com/handbook/values/#move-fast-by-shipping-the-minimum-viable-change) (MVC) approach – iteratively making visual updates while providing continuous improvement.\n\n## Minimum viable change\n\nAt GitLab, we’re comfortable iterating and releasing designs similar to how our development counterparts iterate on functionality. We still research and test our solutions, but we have the freedom to quickly learn and iterate because of our constant exposure to real use. Our end goal is always to have a [beautiful, guiding, and functional interface](https://youtu.be/Z_DpZZyxwEA?t=1216).\n\nAt the time of this writing, we have 277 custom SVG icons in our library. There are also more than [800 instances](https://leipert-projects.gitlab.io/is-gitlab-pretty-yet/icons/) of FontAwesome icons in the product. We reference icons in HAML, HTML, JavaScript, Ruby, and Vue. A wholesale change to use a new set of custom icons across the entire product would be a massive undertaking. Incremental changes are a must.\n\nAs it turns out, one of our weaknesses is also a strength. With our UI already mixing icons from two different sources and two different styles, we can concern ourselves less with near-term differences and instead focus on making the right changes moving forward.\n\n![Pipelines row that has both SVG and FontAwesome icons together](https://about.gitlab.com/images/blogimages/mvc-icon-mixed.png){: .shadow.center}\nA row in the Pipelines section that contains SVG and FontAwesome icons.\n{: .note.text-center}\n\n## Laying the foundation\n\nOne of our values is to create a distinct GitLab personality that is strong and consistent. Iconography offers a powerful visual cue to users and should reflect our particular sense of style. (This is the opening statement in our new [iconography documentation](https://design.gitlab.com/product-foundations/iconography).)\n\nWe decided that the MVC with the greatest initial impact was updating the icon documentation itself. To reflect the promise of a strong and consistent presence within the product, we had to offer docs that would help fix problems in meaningful and sustainable ways.\n\nTo be sure we were iterating in the right direction, we established guidelines that considered the entire icon ecosystem, but still allowed us to make quick changes. At the same time, we also overhauled our [iconography documentation](https://design.gitlab.com/product-foundations/iconography) to make icon updates and creation as self-help as possible.\n\n**Guidelines**\n* Each icon must have a clear meaning or metaphor in context.\n* SVGs are optimized for performance and accessibility.\n* Visual changes are minor first, only updating to align with new documentation.\n* A change in metaphor requires validation and/or usability testing.\n* Icons are categorized in Sketch for easier use.\n* Unused icons are deprecated.\n* Icons are added only when existing ones can’t be used.\n\n\n> One of our values is to create a distinct GitLab personality that is strong and consistent. Iconography is a powerful visual cue to the user and should reflect our particular sense of style.\n\nWith directional guidelines and documentation in place, we turned to specific constraints that we could leverage in practice.\n\n## Embracing constraints\n\nWho doesn’t love a good set of constraints? We definitely have some.\n\nPerhaps the largest (pun intended), was the small 16×16 pixel grid used for each icon. We wanted to use a fairly common 24×24 pixel grid with strokes set to 2 pixels, so that we could include more fidelity in each icon, scale more freely, and stay within our base-8 pixel grid. When scaled down to our most common size (16 pixels), the strokes would effectively be 1.5 pixels, which looks great on a HiDPI screen. It's just enough weight to stand out and not feel too bold, although they’re blurry on standard definition due to the half pixels.\n\n![Visual guidelines from the icon documentation](https://about.gitlab.com/images/blogimages/mvc-icon-docs.png){: .shadow.center}\nExamples of visual guidelines from the icon documentation\n{: .note.text-center}\n\nOur analytics show that many users are still on non-HiDPI screens, and while we wanted to push for a new standard, we weren’t ready to make the leap until a majority of users could experience crisp icons in the UI. So, the best choice was to keep the 16 pixel grid and have crisp icons for all.\n\n\n\nAnother key constraint was stroke weight. Within an even-pixel grid, a 1 pixel stroke can never be centered *and* aligned to the pixel grid, so we chose to stick with a 2 pixel stroke weight rather than offset some icons. This meant less room for fidelity in the small space, and as a result we aimed for the least amount of detail that provided the most concept clarity.\n\nBy nature, other constraints exist in the documentation that deal primarily with stylistic elements.\n\n## The process\n\nWork at GitLab starts with an issue or merge request, so we can tackle things in an efficient, async way. Since there were already many icon issues in existence, we created an [epic](https://gitlab.com/groups/gitlab-org/-/epics/1557) to collect them and added new issues to it. As common themes emerged, we knew that updating documentation would be the place to start, as it gave us something to point back to for current issues and something to stand on for new work.\n\nUpdating nearly 300 icons takes time, so we divided them into separate batches where related groups, like everything associated with documents, were updated at the same time. Even though, at this step, style might differ between groups, we were still consistent within the group itself.\n\nEvery batch of icons went through an async group review, where we offered feedback and made adjustments over the course of several days. At the close of the review period, we created a merge request to bring the updates into the SVG library. Then, we could test and evaluate the new icons one last time through a [review app](https://docs.gitlab.com/ee/ci/review_apps/) before releasing them into production.\n\nIn each batch, we added a few new icons and deprecated others. We also released updated versions of our [Sketch UI Kit](https://gitlab.com/gitlab-org/gitlab-design/blob/master/doc/sketch-ui-kit.md) concurrently with the product changes.\n\nNot all icons followed this exact process. For example, concepts like epics and issues are fairly abstract, and we really want to ensure their visual representation is both meaningful and proprietary. There’s an entire subgroup that is just for the status of these, so getting them right is crucial. These icons are currently undergoing three rounds of usability testing, and testing will continue to be an important step in our process.\n\n## Early results and next steps\n\nAfter working through hundreds of icons, five batches of updates, and several rounds of usability testing, reactions thus far have been positive and productive. Here are a few worth noting:\n\n* Several users thought we added a new feature that adds a pre-formatted markdown table in our text editor. The feature has been there for some time, but the previous icon didn’t look enough like a table. If you’ve ever had to manually create a table in markdown, then you know how helpful this feature is. Imagine all the time saved!\n* One of our developers [created a tool](https://leipert-projects.gitlab.io/is-gitlab-pretty-yet/icons/) to audit all instances of FontAwesome icons in the product, so that we can better audit changes and replace instances with our SVGs. He also added the ability in our [SVG Previewer](http://gitlab-org.gitlab.io/gitlab-svgs/?color=indigo) to view icons in different color schemes, so that we could identify issues (like style or color artifacts) in the SVG code and explore theming.\n* Many “is this known” questions are being asked about icons in our Slack channels. This is useful, because they point out where incorrect icons have previously been used and where style differences are too glaring between our SVGs and FontAwesome. That's exciting, because visual updates are helping us prioritize friction in the product caused by icons.\n\n![Before and after of editor icons](https://about.gitlab.com/images/blogimages/mvc-icon-table-ba.png){: .shadow.center}\nBefore (top) and after of text editor icons\n{: .note.text-center}\n\nBecause this was an MVC, the work isn’t done yet. Here are some things to watch for in the coming months:\n\n* Fewer FontAwesome icons in use, with the end goal of only using our own SVG library.\n* Additional grids for specific contexts where scaling icons isn’t ideal.\n* Assessing the effectiveness of documentation and adjusting accordingly.\n* Evaluating instances where the same icon is used for different actions by considering context and performing usability testing where needed.\n* Creating a better and more consistent naming system for icons in Sketch and the SVG library.\n* Conducting more usability testing to ensure metaphors bridge cultural or experiential gaps.\n\nLastly, you can contribute too! If you have anything you’d like us to consider with regard to icons, [create a new issue](https://gitlab.com/gitlab-org/gitlab/issues/new) and tag the GitLab UX Department (@gitlab-com/gitlab-ux). Also, if you’d like to be a part of our testing efforts at any level, be sure to sign up for our [GitLab First Look](/community/gitlab-first-look/) program.\n\n",[9,725,682],{"slug":1058,"featured":6,"template":686},"gitlab-iconography-where-mvc-meets-visual-design","content:en-us:blog:gitlab-iconography-where-mvc-meets-visual-design.yml","Gitlab Iconography Where Mvc Meets Visual Design","en-us/blog/gitlab-iconography-where-mvc-meets-visual-design.yml","en-us/blog/gitlab-iconography-where-mvc-meets-visual-design",{"_path":1064,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1065,"content":1071,"config":1079,"_id":1081,"_type":13,"title":1082,"_source":15,"_file":1083,"_stem":1084,"_extension":18},"/en-us/blog/gitlab-product-navigation",{"title":1066,"description":1067,"ogTitle":1066,"ogDescription":1067,"noIndex":6,"ogImage":1068,"ogUrl":1069,"ogSiteName":672,"ogType":673,"canonicalUrls":1069,"schema":1070},"Inside the vision for GitLab’s new platform navigation","A peek into what inspired our new navigation design, which is coming soon.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668078/Blog/Hero%20Images/cover-image-helm-registry.jpg","https://about.gitlab.com/blog/gitlab-product-navigation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Inside the vision for GitLab’s new platform navigation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christen Dybenko\"}],\n        \"datePublished\": \"2023-05-01\",\n      }",{"title":1066,"description":1067,"authors":1072,"heroImage":1068,"date":1074,"body":1075,"category":1076,"tags":1077},[1073],"Christen Dybenko","2023-05-01","\n\nSoon, we’ll be launching an entirely redesigned navigation in the GitLab product that is based on feedback from users. We’re both excited and a little nervous because navigation is so critical to every user’s workflow. That’s why we made a thoughtful shift in our iteration strategy, taking extra time and intention to develop a new and refined vision. We'd like to share a peek into how we ended up where we did and why we are so excited for our new design!\n\n## We had to invest in the right user experience\n\nBecause it has such an obvious impact on user experience, a navigation overhaul is no small feat. That’s why we fully funded a team to work exclusively on navigation, and provided the time and space to create the best experience possible. During the past year, we put a big focus on design ideation and UX research. It was a lot of work, but we believe this level of user focus has really paid off. \n\nBacked by our amazing design and product leadership team, we put much of our focus on the new navigation for more than nine months while we designed and tested it with end users.\n\nIn this blog post, we’ll share insights on our process, what we learned, and our vision for the future.\n\n![New navigation](https://about.gitlab.com/images/blogimages/2023-04-20-new-navigation-vision/new-navigation-vision.png){: .shadow}\n\n## Predicting what users will need\n\nWhen we first started to think about how to redesign our navigation, the challenge seemed overwhelming. How do we know how to make the best decisions for our navigation? How can anyone know which design or solution is *right*?\n\nWe did not want to make users unhappy for even a short period of time. At GitLab, we have [15 user personas](/handbook/product/personas/#user-personas), incredibly savvy users, and so many different workflows. We had to consider opinions that were not present in our backlog. For example, our power users can be very verbose in issues, but new users are not.\n\nIt is a huge undertaking to get to this kind of understanding and know what is right. Time pressure and needing to ship quickly could have made this type of work impossible at this scale.\n\nThankfully, our team dedicated to navigation was amazing. They invested time to reveal our users' key pain points with navigation, which set the litmus test by which we could evaluate every mockup and solution.\n\n## Establishing a north star\n\nBefore we wrote a line of code or started planning, we did a crucial piece of alignment to know our goals. Our design team led us in a north star exercise where we examined every piece of [System Usability Score (SUS)](/handbook/product/ux/performance-indicators/system-usability-scale/) feedback we had received on navigation.\n\nWe coded this feedback and [three themes](/direction/manage/foundations/navigation_settings/#1-year-plan) emerged. We needed to: \n\n- minimize feelings of being overwhelmed\n- orient users across the platform\n- allow users to pick up where they left off easily\n\nThis north star was amazing for understanding the problem and how to proceed. We learned _a lot_ about what our users’ pain points are and what our users struggle with daily.\n\nThankfully, this also helped us remove the dread of trying to ship something with the impossible goal of being all things to all people as we could now test these three themes with any persona.\n\nWe applied the themes to every design validation effort that we conducted with users moving forward. Our UX Research team also conducted interviews to understand how users felt about these specific themes. It felt incredible to have these insights available right from the start. It was also empowering to let some of the noise go to focus more clearly on what matters and what would move us forward.\n\n## Shifting our perspective on iteration for the right user experience\n\nGitLab is amazing at [iteration](/handbook/engineering/workflow/iteration/), and lately, we’ve been raising the bar on the quality of our [MVCs](/handbook/product/product-principles/#the-minimal-viable-change-mvc) and [definition of done](https://docs.gitlab.com/ee/development/contributing/merge_request_workflow.html?#ui-changes) with the goal of not degrading the current user experience. For navigation, we took this extra seriously, with the intention of protecting every part of the navigation experience.\n\nAs we reviewed the history of many iterative navigation updates over the past five years, we could see that there was very little overall consistency in the code and in the intention of the updates. This is what happens at fast-moving startups, and it can be ok for a period of time, but at some point, it's necessary to take a pause to strip things back for a meaningful change. The small iterations over time gave us an indication of pain points overall, and we needed a thoughtful plan to proceed. \n\nWe decided that anything we change in this new navigation should not degrade a user’s core workflow. We would first hit a baseline for what currently exists in navigation and then make meaningful updates. We agreed that anything we ship after our Alpha had to be fully usable by our own team. We didn’t want users to feel like we’d moved backward or that they had lost functionality in this next phase.\n\nSo, while we have some exciting features planned for the future, we won’t take action on them until we fully refine the core features and address user feedback.\n\n## Iterations now and vision for the next year \n\nWhile holding the baseline promise of no degradation in the new navigation, we did find opportunities to ship small iterations to our current navigation since January. First, we shipped a new navigation called “Your Work” and second, we shipped a new “Explore” menu to all users. Those menus are central to our new navigation vision, but they improved the legacy navigation, too.\n\nAfter launch, we can’t wait to improve even further with more customizable navigation experiences like allowing pins on Your Work and seamless integration with search, command line, and keyboard use. We also have ideas on how to add better landing pages that make life more custom in GitLab, and we couldn’t do that without this new navigation.\n\n## No one likes a navigation re-design\n\nAll that said, we know that no one actually likes a navigation redesign, even if it is best in the long run. Core workflows are ingrained muscle memory that no one wants to mess with if possible.\n\nThat’s why we are releasing our new navigation with a built-in on/off switch. With this approach, you can gradually move to the new navigation by switching back and forth for a little while, as needed. \n\nOur hope is that you’ll take a similar approach and share your feedback along the way, too. We want to hear about your experiences, so please be honest and your feedback will help us iterate.\n\n## What to expect for rollout\n\nWe are proud of our vision for a new navigation! Over the next few months, our new navigation will be available via an opt-in process in the user profile menu, and we'd love your feedback. Watch our Twitter, upcoming release posts, and our [direction page](/direction/manage/foundations/navigation_settings/) for more information!\n","devsecops",[723,9,1078,876],"features",{"slug":1080,"featured":6,"template":686},"gitlab-product-navigation","content:en-us:blog:gitlab-product-navigation.yml","Gitlab Product Navigation","en-us/blog/gitlab-product-navigation.yml","en-us/blog/gitlab-product-navigation",{"_path":1086,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1087,"content":1092,"config":1098,"_id":1100,"_type":13,"title":1101,"_source":15,"_file":1102,"_stem":1103,"_extension":18},"/en-us/blog/gitlab-ux-2020-year-in-review",{"title":1088,"description":1089,"ogTitle":1088,"ogDescription":1089,"noIndex":6,"ogImage":800,"ogUrl":1090,"ogSiteName":672,"ogType":673,"canonicalUrls":1090,"schema":1091},"GitLab UX 2020 Year in Review","2020 was a difficult but productive year. Let's take a look back.","https://about.gitlab.com/blog/gitlab-ux-2020-year-in-review","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab UX 2020 Year in Review\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2020-11-20\",\n      }",{"title":1088,"description":1089,"authors":1093,"heroImage":800,"date":1094,"body":1095,"category":723,"tags":1096},[742],"2020-11-20","\nA global pandemic and broad social unrest have made this year difficult for everyone. When times are as tough as 2020 has proven to be, it's easy to focus on the negative and forget about the many good things that happened along the way. But our product designers, user researchers, and technical writers spend every day doing great work, and we can't let that slip by unnoticed. \n\nIn this post, I want to be intentional about celebrating our successes during a year when many of us wanted to just curl up under a comfy blanket and wait for the turmoil to pass. So, let's take a moment to reflect on some of the things we can feel really proud to have achieved.\n\n## Usability is now a key consideration in our category maturity model\n\nHistorically, we rated the [maturity](https://about.gitlab.com/direction/maturity/) of our product areas fairly subjectively and based almost entirely on feature availability. This year, that changed when we introduced [Category Maturity Scorecards](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/) that are based on user research. Now, we start by considering the Job to be Done (JTBD) that our users need to accomplish, and we gather user feedback to rate the entire experience -- not just functionality, but usability, too. \n\nWe've learned some amazing things through this new approach, and those learnings have enabled us to make [valuable recommendations](https://gitlab.com/gitlab-org/gitlab/-/issues?label_name%5B%5D=cm-scorecard-rec) to improve our product experience in areas like Code Review, Logging, and Issue Management. We have several additional scorecard initiatives underway, which means that our focus on creating an exceptional experience will only continue to grow. \n\nSo often, UX departments complain that they have to fight for executives to acknowledge the importance of usability on business outcomes. In this case, refining category maturity started as an idea from [Sid](https://gitlab.com/sytses), our CEO. This is honestly amazing! It's the kind of user-centered focus that UX teams get really excited about.\n\nAs the person who leads UX at GitLab, it was awesome for me to watch our cross-functional team immediately get on board. Because measuring product maturity isn't an industry standard, through our value of [Iteration](https://handbook.gitlab.com/handbook/values/#iteration) it took us some time (and a false start) to determine the right approach. Fortunately, Product leadership was both enthusiastic and patient, UX Researchers were persistent in taking feedback and making methodological refinements, and Product Designers were courageous in trying something they've never done before. Even better: Technical Writing has been involved, too, as we've identified documentation improvements that will refine our product maturity. \n\nThis was truly a team effort, and I appreciate everyone who participated. 🤝\n\n## Our design system evolved from an idea into reality\n\nWhen I joined GitLab in early 2019, our design system, [Pajamas](https://design.gitlab.com/), was a scrappy project that the design team was working hard to get off the ground. We had designed a set of 28 single-source-of-truth components and were working hard to build them into [GitLab UI](https://gitlab.com/gitlab-org/gitlab-ui), our Vue-based component library.\nWe now have a robust design library that's implemented in Figma, and a large collection of SSOT Vue components are available to use in the product, too. Even more exciting: We're just finishing with implementing our 8 most impactful components across the entire product UI (buttons, alerts, dropdowns, modals, tabs, popovers, and tooltips), which will result in better performance and consistency when we're done. (We're so close!)\n\nMost amazing to me was watching product designers and technical writers jump in to do much of this component migration work themselves. This was no small feat, because frontend development is not something that many of us are deeply skilled at. But, apparently we're both tenacious and brave, because we did the work anyway (with lots of help from our Frontend Engineers and the awesome documentation that our UX Foundations team created). In the process, we've gotten to know both our product features (which are complex) and our code base (which is also complex) even better, which makes us more effective in our day-to-day jobs.\n\nSpeaking of our UX Foundations team, this is another related success. At the beginning of 2020, we got the budgetary support to create a team that is dedicated solely to maintaining our design system and tooling. The team may be small, but its impact certainly isn't. They've already made some big improvements to things like:\n\n* **Improving tooling for designers:** The move to Figma allows for greater collaboration, as well as community contributions. Sketch is only available on Mac platforms and there are no real-time collaboration features. Figma allows us to provide a UI Kit that is available across platforms, while being available for community contributors to use for free. It also promotes collaboration through its use of real-time editing capabilities and version history. We were able to streamline developer handoff by simply linking to the design file, reducing the need for additional plugins such as Sketch Measure.\n* **Making our color palette consistent and accessible:** We addressed color contrast for accessibility and normalized the palette across hues, so that we can better systematize variable use throughout the UI.\n* **Improving consistency in our icons:** With the creation of our own [SVG Library](http://gitlab-org.gitlab.io/gitlab-svgs/), we've been working to [deprecate our use of Font Awesome](https://gitlab.com/groups/gitlab-org/-/epics/2331) throughout the year. With the help of the Frontend department, we've closed out 156 out of 168 issues related to this effort.\n* **Moving towards more accessible workflows:** Near the end of the year, we've started focusing more on building accessibility standards into our workflows. We are currently auditing and updating our [voluntary product accessibility template](https://design.gitlab.com/accessibility/vpat), as well as [incorporating accessibility audit guides](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com/-/merge_requests/2158) into Pajamas.\n\n## Actionable insights\n\nUser research is so incredibly valuable... when you take action on it. But it can be a challenge for research teams to condense their powerful findings into small but compelling insights and then track those insights to determine whether they actually make it into the product.\n\nIn the second half of this year, our user research team made two big strides in this area. First, we started using [Dovetail](https://dovetailapp.com/) to help us more easily analyze research data to find meangingful insights and share it collaboratively with Product Managers and Product Designers (and anyone else who may be interested). But, they took this a step farther by also beginning to [track actionable insights](https://about.gitlab.com/handbook/product/ux/performance-indicators/#actionable-insights) as a performance indicator.\n\nThe considerable effort it took to get both of these programs in place will be worth it as we watch our research efforts result in an even better product.\n\n## Beautifying our docs\n\nComplex products like GitLab require high-quality documentation. Some things you just can't (and shouldn't) communicate through the UI, so users rely on great docs to get their daily jobs done.\n\nOur Technical Writing team (many of whom have been with GitLab less than a year) worked hard to improve our docs site during 2020, including:\n\n- Several UX research projects to discover - and fix! - problems users encounter when using the docs site.\n- A \"Beautification\" effort that focused on an updated visual design. Our 2020 GitLab Contribute event included many rapid improvements to the docs site, and we made many more afterward. (Did you notice?)\n- Ongoing content improvements, including making our docs more consistent, findable, detailed, and easier to read.\n- Adding (a lot of) metadata information to product docs to help connect content contributors with Technical Writers.\n- Coding innovations for automation, such as grammar checking with Vale, a linter, to automatically catch errors before they’re merged.\n\nWe’ve also completed work on a Docs Strategy roadmap to drive even more improvements in the upcoming months.  \n\n## And so much more...\n\n* GitLab Design Talks: In this fun video series, watch designers, technical writers, researchers, and product managers talk about [Iteration](https://www.youtube.com/playlist?list=PL05JrBw4t0KpgzLWbRCXf8o7iap-uoe7o) and [Collaboration](https://www.youtube.com/playlist?list=PL05JrBw4t0KrER807JktsL-addVZa4N0-) at GitLab. (Special thanks to host [Nick Post](https://gitlab.com/npost)!)\n* UX Showcase: See [100+ videos](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz) highlighting exciting UX work happening across GitLab. I learn something new everytime I watch one of these.\n* Blog posts: Read about a variety of topics we were thinking about in 2020, including:\n    * [Designing in an all-remote company](https://about.gitlab.com/blog/designing-in-an-all-remote-company/)\n    * [Running an asynchronous sketching workshop for UX](https://about.gitlab.com/blog/async-sketching/)\n    * [Synchronous collaboration as a remote designer at GitLab](https://about.gitlab.com/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab/)\n    * [A tale of two file editors](https://about.gitlab.com/blog/a-tale-of-two-editors/)\n    * [How holistic UX design increased GitLab.com free trial signups](https://about.gitlab.com/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups/)\n    * [Improving iteration and collaboration with user stories](https://about.gitlab.com/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool/)\n    * [Designing incident management from scratch](https://about.gitlab.com/blog/designing-alerts-and-incidents/) \n    * [Why GitLab is the right design collaboration tool for the entire team ](https://about.gitlab.com/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team/)\n\nAgain, the GitLab UX team does amazing work every single day, and there is no way to capture all of that effort in a single blog post. As this year wraps up, I hope you personally take time to think about your own successes and the impact they had on our fast-moving company. \n\nI also hope you know that we value every one of you. You are appreciated. 💜\n\n{::options parse_block_html=\"true\" /}\n\n\u003Cdiv class=\"panel panel-gitlab-purple\">\n  \u003Cp class=\"panel-heading\">\u003Cstrong>One more thing...\u003C/strong>\u003C/p>\n\u003Cdiv class=\"panel-body\">\n\n\u003Cp>The final 2020 highlight I wanted to ensure is here was Christie Lenneville's own promotion to be GitLab's first \u003Cstrong>Vice President of User Experience (UX)\u003C/strong>. I knew that as both the author of this article, and as a humble (and great) leader she'd be hesitant to add this herself. But it's not only a recognition of her achievements and her potential. VP-level leadership of UX at GitLab should \u003Ci>also\u003C/i> be a signal of how important UX is to our organization and to our community. And it should indicate that usability is an important differentiator for GitLab, and a critical part of our company's strategy. Congratulations again, Christie!\u003C/p>\n\n— Eric Johnson, Chief Technology Officer\n\n\u003C/div>\n\u003C/div>\n\n{::options parse_block_html=\"false\" /}\n",[682,9,876,1097],"research",{"slug":1099,"featured":6,"template":686},"gitlab-ux-2020-year-in-review","content:en-us:blog:gitlab-ux-2020-year-in-review.yml","Gitlab Ux 2020 Year In Review","en-us/blog/gitlab-ux-2020-year-in-review.yml","en-us/blog/gitlab-ux-2020-year-in-review",{"_path":1105,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1106,"content":1112,"config":1118,"_id":1120,"_type":13,"title":1121,"_source":15,"_file":1122,"_stem":1123,"_extension":18},"/en-us/blog/helping-organizations-build-successful-design-systems",{"title":1107,"description":1108,"ogTitle":1107,"ogDescription":1108,"noIndex":6,"ogImage":1109,"ogUrl":1110,"ogSiteName":672,"ogType":673,"canonicalUrls":1110,"schema":1111},"Benefits of building a design system for your organization ","At GitLab, we want to help organizations build successful design systems. In order to do that, we are looking for your feedback.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681349/Blog/Hero%20Images/helping-organizations-build-successful-design-systems.png","https://about.gitlab.com/blog/helping-organizations-build-successful-design-systems","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Benefits of building a design system for your organization \",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taurie Davis\"}],\n        \"datePublished\": \"2020-06-16\",\n      }",{"title":1107,"description":1108,"authors":1113,"heroImage":1109,"date":1114,"body":1115,"category":764,"tags":1116},[1013],"2020-06-16","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n## Creating a design system\n\nOver the last few years, GitLab has invested in the creation of [Pajamas](https://design.gitlab.com/), our living\ndesign system. We believe that a design system can help us scale more efficiently by creating a shared\nvision and language that is used across departments and teams. \n\nNow, we're interested in hearing from our\ncommunity: **How can GitLab help you build a successful design system in your own organization?**\n\n### What is a design system\n\nA design system is a series of documentation that includes both design practices, as well as frontend guidelines.\nLive coded demos are included to allow cross-functional teams to easily reuse styles and components in\nseveral instances across your product. The underlying principles and guidelines that you develop are what\nset your design system apart from others.\n\n### Benefits of a design system\n\nDesign systems provide many benefits to organizations including:\n\n**Efficiency**\n- Product Designers can spend more time solving problems and less time designing (and redesigning) UI components.\n    Components can be reused, making design efforts scalable and ensuring the UI stays [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself).\n- Engineers can reference design documentation that helps them to easily eliminate inconsistencies between\n    design and code without assistance from a Product Designer.\n- Engineers can find coding and development guidelines that help them write better code and conform\n    to set practices more efficiently.\n- Product Managers can quickly propose solutions that follow documented usability guidelines.\n\n**Consistency**\n- Teams can make fast, continuous feature additions within their iterative groups, while still maintaining\n    consistency with other product areas.\n- Users can get up to speed more quickly on new features, because they don’t need to spend time learning how to\n    interact with inconsistent UI patterns.\n- Product Designers can feel more confident that their designs are visually appealing, consistent, accessible, and on brand.\n- Marketing and UX departments can create consistent experiences across platforms through a shared visual language.\n\n**Improved communication**\n- Teams can quickly envision and align on the details of how a proposed solution might be implemented.\n- Organizations are able to prove to customers that they have a deep commitment to improving the experience of the product.\n- Departments are aligned through shared principles and personas.\n\n## Challenges with design system integration\n\nAlthough the benefits of a design system may be clear to many, most organizations struggle with integrating a design\nsystem workflow into their organization. Building a design system takes more upfront planning and gaining buy-in from\nyour organization’s executive team can be difficult.\n\n## How can GitLab help?\n\nAt GitLab, we recognize the benefits a design system can bring to an organization, and we're exploring whether we can support other organizations with this experience. For this reason,\nwe’ve begun drafting a [design system direction page](/direction/manage/foundations/) that focuses on providing a foundation\nfor your organization to begin building and implementing your own design system.\n\nWe’d love to know more about  whether your organization has begun building its own design system:\n\n- Whether your organization has begun building your own design system\n- If yes, how has a design system helped you? What struggles have you faced with implementing a design system?\n- If no, what has stopped you?\n\nIf you have thoughts, suggestions, or feedback, please contribute to our \n[Design System MVC and Roadmap Discussion issue](https://gitlab.com/gitlab-org/gitlab/-/issues/219445).\n",[1117,9],"careers",{"slug":1119,"featured":6,"template":686},"helping-organizations-build-successful-design-systems","content:en-us:blog:helping-organizations-build-successful-design-systems.yml","Helping Organizations Build Successful Design Systems","en-us/blog/helping-organizations-build-successful-design-systems.yml","en-us/blog/helping-organizations-build-successful-design-systems",{"_path":1125,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1126,"content":1132,"config":1137,"_id":1139,"_type":13,"title":1140,"_source":15,"_file":1141,"_stem":1142,"_extension":18},"/en-us/blog/hey-icons-lighten-up",{"title":1127,"description":1128,"ogTitle":1127,"ogDescription":1128,"noIndex":6,"ogImage":1129,"ogUrl":1130,"ogSiteName":672,"ogType":673,"canonicalUrls":1130,"schema":1131},"Hey icons, lighten up","Icons can be better, here's how.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663383/Blog/Hero%20Images/tanuki-bg-full.png","https://about.gitlab.com/blog/hey-icons-lighten-up","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Hey icons, lighten up\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jeremy Elder\"}],\n        \"datePublished\": \"2021-12-17\",\n      }",{"title":1127,"description":1128,"authors":1133,"heroImage":1129,"date":1134,"body":1135,"category":298,"tags":1136},[850],"2021-12-17","\n\nAround this time a few years ago, I had the opportunity to bring more consistency and rigor to GitLab’s product icons, and ever since then I’ve been working through the next iteration. You can read more about the previous effort in this post, [GitLab Iconography: MVC meets visual design](/blog/gitlab-iconography-where-mvc-meets-visual-design/). Today, though, the next iteration is here, and I’d like to briefly share a bit of what went into it.\n\nFirst up, a little housekeeping. Changes to a user interface (UI) can be highly subjective, and while I don’t think preference will or should ever be eliminated, it shouldn’t be the driving factor for change. To that end, we always take a thoughtful approach to any change in the GitLab UI. And in the spirit of iteration, I think my colleague, Tim Noah, put it best when he said that we’re privileged to “work on the ink that never dries.” This isn’t the first iteration, and it certainly won't be the last.\n\n## Icons can be better\n\nWhile there’s more nuance than I can unpack here, at a high level the problem we faced was this: *Icons can be better*. And *better* isn’t that subjective after all; it’s measurable.\n\nTo name a few things, icons can:\n\n- Be more balanced with other UI elements.\n\n- Better align with the brand.\n\n- Be constructed to be more future-proof and available for further iteration.\n\n- Work well in both light and dark UI.\n\n- Better convey abstract concepts and metaphors.\n\n## Choosing what to change\n\nHistorically, our product icons had most commonly used a 16-pixel grid and 2-pixel stroke. In a condensed UI, space is at a premium, and there’s a careful balance to strike between helpfulness and distraction. This isn’t a site where icons are visual anchors and decoration. This is a complex application where icons perform tasks and indicate status and state. They should be available when you need them, but not in the way when you don’t.\n\nSince each icon concept and metaphor can be evaluated on its own, and the grid size was out of scope, I focused on a single shared attribute that relates to all of the ways we determined icons could be better: the stroke weight. Seriously, though, a seemingly trite attribute can have that much impact. Instead of the previous 2-pixel stroke, the icons now use a 1.5-pixel stroke. It turns out that half of a pixel is a big deal.\n\n![Before and after icon comparison in light and dark UI](https://about.gitlab.com/images/blogimages/light-icons/light-icons-before-after.png){: .medium.center}\nBefore (top) and after icon comparison in light and dark UI\n{: .note.text-center}\n\n## Exploring the benefits\n\nHere are some of the benefits we’re starting to experience as a result:\n\n- Because minor icon differences and details are now more distinguishable, our icons have better fidelity. That makes a big difference when a metaphor may fall short with less detail.\n\n- GitLab uses system fonts, and the updated icons match the weight of a regular sans-serif font at body size (the most common font in our UI). Icons don’t compete with the text as much, and there’s a better balance of visual weight.\n\n- For users who experience visual impairments, UI elements can appear blurry. With more negative space in the icons, there’s less opportunity for elements within each icon to blend together and become indistinguishable.\n\n- In a dark UI, the light emitted from an element tends to bleed into surrounding pixels. This creates a ghosting effect and makes the element feel visually heavier than it is. A lighter stroke weight can help offset this effect and make the dark UI as balanced as its light counterpart.\n\n- Previously, we went with a 2-pixel stroke weight, because there was still a significant percentage of users with standard resolution monitors. This meant that we weren’t comfortable with making the leap to aesthetics that favored higher-resolution displays, because a 1.5-pixel stroke could have appeared blurry for many users. Based on current analytics, though, we no longer feel constrained by display resolution and have solved our half-pixel alignment concerns.\n\n- Icons feel more consistent, polished, and on brand than before. They also share more characteristics with the marketing iconography.\n\n- Getting an icon asset ready for production used to mean that we needed an original layered version and another outlined version to export. We create GitLab product icons in Figma, so we can now leverage their boolean unions to keep all icons in an editable state and export a single pathed SVG from the same layers. This is a huge efficiency gain and also makes it easier to create differently sized icon sets, if we need to. We’re also leveraging reusable icon elements as components to help propagate changes.\n\n- Lastly, on a more subjective point, the UI in general feels lighter and more modern, both of which are desirable outcomes and something we’ll continually work towards with other parts of the UI.\n\n![Before and after icon comparison in GitLab's navigation](https://about.gitlab.com/images/blogimages/light-icons/light-icons-nav.png){: .medium.center}\nBefore (left) and after icon comparison in the navigation\n{: .note.text-center}\n\n## What’s trending\n\nDo a quick search, and you’ll find that this road has been traveled before, with product after product making the shift to lighter icons. At first, it might seem like this is another UI trend to chase, but look a little closer and you’ll find that the real trend is to create a better user experience. And that’s a trend we’re happy to chase all day.\n",[9,725,682],{"slug":1138,"featured":6,"template":686},"hey-icons-lighten-up","content:en-us:blog:hey-icons-lighten-up.yml","Hey Icons Lighten Up","en-us/blog/hey-icons-lighten-up.yml","en-us/blog/hey-icons-lighten-up",{"_path":1144,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1145,"content":1151,"config":1158,"_id":1160,"_type":13,"title":1161,"_source":15,"_file":1162,"_stem":1163,"_extension":18},"/en-us/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups",{"title":1146,"description":1147,"ogTitle":1146,"ogDescription":1147,"noIndex":6,"ogImage":1148,"ogUrl":1149,"ogSiteName":672,"ogType":673,"canonicalUrls":1149,"schema":1150},"How holistic UX design increased GitLab.com free trial signups","We boosted free trial signups by 141% by focusing on designing whole experiences instead of separate screens, small interactions, or pieces of UI.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681113/Blog/Hero%20Images/user-journey-map.jpg","https://about.gitlab.com/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How holistic UX design increased GitLab.com free trial signups\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matej Latin\"}],\n        \"datePublished\": \"2020-02-27\",\n      }",{"title":1146,"description":1147,"authors":1152,"heroImage":1148,"date":1153,"body":1154,"category":1155,"tags":1156},[951],"2020-02-27","\n\nOur new improved free trial signup flow launched in October 2019 and it reduced the number of interactions a user needed to do to complete the process from around 35 to 15. We reduced the time required to sign up and start a trial from more than five minutes to around 2.5 minutes – less than half of the original. Not surprisingly, our free trial signups soon went from around 400 per week to more than 800. This is the journey of three designers battling the complexity that comes with user experiences that weren’t designed holistically but instead grew “organically.”\n\n## Discovering the problems\n\nI started working on designing a new user onboarding experience sometime in the second quarter of 2019. The first step I took was to map the existing user journey from when users sign up for GitLab to the end of the existing onboarding. I wanted insight into the mindset of users at the moment they finished signing up for a free trial. We wanted our users to be excited and eager about the onboarding experience. I never expected to find what I did by mapping the current user journey.\n\n![GitLab’s marketing page](https://about.gitlab.com/images/blogimages/free-trial-improvements/homepage.jpg){: .large.shadow.center}\n\nI started to map the journey on the homepage of our marketing website and clicked on the big orange “Try GitLab for FREE” button. That took me to our free trial landing page where a user can choose between trialing GitLab as a SaaS (GitLab.com, hosted by GitLab) or self-managed (GitLab Self-Managed) solution. And this is where the problems started to appear.\n\n### Symptoms of a broken user experience\n\nThe two options for trialing GitLab (SaaS or Self-Managed) were presented by two tabs, one of which (Self-Managed) was active by default. To start a Self-Managed trial, the user had to fill in a large form right away. The SaaS option, on the other hand, only required a click on a button. My assumption here was that setting up a Self-Managed GitLab trial takes much longer so I concluded that someone who just stumbled upon GitLab is more likely to try it out as a SaaS. But on this page, few users actually noticed that option.\n\n![Original Free trial landing page](https://about.gitlab.com/images/blogimages/free-trial-improvements/landing-page.jpg){: .large.shadow.center}\n\nProblems identified:\n\n1. Self-Managed is the prioritized option but users need to fill in a large form to get started. Huge drop-off is expected even before the signup flow started.\n2. Affordance issues: the second option (the non-active one) was barely discoverable because of the way it was presented. The contrast was too low and most users missed it.\n3. Even the simpler option for starting a SaaS trial had instructions that needed to be followed. Most users missed these instructions and simply clicked on the big orange button labeled “Start Your Trial.”\n\n![Instructions](https://about.gitlab.com/images/blogimages/free-trial-improvements/instructions.jpg){: .shadow.medium.center}\n\nSigning up for a SaaS GitLab trial required users to complete two separate steps in the correct order. If step 1 wasn't completed, clicking on the “Start Your Trial” button led to a free trial signup flow that couldn’t be completed.\n\nSo a user would either have to fill in a large form and install their own instance of GitLab or follow these instructions to start a trial on GitLab.com. This reminds me of a design joke I heard ages ago but it stuck with me because it’s so true:\n> Design is like a joke: if it needs an explanation, it’s not a good joke.\n\u003C!-- ### Two separate steps to sign up for a free trial -->\n\nI didn’t know this at the time but these instructions where there for a reason. Users needed to complete two separate steps in two different applications to successfully sign up for a free trial – GitLab.com and a tool we call Subscription Manager. That’s why we had these instructions written on this page and that’s why the experience was completely broken if they weren’t followed. The following is the user journey map that I created:\n\n![Original user journey map](https://about.gitlab.com/images/blogimages/free-trial-improvements/original-user-journey-map.jpg){: .large.shadow.center}\n\nAltogether, it took users more than five minutes and almost 40 interactions to complete the process. When I say “interactions” I mean things like clicking a button, landing on a page, filling in a form field and similar. A user who just completed the process of signing up for a free trial of a tool should feel excited, but in our cause they most probably felt exhausted. You can [watch my video walkthrough of the experience](https://www.youtube.com/watch?v=O-zjek64d0g&feature=youtu.be) as it was at the time. Here are the key points of the experience:\n\nUsers had to sign up for a [GitLab.com](http://gitlab.com) account first. After this step, they were shown an “Almost finished” message as they had to confirm their email by clicking on a link in an email message that was automatically sent.\n\n![Registration form](https://about.gitlab.com/images/blogimages/free-trial-improvements/registration-form.jpg){: .large.shadow.center}\n\nProblems discovered:\n\n- We asked for a lot of information, probably too much for simply signing up.\n- We sent the newly signed-up users to their inbox – a huge source of distractions.\n\nAfter they successfully confirmed their email, we showed them the following screen – the beginning of the Free Trial signup:\n\n![Free trial sign up](https://about.gitlab.com/images/blogimages/free-trial-improvements/free-trial-signup.jpg){: .large.shadow.center}\n\nProblems identified:\n\n- Visual style was different.\n- We asked for a lot of information again. A lot of this we already had from their GitLab.com signup but we didn’t use any of it to pre-fill the form.\n\nAfter they filled in and submitted the Free Trial signup form, they were shown the following from the Subscription Manager app. This is when the users started to interact with the second app.\n\n![Subscription manager](https://about.gitlab.com/images/blogimages/free-trial-improvements/subscription-manager.jpg){: .large.shadow.center}\n\nProblems identified:\n\n- We told the users to confirm their email address again. It’s a different app for us, but for them it’s all GitLab.\n- The most obvious next step – confirming the email address – actually led to a broken flow that couldn’t be completed.\n- This screen created a lot of confusion and users didn’t know what they had to do. Sign in, register, or sign in with GitLab.com?\n\nIn the end, signing in with GitLab.com was the only way to successfully complete the process. It took the users to the next screen – activating their free trial.\n\n![Free trial activation](https://about.gitlab.com/images/blogimages/free-trial-improvements/free-trial-activation.jpg){: .large.shadow.center}\n\nProblems identified:\n\n- We asked the users to choose which group their free trial is for. We asked this even if the user had no groups created at all. In that case, the users could only apply the trial to their namespace so the dropdown only had one option. As this was commonly the case, this step was unneeded manual work.\n\nTo add to the confusion, we sent users to the final screen in the flow: the billing overview. The fact that we sent them to this screen wasn’t the problem, it was the information we showed.\n\n![Billing page](https://about.gitlab.com/images/blogimages/free-trial-improvements/billing.jpg){: .large.shadow.center}\n\nProblems identified:\n\n- We told the users they’re on the Gold Plan but we also showed the purchase options right below. Some users were confused about whether their trial was actually activated or not.\n\nWith all this done we could summarize what the main problems that needed to be solved were:\n\n- Two separate apps with different visual styles\n- The two apps didn’t work well with each other\n- We repeatedly asked for information users already provided\n- Poor flow of screens and unclear information architecture led to confusion. Users didn't know where they were and what they were required to do.\n\n## Fixing a broken flow\n\nOk, so at this point I learned that the flow for signing up for a free trial was disjointed and sometimes even broken. I recognized what the main reason for that was – separate applications not communicating with each other through some form of automation – as well as other UI and UX issues of course.  To tackle the main problem, I came up with a vision: *about one minute and no more than 15 interactions required to complete the free trial signup flow.* The main outcome I wanted to achieve with this work was to improve the state of mind a user is in after successfully signing up for a free trial – *excited* instead of *exhausted*.\n\n![Users state of mind](https://about.gitlab.com/images/blogimages/free-trial-improvements/user-state-of-mind.jpg){: .large.center}\n\nBut how do we get there? Well, first of all, we need to move away from forcing users to interact with two separate applications. We do that by moving the second part of the process into the first application (GitLab.com) and making it communicate with the other application in the background. I proposed a unified signup flow that happens in one application but is adapted based on the user’s intent. Is the person an existing GitLab.com user trying to sign up for a free trial? Or are they a new user and they need to sign up for both GitLab.com and Subscription Manager accounts?\n\n![Unified flow](https://about.gitlab.com/images/blogimages/free-trial-improvements/unified-flow.jpg){: .shadow.large.center}\n\nMy colleague [Timothy Noah](/company/team/#timnoah) took over from here as he was the designer working with the team that owned this part of the product. He completed a [UX scorecard](https://gitlab.com/gitlab-org/ux-research/issues/285) and [video-documented](https://www.youtube.com/watch?v=MkTOwTxsoL8) the flow again. The result of his work was a [well structured approach](https://gitlab.com/gitlab-org/ux-research/issues/304) to breaking things down into smaller steps but with a holistic overview. Based on all this work, he then created a proposal of what the user journey should be like.\n\n![Proposed user journey](https://about.gitlab.com/images/blogimages/free-trial-improvements/proposed-user-journey.jpg){: .shadow.large.center}\n\nAnd translated it into actual UI, pages and their flow:\n\n![Proposed flow](https://about.gitlab.com/images/blogimages/free-trial-improvements/proposed-flow.jpg){: .large.center}\n\n[This clickable prototype](https://sketch.cloud/s/v1zJb/a/mgkLnw/play) illustrates perfectly how the new free trial signup flow should behave. It’s immediately clear that it’s much simpler and more cohesive than the original.\n\nWith that we could also improve the Free Trial landing page by removing the instructions (as we didn’t need them anymore) and balancing the two options for starting a free trial:\n\n![Improved free trial landing page](https://about.gitlab.com/images/blogimages/free-trial-improvements/improved-landing-page.jpg){: .large.shadow.center}\n\n## The new free trial signup flow launches\n\nAfter a lot of hard but well coordinated work, the new free trial signup flow launched on October 29, 2019. The results were clear in less than one week. The week before the launch, we had 466 free trial signups. In the week of the launch the number rose to 628, then to 842 in the week after. They remained well above 800 throughout November. We then saw a small dip during December (but it never fell below 600) and the climb resumed in January. We’re now getting more than 900 free trial signups per week.\n\n![Free trial signups chart](https://about.gitlab.com/images/blogimages/free-trial-improvements/chart.jpg){: .large.center}\n\nI quickly crunched the numbers and came to the following conclusion:\n\n> Average signups per week before launch: **330** \u003Cbr>\n> Average signups per week after launch: **794** \u003Cbr>\n> Which results in an improvement of **141%**\n\nSo we more than doubled the amount of free trial signups, but what exactly led to these results? Another colleague, [Kevin Comoli](/company/team/#kcomoli), recently did a follow-up [UX scorecard](https://gitlab.com/gitlab-org/growth/product/issues/166) to rescore the experience. His findings? It now takes around 17 interactions (instead of the original 37) and around 2.5 minutes to complete the process. So we reduced both by more than half and that’s why we’re seeing such an increase in completed signups. Take a look at the latest version of the [user journey](https://app.mural.co/t/gitlab2474/m/gitlab2474/1572360181709/cb4df793a4d4b98395b8c98c6510d21b4a2d6747) mapped by Kevin.\n\n## Organically grown versus holistically designed experiences\n\nExperiences are either intentionally and holistically designed by someone or they get designed by what I call “organically grown” smaller parts of the experience. It’s like cultivating a garden: we start off by planting a few flowers and bushes but leave some empty space around them. Eventually, if we don’t do anything, this empty space will get overgrown with weeds. Our flowers and bushes will also grow in an uncontrolled way. So until a gardener comes around and tidies everything up, our garden will be a mess. It’s the same with our digital products – if a designer with a holistic overview isn’t involved, different parts of our products grow into a mess that doesn’t work as a whole. The *holistic overview* is the key here. It’s not enough to have designers involved if all they do is design separate screens instead of complete experiences. We need to look at how things work as a whole. That’s when designers, and the teams they work with, are most successful.\n\n## Where do we go from here?\n\nWe’re thrilled about the improvements we have already achieved but we also feel there’s a lot more we can do. I personally would still like to see the time required to complete the process be reduced to around a minute. As part of his UX scorecard, Kevin also came up with additional [recommendations for improvements](https://gitlab.com/groups/gitlab-org/growth/-/epics/7). There, he talks about trimming down the information shown in the process, improving the entry points to the flow and tailoring its steps based on the user type. We’re all looking forward to  these improvements being implemented.\n\nPhoto by [Startaê](https://unsplash.com/@startaeteam?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) Team on [Unsplash](https://unsplash.com/s/photos/post-it?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n","news",[682,9,1157,876],"growth",{"slug":1159,"featured":6,"template":686},"how-holistic-ux-design-increased-gitlab-free-trial-signups","content:en-us:blog:how-holistic-ux-design-increased-gitlab-free-trial-signups.yml","How Holistic Ux Design Increased Gitlab Free Trial Signups","en-us/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups.yml","en-us/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups",{"_path":1165,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1166,"content":1171,"config":1177,"_id":1179,"_type":13,"title":1180,"_source":15,"_file":1181,"_stem":1182,"_extension":18},"/en-us/blog/how-to-improve-communication-remote-designer",{"title":1167,"description":1168,"ogTitle":1167,"ogDescription":1168,"noIndex":6,"ogImage":1008,"ogUrl":1169,"ogSiteName":672,"ogType":673,"canonicalUrls":1169,"schema":1170},"How to improve your communication as a remote designer in 6 simple steps","When you're explaining designs or requesting feedback, it's easy to give too much information. Here are some tips on how you can communicate better as a designer, especially if you're working remotely.","https://about.gitlab.com/blog/how-to-improve-communication-remote-designer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to improve your communication as a remote designer in 6 simple steps\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pedro Moreira da Silva\"}],\n        \"datePublished\": \"2021-01-06\",\n      }",{"title":1167,"description":1168,"authors":1172,"heroImage":1008,"date":1174,"body":1175,"category":764,"tags":1176},[1173],"Pedro Moreira da Silva","2021-01-06","\n{::options parse_block_html=\"true\" /}\n\n## Communication is hard\n\nAt GitLab, [efficiency](https://handbook.gitlab.com/handbook/values/#efficiency) is one of our core values. Being efficient in everything we do is important, but it's even more important when communicating and collaborating with others. We need this emphasis on efficiency, [collaboration](https://handbook.gitlab.com/handbook/values/#collaboration), and [communication](https://about.gitlab.com/handbook/communication/) for GitLab to work as an all-remote company, with zero offices and team members distributed across the globe.\n\nIn the context of design, when you're explaining a design decision or requesting feedback, it's easy to fall into the trap of giving too much information. **You want people to understand it right away, so you give as much background and arguments as possible. The problem is that long messages and explanations can put up a collaboration-barrier.** When people have many things competing for their attention, it's hard for them to take the necessary time to read long messages and engage themselves in a constructive discussion. Also, often the most important points get diluted because of how long something is.\n\n**So how can you communicate better and more efficiently as a designer, especially if you're working remotely?** I'm a designer working remotely for over 4 years and I've learned a lot about communication. Let me share 6 practical tips that you can use when sharing information or requesting something from someone:\n\n1. Important things first\n1. Keep it short\n1. Balance context and conciseness\n1. Use multiple formats\n1. Clear calls-to-action\n1. Use simple language\n\nAt the end of this article, there's a [structure and example that puts all of these tips together](#example), so that you can improve your communication today.\n\n## ❗️ Important things first\n\n**Make sure you communicate the important things first.** Journalists do this very well by using the [inverted pyramid](https://en.wikipedia.org/wiki/Inverted_pyramid_(journalism)) method: information is prioritized so that the major details come before the minor details. So empathize with your audience and think how much little time they can afford to invest in your message. Prioritize and structure your communication so that the key aspects come first and it's as easy as possible to learn about them.\n\n## 📟 Keep it short\n\n[**Keeping written communication short**](https://handbook.gitlab.com/handbook/values/#keep-broadcasts-short) **and** [**giving short verbal answers**](https://handbook.gitlab.com/handbook/values/#short-verbal-answers) goes hand in hand with communicating the important things first. If you need to give a lot of information, maybe there's a communication or expectations problem.\n\nAlthough we default to [asynchronous communication](https://about.gitlab.com/handbook/communication/#asynchronous-communication) at GitLab, sometimes a short video call is enough to unblock and make sure everyone's aligned without having to invest too much time in writing and reading something. Our rule of thumb is: “if you have gone back and forth 3 times, it's time for a video call.” (also see [video calls guidelines](https://about.gitlab.com/handbook/communication/#video-calls)).\n\nOther times, it can also be that the topic at hand is just too large to discuss in one go. Think about how you can break it down into smaller, more “consumable” pieces. It will make life easier for you, the other participants, and anyone else that is following that topic. To help you break things down, read “[Iterate Like a GitLab Designer](https://about.gitlab.com/blog/iterate-like-a-gitlab-designer/)” or our handbook section on [iteration](https://handbook.gitlab.com/handbook/values/#iteration).\n\n## 🤹 Balance context and conciseness\n\n**Try to provide as much context as possible while balancing the conciseness of your message.** This may seem the opposite of keeping it short, but you do need to strike a balance. You don't want your message to be too short, as it can cause confusion and require clarification, which ultimately delays things. But you also don't want your message to be too long, for all of the reasons I've mentioned so far. Striking this balance sounds incredibly challenging, but fortunately, we have some methods to help us with that, like the inverted pyramid that I described before or multiformat communication.\n\n## 🎨 Use multiple formats\n\n**Communicating through multiple formats means thinking about your audience and applying your message to the formats that are most likely to attract that audience.** An example is requesting feedback on an idea: you can share an image, a brief paragraph explaining the idea, a list of bullet points with the pros and cons, and maybe even a short video where you walk people through it. This way, each person jumps to and consumes the format that resonates the most with them, how they want it.\n\nBut remember that you don't have to use every format, every time. It depends on who you're communicating with, what you're communicating, and when a certain action is needed. Think about these aspects and choose the communication format that best suits them (and also the time you can invest in crafting your message).\n\n## ☝️ Clear calls-to-action\n\n**If you have calls-to-action, make them clear, direct, and specific.**\n\nPerhaps the most important aspect of those three: try to direct your asks to specific people, instead of a group of people or no one at all. The work you put into selecting and targeting who you ask is proportional to the quality of their responses. Asking a group of people is sometimes necessary, but there's a risk of getting nothing but “radio silence,” so be extra careful in crafting your message if you're targeting a group.\n\nRegarding CCs, one of our [communication best practices](https://about.gitlab.com/handbook/communication/#top-tips-and-best-practices) says it best:\n\n> It is OK to bring an issue to someone's attention with a CC (\"cc @user\"), but CCs alone are not enough if specific action is needed from someone. The mentioned user may read the issue and take no further action. If you need something, please explicitly communicate your need along with @ mentioning who you need it from.\n\nBe clear and specific about the who, what, and why. If it's a vague or broad ask, it will be much more difficult for others to respond.\n\nFinally, place any asks you have at the beginning of your message. These asks fall into the “important things first” tip because, well, they are supposed to be important! If possible, consider repeating them at the end of the message as a reminder.\n\n## 👐 Use simple language\n\n**Finally, use** [**simple language**](https://about.gitlab.com/handbook/communication/#simple-language) **and terms that everyone understands** (see [ubiquitous language](https://about.gitlab.com/handbook/communication/#ubiquitous-language)). For example, instead of using the “IxD” acronym, say “interaction design.” Or explain what that means with simple language if you can, like saying “how a user might interact with the user interface and how it behaves.”\n\n## Example\n\nTo bring it all together, I'll first share with you a structure that you can use when requesting feedback or communicating your work, either in a written message, a video, or a presentation:\n\n1. **Summary**: A very short summary ([tl;dr](https://en.wiktionary.org/wiki/tl;dr)) of your message, with simple language and shared terms. If possible, consider bolding the whole summary so it sticks out from the rest.\n1. **Asks**: Be clear about what you want and until when. If possible, mention specific people and make sure to bold/highlight their names (if not automatically highlighted). When requesting feedback, specify the kind of feedback you're looking for, what they should comment on, and also what they should not comment on.\n1. **Walkthrough**: If you have a video or presentation that gives an overview of the topic, link to it. Better yet, embed it in your message to reduce clicks and friction, but always keep a link so it's accessible to everyone.\n1. **Visual**: Try to add a simple image/diagram that describes the core elements of what you're communicating.\n   - If you have more visuals that you'd like to share, link to an external page with them. For example, at GitLab we use Figma to design user interfaces, so we link to Figma files where people can view all of the design work.\n1. **Details**: More information in the form of short paragraphs or lists. It could be links to any additional references, support documentation, or artifacts. Remember to keep them short!\n   - Tip: Some writing tools support the `\u003Cdetails>` HTML tag, that allows you to easily hide information behind a toggle, like an accordion. See the [MDN web docs](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/details) for a simple example and copy-pastable markup.\n1. **Close**: Consider reiterating your asks and thank people for their time.\n\nAnd to see how this can work in practice, here's an example message, where I requested feedback from my team members on a few possible design options:\n\n![Example feedback request message showing an embedded video and collapsible information panels](https://about.gitlab.com/images/blogimages/how-to-improve-communication-remote-designer/example.gif){: .shadow.center}\n\n## Keep improving your communication skills\n\nThe act of improving one's communication skills doesn't stop, because the “why, what, how, and who” are always changing. The quality of communication can make or break an individual, a team, or an organization. As Anthony Robbins puts it:\n\n> The way we communicate with others and ourselves ultimately determines our quality of life.\n\nIn this article I focused on writing, speaking, and showing. But communication is also about how you read, listen, and watch. Maybe I'll write about that other side of communication in the future. In the meantime, I leave you with our [handbook page on communication](https://about.gitlab.com/handbook/communication/), which is a great place to learn more about what makes good communication in a remote company.\n\nCover image by [Stellan Johansson](https://unsplash.com/@stellanj) on [Unsplash](https://unsplash.com/photos/1PP0Fc-KSd4)\n{: .note}\n",[811,9,683,682],{"slug":1178,"featured":6,"template":686},"how-to-improve-communication-remote-designer","content:en-us:blog:how-to-improve-communication-remote-designer.yml","How To Improve Communication Remote Designer","en-us/blog/how-to-improve-communication-remote-designer.yml","en-us/blog/how-to-improve-communication-remote-designer",{"_path":1184,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1185,"content":1191,"config":1197,"_id":1199,"_type":13,"title":1200,"_source":15,"_file":1201,"_stem":1202,"_extension":18},"/en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo",{"title":1186,"description":1187,"ogTitle":1186,"ogDescription":1187,"noIndex":6,"ogImage":1188,"ogUrl":1189,"ogSiteName":672,"ogType":673,"canonicalUrls":1189,"schema":1190},"How we are closing the gap on replicating *everything* in GitLab Geo","Developing an internal framework to enable other teams to add Geo support for their features","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669673/Blog/Hero%20Images/engineering.png","https://about.gitlab.com/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we are closing the gap on replicating *everything* in GitLab Geo\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Michael Kozono\"}],\n        \"datePublished\": \"2021-04-29\",\n      }",{"title":1186,"description":1187,"authors":1192,"heroImage":1188,"date":1194,"body":1195,"category":764,"tags":1196},[1193],"Michael Kozono","2021-04-29","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIn early 2020, it took 3.5 months of solid work to implement replication of a new data type in Geo. One year later, support can be added within a month -- including development and all required reviews. How did we do it? First, let me introduce you to Geo.\n\n## What is Geo?\n\n[GitLab Geo](https://about.gitlab.comhttps://docs.gitlab.com/ee/administration/geo/index.html) is the solution for widely distributed development teams and for providing a warm-standby as part of a disaster recovery strategy. Geo replicates your GitLab instance to one or more local, read-only instances.\n\n## What are data types?\n\n[GitLab Geo was released in June 2016 with GitLab 8.9](https://about.gitlab.com/releases/2016/06/22/gitlab-8-9-released/#gitlab-geo-new-product) with the ability to replicate project repositories to a read-only secondary GitLab site. Developers located near secondary sites could fetch project repositories as quickly as if they were near the primary.\n\nBut what about wiki repositories? What about LFS objects or CI job artifacts? In GitLab, each of these things is represented by different Ruby classes, database tables, and storage configurations. In Geo, we call these data types.\n\n## Is it really that hard to copy data?\n\nWhen we say a new data type is supported by Geo, this is what we mean:\n\n* Backfill existing data to Geo secondary sites\n* As fast as possible, replicate new or updated data to Geo secondary sites\n* As fast as possible, replicate deletions to Geo secondary sites\n* Retry replication if it fails, for example due to a transient network failure\n* Eventually recover missing or inconsistent data, for example if Sidekiq jobs are lost, or if infrastructure fails\n* Exclude data according to [selective sync settings](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization) on each Geo secondary site\n* Exclude remote stored data unless [Allow this secondary node to replicate content on Object Storage](https://docs.gitlab.com/ee/administration/geo/replication/object_storage.html#enabling-gitlab-managed-object-storage-replication) is enabled on a Geo secondary site\n* Verify data integrity against the primary data, after replication\n* Re-verify data integrity at regular intervals\n* Report metrics to Prometheus\n* Report metrics in the Admin UI\n* View replication and verification status of any individual record in the Admin UI\n* Replication and verification job concurrency is configurable in Admin UI\n* Retry replication if data mismatch is detected ([coming soon to all data types using the framework](https://gitlab.com/gitlab-org/gitlab/-/issues/301244))\n* Allow manual re-replication and re-verification in the Admin UI ([coming soon to all data types using the framework](https://gitlab.com/gitlab-org/gitlab/-/issues/216100))\n* And more\n\n## How to iterate yourself into a problem\n\n[Iteration is a core value](https://handbook.gitlab.com/handbook/values/#iteration) at GitLab. In the case of Geo, by [GitLab 12.3](https://about.gitlab.com/releases/2019/09/22/gitlab-12-3-released/#geo-natively-supports-docker-registry-replication) we had added replication support for the most important data types, for example:\n\n* Project Git repositories\n* Project wiki Git repositories\n* Issue/MR/Epic attachments\n* LFS objects\n* CI job artifacts\n* Container/Docker registry\n\nAnd we had added a slew of features around these data types. But suddenly it was clear we had a problem. **We were falling behind in the race to replicate and verify all of GitLab's data.**\n\n* A new data type was being added by other teams, every few months. It was painful to prioritize 3 months of development time only to add replication to one data type. And even if we caught up, the latest features would always be unsupported by Geo for 3 months.\n* Automatic verification of Project and Wiki repositories was implemented, but adding it to a single data type was going to take 3 months.\n* Maintenance and other new features were increasing in effort due to the amount of code duplication.\n* Our event architecture needed too much boilerplate and overhead to add new events\n\n## How to iterate yourself out of a problem\n\nJust because it's possible to iterate yourself into a problem doesn't mean iteration failed you. Yes, ideally we would have seen this coming earlier. But consider that fast and small iteration has likely saved many hours of upfront work on features that have been quickly validated, and have since been changed or removed. It's also possible to [DRY up](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) code too soon into bad abstractions, which can be painful to tear apart.\n\nBut we reached a point where everyone agreed that the most efficient way forward required consolidating existing code.\n\n### Do the design work\n\n[Fabian](https://gitlab.com/fzimmer), our esteemed product manager, [proposed an epic](https://gitlab.com/groups/gitlab-org/-/epics/2161):\n\n> to build a new geo replication and verification framework with the explicit goal of enabling teams across GitLab to add new data types in a way that supports geo replication out of the box\n\nMost of the logic listed above in [Is it really that hard to copy data?](#is-it-really-that-hard-to-copy-data) is exactly the same for all data types. An internal framework could be used to significantly reduce duplication, which could deliver huge benefits:\n\n* Bugs in the framework only have to be fixed once, increasing reliability and maintainability.\n* New features could be added to the framework for all data types at once, increasing velocity and consistency.\n* Implementation details would be better hidden. Changes outside the framework become safer and easier.\n\nThe proposal went further than making it easy for *ourselves* to add Geo support to new data types. The goal was to make it easy for *non-Geo engineers* to do so. To achieve this goal, the framework must be easy to use, easy to understand, and well-documented. Besides the usual benefits of reducing duplication, this higher standard would help:\n\n* Minimize the effort to implement Geo support of new features, whether it's done by a Geo engineer or not.\n* Minimize lag time to add Geo support. If it's easy to do, and anyone can do it, then it's easy to prioritize.\n* Increase awareness in other teams that new features may require Geo support.\n* Influence the planning of new features. There are ways to make it more difficult to add Geo support. This is much easier to avoid during initial planning.\n\nAs a first step, Fabian [proposed creating a proof of concept of a framework](https://gitlab.com/gitlab-org/gitlab/-/issues/35540) leveraging lessons learned and incorporating improvements we already wanted to make to the existing architecture. The issue stimulated lots of design discussion in the team, as well as multiple POCs riffing off one another.\n\nThe biggest change was the introduction of a `Replicator` class which could be subclassed for every data type. The subclasses would contain the vast majority of the specifics to each data type.\n\nIn order to further reduce duplication, we also introduced the concept of a `Replicator strategy`. Most data types in GitLab could be categorized as blobs (simple files) or Git repositories. Within these categories, there was relatively little logic that needed to be specific to each data type. So we could encapsulate the logic specific to these categories in strategies.\n\nAnother significant decision was to make the event system more flexible and lightweight. We wanted to be able to quickly implement new kinds of events for a `Replicator`. We decided to do this without rewriting the entire event processing layer, by packaging and transmitting `Replicator` events within a single, generic event leveraging the existing heavyweight event system. We could then leave the old system behind, and after migrating all data types to the framework, we could easily replace it.\n\nOnce a vision is chosen, it can be difficult to see how to get there with small iterations. But there are often many ways to go about it.\n\n### Code\n\n#### High-level approach\n\nAt a high-level, we could have achieved our goal by taking two data types that were already supported, DRYing up their code, and refactoring toward the desired architecture. This is a proven, safe, and effective method.\n\nBut to me it felt more palatable overall to deliver customer value along the way, by adding support for a brand-new data type while developing the reusable framework. We already had practice implementing many data types, so there was little risk that we would, for example, take too long or use suboptimal abstractions. So we decided to do this with [Package registry](https://docs.gitlab.com/ee/user/packages/).\n\n#### Lay the foundation\n\nOur POCs already answered the biggest open questions about the shape of the architecture. The next step was to get enough of a skeleton merged, as quickly as possible, so that we could unlock further parallel work. To ensure correctness, we aimed to get something working end-to-end. We decided to implement \"replication of newly created Package files\". Much was left out, for example:\n\n* Replication of changes. (Most Blob types, including Package files, are immutable anyway)\n* Replication of deletes\n* Backfill of existing files\n* Verification was left out entirely from the scope of the first epic, since we already knew replication alone provides most of the value to users.\n\nSince the work still required many specific design decisions, we decided to [pair program](https://en.wikipedia.org/wiki/Pair_programming). [Gabriel Mazetto](https://gitlab.com/brodock) and I used [Zoom](https://zoom.us/) and [Visual Studio Live Share](https://visualstudio.microsoft.com/services/live-share/), which worked well for us, though there are many options available. [See a recording of our first call](https://www.youtube.com/watch?v=2XedCiU634s).\n\n[The spike](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23447) was merged and we thought ourselves safe under the feature flag. Looking back on this particular merge request, we did make a couple mistakes:\n\n1. An [autoloading bug was discovered](https://gitlab.com/gitlab-org/gitlab/-/issues/202044). The merge request was reverted, fixed, and remerged. Thanks to [CI](https://docs.gitlab.com/ee/ci/) and end-to-end QA tests using actual builds, the impact was limited.\n1. The size of the spike was unnecessarily large and difficult to review for a single merge request. As it grew, we should have used it as a \"reference\" merge request from which we could break out smaller merge requests. Since then, GitLab policies have further emphasized [smaller iterations](https://about.gitlab.com/handbook/product/product-principles/#iteration).\n\n#### Build on the foundation\n\nWith the skeleton of the framework in the main branch, we could implement multiple features without excessive conflicts or coordination. The feature flag was enabled on [GitLab's staging environment](https://about.gitlab.com/handbook/engineering/development/enablement/systems/geo/staging.html), and each additional slice of functionality was tested as it was merged. And new issues for bugs and missing features were opened.\n\nWe built up the [developer documentation](https://docs.gitlab.com/ee/development/geo/framework.html) as we went along. In particular, we documented specific instructions to implement a new data type, aimed at developers with no prior knowledge of Geo. These instructions have since been moved to issue templates. For example, [this is the template for adding support to a new Git repository type](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Geo%20Replicate%20a%20new%20Git%20repository%20type.md). This caught a lot of would-be pain points for users of the framework.\n\nFinally, we released [Geo supports replicating GitLab Package Registries in GitLab 13.2](https://about.gitlab.com/releases/2020/07/22/gitlab-13-2-released/#geo-supports-replicating-gitlab-package-registries)!\n\n## Reaping the benefits\n\nFollowing the release of Geo support for Package Registries, we added support for many new data types in quick succession. Automatic verification was added to the framework. This recently culminated in a non-Geo engineer implementing replication *and verification* for a new data type, within one month!\n\n* In GitLab 13.5, [Geo replicates external merge request diffs and Terraform state files](https://about.gitlab.com/releases/2020/10/22/gitlab-13-5-released/#geo-replicates-external-merge-request-diffs-and-terraform-state-files). These were added by Geo engineers who had been less involved in building the framework. Many refinements to the framework, and especially to the documentation, came out of this.\n* In GitLab 13.7, [Geo supports replicating Versioned Snippets](https://about.gitlab.com/releases/2020/12/22/gitlab-13-7-released/#geo-supports-replicating-versioned-snippets). This was also added by a Geo engineer, and it was the first Git repository type in the framework, so it required more work than adding new Blob types.\n* In GitLab 13.10:\n  * [Geo supports replicating Group wikis](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#geo-supports-replicating-group-wikis) was implemented by a non-Geo engineer.\n  * [Geo verifies replicated package files](https://about.gitlab.com/releases/2021/03/22/gitlab-13-10-released/#geo-verifies-replicated-package-files). This was a big new feature in the framework, adding automatic verification to any data type that can be checksummed.\n* GitLab 13.11:\n  * [Geo supports Pipeline Artifacts](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#geo-supports-pipeline-artifacts) was implemented by a non-Geo engineer.\n  * [Geo verifies replicated Versioned Snippets](https://about.gitlab.com/releases/2021/04/22/gitlab-13-11-released/#geo-verifies-replicated-versioned-snippets).\n* GitLab 13.12:\n  * [An already supported data type, LFS objects, is migrated to the framework under feature flag](https://gitlab.com/gitlab-org/gitlab/-/issues/276696). Following this will be the migration of \"Uploads\" and \"CI Job artifacts\", and then **deleting thousands of lines of code**. This should improve both reliability and velocity, for example, verification will be added to these data types.\n\nIn aggregate:\n\n* In GitLab 12.9, we replicated ~56% of all data types (13 out of 23 in total) and verified ~22%.\n* In GitLab 13.11, we replicate ~86% of all data types (25 out of 29 in total) and verify ~45%.\n* **In the last year, GitLab released six new features that needed Geo support. We replicate 100% of those new features and verify ~57%.**\n\n## What did it cost?\n\nFor comparison, it took around 3.5 months to [implement replication of Design repositories](https://gitlab.com/groups/gitlab-org/-/epics/1633). It took around 6 months to [implement the framework for replication of Package files](https://gitlab.com/groups/gitlab-org/-/epics/2346). So the cost to produce the framework for replication was roughly 2.5 months of work.\n\nWe don't really have a comparable for [implementation of verification](https://gitlab.com/groups/gitlab-org/-/epics/1817), but it looked like it would take about 3 months to implement for a single data type, while it took about 4 months total to implement for Package files and simultaneously add to the framework, for a cost of about 1 month.\n\nGiven that new data types now take about 1 month to implement replication *and verification*, the work to produce the framework **paid for itself with the implementation of a single data type**. All the rest of the benefits and time saved are more icing on the cake.\n\nMy only regret is that we should have done it sooner. I intend to be more cognizant of this kind of opportunity in the future.\n\n## What to expect in the future\n\n* [Already supported data types will be migrated into the framework](https://gitlab.com/groups/gitlab-org/-/epics/3588)\n* New features will be added more quickly, for example, verification will be rolled out for all [Blob](https://gitlab.com/groups/gitlab-org/-/epics/5285) and [Git repository](https://gitlab.com/groups/gitlab-org/-/epics/5286) data types\n* Duplication will be further reduced, for example, by [leveraging Rails generators](https://gitlab.com/gitlab-org/gitlab/-/issues/326842)\n\nHuge thanks to everyone who contributed to closing the gap on replicating *everything* in Geo!\n",[768,811,9,1078,876,683,855],{"slug":1198,"featured":6,"template":686},"how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo","content:en-us:blog:how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo.yml","How We Are Closing The Gap On Replicating Everything In Gitlab Geo","en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo.yml","en-us/blog/how-we-are-closing-the-gap-on-replicating-everything-in-gitlab-geo",{"_path":1204,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1205,"content":1211,"config":1218,"_id":1220,"_type":13,"title":1221,"_source":15,"_file":1222,"_stem":1223,"_extension":18},"/en-us/blog/how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics",{"title":1206,"description":1207,"ogTitle":1206,"ogDescription":1207,"noIndex":6,"ogImage":1208,"ogUrl":1209,"ogSiteName":672,"ogType":673,"canonicalUrls":1209,"schema":1210},"GitLab Runner Fleet dashboard improved through user research","Learn how GitLab user research drives the product development process when enabling more runner fleet features.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666543/Blog/Hero%20Images/lightvisibility.png","https://about.gitlab.com/blog/how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How user research transformed GitLab Runner Fleet dashboard visibility and metrics\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Gina Doyle\"}],\n        \"datePublished\": \"2023-11-07\",\n      }",{"title":1212,"description":1207,"authors":1213,"heroImage":1208,"date":1215,"body":1216,"category":787,"tags":1217},"How user research transformed GitLab Runner Fleet dashboard visibility and metrics",[1214],"Gina Doyle","2023-11-07","\nContinuous integration and continuous deployment (CI/CD) are a crucial part of the product development workflow. Companies depend on CI/CD to get new software features, bug fixes, and improvements out the door quickly. At GitLab, runners are at the core of CI/CD and are needed to build, test, and deploy code. [GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner) is the open source project that is used to run CI/CD jobs and send the results back to GitLab. However, since GitLab's early years, GitLab Runner has been code-centric with limited UI capabilities. We recently embarked on a journey to change that – follow along to see how we gathered user input and made desired improvements to the visibility and metrics of the GitLab Runner Fleet dashboard.\n\n## Managing runners\nAs GitLab scaled as a company, so did the number of GitLab users with complex and evolving use cases. In the past five years, we have seen a radical increase in the need for a best-in-class experience when managing a large number of self-managed runners. This need has led us to put more time and focus into improving how GitLab manages runners and how it supports users in making decisions quickly and effectively.\n\nTo that end, we’ve been making incremental changes to the runner fleet management experience, including improving the general usability of admin and group runner pages, providing more data around runners such as jobs run and status checks, and improving the runner creation process so it’s more secure and easier to follow. By doing this, we built a better underlying system so we could add new features easily.\n\nHowever, runner admins and platform engineers shared this recurring problem with us: \n- It is difficult to get an at-a-glance view of my fleet of runners, including how they are performing (how fast they pick up jobs, which ones are running the most jobs, etc.) and what issues (if any) are present that need to be fixed. \n\nIn addition to this problem, the GitLab Runner Fleet team was also running into issues with the performance of runner pages and with scalability when trying to add new features. This was a perfect opportunity to learn more about the problem users were facing and to innovate to extend our runner offering.\n\n## Gathering insights and exploring proposals\nTo fully understand the problem at hand and help make the requirements more clear, we carried out [problem validation](https://about.gitlab.com/handbook/product/ux/ux-research/problem-validation-and-methods/) research. We held [moderated in-depth interviews](https://www.usability.gov/how-to-and-tools/methods/individual-interviews.html) and sifted through much of our existing data from previous interviews. As we gained confidence in our understanding of the problem, we created a first iteration of the design to be tested with users through [moderated usability testing](https://about.gitlab.com/handbook/product/ux/ux-research/usability-testing/#different-types-of-usability-testing), which would [determine whether the solution really did solve the problem](https://about.gitlab.com/handbook/product/ux/ux-research/solution-validation-and-methods/).\n\nThis first design proposal focused on: \n- a general overview of the fleet, broken down by types (instance, group, project runners) and status\n- visibility into runner system failures\n- a general concept of runner load - how many jobs are running at once out of how many possible jobs the runner can run?\n- how long it takes for runners to pick up jobs\n= a list of runner events (job failures, status changes, upgrades, etc.)\n\n![Initial design of dashboard 1](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/initial-design-1.png)\n\n\n![Initial design of dashboard 2](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/initial-design-2.png)\n\n\n## Testing the usability of iteration\nWe ran moderated usability testing sessions so we could measure user responses and satisfaction based on a set of consistent questions across multiple participants. We used a Figma prototype and had participants complete tasks that connected back to the problem we were solving. \n\nAn advantage of running moderated sessions compared to unmoderated sessions is that we could tailor our follow-up questions as required once participants completed a task or provided an answer. After completing these sessions, we summarized the data we received into the following key insights to create the MVC (minimal viable change) of the runner fleet dashboard:\n1. Runner failures/errors are crucial to identify problems (voted the most important feature on the dashboard).\n2. Online and offline runners matter the most in terms of status breakdowns for a fleet.\n3. Visibility into busy runners (tied for second most important feature on the dashboard) helps users see individual runner load.\n4. Wait time to pick up a job was tied for the second most important feature on the dashboard and seeing this over time with more configuration options can help identify where to make optimizations in the fleet.\n\nThere are many other features requested by participants that should be handled in follow-up iterations of the dashboard. See [this epic](https://gitlab.com/groups/gitlab-org/-/epics/10631) for more information.\n\n## Updating the designs\nOur next step was to update the designs to consider the research we ran.\n\n### Responding to feedback\n\n1) Wait times\n\n**What we heard:**\n- “Right now, there is very little information available as to how soon a CI build might start. Oftentimes, users are left wondering why jobs won’t run.” \n- “It's mostly reactive for us at this point anyway when, as you know, we get users reporting problems, we might want to go look at wait times here. And be able to dig down on those to see who's waiting...”\n\n**What we did:**\n- Added an in-depth visualization of wait times for all instance runners in the fleet in the past three hours and included percentiles to give users a true representation of the wait times. By providing the data over this interval, we enable runner admins to quickly get a sense of how their runners are performing and if there are any issues with the fleet that would cause jobs to stay in pending state.\n\n![Wait time graph](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/wait-time-graph.png)\n\n2) Runner loads\n\n**What we heard:**\n- “I have three build servers that are shared amongst many projects and in order for me to ensure each build server is properly set up, it's important for me to track builds by server. So, if one particular server is having issues, I need to be able to focus on that server.”\n\n**What we did:**\n- To start indicating some data on runner load, we’ve added a list of the top five busiest runners based on the number of running jobs they have at the moment, ranked from highest to lowest. This should help when analyzing concurrency settings and seeing if runners really need the capacity set for them.\n\n![Active runners](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/active-runners.png)\n\n3) Understanding of most recent failures\n\n**What we heard:**\n- “We actually have a dashboard on Datadog that gives us error counts and errors coming from the runners themselves. But you know, without a dashboard, we have no visibility on anything inside of GitLab, like queue lengths or wait times or anything like that.”\n\n- “Our setup is not perfect...some of the runners run on spot instances and can disappear, which means the background engine can die. You get this very strange error that the job failed because of something and we need to retry the job using a different runner.”\n\n**What we did:**\n- Created a list of most recent failures in the last hour for instance runners. Not only can you quickly navigate to the job log and details, but you’re also given a short summary of the error so you get insight into it immediately and can get on your way to fix it.\n\n![Runner failures](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/runner-failures.png)\n\n**The full dashboard:**\n\n![Full runner dashboard](https://about.gitlab.com/images/blogimages/2023-11-01-how-we-used-research-to-provide-visibility-into-runner-fleets/full-dashboard.png)\n\n## What's next?\nThis first iteration of the dashboard is not the end. We have many iterations planned to improve the dashboard over the next year. To first get feedback on how it works for users, we will run an [Early Adopters Program](https://gitlab.com/groups/gitlab-org/-/epics/11180) for GitLab Ultimate self-managed users. We will work with teams to set up the feature on their instance and continuously ask for feedback once it is being used. This will also help us understand user satisfaction levels and help our team prioritize fixes and new features as we continue improving the experience.\n\n**Do you want to provide feedback now?** We would love to hear what you think! Please add your thoughts about the Fleet Dashboard to [this feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/421737). To learn more about how we built this dashboard, [watch this technical demo](https://www.youtube.com/watch?v=clyfLsss-vM) by Miguel Rincon, Pedro Pombeiro, and Vladimir Shushlin.\n",[108,1097,9],{"slug":1219,"featured":6,"template":686},"how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics","content:en-us:blog:how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics.yml","How We User Research Transformed Gitlab Runner Fleet Dashboard Visibility And Metrics","en-us/blog/how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics.yml","en-us/blog/how-we-user-research-transformed-gitlab-runner-fleet-dashboard-visibility-and-metrics",{"_path":1225,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1226,"content":1232,"config":1238,"_id":1240,"_type":13,"title":1241,"_source":15,"_file":1242,"_stem":1243,"_extension":18},"/en-us/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool",{"title":1227,"description":1228,"ogTitle":1227,"ogDescription":1228,"noIndex":6,"ogImage":1229,"ogUrl":1230,"ogSiteName":672,"ogType":673,"canonicalUrls":1230,"schema":1231},"Improving iteration and collaboration with user stories","From problem validation to implementation, here's the Release Management team workflow for building user-centered features at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681193/Blog/Hero%20Images/blog-user-stories.jpg","https://about.gitlab.com/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Improving iteration and collaboration with user stories\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rayana Verissimo\"}],\n        \"datePublished\": \"2020-03-27\",\n      }",{"title":1227,"description":1228,"authors":1233,"heroImage":1229,"date":1235,"body":1236,"category":764,"tags":1237},[1234],"Rayana Verissimo","2020-03-27","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nIncorporating UX into Agile practices is a known challenge on software projects. One of the most common rants from design teams is how Agile does not embrace UX. \n\nGitLab's focus on [results](https://handbook.gitlab.com/handbook/values/#results) empowers us to create processes that work best for us, our organization, constraints, and opportunities. That includes applying Agile principles to efficiently approach how we design our product.\n\nOn GitLab's Release Management team, we rely on [User stories](https://en.wikipedia.org/wiki/User_story) to help Product Designers, Product Managers, and Engineers understand how the features we prioritize affect our end users. \n\nBy expressing one very specific need that a persona has in the format of a user story, our team has seen the following benefits:\n\n1. Keep the scope of feature proposals minimal, while focusing on users instead of solutions.\n1. Engage in a conversation with our engineering team and stakeholders, so they can help raise technical constraints and more easily estimate implementation effort.\n1. Provide an essential foundation for the next phases of design.\n1. Proactively identify follow-up stories to iterate on.\n\n## We base our user stories on real data\n\nTo ensure we're building GitLab features that are relevant to our target market, as a design practitioner, I partner up with [Jackie](https://gitlab.com/jmeshell) (Product Manager) and [Lorie](https://gitlab.com/loriewhitaker) (UX Researcher) to talk to our users, identify patterns, determine priorities, and translate research into actionable insights. \n\nUser stories are just another way to articulate the user insights into the features we prioritize. [Problem validation](https://about.gitlab.com/handbook/product-development-flow/#validation-track) is also key to building strong user stories that will deliver a great user experience. \n\nRemember: great user stories are informed by real user insights! There is no other way to achieve [user-centered design](https://en.wikipedia.org/wiki/User-centered_design).\n\n## How a user story was turned into an MVC for Deploy Freezes\n\nWhen we started talking about the value of being able to restrict deployment time frames and declare accepted windows of code releases in enterprise and regulated industries, our Product Manager turned to customer interviews to [validate our assumptions](https://gitlab.com/gitlab-org/gitlab/issues/39108). We surveyed more than 200 participants and interviewed five customers about what we call [Deploy Freezes](https://gitlab.com/gitlab-org/gitlab/issues/39108). As a result, we were able to understand the interplay of Deploy Freezes with Release Runbooks, as well as how this problem impacts the GitLab stages of Secure and Plan.\n\n### What we learned from problem validation\n\nWe learned that for teams that are not global, the ability to halt [CI/CD deployments](/topics/ci-cd/) in off hours or suspend CI/CD pipelines on weekends when there is limited team availability can be critical. These users were usually configuring Deploy Freeze policies manually or outside of the GitLab system. Interlocking these policies within CI/CD and automation is a must have to support our users. \n\nAdditionally, when looking at [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) Deploy Freezes, our internal customers (Production and Delivery teams at GitLab) may need to support users freezing code deploys as they relate to special events like big company announcements, live streamed content, and holidays.\n\nThe main difference between this and a pipeline implementer for a `.gitlab-ci.yml` file is that the authors of these kinds of pipelines are much less technical, and even editing yaml might be a challenge — though they will still need to understand markdown. The personas responsible for enforcing those policies include: [Release managers (Rachel)](https://about.gitlab.com/handbook/product/personas/#rachel-release-manager), [DevOps Engineers (Devon)](https://about.gitlab.com/handbook/product/personas/#devon-devops-engineer), [Software Developers (Sasha)](https://about.gitlab.com/handbook/product/personas/#sasha-software-developer), and [Development Team Leads (Delaney)](https://about.gitlab.com/handbook/product/personas/#delaney-development-team-lead).\n\nThrough research, we identified that our next focus areas should be setting Deploy Freezes in the UI on a project instance level (and eventually on a group level), having a dashboard to report across environments, and logging failed attempts for deployments during a freeze window.\n\n## From user insights to user stories\n\nAs I start working on the design phase of the [MVC](/handbook/product/product-principles/#the-minimal-viable-change-mvc), I'll break my tasks into the following steps:\n\n1. Work with my Product Manager to identify the main user story.\n1. Identify possible scenarios and edge cases with the entire team.\n1. Write acceptance criteria for user stories and create a low-fidelity prototype.\n1. Discuss and iterate with the team, and move the prototype to high fidelity.\n\nThe typical format of a user story is a single sentence: “_As a [type of user], I want to [goal], so that [benefit]_”. Toward the beginning of the design phase, I documented this user story:\n\n> As a DevOps Engineer/Release Manager, I want to specify windows of time when deployments are not allowed for an environment with my GitLab project, so that I can interlock it within CI/CD and automation.\n\nLooking back at the extensive research our Product Manager conducted, as a designer, I am confident that my user story focuses on the right persona and that the scope covers one specific use case (specifying Deploy Freezes on a project level). All other scenarios, such as dashboard, reporting, group level configuration, and auditing are too large for the MVC. This user story also talks about what we are going to build, not how we are going to do it.\n\nIt is important to highlight that for some organizations, the DevOps Engineer and Release Manager personas [merge into one](https://gitlab.com/gitlab-org/ux-research/issues/346), where parties responsible for releases also need to keep a hand in development, creating code and contributing to applications, outside of automation. This is one of the reasons why when designing for Release Management, I need to remember our users might have different levels of familiarity and expectations with developer-centered flows.\n\n## Thinking big as a team\n\nI carefully consider the development proposal and team conversations to understand the goals and constraints that can inform my initial user story. Every single member of the Release Management team is design minded, so collaborating to improve my design proposals is usually a no brainer!\n\nInstead of collecting user stories in our backlog, we groom and refine them on the fly during the planning phase. Being an all-remote company requires some adjustments to my design process, and our team tries to work as asynchronously as possible. \n\nWe tackle collaboration in many different ways: by using issue threads, during Think Big sessions, PM/UX sync calls, 1:1s, and via Slack messages. The most important thing is that every design and technical decision we make is incorporated back into a single source of truth ([SSOT](https://docs.gitlab.com/ee/development/documentation/styleguide/#documentation-is-the-single-source-of-truth-ssot)) -- in our case, the MVC issue. \n\nUpdating the scope and acceptance criteria of issues is a shared responsibility between my Product Manager, the Engineers, and me. We do our best to collect all relevant information, so that our customers and counterparts can have a clear understanding of what we are delivering in the next milestone.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/SU9mqOUSl1k\" frameborder=\"0\" allowfullscreen=\"true\">\u003C/iframe>\n\u003C/figure>\n\nOur team (UX, FE, BE, PM) met to discuss the latest decisions made and discoveries about deploy freezes. Watch on [GitLab Unfiltered](https://youtu.be/SU9mqOUSl1k).\n{: .note.text-center}\n\n## Defining the acceptance criteria\n\nDuring our refinement process, I learned from engineering that we could specify timeboxes for the freezes using cron syntax, and that we could reuse this from the existing [Pipeline schedules](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) capability. Hooray! Engineers also proposed that the `gitlab-ci.yml` file would instruct the pipeline to not run per the cron syntax. They also thought that it would be great to automatically retry the job and continue the deployment process when the freeze period was over.\n\nOn the design side, my additional proposal focused on [notifying users on the interface](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_278661935) when a freeze period would be enabled for specific environments. This was especially important to inform users that are consuming the deployments, and not necessarily the people involved in setting up Deploy Freezes.\n\nThis is how one of the first versions of the MVC looked like:\n\n![Initial take on depoy freeze acceptance criteria](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-iteration.jpg){: .large.center}\n\nHigh-level acceptance criteria including some interaction and requirements for frontend. No high-fidelity prototyping at this point.\n{: .note.text-center}\n\n![Initial take on depoy freeze prototype](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-prototype.jpg){: .large.center}\n\nA _quick-and-dirty_ mockup produced by manipulating the source and styles of the Environments page on the browser.\n{: .note.text-center}\n\nAlthough engineering wanted to support the ability to configure everything related to a Deploy Freeze using the `gitlab-ci.yml` file at some point, while being able to retry a pipeline or even bypass a freeze period, we had significant data showing that it would be more valuable to users to instead have the ability to easily configure their policies using the UI. Our user insights told us that users configuring these kinds of pipelines are much less familiar with the terminal, and even editing yaml might be a challenge.\n\n## Iterate, iterate, iterate\n\nBack to the drawing board (or, in my case, the GitLab issue). My focus shifted from simply notifying users to allowing them to enter data in the UI. We worked asynchronously on [different proposals](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_298796163), until the point the scope could fit an MVC that satisfies the user goals we identified through research.\n\nUsing the same user story, the acceptance criteria shifted to:\n\n![Deploy freeze mvc user story](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-user-story-iteration.jpg){: .large.center}\n\nWhile working on the new acceptance criteria, I started raising a couple of questions and [thinking of edge cases](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_308692974). For example, \"can we use a date picker UI component to select the deploy freeze period?\", \"will the end freeze field always be mandatory when setting a new period?\", \"can we support the user's default browser timezone when showing a dropdown on the UI?\", and \"how do we validate the cron syntax on the frontend?\". \n\nOnce again, Engineers to the rescue! [Nathan](https://gitlab.com/nfriend), our Super-Frontend Engineer, and I had a quick call where I walked him through my low-fidelity prototypes and we aligned our goals. Our decisions were documented as a [comment on the MVC](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_308765612) to ensure everyone involved could access the information.\n\n## Break the user story down into something even smaller\n\nMy conversation with Nathan also made it clear that editing and deleting a deployment freeze using the UI, as well as showing human-readable cron syntax descriptions, would increase the MVC scope. Because of that, I proactively broke the user story down into four new user stories that were logged as new feature proposals:\n\n> As a user, I want to see human-readable cron syntax descriptions for deploy freezes in GitLab's UI, so that I can easily understand the information about a freeze. [gitlab#212458](https://gitlab.com/gitlab-org/gitlab/-/issues/212458)\n\n> As a DevOps Engineer/Release Manager, I want to edit Deploy Freezes I specify, so that I can keep my information up to date. [gitlab#212449](https://gitlab.com/gitlab-org/gitlab/-/issues/212449)\n\n> As a DevOps Engineer/Release Manager, I want to delete deployment freezes I specified, so that I can keep my information up to date. [gitlab#212451](https://gitlab.com/gitlab-org/gitlab/-/issues/212451)\n\n> As a user, I want to be informed when a Deploy Freeze is active for my project in GitLab, so that I can stay up to date with the status of production deployments. [gitlab#212460](https://gitlab.com/gitlab-org/gitlab/-/issues/212460)\n\nBy reducing the scope of the MVC, the Product Manager and Engineers could start a new conversation about delivery efforts:\n\n![Async discussion and frontend estimation of the MVC](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-breakdown.jpg){: .large.center}\n\nAsync discussion and frontend estimation of the MVC. Read more on [gitlab#24295](https://gitlab.com/gitlab-org/gitlab/-/issues/24295#note_311365886)\n{: .note.text-center}\n\nI then placed the descoped stories in the “backlog” for short-term assignment and long-term reference. By having our Product Manager serve as gatekeeper to the backlog, our team can focus on working on high-value features that have already been vetted and are supported by user insights.\n\n## Prototyping with a focus\n\nWith everyone on board, I can finally spend proper time prototyping the MVC solution! 🎉\n\nI personally am a fan of spending more time writing down design specifications than pushing pixels. Because [the GitLab train is always moving](https://about.gitlab.com/releases), prototyping is costly and prone to becoming obsolete in the blink of an eye. I also try to be mindful when I need to provide a prototype to my team. Will it help them understand my proposal? Can the prototype unlock hidden edge cases I didn't account for? Do I work with people that need visual cues to better understand the design goals?\n\n![Final depoy freeze prototypes](https://about.gitlab.com/images/blogimages/user-stories-as-design-tool/blog-deploy-freeze-prototype-iteration.jpg){: .large.center}\n\nFinal high-fidelity prototypes used by the engineering team to estimate the MVC. Adjustments of UI copy are aligned on the fly with Technical writers after this phase.\n{: .note.text-center}\n\nPreviously, [Pedro](https://gitlab.com/pedroms) shared how one of the designer’s responsibilities is [handing off the design to developers](https://about.gitlab.com/blog/how-gitlab-pages-made-our-sketch-design-handoffs-easier-and-faster/), so that it gets implemented as intended. I trust that my frontend team will follow the acceptance criteria, for example, by reusing the Pajamas components I specified. And if by any chance they need to make changes/improvements to the design proposal on the fly: so be it!\n\nThe prototypes I build facilitate the design/development conversation, and they are meant to be used as assets to help our engineers have a starting point to build features. Prototypes are not the end product! Because I am also added as a UX reviewer to frontend merge requests, I can spot inconsistencies under development and discuss the proposed changes on the fly with the team. Once we agree on a direction, and if the change is big enough to be noted on the scope of our MVC, I make sure the information is updated in the SSOT.\n\n## Five keys takeaways from our workflow\n\n1. **You don't need to do Agile to be agile (lower case _a_).** Work around implementing best practices that work for you and your team.\n1. **Communicate with your team early and often.** As a tool, user stories help facilitate the conversation between UX, Research, Engineering, and Product. Look at the user stories to estimate design and development effort.\n1. **Identify user stories before jumping into designing a \"solution.\"** Make an effort to use research insights to guide your decisions. Deliver on real user needs. If user data is not available, try looking into different [research methods](https://about.gitlab.com/handbook/product/ux/ux-research/#research-methods). \n1. **Play around with the acceptance criteria.** For each user story, see if it can be broken down into smaller, more specific stories.\n1. **Document, iterate, and validate your decisions.** \n\n## Where do we go from here?\n\nAs with everything we do, this process is in constant change. User stories have been a great ally to promote a shared vision of the end user, while shifting the way we ship solutions. We went from having a list of functionalities with dubious origins that simply focused on solutions to having user-centered proposals that clearly let us communicate _why_ we are building things and _how_ we want to help our users achieve their goals.\n\nI am beyond excited about the relationship the Release Management team built around design and research. We are confident with the solution proposed for Deploy Freezes, but further developments may require [solution validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-4-solution-validation) to test the usability of our prototypes and implemented features. Personally, I would still like to uncover more opportunities to contribute to [gitlab-ui](https://gitlab.com/gitlab-org/gitlab-ui) components and the [Pajamas Design System](https://design.gitlab.com/) through our user stories, so that we can come up with additional improvements to patterns that are used globally across GitLab.\n\nIf any of these topics interest you or if you have some feedback on our ideas, please get in touch and let us know what you think. We are planning great things for Release Management, in particular [Release Orchestration](https://about.gitlab.com/direction/release/release_orchestration/) with GitLab. \n\nYou can get to know more about the [Release UX Team Strategy](https://about.gitlab.com/handbook/product/ux/stage-group-ux-strategy/release/) in our handbook! We would love to hear from you!\n\nCover image by [Christina @ wocintechchat.com](https://unsplash.com/@wocintechchat?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/)\n{: .note}\n",[682,9,811,876,9],{"slug":1239,"featured":6,"template":686},"how-we-utilize-user-stories-as-a-collaborative-design-tool","content:en-us:blog:how-we-utilize-user-stories-as-a-collaborative-design-tool.yml","How We Utilize User Stories As A Collaborative Design Tool","en-us/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool.yml","en-us/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool",{"_path":1245,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1246,"content":1252,"config":1258,"_id":1260,"_type":13,"title":1261,"_source":15,"_file":1262,"_stem":1263,"_extension":18},"/en-us/blog/illustrations-and-icons-on-gitlab-com",{"title":1247,"description":1248,"ogTitle":1247,"ogDescription":1248,"noIndex":6,"ogImage":1249,"ogUrl":1250,"ogSiteName":672,"ogType":673,"canonicalUrls":1250,"schema":1251},"Inside GitLab: Illustrations and icons on GitLab.com","Learn how our UX team creates icons and illustrations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666717/Blog/Hero%20Images/cover-image.jpg","https://about.gitlab.com/blog/illustrations-and-icons-on-gitlab-com","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Inside GitLab: Illustrations and icons on GitLab.com\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Hazel Yang\"}],\n        \"datePublished\": \"2017-12-04\",\n      }",{"title":1247,"description":1248,"authors":1253,"heroImage":1249,"date":1255,"body":1256,"category":787,"tags":1257},[1254],"Hazel Yang","2017-12-04","\nIn our 10.0 release, we introduced a [new navigation](/blog/unveiling-gitlabs-new-navigation/) complete with a redesigned color palette and icon set. We replaced [Font Awesome](http://fontawesome.io/icons/) with our own, SVG based, icon system, and we’ve also been hard at work on a series of illustrations to provide consistent visual language and improve our onboarding experience. Read on to find out more about how the UX team goes about creating new icons and illustrations.\n\n\u003C!-- more -->\n\nIllustrations and icons are powerful communication tools. They tell a story where words fail and can facilitate understanding across both language and culture barriers. Replacing text with illustrations and icons can make things clear at a glance. They also open up space and allow the eye to navigate more easily across the interface.\n\n## Illustrations\n\nA common mistake when designing a product is to assume that your users will understand how to use it. In reality, most users need a little help understanding where to start on their journey in order to discover all it has to offer. This is especially true for a product like GitLab, which is brimming with features. To assist users and [improve the onboarding experience](https://gitlab.com/gitlab-org/gitlab-ce/issues/15632), we decided to implement illustrations.\n\n### Defining the style\n\nTo begin, we reviewed our product’s existing styles to ensure that the illustrations we created would support a consistent brand experience for the application and our [official site](/).  During this review, we found that the visual design of these two products had diverged. The colors on our official website were vivid and energetic, orange and purple, while the colors of GitLab.com were soft and gentle, grey and white. Blending these two opposing styles into one set of illustrations was not going to be an easy task.\n\n{: .text-center}\n![gitlab-websites](https://about.gitlab.com/images/blogimages/illustrations-and-icons/gitlab-websites.png)\n\n### Visual consistency\n\nTo provide visual consistency across both products, we decided to pick up the primary, orange, and secondary, purple, colors from the official site for use in our illustrations. However, these two colors had a similar chroma and, used without modification, would create a jarring effect. Also, they just didn’t work well with the style of GitLab.com at the time. Our solution for this was to adjust the chroma of the two colors to generate new ones. These new colors played more harmoniously with the existing style of GitLab.com and allowed us to play with color in more creative ways.\n\n{: .text-center}\n![color-palettes](https://about.gitlab.com/images/blogimages/illustrations-and-icons/color-palettes.png)\n\n### Following GitLab values\n\n[Values](https://handbook.gitlab.com/handbook/values/) are important to us at GitLab. It was essential that our illustrations reflected these values and enhanced the brand experience to create a personal connection with our users. At GitLab we encourage people to maintain a positive attitude. Our illustrations needed to bring out a sense of playfulness, delight, and overall positivity.\n\n{: .text-center}\n![positive-illustration](https://about.gitlab.com/images/blogimages/illustrations-and-icons/positive-illustration.png){: .shadow}\n\nWe quickly found that these illustrations provided value as well as functionality. Used in an empty state, they inform users of features they may not know about and provide valuable onboarding. Used in error messaging, they quickly redirect users and get them back on track.\n\n{: .text-center}\n![errors-illustration](https://about.gitlab.com/images/blogimages/illustrations-and-icons/404.png){: .shadow}\n\nDiversity and inclusivity are essential to who we are as well. We have users, employees, and community members from many different cultural and geographical backgrounds. We reflected this variety of races, nationalities, and genders in the development of the illustrations for our [UX personas](https://design.gitlab.com/). We chose to use illustrations rather than stock photos. Illustrations make it easy to cover a variety of personas with no need to worry about copyrights.\n\n{: .text-center}\n![person-avatars](https://about.gitlab.com/images/blogimages/illustrations-and-icons/person-avatars.png){: .shadow}\n\nYou can find out more about our illustrations in the [handbook](https://docs.gitlab.com/ee/development/ux/).\n\n## Icons\n\nWhen GitLab was first in development, we chose Font Awesome as the primary icon set. It contained a variety of commonly used icons and was easy to implement. For an early-stage startup, it was a very useful tool.  \n\nAs GitLab matured, we needed more and more custom icons. These custom icons were created by our designers and, when mixed in with Font Awesome, led to an inconsistent visual style. Adding to the problem was the fact that we didn’t have a guide for icon usage. The lack of guidance caused [inconsistent](https://gitlab.com/gitlab-org/gitlab-ce/issues/29584) and [duplicated](https://gitlab.com/gitlab-org/gitlab-ce/issues/19751) icon usage to occur frequently. It confused users and had a detrimental effect on usability.\n\n### Creating our icons\n\nIt was time to build a consistent visual style and eliminate the confusion by [creating a complete custom icon set](https://gitlab.com/gitlab-org/gitlab-ce/issues/32894). Using distinct and unique iconography offered a powerful way to emphasize our unique personality.\n\n{: .text-center}\n![new-icon-set](https://about.gitlab.com/images/blogimages/illustrations-and-icons/new-icon-set.png){: .shadow}\n\nOnce again, consistency was key here. We gave our icons a thick border and rounded corners. Creating a consistent style between our illustrations and icons strengthened our brand identity by making it memorable and more easily recognizable.\n\nThick borders also help with accessibility. We were aware that some of our users adjusted their screen to higher resolutions, making an icon with a thin border harder to recognize. For this reason, we went with a `2x` width border.\n\n## The outcome\n\n### More recognizable and consistent visual language\n\nOur new color palette and icons on GitLab.com created a robust and consistent brand experience, making GitLab identifiable at a glance.\n\n### Illustrations for empty states and persona avatars\n\nMany of our empty state illustrations have been implemented, and we continue to develop more. You can see our avatar illustrations on [UX personas](https://design.gitlab.com/).\n\n{: .text-center}\n![example-empty-state](https://about.gitlab.com/images/blogimages/illustrations-and-icons/example-empty-state-issues.png){: .shadow}\n\n### Icons in contextual navigation and system notes\n\nWe have implemented most of our new icons on GitLab.com. You can find them in the [system notes](https://gitlab.com/gitlab-org/gitlab-ce/issues/24784) and [contextual navigation](https://gitlab.com/gitlab-org/gitlab-ce/issues/34027). Font Awesome will soon be completely phased out. We'd like to thank the Font Awesome team, their open source icon set allowed us to get very far, very fast!\n\n{: .text-center}\n![example-system-notes](https://about.gitlab.com/images/blogimages/illustrations-and-icons/system-notes.png){: .shadow}\n\n{: .text-center}\n![example-contextual-nav](https://about.gitlab.com/images/blogimages/illustrations-and-icons/contextual-nav-02.png){: .shadow}\n\n### Streamline process with the use of SVGs\n\nAll of our illustrations and icons are now exported as SVG files. Our Frontend AC Lead [Tim Zallmann](/company/team/#tpmtim) created [GitLab SVGs](http://gitlab-org.gitlab.io/gitlab-svgs/), a repository to manage all SVG Assets for GitLab. It creates SVG Sprites out of Icons and optimises SVG-based Illustrations. These are then exported to a live preview site. This enables the design team to add new icons and the frontend team to find icons quickly and easily.\n\n{: .text-center}\n![screenshot-gitlab-svgs](https://about.gitlab.com/images/blogimages/illustrations-and-icons/gitlab-svgs.png){: .shadow}\n\n## Conclusion\n\nYou will see GitLab's brand experience and UX design become more consistent and distinctive, and GitLab SVGs will soon be integrated into our [Design Library](https://gitlab.com/gitlab-org/gitlab-design/issues/26) we are working on. Stay tuned!\n",[9,682,876],{"slug":1259,"featured":6,"template":686},"illustrations-and-icons-on-gitlab-com","content:en-us:blog:illustrations-and-icons-on-gitlab-com.yml","Illustrations And Icons On Gitlab Com","en-us/blog/illustrations-and-icons-on-gitlab-com.yml","en-us/blog/illustrations-and-icons-on-gitlab-com",{"_path":1265,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1266,"content":1272,"config":1277,"_id":1279,"_type":13,"title":1280,"_source":15,"_file":1281,"_stem":1282,"_extension":18},"/en-us/blog/interesting-things-ux-is-working-on-february-2021",{"title":1267,"description":1268,"ogTitle":1267,"ogDescription":1268,"noIndex":6,"ogImage":1269,"ogUrl":1270,"ogSiteName":672,"ogType":673,"canonicalUrls":1270,"schema":1271},"Interesting things UX is working on - February 2021","Take a look at some of the design work we've got in process","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679569/Blog/Hero%20Images/med-badr-chemmaoui-ZSPBhokqDMc-unsplash.jpg","https://about.gitlab.com/blog/interesting-things-ux-is-working-on-february-2021","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Interesting things UX is working on - February 2021\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2021-02-12\",\n      }",{"title":1267,"description":1268,"authors":1273,"heroImage":1269,"date":1274,"body":1275,"category":764,"tags":1276},[742],"2021-02-12","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAs always, the UX department is working on some interesting and valuable things. Check out what we've got in process during February 2021.\n\n## Help users configure API fuzzing scanners more efficiently\n\nConfiguring API fuzzing scanners requires editing the project .yaml file, which can be long and difficult to parse. Editing can also lead to potential errors.\n\n**Solution:** We're starting with a boring solution (currently scheduled for 13.9) that [generates the necessary code snippet](https://gitlab.com/gitlab-org/gitlab/-/issues/299234) for API fuzzing scanner configuration. Our solution will also help users add the code snippet to the correct .yaml locations.\n\n![Fuzzing Scanner configuration efficiency](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/Slide14_secure-fuzz-api-configuration-mvc.gif){: .shadow.medium.center}\n\n## Provide visibility to the GitLab Agent for Kubernetes status & deployments\n\nCustomers who use the Agent to automate their deployments to their Kubernetes clusters need to be able to easily see the Agent's status and activity to troubleshoot errors that can break their deployments.\n\n**Solution:** Provide a details page for the Agent where users can see the list of Agent activities, the manifest projects it deploys, and their sync status, so they can more easily troubleshoot the Agent. Design is in process with solution validation planned for 13.11.\n\n![Kubernetes Agent status & deployments](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/kubernetes-agent.png){: .shadow.medium.center}\n\n## Make it easier to find settings on a page\n\nFinding a specific setting can be hard. Users need to know where it is or hunt for it by opening each section, because the browser search (CMD + f) doesn’t work.\n\n**Solution:** In-page search for Settings as a first step in directly getting users to the settings they need. We added this under a feature flag in 13.8. Currently available on the www-gitlab-com project.\n\n![Search on settings page](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/search-settings.gif){: .shadow.medium.center}\n\n## Help users triage and track changes made to vulnerabilities\n\nWhen triaging vulnerabilities, users need the ability to modify information and document their decisions for accountability. Additionally, users need to discuss the details, priority, and risk before opening an issue for remediation.\n\n**Solution:** Meet users' expectations when interacting with vulnerabilities by providing corollary experiences used elsewhere in GitLab: (1) Required comments on state/status change and (2) Commenting and threaded comments in vulnerabilities.\n\n![Triage and track vulnerability changes](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/Slide17_Change-status-with-required-comment.gif){: .shadow.medium.center}\n\n## Call out the priority of compliance violations\n\nToday, users can only see a generic violation message for the latest Merge Request, which makes it difficult to keep track of and discern priority.\n\n**Solution:** Assign a severity to merge request violations. This [epic](https://gitlab.com/groups/gitlab-org/-/epics/5237) moved into planning breakdown in 13.9.\n\n![Compliance violation priority](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/priority-compliance-violations.gif){: .shadow.medium.center}\n![Compliance violation priority before and after](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/compliance-violation-before-after.png){: .shadow.medium.center}\n\n## Make it easier for new users to get started with CI/CD\n\nCurrently, we don't do a good enough job of showing new GitLab users the value of CI/CD and how to implement it well.\n\n**Experiment:** Feature CI/CD templates to users who haven’t activated pipelines. We hypothesize this will make the process less intimidating and lead to more usage.\n\n![Getting started with CI/CD](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/get-started-cicd.gif){: .shadow.medium.center}\n\n## Make GitLab purchases more seamless for SaaS customers\n\nToday, SaaS customers are directed away from GitLab.com to the Customers Portal to make purchases. Then, they have to reauthenticate, creating friction in the purchase process.\n\n**Solution:** We're iterating toward [eliminating the Customers Portal](https://gitlab.com/groups/gitlab-org/-/epics/1888) to allow customers to make GitLab purchases inside the product. The new subscription purchase flow has already been moved to GitLab.com. In 13.9, we’ll start to move the CI minute purchase flow and then the storage purchase flow after that. Renewals, upgrades, and purchasing additional seats will follow.\n\n![New checkout](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/checkout.png){: .shadow.medium.center}\n\n## Help users manage Feature Flags more effectively\n\nUsers are unable to manage and connect feature flags to MRs, epics, issues, and discussions, leading to friction when coordinating strategies.\n\n**Solution:** Validate the concept of feature flags as an issue type, where users can manage feature flags in a centralized location and benefit from all the capabilities that come with issues. This is currently [in solution validation](https://gitlab.com/gitlab-org/ux-research/-/issues/1240) with development work planned to start in 13.10.\n\n![New checkout](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/feature-flags.png){: .shadow.medium.center}\n\n## Allow users to re-add a merge request to the merge train\n\nWhen a merge train pipeline fails due to infrastructural failures, users can't easily add the MR back to the merge train.\n\n**Solution:** As an MVC solution, we're providing users with better messaging in the MR widget that communicates the possible reason for the failure and the appropriate workflow to add the MR back to the train. [Currently scheduled for 13.9](https://gitlab.com/gitlab-org/gitlab/-/issues/291168/).\n\n![Re-add MR to merge train](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/readd-mr-merge-train.png){: .shadow.medium.center}\n\n## Make merging easier, so that changes can be integrated faster\n\nMerging changes is one of the key moments in the DevOps lifecycle. But today, merging in GitLab has various UX problems that slow down users and their team's pace of shipping.\n\n**Solution:** First steps to make merging lovable: [Map states, actions, and information associated with the merge request merge widget](https://gitlab.com/gitlab-org/gitlab/-/issues/299193), [Conduct a competitive analysis of merge checks UX](https://gitlab.com/gitlab-org/gitlab/-/issues/300767), and [Create a design framework for MR merge widget](https://gitlab.com/gitlab-org/gitlab/-/issues/299195).\n\n![Make MR widget lovable](https://about.gitlab.com/images/blogimages/2021-february-interesting-ux/make-mr-widget-lovable.png){: .shadow.medium.center}\n\nCover image by [Med Badr Chemmaoui](https://unsplash.com/@medbadrc) on [Unsplash](https://unsplash.com/photos/ZSPBhokqDMc)\n{: .note}\n",[9,725,682],{"slug":1278,"featured":6,"template":686},"interesting-things-ux-is-working-on-february-2021","content:en-us:blog:interesting-things-ux-is-working-on-february-2021.yml","Interesting Things Ux Is Working On February 2021","en-us/blog/interesting-things-ux-is-working-on-february-2021.yml","en-us/blog/interesting-things-ux-is-working-on-february-2021",{"_path":1284,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1285,"content":1291,"config":1297,"_id":1299,"_type":13,"title":1300,"_source":15,"_file":1301,"_stem":1302,"_extension":18},"/en-us/blog/is-devops-for-designers",{"title":1286,"description":1287,"ogTitle":1286,"ogDescription":1287,"noIndex":6,"ogImage":1288,"ogUrl":1289,"ogSiteName":672,"ogType":673,"canonicalUrls":1289,"schema":1290},"Can DevOps be beneficial for design and UX?","Look at how DevOps phases can be integrated with design and UX, and why we've built the Figma plugin to help with this.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681548/Blog/Hero%20Images/GitLab-Figma-header.png","https://about.gitlab.com/blog/is-devops-for-designers","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Can DevOps be beneficial for design and UX?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jordi Mon\"}],\n        \"datePublished\": \"2020-09-03\",\n      }",{"title":1286,"description":1287,"authors":1292,"heroImage":1288,"date":1294,"body":1295,"category":787,"tags":1296},[1293],"Jordi Mon","2020-09-03","\n\nAccording to two legends on the field of Design, [Don Norman](https://en.wikipedia.org/wiki/Don_Norman) and [Jakob Nielsen](https://en.wikipedia.org/wiki/Jakob_Nielsen_(usability_consultant)), a successful user experience occurs when the user can fulfill his or her needs. A product designed with high UX standards in mind should have enough functionality and self-explanatory visual information for all its users to complete their tasks without help.\n\nGitLab is a complete [DevOps platform](/topics/devops-platform/) – meaning, good UX within GitLab equals good developer experience (DX). Following Nielsen and Norman's argument, good DX is the ability to not only use the product’s UI to serve a dev's needs, but also to find good documentation in context, a versatile API, and general compatibility with their working environment. Considering this succinct description of the GitLab app, one could easily infer that all its users are either software developers or system administrators, right?\n\nHowever, this assertion isn’t entirely true. There's no doubt that developers and operators are still the protagonists of DevOps, but more and more people from other professions (including graphic design, research, marketing, and even psychology) are contributing to software building. At GitLab, we acknowledge that in our vision.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">We've got a vision for our product and \u003Ca href=\"https://twitter.com/CLenneville?ref_src=twsrc%5Etfw\">@CLenneville\u003C/a>, VP of UX at GitLab, is sharing it live at \u003Ca href=\"https://twitter.com/hashtag/GitLabCommit?src=hash&ref_src=twsrc%5Etfw\">#GitLabCommit\u003C/a>. \u003Ca href=\"https://t.co/if4xVWgxqT\">pic.twitter.com/if4xVWgxqT\u003C/a>\u003C/p>— GitLab (@gitlab) \u003Ca href=\"https://twitter.com/gitlab/status/1298911891352367104?ref_src=twsrc%5Etfw\">August 27, 2020\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWe're already taken the first strides in this long-term vision for the GitLab product, and they aim to welcome designers to [DevOps](/topics/devops/). This post describes the first steps taken by GitLab's Product team to connect DevOps with design.\n\n## Is DevOps for designers?\nVisual design for applications is a completely different field than application development. For starters, designers work with designs, screens, user flows, prototypes, and so many other graphic assets, while developers only use [source code](/solutions/source-code-management/). Their workflows are also pretty different: While devs may find enough solace in push, pull, merge, and other operators useful to their daily routines with code, visual designers may require other sets of features that allow them to communicate, receive, and apply feedback on designs.\n\nIs a platform like GitLab a good place for designers to try DevOps? We think so. One of the foundations of DevOps is that [cross-functional teams deliver better products faster](http://cloudplatformonline.com/rs/248-TPC-286/images/DORA-State%20of%20DevOps.pdf). If that is the case, then why keep designers' collaboration platforms separate? Why make their workflows independent and disconnected, and why hand off deliverables when it should be all about constant iteration with handovers?\n\n[Figma](https://www.figma.com/) is a vector graphics editor and prototyping tool. Figma founder and CEO, [Dylan Field](https://twitter.com/zoink?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor), crunched some numbers and discovered that the designers: developer ratio had increased considerably among top players.\n\n![2.5x increase in desginer to dev ratio](https://about.gitlab.com/images/blogimages/2020-09-03-is-devops-for-designers-figma-plugin/designer-to-dev-ratio.png){: .shadow.center}\nScreenshot from [TechCrunch](https://techcrunch.com/2017/05/31/here-are-some-reasons-behind-techs-design-shortage/)\n{: .note.text-center}\n\nWhen we mention \"top players,\" we're not talking about adaptable, flexible startups. Quite the contrary, in fact.\n\n> \"The companies willing to go on the record were mostly enterprise, so this sample doesn’t even include the consumer startups that famously focus on design, like Airbnb. Facebook staffers told us the social network has quadrupled its designer hiring target in the last two years alone - but Facebook wouldn’t officially comment.\" - Dylan Field wrote in [TechCrunch](https://techcrunch.com/2017/05/31/here-are-some-reasons-behind-techs-design-shortage/)\n\nAt GitLab, we've learned that frictionless feedback loops are the best way to validate our work. The feedback loop is fastest when designers can work hand in hand with the developers that create the source code that will later give life to their visuals.\n\n## Let DesignOps connect with DevOps: GitLab ❤️ Figma\n\nWe want designers to work in GitLab, which is why we created a new product category called [Design Management](/direction/plan/design_management/#introduction) that strives to make Designers welcome within GitLab and support their workflows. The first step in this direction is to change the dreaded handoff to a more iterative handover that will more accurately capture the feedback loops of the last part of the design workflow. How Design Management works at large will be the subject of another, in-depth blog post coming soon. You can catch a brief sneak peek on [YouTube](https://youtu.be/5oo0m3s5Gfk).\n\nWe developed a plugin to connect GitLab to Figma, to simplify the handover process. Now, you can upload one or multiple frames to any issue. From then on designers, PMs, and engineers can discuss the designs within GitLab.\n\nNext, we explain why we picked Figma and then dive deeper into how to install and use the plugin.\n\n## Why did we choose to integrate with Figma?\n\nWatch the video below as [Jeremy Elder](/company/team/#jeldergl), senior product designer, FE/UX Foundations, Visual Design, explains why we chose Figma as the main tool for Product Designers in GitLab.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/Qa9M74CfuXY?start=650&end=1040\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nOnce Product Design was comfortable using Figma to work on GitLab's design, the decision to build a plugin came naturally, considering how much we value [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding): Why not make the transition from Figma to GitLab much easier? GitLab team members are heavy Figma users ourselves (our Figma community is [here](https://www.figma.com/@GitLab)) and you can see how we use it for product design below:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe style=\"border: 1px solid rgba(0, 0, 0, 0.1);\" width=\"800\" height=\"450\" src=\"https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2F73OcYdBfOaK2xlChC3tbNX%2FFigma-for-GitLab%3Fnode-id%3D2%253A61%26scaling%3Dscale-down&chrome=DOCUMENTATION\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\nGitLab's own community was requesting we build the Figma plugin.\n\n> “When will the plugin be published? Because our entire development team works on Linux\n> machines and can't run the Desktop application. When is this plugin going to be published so > it would be possible also for the users with Linux-based systems, which are more or less\n> forced to use the Web app, to use this plugin? I think, this would bring both, Figma and GitLab, generally a huge step forward.” – Community member [Emanuel Bennici](https://gitlab.com/l0nax) commented in the ([issue](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/issues/2#note_371842296))\n\n>“I also work on Linux and this would be a huge improvement for me and my company.” – Community member [Gabriel Jann](https://gitlab.com/JAIABRIEL) commented in the ([issue](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/issues/2#note_371844752))\n\n## How do I get started with the Figma plugin?\n\n First and foremost [download the plugin](https://gitlab.com/gitlab-org/gitlab-figma-plugin) and get going with the first steps in the [User Guide](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/wikis/home). In the video below, [Christen Dybenko](/company/team/#cdybenko), Design Management PM, walks you through the installation and the first steps with the plugin in GitLab:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/KR2nuehGtrU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## What's next?\n\nTell us about your experience using the plugin by commenting on the [issue](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/issues/44).\n\nQuestions about the future of Design Management? Wondering about how it fits into our broader DevOps scheme? Check our [next steps](/direction/plan/design_management/#whats-next--why) and [long term strategy for Design Management](/direction/plan/design_management/#long-term-strategy).\n",[9,725,682],{"slug":1298,"featured":6,"template":686},"is-devops-for-designers","content:en-us:blog:is-devops-for-designers.yml","Is Devops For Designers","en-us/blog/is-devops-for-designers.yml","en-us/blog/is-devops-for-designers",{"_path":1304,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1305,"content":1310,"config":1316,"_id":1318,"_type":13,"title":1319,"_source":15,"_file":1320,"_stem":1321,"_extension":18},"/en-us/blog/iterate-like-a-gitlab-designer",{"title":1306,"description":1307,"ogTitle":1306,"ogDescription":1307,"noIndex":6,"ogImage":926,"ogUrl":1308,"ogSiteName":672,"ogType":673,"canonicalUrls":1308,"schema":1309},"Iterate Like a GitLab Designer","Think big, ship small, learn fast","https://about.gitlab.com/blog/iterate-like-a-gitlab-designer","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Iterate Like a GitLab Designer\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Holly Reynolds\"}],\n        \"datePublished\": \"2020-10-16\",\n      }",{"title":1306,"description":1307,"authors":1311,"heroImage":926,"date":1313,"body":1314,"category":764,"tags":1315},[1312],"Holly Reynolds","2020-10-16","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAny GitLab team member can tell you that [iteration](https://handbook.gitlab.com/handbook/values/#iteration) is often the most challenging organizational value to practice. Designing and shipping the smallest thing possible can often feel like it goes against our desire to beautify, polish, and perfect.  \n\nThe major challenge is in scoping down the initial vision. Sometimes, we may have to cut scope so much that we do not feel we are shipping anything of value. We often feel a [low level of shame](https://handbook.gitlab.com/handbook/values/#low-level-of-shame) that it doesn't look complete. We sometimes worry that perhaps even a paying customer will feel this pain too.\n\nIn a [GitLab Unfiltered conversation](https://www.youtube.com/watch?v=0lhjzU-QZ2w&feature=youtu.be) about iteration between two GitLab product designers, they talk about our iteration value and some of the challenges teams experience while practicing it: \n\n_\"What we try to do differently than other companies is that we try to make something embarrassingly small. Sometimes I feel that we get trapped in that thought. We become too focused on minimal. Then we've gone past the point of being viable for our business or valuable for our users.\"_\n\nAt best, the goal of making a feature smaller can cause a low level of shame. And at worst, it can create tension on a team that worries about shipping an incomplete vision to customers. \n\nWhen we try to deliver an MVC (or [Minimal Viable Change](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc)), a challenging aspect is when the problem feels too large. Perhaps there is a clear [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions), but the amount of time and resources needed to accomplish it is too large. We ask ourselves: _\"What needs to be cut while still providing immediate value and paving the way for scalable improvements?\"_ We often address this question with our [Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/), which includes steps to validate the problem or solution and test in advance to minimize the more significant unknowns.\n\nAnother challenge is keeping our eyes on the bigger picture while also creating MVC solutions. It's easy to focus on the trees we're trimming at the time, but this can cause erosion in the forest elsewhere if we cut them back too much. Collaboration amongst Product Designers and Product Managers in various stages is critical to ensuring we're not making choices that could have a negative ripple effect throughout the application.\n\nAs our team members phrase it, the solution to all of this is to _think big, ship small, and learn fast_.\n\n## Keeping MVCs as C's, not P's\n\nWe can balance smaller with viable if we define the [MVC](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc). MVC (Minimal Viable Change) is not the same as MVP (Minimum Viable Product). Thousands of little changes make up a product, and there is often more than one right way to solve a problem. An MVC is a singular yet mighty change that takes a step in the right direction to improving the product for the user. \n\nA series of incremental, step-wise MVCs make a feature more complete. It can often take multiple releases to discern if this is the right direction. However, we can also learn more and at a faster pace along the way. The inverse would be to ship extensive features that take longer to build, which means we're less likely to learn quickly.\n\nAt GitLab, we currently release in a 1-month milestone cadence. That said, there are many opportunities to learn faster, and we employ a variety of methods to do so. Designers work with Product Managers (PMs) to incrementally de-risk feature ideas. We break solutions down into smaller experiments, all while considering the impact of these experiments both in the short and long term. Our approach requires both divergent and convergent thinking at any given time on an idea. We need to think big to know what small changes will make sense within the broader vision.\n\n## Think Big: Define the Vision\n\nThinking big helps us keep a high-level view of the overall product while exploring ways to learn from small, valuable features that we can ship quickly. \n\nSo, what does it look like to _Think Big_? We start with a known problem and examine how that problem impacts our users, the organization, and the product as a whole. The [GitLab product development flow](https://about.gitlab.com/handbook/product-development-flow/) helps us balance being reactive to known issues while proactively identifying UX improvements. Before we begin to generate solutions for a problem we hear about, we first must weigh this problem against all others in our backlog.\n\nThis process of determining what to work on first can be a bit tricky at times. However, some of the criteria we consider when we prioritize include:\n1. New product category work\n2. Determining the next [maturity state](https://about.gitlab.com/direction/maturity/) for a product category (e.g., _viable_ to _complete_)\n3. The envisioned feature is large or introduces a significant change to the product's UX\n4. Understanding if a JTBD is relevant to why customers buy or use the product\n5. When targeting a new user or buyer persona\n\nOnce we've determined what we want to address first, ideas enter a phase known as [Problem Validation](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-2-problem-validation). When a problem is known, our ideas for a solution also become more focused. An important signal to watch for revolves around whether we have a shared language about the problem, who feels it, and if we have a collection of reasonably small solution proposals. \n\nProduct and UX Research may work together to run studies, user interviews, competitor analysis, and other research efforts within the problem validation phase. We also review data from previous studies surrounding the [category maturity](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/) and [System Usability Score (SUS)](https://about.gitlab.com/handbook/product/ux/ux-resources/#system-usability-score) results.\n\nAs the conversational thread coalesces around a viable range of solutions, we know what to do next. At this point, the idea may move into our [Design phase](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-design), where we create wireframes and prototypes.\n\n## Solution Evolution\n\nAt GitLab, nothing should ever happen in a silo. If we are to think big, we need to be sure that we are sharing and collaborating on our ideas with others in the organization and even the wider GitLab community. \n\nThe [Design phase](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-design) is often a highly collaborative phase involving at the very least: Design, Product (for insight on business needs, strategy and priorities), and Engineering (to help determine the feasibility of possible solutions). Others involved may include Tech Writing, UX Research, Sales, Customer Success, the CEO, and GitLab community members.\n\nThis phase's challenge is not to let the conversation stall or the participants get into _analysis paralysis_. As the DRI (directly responsible individual) of this phase, the Designer often needs to select a path and move forward.\n\nLastly, the [GitLab Pajamas design system](https://design.gitlab.com/) is an excellent resource for providing a solid foundation for UI and design patterns. It reduces the time needed to think through solutions and create visual deliverables for those solutions. Again, thinking about the big picture of being consistent while exploring ways to move fast and ship small.\n\nOnce design solutions are in place, the idea can move into the [Solution Validation phase](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-4-solution-validation) to test and validate the MVC with users. Suppose users' feedback proves that the solution is right - meaning, it aligns with the business needs, and it's feasible. In that case, we can move into the [Planning Breakdown phase](https://about.gitlab.com/handbook/product-development-flow/#build-phase-1-plan), where it is weighted and prioritized by engineers.\n\n\n## Ship Small: Build and Ship\n\nAn aspect of GitLab's value proposition revolves around helping teams release faster and at a _sustainable_ pace. Organizations will evolve their workflows to fit their context. Every process seeks to understand what customers need, deploy the solution, and learn. We utilize our product to its fullest extent to accelerate iterations that converge toward optimal solutions to real-world problems.\n\nWe strive in the [Design phase](https://about.gitlab.com/handbook/product-development-flow/#validation-phase-3-design) to both understand the big picture and define the smallest [MVC](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc) solution. We use tools like [Figma](https://www.figma.com/community/plugin/860845891704482356/GitLab) to create prototypes and other deliverables. With Figma, engineers can view coded aspects of the design, saving time in translating design expectations during design hand-off.\n\nDesign and Engineering review the proposed solution and collaborate to:\n*   Ensure the MVC is as small as possible in terms of both the frontend and backend.\n*   Identify impacts on other areas of the product. \n*   Discuss possible performance issues.\n*   Decide whether to implement new vs. existing patterns and UI elements.\n\nAdditional design iterations could occur if the idea is still too large to deliver within a single milestone.\n\n## Learn Fast: Measure and Learn\n\nThroughout the entire GitLab Product Development Flow, we're learning. We're not just uncovering what needs our users have. We're also learning about ways to improve our methods to make our process more efficient. Because we ship small, our learnings can and should happen quickly. We're always exploring ways to get feedback faster from our users and empathize with their needs. We also [dogfood](https://about.gitlab.com/handbook/engineering/development/principles/#dogfooding) our product, which helps us to experience and identify the same usability and performance pains as our users. \n\nFinally, we regularly:\n*   Have 1:1 conversations with our users\n*   Evaluate quantitative data\n*   Document and tag the qualitative feedback for future reference\n*   Take action on insights\n\n## Conclusion \n\nPractice and theory don't always align. Sometimes, we'll realize later that we could have made something smaller or better. Instead of charging ahead with the plan, we take a step back and make the idea smaller. The ultimate goal of iteration is to release the smallest change possible to learn from real-world usage.\n\nWe also embrace contributions from team members and the wider community. In the words of [Jeremy Elder](https://gitlab.com/jeldergl): \"[In the cycle of iteration, there are multiple on-ramps](https://www.youtube.com/watch?v=apQTxlqZeBA&feature=youtu.be&list=PL05JrBw4t0KpgzLWbRCXf8o7iap-uoe7o&t=1278).\"\n\n\n## Explore further\n*   [GitLab design talks: Iteration](https://www.youtube.com/playlist?list=PL05JrBw4t0KpgzLWbRCXf8o7iap-uoe7o)\n*   [Presenting an MVC solution](https://about.gitlab.com/handbook/product/ux/product-designer/index.html#present-an-mvc-solution)\n*   [Conduct a Job statement activity with the team](https://about.gitlab.com/handbook/product/ux/jobs-to-be-done/)\n*   [Opportunity Canvas](https://about.gitlab.com/handbook/product-development-flow/#opportunity-canvas)\n*   [Improvement phase in the Product Development Flow](https://about.gitlab.com/handbook/product-development-flow/#build-phase-4-improve)\n",[9,682,725,1097,811],{"slug":1317,"featured":6,"template":686},"iterate-like-a-gitlab-designer","content:en-us:blog:iterate-like-a-gitlab-designer.yml","Iterate Like A Gitlab Designer","en-us/blog/iterate-like-a-gitlab-designer.yml","en-us/blog/iterate-like-a-gitlab-designer",{"_path":1323,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1324,"content":1330,"config":1336,"_id":1338,"_type":13,"title":1325,"_source":15,"_file":1339,"_stem":1340,"_extension":18},"/en-us/blog/jira-importer-research",{"title":1325,"description":1326,"ogTitle":1325,"ogDescription":1326,"noIndex":6,"ogImage":1327,"ogUrl":1328,"ogSiteName":672,"ogType":673,"canonicalUrls":1328,"schema":1329},"Jira Importer Research","Senior Product Designer Holly Reynolds is seeking participants for research surrounding importing Jira issues.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679490/Blog/Hero%20Images/jira-importer-blog-post.png","https://about.gitlab.com/blog/jira-importer-research","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Jira Importer Research\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Holly Reynolds\"}],\n        \"datePublished\": \"2020-04-08\",\n      }",{"title":1325,"description":1326,"authors":1331,"heroImage":1327,"date":1332,"body":1333,"category":764,"tags":1334},[1312],"2020-04-08","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nWorking with multiple DevOps applications including Jira and GitLab? Looking to consolidate to or test drive GitLab with your own existing Jira issues? We are researching ways to provide options for importing issues from Jira into GitLab and need your help!\n\n**Problem Overview**\nWe believe our [Project Management](https://about.gitlab.com/solutions/agile-delivery/) users need a way to easily transfer existing issues from Jira into GitLab beyond what's possible with CSV exports. We want to dive deeper into understanding what will provide the most value for these users in this import process from the start and what their expectations are for this experience.\n\n**Our recruiting Challenge**\nThis is a bit of a unique group we're seeking feedback from in that a specific persona may not always apply. For example, both a [Systems Admin](https://about.gitlab.com/handbook/product/personas/#sidney-systems-administrator) or a [DevOps Engineer](https://about.gitlab.com/handbook/product/personas/#devon-devops-engineer) could be responsible for helping their team transition from Jira to GitLab. We'd like to hear from anyone with issues currently in Jira that would like to import them into GitLab via an API.\n",[1078,9,682,1335,1097],"developer survey",{"slug":1337,"featured":6,"template":686},"jira-importer-research","content:en-us:blog:jira-importer-research.yml","en-us/blog/jira-importer-research.yml","en-us/blog/jira-importer-research",{"_path":1342,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1343,"content":1348,"config":1356,"_id":1358,"_type":13,"title":1359,"_source":15,"_file":1360,"_stem":1361,"_extension":18},"/en-us/blog/lessons-learned-as-data-team-manager",{"title":1344,"description":1345,"ogTitle":1344,"ogDescription":1345,"noIndex":6,"ogImage":800,"ogUrl":1346,"ogSiteName":672,"ogType":673,"canonicalUrls":1346,"schema":1347},"Lessons learned managing the GitLab Data team","Staff Data Engineer Taylor Murphy shares his lessons and takeways from one year as the Data team manager.","https://about.gitlab.com/blog/lessons-learned-as-data-team-manager","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Lessons learned managing the GitLab Data team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taylor Murphy\"}],\n        \"datePublished\": \"2020-02-10\",\n      }",{"title":1344,"description":1345,"authors":1349,"heroImage":800,"date":1351,"body":1352,"category":1353,"tags":1354},[1350],"Taylor Murphy","2020-02-10","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-02-19.\n{: .alert .alert-info .note}\n\nFrom April 2018 to May 2019 I was the manager of the Data team for GitLab. I took this role after my manager left, when I started reporting directly to the CFO as a Data Engineer.\n\nI remember saying to him \"this doesn't seem like the right level of abstraction for you,\" and proposed I step up to become the manager. I also said I didn't want to do this for a long period of time, since I intentionally came to GitLab to move from a manager role to an individual contributor role and focus on Data Engineering.\n\nWhat follows are a few lessons I learned (and relearned!) in my one-year stint as the manager of the Data team. Eventually, I aim to become a manager again and I hope to remember these lessons and learn even more.\n\n### Plan for growth\n\nWhile I was Data team manager, GitLab grew in size by ~300%. Having only worked previously at established companies and at a very small startup, I was not prepared for this level of growth and the strain it would put on our resources.\n\nI recently surveyed colleagues of mine in the data community and discovered that, as a percentage of headcount, most Data teams are anywhere from 2-8%.\n\nThis means a 200-person company should have at least four people, and realistically around 10 people, focused on data. This includes analysts, engineers, scientists, and managers.\nIn April of 2018, we were at \u003C 1% (1/300) and would continue to be \u003C 1% throughout 2018.\n\nAs the company grew, I did not wholly understand how the business was planning to grow and how the Data team would scale to meet the data needs of the organization. This lack of strategic thinking led to a situation where I felt blindsided and overwhelmed by the number of requests for data and analytics.\n\nEven with the addition of the excellent people I was able to hire, I wasn't doing as good a job as I needed to help my team truly succeed.\n\nLesson: Understand the trajectory of the company, the workload you have and expect to have, pick a gearing ratio for headcount, stick to your hiring targets, and think about [team structure](https://blog.getdbt.com/data-team-structure-examples/).\n{: .alert .alert-gitlab-purple}\n\n### Individual contributor or manager? Pick one\n\nBy the end of 2018, the Data team was a three-person team: one data analyst, one data engineer, and me.\nThankfully, the three of us were, I'm not ashamed to say, excellent at our jobs and performed at a level beyond what you would expect three FTEs to handle.\n\nBut even we have limits and couldn't do it all.\n\nDue to the volume of work we were trying to accomplish, it was critical that I take on analyst and engineering work as well.\n\nThis created a situation where I was splitting my brain and my attention trying to do too many things at once.\n\nSome days would be all manager work, and I would make zero progress on issues assigned to me. Others would be IC work, and I would fall behind on managerial tasks. The worst days were when I would try to do both, and everything would suffer.\n\nAs time went on this split brain effect would become worse – the signs of burnout were starting to ramp up rapidly.\n\nI was able to hire more people, which put more demand on the manager side of me, yet the volume of work was increasing while I was still the primary contributor and maintainer of our codebase. By the end, I didn't feel like I was a good manager, and I felt like my technical skills were rapidly atrophying.\n\nLesson: If you're a manager, be a manager. Yes, you'll have to pick up some work, especially at a startup, but figure out your exit plan so you can pass that work to your team who will be much better at accomplishing it than you.\n{: .alert .alert-gitlab-purple}\n\n### Hire awesome people\n\nThis should go without saying, but hire excellent people and your life will be better. My first four hires for the Data team (two in 2018, two in early 2019) have blown me away with their skill, curiosity, tenacity, and intelligence.\n\nI learned from my previous job and past bosses the value in finding great people and the force multiplier they can have on the work you're trying to accomplish.\n\nLesson: Continue hiring great people! But think about how to scale it.\n{: .alert .alert-gitlab-purple}\n\n### Invest in process\n\nThis lesson I learned from [Emilie Schario](https://gitlab.com/emilie), the first Data Analyst I hired. She taught me to think about how and where we'll need processes as the company scaled, so we could remain [efficient](https://handbook.gitlab.com/handbook/values/#efficiency).\n\nWe, of course, used GitLab for managing our code, and we had built-in merge request workflows, but she took the time to think about the messy \"people stuff\" surrounding the technology.\n\nA short list of artifacts she created:\n\n- [Onboarding issue for new analysts](https://gitlab.com/gitlab-data/analytics/-/blob/master/.gitlab/issue_templates/Data%20Onboarding.md)\n- [Onboarding script to get new analysts up and running quickly](https://gitlab.com/gitlab-data/analytics/-/blob/master/admin/onboarding_script.sh)\n- [Merge request templates, so everyone is working off the same checklist](https://gitlab.com/gitlab-data/analytics/-/blob/master/.gitlab/merge_request_templates/dbt%20Model%20Changes.md)\n\nAnd many more I'm sure I'm forgetting.\n\nWhile she wasn't the manager, she had the experience and understood the parts of working at a company that can slow down team members, and she worked to automate as much of it as possible. I've heard from many people outside the company how much they appreciate our documentation in general and our onboarding process in particular.\n\nThat is a testament to thinking about scale and having the empathy to continually step into the shoes of a GitLab learner and to see things from an outsider's perspective.\n\nAs Data teams have grown and evolved they've also [become more technical](https://blog.getdbt.com/what-is-an-analytics-engineer/). These mean it's important to invest in the technical process as well – this means you should have [version control](/topics/version-control/), change control (merge requests), automated testing, and [documentation on everything you're doing](https://dbt.gitlabdata.com/).\n\nCertain tools make implementing technical processes better and easier, which I'll highlight in the next section.\n\nLesson: (1) Think about process deeply and document everything. (2) Maintain the mind of a learner and continually think about what day one with GitLab is like for new people. (3) Invest in process, documentation, and testing - they are gifts you give your future self.\n{: .alert .alert-gitlab-purple}\n\n### Pick excellent tools\n\nAlong with process, picking the right tools can be a force multiplier for team productivity. When the Data team started, we were using PostgreSQL as our data warehouse. Postgres is not column-oriented, and at a certain point it doesn't make sense to use it as an analytics database.\n\nWe went with Postgres anyway because we believe in using a [boring solution](https://handbook.gitlab.com/handbook/values/#boring-solutions) and it aligns with our value of [iteration](https://handbook.gitlab.com/handbook/values/#iteration). For the volume of data we were throwing at it, Postgres did admirably. We used the CloudSQL-hosted version which enabled us to do cool, programmatic things with GitLab CI (I'll save that for another post).\n\nOnce we outgrew Postgres we decided to move to Snowflake.\n\nOf course, being GitLab, we use GitLab the product for anything and everything, which saved us much of the stress around picking tools. It has all the things you want from a coding perspective, and it has enough of the things you need to be productive as a manager. No need for Trello, Jira, and a dozen other tools.\n\nBy far though, the best tool for the Data team's productivity is [dbt (data build tool)](https://www.getdbt.com/). I could talk forever about how great dbt is, but suffice to say that we would not be where we are today and we would not have been able to support the organization this well with such a small crew, were it not for dbt and the great community behind it.\n\nLesson: Find the best tools you can for your team. Use dbt!\n{: .alert .alert-gitlab-purple}\n\n### Handling under-performers is a challenge\n\nUp until 2019, I'd never hired somebody who didn't perform well in their job, aside from a few interns.\nI'd like to think most of this was my ability to find good people, but it was probably luck, if I'm being honest.\n\nLast year challenged me with two under-performers on the team that I now realize I could have supported better. Having those difficult conversations with people was hard when I wasn't 100% in the manager brain space. My advice is to pay attention to those first few weeks of productivity, and if you find there are gaps, either in skills or motivation, do whatever you can to call out the gaps in a friendly and productive way, and then give your people every opportunity to become better.\n\nLesson: Be a good manger, notice things early, and help your team proactively.\n{: .alert .alert-gitlab-purple}\n\n### So many meetings\n\nGitLab has a great culture around meetings.\n\nThey [always start on time](/handbook/communication/#video-calls), there [must be an agenda for every meeting](/handbook/communication/#scheduling-meetings), and [people aren't afraid to end meetings early if everything on the agenda is done](https://handbook.gitlab.com/handbook/values/#be-respectful-of-others-time).\nEven with this rigor and discipline you will find yourself on the [\"Manager's Schedule\"](http://www.paulgraham.com/makersschedule.html) and will be in a lot of meetings. But that's okay! That's part of your job.\n\nI will always argue that you should still try to reduce the time you're in meetings, but if you're in a meeting, do your best to ensure your team *isn't* also in a meeting, if at all possible. Meetings are terrible for makers (i.e., your direct reports). Shield your team from them as much as possible.\n\nLesson: Meetings are a part of the job, reduce them as much as you can, and protect your team from unnecessary meetings.\n{: .alert .alert-gitlab-purple}\n\n### You need executive buy-in and representation\n\nPart of the reason I was excited to join GitLab was because the C-Suite clearly supported having a Data team in the organization.\nThe CEO and CFO understood the value a Data team could bring, even if the specifics and execution were blurry.\nThis is important! You will be in a tough spot if your company has nobody on the executive team that understands the value that good descriptive and predictive analytics can provide.\nData literacy is a cultural attribute, and it's [near impossible to grow literacy](https://towardsdatascience.com/is-your-company-too-dumb-to-be-data-driven-696932d597c3) in an organization if the CEO isn't driving it in some way.\n\nAt a certain scale though, you need Data leadership beyond a team manager.\nYou absolutely need someone at the Director level and up that can advocate and champion Data literacy and fluency across the functional areas of the organization.\nManagers can't be expected to spend much time on this since there is so much daily work to be done.\n\nLesson: Be wary of organizations that don't have C-Suite buy-in around the data function.\nAdvocate for a Director-level and up position that can be the cheerleader for Data across the organization.\n{: .alert .alert-gitlab-purple}\n\n### Plan to spend some money\n\nExecutive level buy-in for a Data team is important because of this fact: Starting a Data team can be expensive. To be effective, you'll need to hire several people or empower your single data lead to purchase some third-party software.\n\nOut of the gate you'll need an extract and load tool like Stitch or Fivetran, you'll need a data warehouse (e.g., Snowflake, BigQuery, Redshift), you'll need compute to run transform jobs, and you'll want a BI tool.\nThere are free tools that can sustain you for a while, but plan to invest some money up front if you're in it for the long haul.\n\nLesson: Long term success will require investment. You can start cheaply, but to scale requires resources.\n{: .alert .alert-gitlab-purple}\n\n### Don't reinvent the wheel\n\nEspecially for things like extracting data from tools such as Salesforce, Zendesk, or Zuora, please, please, PLEASE don't write your own scripts to do this. Just pay a company to do it for you. You'll waste a ton of time doing something that doesn't deliver business value and will probably come back to bite you in the end.\n\nYou should spend most of your time [delivering value for the business](https://blog.getdbt.com/the-startup-founder-s-guide-to-analytics/) in the form of automated reporting and generating insights, not writing a Salesforce to Snowflake extractor for the thousandth time.\n\nLesson: Pay for Stitch or Fivetran for common data extractions.\n{: .alert .alert-gitlab-purple}\n\n### Manager is a different career\n\nDon't think about becoming a manager as an extension of your individual contributor career. It *is* a different career path and your IC-skills will certainly help you be a better manager. However, management is its own set of skills and choosing to go into this field puts you on a different career path. It's not necessarily better depending on how you define success.\n\nGo into management with open eyes and a full understanding that you are switching tracks and not \"moving ahead\". It isn't permanent, though, and can be reversed if you choose.\n\nLesson: Don't assume the move to manager is the default for an IC. Think deeply about your [career](https://www.locallyoptimistic.com/post/career-ladders-part-1/). Read [about the Engineer/Manager Pendulum](https://charity.wtf/2017/05/11/the-engineer-manager-pendulum/).\n{: .alert .alert-gitlab-purple}\n\n### It's okay to be a little selfish\n\nOne area I've struggled with for a while is making the effort to be a little selfish. I can have a people-pleaser mentality which, when applied to the business of a startup, can be useful: Startups need people that are willing to do what it takes to make the company successful (within reason!). But once the company is in a growth stage or beyond, that mentality is a recipe for burnout.\n\nAt my previous company, we were less than 30 people. Having the attitude of trying to do and learn as much as possible was a good strategy for me. I learned a ton, was given a bunch of responsibility, and helped the business grow. That strategy worked for me at GitLab for a while too. After some time passed, it was clear I couldn't keep up with everything, and my sanity would start to suffer without a fix.\n\nBeing selfish in this case meant I had to be okay with wanting to take a \"step back\" from the manager role to the IC role (Spoiler: it's not a step back! See the previous point).\n\nI had to admit to myself that I wanted to focus on programming more and that continuing down the manager track wasn't currently right for me.\n\nIt felt selfish because it was hard in the moment to see that what the business needed was somebody who *wanted* to be the manager. It didn't need me to continue in the role just because I happened to currently be in the role.\n\nWhile there were short-term ramifications for the team because of my move to an IC role, I know that I'm healthier for it, and we now have two excellent managers who are leading the team further than I could have.\n\nLesson: (1) It's a *good* thing to prioritize and be selfish about your mental health. (2) It's okay to say \"No, I can't do this anymore\". (3) Companies need people who want to be in their jobs - performance is better and people are happier.\n{: .alert .alert-gitlab-purple}\n\n### Fin\n\nMy hope is that these lessons are valuable to you, and are applicable in your own life and career. I would love to hear from you if you disagree with any of these, or if you have your own stories and lessons to share about your career in data; please reach out on [Twitter](https://twitter.com/tayloramurphy), via email (tmurphy at gitlab.com), or in an [issue in our main project](https://gitlab.com/gitlab-data/analytics/).\n\nThank you for reading and thank you to GitLab for enabling my growth as a Data professional.\n\n*Special thanks to [Emilie Schario](https://gitlab.com/emilie) for her review on multiple drafts of this post.*\n","culture",[1355,9,768],"demo",{"slug":1357,"featured":6,"template":686},"lessons-learned-as-data-team-manager","content:en-us:blog:lessons-learned-as-data-team-manager.yml","Lessons Learned As Data Team Manager","en-us/blog/lessons-learned-as-data-team-manager.yml","en-us/blog/lessons-learned-as-data-team-manager",{"_path":1363,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1364,"content":1370,"config":1378,"_id":1380,"_type":13,"title":1381,"_source":15,"_file":1382,"_stem":1383,"_extension":18},"/en-us/blog/navigate-application-architecture-drift-and-organizational-alignment",{"title":1365,"description":1366,"ogTitle":1365,"ogDescription":1366,"noIndex":6,"ogImage":1367,"ogUrl":1368,"ogSiteName":672,"ogType":673,"canonicalUrls":1368,"schema":1369},"Navigate application architecture drift and organizational alignment","Explore how to manage architecture drift by balancing simplification and team realignment using the FINE Analysis. Ensure efficiency and agility throughout an application's lifecycle.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749676151/Blog/Hero%20Images/navigation.jpg","https://about.gitlab.com/blog/navigate-application-architecture-drift-and-organizational-alignment","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Navigate application architecture drift and organizational alignment\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stephen Walters\"},{\"@type\":\"Person\",\"name\":\"Lee Faus\"}],\n        \"datePublished\": \"2024-09-18\",\n      }",{"title":1365,"description":1366,"authors":1371,"heroImage":1367,"date":1374,"body":1375,"category":787,"tags":1376},[1372,1373],"Stephen Walters","Lee Faus","2024-09-18","Application architecture drift is a common phenomenon in software development as projects evolve and grow in complexity. When this happens, you face a critical decision: Should you simplify the application architecture to fit the current team topologies, or should you adjust your team topologies to match the changing application architecture? This decision is pivotal for maintaining efficiency, innovation, and success throughout an application's lifecycle, which spans years and includes stages from experimentation to production, maintenance, and, ultimately, the end of support.\n\n## What is application architecture drift?\n\nApplication architecture drift occurs when the initial design and structure of an application no longer align with its current state due to continuous improvement, feature additions, and technology advancements. This drift can lead to increased complexity, technical debt, and potential performance bottlenecks if not properly managed.\n\nTo effectively manage such drift, it's essential to consider the teaming topology that supports the application at different levels of application maturity. If your team structure does not accommodate the complexities of the application architecture, you risk a failure on deliverables, which leads to poor customer satisfaction metrics and loss of customer adoption.\n\nWhen team topologies properly adjust to application complexities, poor decisions on implementation details are minimized, resulting in a more scalable and resilient application architecture. As Conway’s Law states, “Organizations which design systems are constrained to produce systems which are copies of the communication structures of these organizations.\" This can result in unintended design additions due to organizational setup. In most cases, these additions can lead to weakened team identities, uncertain responsibilities, and poor team interactions and communications.\n\n## The role of team topologies in managing architecture drift\n\n[Team topologies](https://teamtopologies.com/) refer to the roles and responsibilities within a team and how they are organized to deliver value. When an application's architecture changes, it's crucial to assess whether your team structure is still optimal or if adjustments are needed. The FINE Analysis, as defined in the [Value Stream Reference Architecture](https://www.vsmconsortium.org/value-stream-reference-architectures), provides a valuable lens for evaluating and realigning team topologies throughout an application's lifecycle. FINE is defined as:\n\n* F = Flow of work\n* I = Impediments that slow down the flow of work\n* N = Needs that drive the potential for flow to happen\n* E = Effort that is used in the form of cognitive load\n\n### Experimentation phase\n\n- **Architecture:** Simple, flexible, and exploratory\n- **Team topology:** Small, cross-functional, adaptive teams\n- **FINE Analysis:** Stream-aligned teams will have a high Flow of work, with little initial Impedance, but with much fluctuation. Needs will be high, with a heavy reliance on enabling teams to establish standards and templates.\n- **Application architecture drift:** This will be frequent with rapid and constant change, but manageable due to early simplicity and smaller adaptive teams\n\n### Production phase\n\n- **Architecture:** More defined, scalable, and robust\n- **Team topology:** Larger, responsible, perceptible teams\n- **FINE Analysis:** The Flow of work is stabilized, but impedance starts to collect in the form of technical debt, issues and vulnerabilities. This drives up the Effort required on stream-aligned teams. At this point, enabling teams should have established ways of working and platform groups should start to reduce the cognitive load on teams. Complicated sub-systems will be defined and should be closely controlled.\n- **Application architecture drift:** This will be frequent with rapid and constant change as before. However, larger teams and a more robust but changing architecture will require higher levels of monitoring and management.\n\n### Maintenance phase\n\n- **Architecture:** Mature, stable, and optimized for efficiency\n- **Team topology:** Sustaining teams\n- **FINE Analysis:** The Needs for stream-aligned teams will reduce and be more dependent on actual customer and business outcomes. The Flow of work is much more impacted by Impediments, in particular any production issues. The Effort on teams can become exhaustive if platform groups are not stabilized and effective, enabling teams have to be responsive to continuous improvement.\n- **Application architecture drift:** Architectural changes will be far less frequent, and team structures will be aligned to ensure system stability. This is dependent upon the stability when exiting the production phase.\n\n### End-of-support phase\n\n- **Architecture:** Legacy, minimal updates, and decommissioning planning\n- **Team topology:** Transition teams\n- **FINE Analysis:** Flow of work is drastically reduced. Impedance will move to one of two ways, either reducing as production issues scale down due to lower customer usage, or increasing at a high cost due to legacy systems.\n- **Application architecture drift:** Minimal, if any, architectural drift, as teams should be focused on decommissioning over production.\n\n## Balancing simplification and realignment\n\nThe experimentation phase is important to establish the correct disciplines from the outset. The greatest risk of application architecture drift is then in the production phase. In maintenance, this risk is reduced, and, by end of support, should be negligible. So it is during the production phase, potentially the longest living phase for any business system, that we must ensure strong discipline to prevent the drift.\n\nWhen faced with architecture drift, organizations must decide between simplifying the application architecture to fit existing team topologies or adjusting team topologies to match the evolving architecture. Both approaches have their merits:\n\n- **Simplifying application architecture:** This approach can reduce complexity and technical debt, making it easier for existing teams to manage the application. However, it may limit the application's potential for growth and innovation.\n- **Adjusting team topologies:** Realigning teams to match the evolving architecture can enhance the application's capabilities and performance. This approach requires a more flexible organizational model and may involve retraining or restructuring teams.\n\nA key aspect is to consider **when** to make these adjustments, and the answer is as soon as possible. To leave adaptations for too long can cause the architectural drift to become so large that it inevitably leads to one of two events:\n\n- **Massive re-architecture:** This approach will lead to reduced effort in delivering new customer value, impacting business outcomes. In its own right, it can generate massive technical debt and increased work backlog for future efforts, resulting in increased team cognitive load.\n\n- **Re-organization:** Realigning teams on any kind of large scale will most certainly impact team morale. It can lead to a strain on key people and result in higher churn, especially of innovative talent. This can lead to lost IP knowledge and a future skills shortage, which in turn has an impact on the future quality of the designs and applications produced.\n\n## Next steps\nManaging application architecture drift is an ongoing challenge that requires a strategic approach to organizational alignment. By leveraging the FINE Analysis of the Value Stream Reference Architecture and understanding the different phases of an application's lifecycle, you can make informed decisions about team topologies and ensure your organization remains agile and efficient. Whether you choose to simplify application architecture or adjust your team structure, the key is to maintain a balance that supports both current needs and future growth.\n\n> [Learn how to manage application value streams](https://about.gitlab.com/solutions/value-stream-management/) with the GitLab DevSecOps platform.\n",[1377,9],"DevSecOps",{"slug":1379,"featured":90,"template":686},"navigate-application-architecture-drift-and-organizational-alignment","content:en-us:blog:navigate-application-architecture-drift-and-organizational-alignment.yml","Navigate Application Architecture Drift And Organizational Alignment","en-us/blog/navigate-application-architecture-drift-and-organizational-alignment.yml","en-us/blog/navigate-application-architecture-drift-and-organizational-alignment",{"_path":1385,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1386,"content":1392,"config":1398,"_id":1400,"_type":13,"title":1401,"_source":15,"_file":1402,"_stem":1403,"_extension":18},"/en-us/blog/navigation-state-of-play",{"title":1387,"description":1388,"ogTitle":1387,"ogDescription":1388,"noIndex":6,"ogImage":1389,"ogUrl":1390,"ogSiteName":672,"ogType":673,"canonicalUrls":1390,"schema":1391},"Explore the past, present, and future of GitLab's Navigation design","Dive into the history of GitLab's navigation design and learn how GitLab's UX department is making incremental improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678236/Blog/Hero%20Images/navigation.jpg","https://about.gitlab.com/blog/navigation-state-of-play","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Explore the past, present, and future of GitLab's Navigation design\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Katherine Okpara\"}],\n        \"datePublished\": \"2019-07-31\",\n      }",{"title":1387,"description":1388,"authors":1393,"heroImage":1389,"date":1395,"body":1396,"category":680,"tags":1397},[1394],"Katherine Okpara","2019-07-31","\nAs a UX department, we are responsible for creating navigational structures that are intuitive,\nin tune with user needs, and representative of the numerous workflows of our community of users.\nHowever, when designing for the needs of so many different people, we often have to make compromises\nand not everyone is pleased with the result. Navigation is not just about getting from point A to\nB; it can shape workflows, empower users to discover new, more efficient ways of working, and\nultimately determine how comfortable users are with a product. From the moment users log in for\nthe first time to when they start diving deeper into GitLab’s diverse feature set, our navigation\nstructure is critical for shaping the user's path and, ultimately, their success in using GitLab.\n\n### Why does this matter?\nOur UX Research team is always concerned with investigating and advocating for the needs of all\nGitLab users. We have a [history of research](https://gitlab.com/gitlab-org/uxr_insights/blob/master/Navigation-Research-Summary.md)\nthat has resulted in incremental improvements to GitLab’s navigation over time. After gathering\nfeedback from many sources over the years, we are excited to lead a strategic, dedicated\ninitiative to improve GitLab’s navigation. As part of this initiative, we will consider the\ngoals and frustrations of all users and assess the experiences shaped by the most common workflows\nthroughout GitLab. We will continue to gather feedback from our product users, customers, and\ninternal stakeholders as a way to identify key opportunities for improvement.\n\n### History of GitLab's navigation\nBefore we outline our future research and design plans, let’s take a look back and understand GitLab’s\nnavigation design journey.\n\n![Original design](https://i.imgur.com/9oZq3de.png){: .medium.center}\n\nGitLab's original design\n{: .note.text-center}\n\nThere are two ways to navigate throughout GitLab: globally and contextually. Global navigation refers\nto elements that are always available (e.g., browsing between groups and projects using the top navigation bar).\nContextual navigation refers to the elements that change based on the page a user is viewing.\nBalancing these levels of navigation has consistently been one of the top challenges in each\nphase of GitLab’s navigation design.\n\nIn a [June 2016 blog post describing the pain points that led to\nGitLab’s first navigation redesign](/blog/navigation-redesign/), [Dmitriy Zaporozhets](/company/team/#dzaporozhets),\nGitLab’s co-founder and engineering fellow, stated the following as reasons why GitLab’s UI did not\nwork very well:\n\n- *The current navigation is not well organized. There are places where it does not follow logic or best practices.*\n- *We cannot use muscle memory with the collapsed menu sidebar for fast click on links because the menu has too many items, with new ones added every once in a while.*\n- *It's hard to navigate when you come to GitLab via a link from another app (like chat, for example) because of the lack of a logical hierarchy in our UI navigation.*\n\nTo address these pain points, Dmitriy worked with GitLab’s UX designer to iterate through proposed\nchanges. They landed on a navigation design that introduced a dark-colored, collapsible left\nsidebar to house global navigation elements, along with a contextual top navigation that changed\nrelative to pages the user visited in GitLab.\n\n| Group-level navigation | Project-level navigation|\n|------------------------|-------------------------|\n|![Group level](https://i.imgur.com/HD7ElxQ.png){: .shadow}| ![Project level](https://i.imgur.com/w04Zq6D.png){: .shadow} |\n\nAfter this redesign, the team continued to iterate and make incremental changes to the navigation.\nThese changes became more significant when the option to “pin” (to the screen) or “unpin” the left\nsidebar was introduced. “Pinning” would keep the sidebar static while “unpinning” would remove\nit from the screen and place it under a hamburger menu icon. There were more unfavorable reactions\nto the changes after [GitLab’s 9.0 release](/releases/2017/03/22/gitlab-9-0-released/#updated-navigation-ce-ees-eep),\nwhen the [left sidebar was converted into a dropdown](https://gitlab.com/gitlab-org/gitlab-ce/issues/26200)\nfor all users, permanently placed in a hamburger menu at the far left of the top navigation bar.\n\n| \"Pinned\" | \"Unpinned\" |\n|----------|------------|\n| ![Pinned](https://i.imgur.com/IMYn45r.png){: .shadow} | ![Unpinned](https://i.imgur.com/Jag1HeG.png){: .shadow} |\n\nAfter receiving this feedback, our UX team conducted additional rounds of usability testing and [in\n2017 we made significant improvements to the navigation](/blog/redesigning-gitlabs-navigation/).\nThe decision to reorganize the structure of global and contextual content was one of the more prominent changes.\nGlobal navigation elements would now exist in the top navigation while contextual navigation elements\nwould exist in the left sidebar. These changes were first implemented behind a feature flag, to give\nusers a chance to try out the new flow and tell us how they felt about it. We created\na [feedback issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/34917) so users could discuss\ntheir experiences and share their likes and dislikes in an open, collaborative space.\n\nThe feedback issue led to additional improvements and highlighted more opportunities to optimize\nGitLab’s navigation. Our design team used this feedback to iterate for two release cycles and\nidentify changes that would bring the most benefit, such as\n[flyout menus in the left sidebar](https://gitlab.com/gitlab-org/gitlab-ce/issues/34026)\nand [improvements to breadcrumbs](https://gitlab.com/gitlab-org/gitlab-ce/issues/35269).\nIn September 2017, [GitLab’s navigation redesign became official](/blog/unveiling-gitlabs-new-navigation/)\nand turned on for all users.\n\n![2017 redesign](https://i.imgur.com/ovRRBwE.png){: .shadow.medium.center}\n\nOur 2017 redesign\n{: .note.text-center}\n\nGitLab’s navigation design has not drastically changed since the 2017 redesign, aside\nfrom incremental changes made when adding new feature links to the left sidebar and the\nintroduction of instance-wide workflows. However, even with all of these notable improvements,\nsome users are still confused by finding their way around GitLab, especially when interacting\nwith the left sidebar. Many users have unique workflows based on the features they use, companies\nthey work with, and the amount of time they’ve been using GitLab. As a result, even design decisions\nthat are informed and supported by research can receive negative feedback from those who are\nimpacted by the changes.\n\nEven in 2019, our users describe usability issues that reflect the pain points described in our\nfirst navigation redesign blog post. Presently, a large portion of the pain points can be attributed to\nGitLab’s rapid growth and increased focus on\n[shipping features for the entire DevOps lifecycle](/stages-devops-lifecycle/). As the product\ncontinues to grow, users who only interact with specific features can become overwhelmed by all\nof the information and paths available in the interface. In order to avoid a future pattern\nof frequent changes to the navigation structure, we need to create a systematic approach for\naddressing the diverse use cases that come along with a rapidly growing product.\n\n### What we've learned\n\nThe outcome of all of the research we have conducted over the years is an understanding of the\ncore pain points and usability issues users face when navigating throughout GitLab. I believe that\nthe main themes of our research initiative should be **context** and **discoverability**.\n\n- **Context:** How can we help users maintain context and stay oriented while switching between levels\nof navigation and features in different product stages?\n\n- **Discoverability:** How can navigation be a method of promotion and discovery for new features\nwhile still preserving the findability of commonly used features?\n\nThese two themes are important for creating a systematic approach to organizing content in GitLab's UI.\nWe've had [internal discussions](https://gitlab.com/gitlab-org/ux-research/issues/108) around aligning\nGitLab's UI with [our DevOps stages](/handbook/product/categories/#devops-stages) to categorize\ncontent in a way that reflects the evolution of our product and organization. However, the findings\nfrom [a series of research studies](https://gitlab.com/groups/gitlab-org/-/epics/1236) cautioned us\nagainst moving in that direction, to prevent a negative impact on findability and confusion in users\nwho are not familiar with GitLab's DevOps stages.\n\nWhile it may be possible to teach users about the DevOps stages over time, the feedback from this\nresearch showed us that the additional layers of sub-navigation could make navigation a more\ncumbersome experience. Additionally, some of the names of the DevOps stages are broad and not\nimmediately descriptive (e.g., “Manage” and “Create”). This may require users to do more guesswork\nto understand the variety of features that could fall under each stage. Our upcoming research\ninitiative provides us with the opportunity to explore how we can build an intuitive, logical\nsystem for categorizing new features and guiding users through tasks that cross multiple product stages.\n\nTo read more about the key findings from our prior navigation research, please visit\nthe [UX research insights repository](https://gitlab.com/groups/gitlab-org/-/epics/1555) for a summary of\nour research.\n\n## What comes next?\nWe will investigate the paths that users take throughout GitLab and consider how we should balance\nthe needs of users who have contrasting team sizes, roles, and product tiers. Our goal is to find ways\nto align with the principle of [convention over configuration](/handbook/product/product-principles/#convention-over-configuration)\nwhile still addressing the diverse needs of our users. Please see\nthe [navigation research initiative epic](https://gitlab.com/groups/gitlab-org/-/epics/1342) for more information.\n\nThis research initiative will be conducted in the following phases:\n\n1. [Stakeholder interviews](https://gitlab.com/gitlab-org/ux-research/issues/211): Understand what\ninternal stakeholders need and expect from the flow of GitLab's navigation, feature discoverability,\nand usability.\n2. [User interviews](https://gitlab.com/gitlab-org/ux-research/issues/236): Gather insight from GitLab\ncustomers about their experiences navigating throughout GitLab, learning how to use the product, and\ndiscovering new features. Focus on use cases that cross\nmultiple DevOps stages.\n3. [Explore and assess key user journeys](https://gitlab.com/gitlab-org/ux-research/issues/221): Work with\nGitLab product designers to document the common paths and tasks\nour [user personas](/handbook/product/personas/#user-personas) complete,\nhighlighting usability issues and ranking them by severity.\n3. [Share UX research recommendations](https://gitlab.com/gitlab-org/ux-research/issues/222): Recommended\nchanges based on information architecture best practices and feedback from users and\nstakeholders. Share results with Product and UX teams, discuss solutions, and outline next steps.\n\n### We need your help!\nIf you could wave a magic wand, what would be your ideal vision for GitLab’s navigation?\n\nPlease share your top pain points, suggestions for improvement, or things you like about GitLab's\nnavigation design in the comments below!\n",[876,682,9],{"slug":1399,"featured":6,"template":686},"navigation-state-of-play","content:en-us:blog:navigation-state-of-play.yml","Navigation State Of Play","en-us/blog/navigation-state-of-play.yml","en-us/blog/navigation-state-of-play",{"_path":1405,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1406,"content":1412,"config":1419,"_id":1421,"_type":13,"title":1422,"_source":15,"_file":1423,"_stem":1424,"_extension":18},"/en-us/blog/new-typefaces-in-gitlab",{"title":1407,"description":1408,"ogTitle":1407,"ogDescription":1408,"noIndex":6,"ogImage":1409,"ogUrl":1410,"ogSiteName":672,"ogType":673,"canonicalUrls":1410,"schema":1411},"Get to know the new GitLab typefaces","Dive deep into the considerations for changing to GitLab Sans (Inter) and JetBrains Mono, including improved readability.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669926/Blog/Hero%20Images/Cover3.png","https://about.gitlab.com/blog/new-typefaces-in-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Get to know the new GitLab typefaces\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sascha Eggenberger\"},{\"@type\":\"Person\",\"name\":\"Jeremy Elder\"}],\n        \"datePublished\": \"2023-01-17\",\n      }",{"title":1407,"description":1408,"authors":1413,"heroImage":1409,"date":1414,"body":1415,"category":1155,"tags":1416},[992,850],"2023-01-17","\nWe take the choice of typefaces very seriously around here. And, in the spirit of transparency, a [GitLab core value](https://handbook.gitlab.com/handbook/values/#transparency), we like to share our rationale for typeface changes. This blog introduces you to the new default typefaces in GitLab – GitLab Sans (Inter) and JetBrains Mono – and explores in detail why we chose them and how they will improve the user experience.\n\n## Introducing GitLab Sans and JetBrains Mono\n\nIn the recent [GitLab rebrand](/blog/devops-is-at-the-center-of-gitlab/), [Inter](https://rsms.me/inter/) was selected as the primary sans-serif typeface and we've adapted it for use in the GitLab user interface (UI) to have more continuity between the brand and product experience. It will be available for users in Release 15.8. Specifically for the UI, we've enabled disambiguation features (increased distinction between some characters) by default. Because of this change, we're including it under the name GitLab Sans in the open source package of GitLab. To complement GitLab Sans with a monospace typeface, we've chosen another open source option: [JetBrains Mono](https://www.jetbrains.com/lp/mono/).\n\nThe GitLab UI has historically relied on system fonts, like San Francisco on macOS and Segoe UI on Microsoft Windows. There are, however, limitations to using these that we'll cover in a moment.\n\n![GitLab Sans (Inter) and JetBrains Mono typefaces](https://about.gitlab.com/images/blogimages/introducing-new-typefaces/gitlab-sans-jetbrainsmono.png){: .center}\nGitLab Sans (Inter) and JetBrains Mono sample\n{: .note.text-center}\n\n## Why the change?\n\nSo we've already mentioned brand continuity as a driving reason for the change, but let's step back a bit. During the rebrand process, Inter was one of many typefaces considered because it was open source and designed for UI. Choosing a font primarily designed for digital output might seem like an odd choice for branding and print application, but the primary extension and experience is the product itself. GitLab is digital-first, and the brand reflects it. Inter had all of the qualities and features we knew we could leverage to enhance and realize our vision for the UI.\n\nWe realize there's a lot of subjectivity wrapped up in a change like this. Visual updates are, well, highly visible, but we believe they have to be rooted in objective considerations that lead to adding real value, so here are a few other aspects we evaluated and will cover in greater detail:\n\n- **Less is more** - How can we limit certain choices in ways that enable more meaningful ones?\n- **Consistency** - Can we create more harmony within a single view, streamline the experience across platforms, and reinforce the brand?\n- **Enhance the content** - Can content be more readable, discernable, and generally consumable?\n\n### Less is more\n\nTypography is a crucial part of the GitLab UI, if not _the_ most crucial part. As we continue to refine and beautify the experience, it's apparent that more control over the typography would yield a better experience not only for our users, but also the ones creating the experiences — our internal product, design, and development teams. System fonts have led to everything from false positive bug reports to visual regression errors on both sides. More choice — especially when systems are choosing — doesn't always lead to better experiences.\n\nWith multiple system fonts in play, we choose compromises, not enhancements. For example, asking what alignment works best for _most_ system fonts in a button instead of what alignment works best for _this_ font. Or, what weight should we use when not all system fonts have the same available options instead of what weight creates the right hierarchy for this content. With fewer typeface options we have more ability to make meaningful decisions about disambiguation, visual weight, language support, hierarchy, type scales, and so much more.\n\n### Consistency\n\nAn experience has multiple facets: a single view or screen, a flow between multiple views, a transition from reading to editing, or a switch from settings to documentation. Consistency should happen not only within each of these, but also across them. Consistency in a single view means hierarchy, balance, and harmony. In a flow, consistency establishes patterns and understanding. When contexts change, consistency brings familiarity and enhances trust. Typography is an important aspect of all of these.\n\nInconsistencies add up and lead to design, tech, and experience debt. There are known consistency problems with system fonts, for example, in Firefox on macOS, San Francisco has tighter letter spacing than on Chrome or Safari. This leads to different experiences across browsers, and this is just for one system font.\n\n![Comparing system fonts to show varied x-height](https://about.gitlab.com/images/blogimages/introducing-new-typefaces/compare-x-height.png){: .center}\nVaried x-heights of system fonts\n{: .note.text-center}\n\nOptically, system fonts are noticeably different in size. However, the difference is more visible when you compare the length of each due to character width, weight, and kerning (the space between characters). This impacts everything from truncation and component width, to wrapping and legibility.\n\n![Comparing system fonts to show varied width](https://about.gitlab.com/images/blogimages/introducing-new-typefaces/compare-width.png){: .center}\nVaried width of system fonts\n{: .note.text-center}\n\nMenlo has been used as our monospaced typeface. It appears bigger than many sans-serif typefaces when using the same font size. To counter that issue, we had downscaled its size by one pixel to make it appear as the same optical size. This added unnecessary bloat to styles and is also not foolproof since sans-serif system fonts also vary.\n\nInter and JetBrains Mono have nearly identical x-height, which allows us to remove all of the downscaling overrides and more generally handle text styles consistently. While both typefaces have specific use cases, they’re almost always present next to each other in the UI, making cohesiveness that much more important.\n\n![GitLab Sans (Inter) and JetBrains Mono x-height comparison](https://about.gitlab.com/images/blogimages/introducing-new-typefaces/gitlab-sans-jetbrainsmono-x-height.png){: .center}\nGitLab Sans and JetBrains Mono with similar x-height\n{: .note.text-center}\n\nBy reducing our typeface options, we're working towards consistency in so many ways we haven't before, everything from brand to product, product to documentation, and browser to browser. Consistency is not the same as uniformity though, and nor should it inhibit preference, but by creating a baseline those things can have room for more thoughtful approaches in the future too.\n\n### Enhance the content\n\nAs mentioned earlier, typography is a crucial part of the UI, and arguably most of the content is in text form. Whether communication or code, status or state, the typeface is the delivery vehicle for the content. GitLab Sans and JetBrains Mono give us better control over readability.\n\nBoth typefaces include variable webfont and contextual features, which means that the font weight and other settings can be finely tuned to enhance visual weight, hierarchy, and contextual alternates. For GitLab Sans, we've enabled the disambiguation feature set to ensure readability is a top priority. Disambiguation is used to avoid common character confusion. For example, by using the feature set [cv05](https://rsms.me/inter/lab/?feat-cv05=1) (lowercase L with tail for disambiguation), you can easily distinguish between the capital “I” and the lowercase “L” (see image below). We had discussed using either [ss04](https://rsms.me/inter/lab/?feat-ss04=1) (disambiguation without slash zero) or cv05 and decided to go with the latter for a simple, modern look.\n\n![Inter Typface character disambiguation](https://about.gitlab.com/images/blogimages/introducing-new-typefaces/inter-disambiguation.png){: .center}\nInter disambiguation options from left to right: Default, without slashed zero (ss04), lowercase L with tail (cv05)\n{: .note.text-center}\n\nGitLab uses a condensed UI, meaning more content in less space and typically at smaller sizes. Inter is popular for a reason, more likely dozens, but the most applicable to GitLab is that it’s designed specifically for UI. On the [website](https://rsms.me/inter/) it states, “Inter is a typeface carefully crafted & designed for computer screens.” With a tall x-height, contextual alternates, tabular numbers, and more, Inter enables us to actually make more meaningful typography decisions that impact readability.\n\nSimilarly, JetBrains Mono has a tall x-height, which increases readability at smaller sizes, and it has a normal character width to keep more characters on a single line which limits wrapping. During our exploration, we found that typefaces like Menlo, Fira Code, Source Code, or Noto Sans Mono either have shorter x-heights or wider characters that lead to size or spacing compromises.\n\nWith these typefaces in place we've started a deep dive into our type scales and updating design resources in Figma too. The upcoming work on type scales, in particular, will provide more consistency and refinement.\n\n## Other considerations\n\nGitLab is an [open core](/blog/gitlab-is-open-core-github-is-closed-source/) product, which means the core of our product is open source, so selecting typefaces that are also open source was a crucial part of the decision. \n\nAnytime you opt to distribute your own resources versus using what's already available to the system the question of performance comes up. And while it's true that we're increasing the payload by a few kilobytes, we're able to rely on modern CSS and browser handling for delivery and caching. At the same time, we're reducing the CSS by removing styles that have been added to counter aforementioned compromises. This is something we'll continue to evaluate and optimize.\n\nAnd speaking of distribution, we're [packaging the fonts](https://www.npmjs.com/package/@gitlab/fonts) to make it easier for all of our properties to consume. This means we're also able to leverage the same resources in our design tooling.\n\nLastly, we know that changes like this have the benefit (or downside, depending on how you look at it) of exposing other inconsistencies in the UI that need to be addressed. While it seems counterintuitive to release an update that potentially introduces visual regression, we consider it as the dye in the water to let us know what else we have to fix as we continue to work towards a single source of truth for typography styles.\n\n## What's next?\n\nAs the typography changes are being rolled out, we’re working through feedback and addressing any potential regressions. Along with type scale updates, we're going to evaluate headings throughout the product to ensure heading levels align with correct Document Object Model (DOM) structure, visual weight, and styles. In short, our typography decisions are interdependent and foundational for the overall experience. By limiting typeface options, we’re removing the limits of how hard we can make typography work so that we can further refine the interface, bring harmony to the UI, and make content more consumable so that using GitLab is more productive and enjoyable. \n\nIf you’d like to provide feedback or contribute, please use this [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/386205).\n",[9,1417,1418,723,725,682],"frontend","open source",{"slug":1420,"featured":6,"template":686},"new-typefaces-in-gitlab","content:en-us:blog:new-typefaces-in-gitlab.yml","New Typefaces In Gitlab","en-us/blog/new-typefaces-in-gitlab.yml","en-us/blog/new-typefaces-in-gitlab",{"_path":1426,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1427,"content":1433,"config":1444,"_id":1446,"_type":13,"title":1447,"_source":15,"_file":1448,"_stem":1449,"_extension":18},"/en-us/blog/outreachy-sponsorship-winter-2020",{"title":1428,"description":1429,"ogTitle":1428,"ogDescription":1429,"noIndex":6,"ogImage":1430,"ogUrl":1431,"ogSiteName":672,"ogType":673,"canonicalUrls":1431,"schema":1432},"Technology internships meet open source in Outreachy","Inside Outreachy technology internships, where participants work on Git.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664041/Blog/Hero%20Images/open-devops.png","https://about.gitlab.com/blog/outreachy-sponsorship-winter-2020","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Technology internships meet open source in Outreachy\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Joey Salazar\"},{\"@type\":\"Person\",\"name\":\"Charvi Mendiratta\"},{\"@type\":\"Person\",\"name\":\"Nuritzi Sanchez\"},{\"@type\":\"Person\",\"name\":\"Christian Couder\"}],\n        \"datePublished\": \"2021-04-15\",\n      }",{"title":1428,"description":1429,"authors":1434,"heroImage":1430,"date":1439,"body":1440,"category":1441,"tags":1442},[1435,1436,1437,1438],"Joey Salazar","Charvi Mendiratta","Nuritzi Sanchez","Christian Couder","2021-04-15","\n\nAs an enthusiastic participant in the [open source](/blog/innersourcing-using-the-open-source-workflow-to-improve-collaboration-within-an-organization/) community, we were excited to participate in the [Outreachy technology internships program](https://www.outreachy.org/) again this year, which focuses on women and underrepresented groups. It's a way GitLab can give back, and as a bonus, Outreachy's principles intersect with [our Diversity, Inclusion and Belonging value](https://handbook.gitlab.com/handbook/values/#diversity-inclusion).\n\n## About the Outreachy program\n\nInitially, Outreachy began as the Open Source Program for Women (OPW) at [GNOME](https://www.gnome.org/about-us/). The program was successful and grew quickly. Today, Outreachy has grown into the largest global technology internships program that provides opportunities for women and underrepresented groups to work on open source projects.\n\nCurrently, Outreachy is independently organized with the help of many volunteers, or sponsored help. For example, [Cindy Pallares](/company/team/#cindy) is a GitLab employee and helps with organizing Outreachy as a site reliability engineer.\n\nOutreachy is a paid technology internship program that runs twice a year for three months. During that time, interns can work in areas like programming, user experience, documentation, illustration and graphic design, or data science. In this technology internship program, participants work remotely with experienced mentors from prominent FOSS communities like Git, Mozilla, Linux kernel, GNOME, Wikimedia, and many others.\n\nOne of the benefits of the Outreachy technology internship is that the interns do not need to be students. It's a great opportunity for people who are coming back into the workforce after a hiatus, or who are navigating a career change into tech. This technology internship program is unique because it incorporates skill sets beyond engineering – which creates a broader range of skill sets represented in the open source world. The Outreachy internship is remote, making it more relevant than ever during the pandemic by helping interns gain experience working on an all-remote team.\n\nGitLab is one of the organizations that sponsors the Outreachy technology internship program, and we hope that by sharing our experience we can encourage more tech organizations to join us in participating in Outreachy as [corporate sponsors](https://www.outreachy.org/sponsor/).\n\n## Outreachy interns work on Git\n\nMore than 90% of the professional applications created today are built using open source components, according to a [2020 Tidelift survey](https://cdn2.hubspot.net/hubfs/4008838/Resources/The-Tidelift-guide-to-managed-open-source.pdf?utm_source=hs_automation&utm_medium=email&utm_content=66640714). One of the fundamental open source technologies we leverage at GitLab is the [Git project](https://git-scm.com/), so we chose to sponsor an Outreachy intern to work there.\n\n> GitLab sponsors an Outreachy intern to work on one of the most critical open source technologies that it relies on: The Git project.\n\n[Christian Couder](/company/team/#chriscool), senior backend software engineer at GitLab, who works on Git full-time, introduced the [GitLab Developer Relations team](/handbook/marketing/developer-relations/) to the Outreachy opportunity during the winter of 2017-2018 round. An experienced mentor for other programs like Google Summer of Code, Christian thought that it would be great to mentor an intern through the Outreachy program as well. Since the number of mentored interns and the need to sponsor them increased over the years, GitLab has sponsored an Outreachy intern for the Git project since winter 2019-2020.\n\nOutreachy at Git works similarly to the [Google Summer of Code (GSoC) program](https://summerofcode.withgoogle.com/). Git participates in GSoC in the summer and Outreachy in the winter. These programs consist of the Git project finding mentors and project ideas for individual participants to work on. Then there is a selection step, which includes working on a micro-project (a small code-related change), as part of the application process, and writing a proposal for a project to work on during the internship. After the interns are announced, they begin to work on their projects. Typically, Git tries to provide two mentors per intern to provide the best possible experience for the mentee.\n\n> The mentors used to be long-time Git developers, but more and more Outreachy and GSoC alumni have returned to the program as mentors, indicating the power of these programs.\n\nThe mentors volunteer some time each week to help their mentees by answering questions, providing suggestions, reviewing contributions, etc. Contributions still have to be sent by participants to the Git mailing list as patches. Then, other experienced Git contributors review the contributions before they are integrated into the Git code base by [Junio Hamano](https://www.linkedin.com/in/gitster), the Git maintainer.\n\n## Meet the Outreachy interns\n\nWe met with the Outreachy interns at Git to learn more about their experience participating in the winter 2020-2021 Outreachy technology internship program. In the next section, the Outreachy interns shared what the experience was like, in their own words.\n\n### Charvi Mendiratta: A self-taught programmer with an interest in robotics\n\n_This section was written by Charvi._\n\n> I am a recent graduate from the electronics field in India, a self-taught programmer with internship experiences working on mobile robotics projects, and I aim to pursue a career as a software developer. - [Charvi](https://charvi-077.github.io/about/)\n\nIt turned out to be difficult to find a job as a software developer because of my background in electronics and because I lacked professional programming skills. Also, there are very few job opportunities for recent graduates in software engineering roles, especially those related to robotics.\n\nDue to these challenges, I decided to try out open source in parallel with brushing up my skills. I supposed that open source contributions would be the best way to get hands-on experience with projects that required real-life problem solving skills, and I wanted to learn to convert my code into deployable software. That's why I decided to apply to the Outreachy program.\n\nBesides wanting to learn more about creating enterprise-grade code, I have always been interested in being part of the open source community. I first learned about open source work culture from my college programming community. I remember the old days when I attended an open source event called '[Software Freedom Day](http://www.softwarefreedomday.in/)' at my university. That's where I first learned about different open source programs like Outreachy.\n\n> Over the course of my three month internship, I worked on cleaning up and improving the Git interactive rebase, which is a useful git command to rewrite or modify the commit history. - Charvi\n\n#### About Charvi's Outreachy project\n\nMy work on Git's interactive rebase, which was mentored by Christian and [Phillip Wood](https://git.github.io/rev_news/2019/11/20/edition-57/), will help users who want to rework their commits and make it easier for users to improve the quality of their contributions. When teams practice code review, for example, it's very useful to rework commits to make them better or easier to understand before a reviewer steps in, and to fix them when reviews point to problems.\n\nFirst, I added the options '-c' and '-C' to the present `fixup` command in the interactive rebase. The `fixup` command adds the functionality to edit the commit message of the specific commit listed in the interactive rebase (see [merged patches](https://lore.kernel.org/git/20210129182050.26143-1-charvi077@gmail.com/)). This work is based on the [original patch series](https://github.com/phillipwood/git/commits/wip/rebase-amend), started by Phillip.\n\nThen, I worked on the [follow-up patches](https://lore.kernel.org/git/20210210113650.19715-1-charvi077@gmail.com/) and introduced some improvements after discussing the user interface of the added options with the Git community. Next, I worked on adding the new feature to `git commit --fixup` that allows to prepare the \"amend!\" and \"reword!\" commit, as an alternative to the present `fixup!` commit. It works with `git commit --autosquash` and will help to fix-up the content and commit message of the specific commit from the command line (see [merged patches](https://lore.kernel.org/git/20210315075435.18229-1-charvi077@gmail.com/)).\n\n### Joey Salazar: An engineer with international experience\n\n_This section was written by Joey._\n\n> As a female engineer from Costa Rica, who graduated in China through a full scholarship, it has been a challenge to find opportunities with mentoring for my transition from IT into programming. - [Joey](https://about.me/gomezsalazar-jogebeth)\n\nEven though I worked five years in IT (OS, networking, and storage), and was certified in Linux+ and CCNA through self-learning before beginning my software engineering studies, most companies and organizations seem eager to hire mid-senior level developers. Very few seem willing to invest in helping people get to that level, or in finding ways to build on any preexisting IT experience. As an open source advocate, it was through my research of open source technologies and the open source space that I came across community groups such as [WomenWhoCode](https://www.womenwhocode.com/), which was where I learned about Outreachy.\n\n#### About Joey's Outreachy project\n\n> My favorite thing to work on, probably because of my [background in privacy advocacy](https://www.techdirt.com/articles/20200622/08142044757/long-past-time-to-encrypt-entire-dns.shtml), was adding the foundations of HTTPS connection support for the Git protocol by following up on [a patch](https://gitlab.com/wireshark/wireshark/-/merge_requests/1946) started (and shared by) long-time Wireshark developer, [Richard Sharpe](https://sharkfestus.wireshark.org/bios/richard-sharpe). –  Joey\n\nMy work on Git protocol support in [Wireshark](https://www.wireshark.org/), which was mentored by Git developers employed by Google, [Emily Shaffer](https://nasamuffin.dev) and Jonathan Nieder, will help users debugging Git or any Git using software (like GitLab). This work helps production teams or developers understand what's going on between Git clients and servers, so they can better troubleshoot or optimize how Git works. This project will help demystify Git and its inner workings in the tech community.\n\nAs Wireshark is \"the world’s foremost and widely-used network protocol analyzer\", improving the way it dissects and presents the Git protocol to the user is helpful and important. Traffic interception and analysis is part of many user's workflows – from students, to researchers and advocates. For a few years, Git's dissector in Wireshark was bare-bones, and supported only raw traffic transmitted over regular TCP transport – my work is helping to change that.\n\nBy starting with [base functionality](https://gitlab.com/wireshark/wireshark/-/merge_requests/1922) and building on top of other member's work, Joey and her mentors added parsing of the multiplexing ([sideband](https://gitlab.com/wireshark/wireshark/-/merge_requests/1313)) version in use (if any) to Wireshark's dissector for the Git protocol. Next, they [added parsing for the specific version](https://gitlab.com/wireshark/wireshark/-/merge_requests/1714) of the Git protocol that is used, following up on [an MR to parse the Git protocol version](https://gitlab.com/wireshark/wireshark/-/merge_requests/805), did some refactoring on [an MR to refactor Git packet line dissector](https://gitlab.com/wireshark/wireshark/-/merge_requests/1942), and began the foundations for Git protocol's [testing suite](https://gitlab.com/wireshark/wireshark/-/merge_requests/2142).\n\nToday the Git dissector now includes more functionality and error handling, as well as HTTPS transport support – all of which was done through GitLab's platform.\n\n## Outreachy mentor shares experience\n\n_Christian, the Outreachy mentor and GitLab team member who worked with Joey and Charvi, shares what the experience was like in his own words._\n\nThere are many rewarding parts to being a mentor. I really enjoy seeing mentees gain confidence over the weeks in their abilities to contribute significantly by themselves.\n\n> Since Git is used by more than 80% of the developers in the world, I hope that the Outreachy interns get the feeling that they can improve things even in small ways for millions of people and that their work can have a global impact. - Christian\n\nI also really enjoy it when former mentees want to continue contributing to the Git community after their internship. Outreachy alumni contributions can take many forms. Sometimes they continue to contribute on the same topic as their project, sometimes they participate in related discussions, even 10 years later. One of our mentees was recently hired to work full-time on Git. And it is of course great when they want to become mentors, so they can give back to the program and increase the number of people who can get mentored.\n\nIt's great too that Outreachy, Google, and sometimes the Git project itself all provide funds for former mentees to come to in-person Git events or open source-related conferences. Meeting mentees in-person is very rewarding. At in-person events, the interns can also meet a number of Git-related companies and people, and of course, learn even more about Git and open source. For some of them, it was the first time they traveled outside of their country or could visit a different continent.\n\n#### Mentorship comes with challenges\n\nThe most challenging part of being a mentor is the fact that the Git codebase is getting bigger and more complex as Git evolves and gains features all the time.\n\nThis makes it hard for participants to stay on track when the internship starts. They sometimes have to trust that following the process we suggest will lead them to better and better understanding until they can find their own way and become autonomous.\n\n## Outreach interns share their key takeaways\n\nWe asked Joey and Charvi to share some of the ways that the Outreachy technology internship has impacted them.\n\n### Joey has a better understanding of herself\n\n_This section was written by Joey._\n\n> My Outreachy internship helped me better define the type of team and community that I'd like to join and which will benefit the most from the wide range of skills that I can offer. – Joey\n\nOutreachy was an amazing help, not only in technical areas, but also with soft skills. For example, I formed a solid understanding of Git. Now I can use `git cherry-pick` and `git rebase`, as well as squash, comfortably since I understand better what they do, and how. Those Git commands gave me lots of trouble when I was a junior developer for [BIND](https://en.wikipedia.org/wiki/BIND), and now they don't give me trouble anymore. I also reinforced fundamentals in C -- implementing pointers and references without panic and knowing about vtables -- and I learned how to write test cases in Python.\n\nA crowning achievement was finding balance between patience and impatience, and between autonomy and guidance.\n\n### Charvi has fallen in love with the open source world\n\n_This section was written by Charvi._\n\n> Outreachy helped me start my open source journey. - Charvi\n\nI have always been fascinated with the open source work culture as a way to learn, share, and grow. I finally got wonderful working experience too, since both Outreachy and the Git project are prestigious organizations.\n\nI learned a lot throughout the entire internship, starting from when the Outreachy contribution period began before I qualified for the internship. On the technical side, I enhanced my C programming and debugging skills, learned to write neat code, learned about shell scripts, and developed a deeper understanding of Git commands and about the Git project workflow.\n\nApart from this, my internship helped me improve my communication skills, make connections with amazing software developers, and  become more confident in myself. I am sincerely thankful for the Outreachy program, Git community, and my mentors, Christian and Phillip. It was an amazing learning journey.\n\n## So what's next?\n\nNow that the Outreachy internship has concluded, both Joey and Charvi are ready to leverage their skills and experience working on the Git project to future work in FOSS. Learn more about [Charvi's experience](https://charvi-077.github.io/about/) and [Joey's experience](https://about.me/gomezsalazar-jogebeth) by following the links.\n\n## GitLab's continued internship opportunities\n\nGitLab is proud to have sponsored and mentored an intern for the Git project during the most recent round of Outreachy technology internships. We hope to someday qualify for our own Outreachy interns to work on the [GitLab FOSS project](https://gitlab.com/gitlab-org/gitlab-foss) (which celebrates 10 years in October 2021).\n\nThis summer, GitLab will also be participating for the first time in [Google Summer of Code 2021](https://summerofcode.withgoogle.com/organizations/4961424868114432/). We look forward to mentoring engineering students through that technology internship program.\n\nIn addition to participating in these two great technology internship programs, GitLab held its first [engineering internship program](/handbook/engineering/internships/) in 2020 with great success. As a result, GitLab will continue to hire interns for various projects and teams in an ongoing fashion, with a specific [focus on recruiting interns from underrepresented groups in engineering](/handbook/engineering/internships/#recruitment).\n\nWe look forward to supporting these programs that help foster diversity in open source and the wider tech industry, and are excited for the year ahead!\n","open-source",[1418,1443,9],"git",{"slug":1445,"featured":6,"template":686},"outreachy-sponsorship-winter-2020","content:en-us:blog:outreachy-sponsorship-winter-2020.yml","Outreachy Sponsorship Winter 2020","en-us/blog/outreachy-sponsorship-winter-2020.yml","en-us/blog/outreachy-sponsorship-winter-2020",{"_path":1451,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1452,"content":1458,"config":1464,"_id":1466,"_type":13,"title":1467,"_source":15,"_file":1468,"_stem":1469,"_extension":18},"/en-us/blog/overhauling-the-navigation-is-like-building-a-dream-home",{"title":1453,"description":1454,"ogTitle":1453,"ogDescription":1454,"noIndex":6,"ogImage":1455,"ogUrl":1456,"ogSiteName":672,"ogType":673,"canonicalUrls":1456,"schema":1457},"How designing platform navigation is like building a dream home","Go behind the scenes and learn how we ideated toward a new user experience for GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680235/Blog/Hero%20Images/home-improvement.jpg","https://about.gitlab.com/blog/overhauling-the-navigation-is-like-building-a-dream-home","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How designing platform navigation is like building a dream home\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Austin Regnery\"}],\n        \"datePublished\": \"2023-05-15\",\n      }",{"title":1453,"description":1454,"authors":1459,"heroImage":1455,"date":1461,"body":1462,"category":787,"tags":1463},[1460],"Austin Regnery","2023-05-15","\nDeciding on the look and feel of a new home is already challenging. The level of complexity grows even more when ideas involve altering the underlying structure itself. Every decision you make affects the feasibility of future changes. Choosing what is best can be subjective, even when rooted in the realities of physics and mathematics. Now imagine millions of people using this house, each with unique requirements. That gives you an idea of how it feels to update the navigation experience of GitLab. Picking a fork in the road means it won't be perfect for every user, but it needs to work well for the vast majority.\n\nWe'll share how our design process ideated through each solution to make a vision into reality.\n\n## Dreaming of a new home\n\nYou might dream of an extra bedroom, an open kitchen, or more efficient use of space. Regardless, it all starts with a vision of what comes next. In our release post, we shared how our [North Star vision](/blog/gitlab-product-navigation/#establishing-a-north-star) drove our direction. We used these themes to focus on the meaningful foundational elements as we explored new concepts. We built our design assumptions around these themes before filling out user interface elements.\n\n### Theme 1: Minimize the feeling of being overwhelmed\n\nThe project and group left sidebars have been growing. Features were in different places and often required users to search for the page they needed. We started addressing these issues in the following ways:\n\n- Reorganize page elements into consistent collections across groups and projects to reduce confusion.\n- Start everyone with sensible defaults for a baseline that accommodates most user needs.\n- Provide customizable options in the left sidebar which could reduce discovery time in the future.\n- Give back screen real estate so the focus remains on the page content and task.\n\n### Theme 2: Orient users across the platform\n\nIt could be difficult for a user to know where they were inside GitLab. Landmark clues like sidebars, breadcrumbs, and page titles weren't consistent and occasionally were missing. Without these wayfinding cues, jumping from one task to the next was challenging if the next thing wasn't directly in front of the user. To give a sense of place, we:\n\n- Show the pages specific to a given context by displaying all available options in the left sidebar.\n- Fix breadcrumbs at the top of the window to help users retain their context even when scrolling.\n\n### Theme 3: Allow users to pick up where they left off easily\n\nThere can be a lot going on at one time in GitLab, so it can be hard to know what to do next. It should feel natural to transition into GitLab and get started. Helping users transition means we must: \n\n- Make it clear that the homepage of GitLab can redirect anyone to their next task.\n- Keep things familiar so that anyone will feel right at home.\n- Reduce the number of page visits required to jump between tasks.\n\n## Visualizing the navigation layout \n\nIt's helpful to envision how you would use each room in a house before pulling it all together. We started by visualizing five different concepts, and each idea explores a unique design choice to address our assumptions.\n\n| Idea 1: Minimal features on display |\n| ------ |\n| There are so many features that could appear in the sidebar. How might it feel to only show a select number of them? |\n| ![Minimal features](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/minimal-features.png) |\n\n\u003Cbr>\n\n| Idea 2: Fewer collections to choose from |\n| ------ |\n| Organizing features into distinct collections mitigates growth but impacts discovery time. Would it be simpler to search through only a few options? |\n| ![Fewer collections](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/fewer-collections.png) |\n\n\u003Cbr>\n\n| Idea 3: Sidebar broken into multiple layers|\n| ------ |\n| GitLab can feel relatively flat in its structure, but it is far more complex than that. How might we use distinct layers in the sidebar to aid navigation around the platform? |\n| ![Sidebar layers](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/sidebar-layers.png) |\n\n\u003Cbr>\n\n| Idea 4: Breadcrumb navigation |\n| --- |\n| Breadcrumbs are a familiar pattern for distinguishing locations. If the breadcrumb were more prominent, how would it impact awareness? |\n| ![Breadcrumb navigation](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/breadcrumb-nav.png) |\n\n\u003Cbr>\n\n| Idea 5: Static navigation elements |\n| ---|\n| The sidebar has always been specific to the context. How would making the sidebar consistent across all screens impact user mental models? |\n| ![Static navigation](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/static-sidebar.png)|\n\n\u003Cbr>\n\nExploring [multiple ideas](https://gitlab.com/gitlab-org/gitlab/-/work_items/366338) let us evaluate different design decisions before settling on a final plan. We created a baseline across all the [concepts](https://gitlab.com/gitlab-org/gitlab/-/work_items/367687), exposed them to others for feedback, and tested them against a set of standardized tasks:\n\n- Task 1: Where would you go to see all issues for a project?\n- Task 2: How would you create an epic in a group?\n- Task 3: Imagine you started writing a comment and had to navigate away to address something else. Where would you go to find that comment?\n\n![Six frame panel](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/six-frame-vertical.png)\n\nTwo of the concepts felt easier to use and didn't require relearning. Both of these concepts build on familiar user flows. The other four proposals were overwhelming. The breadcrumb, collapse sidebar button, search bar, and pinned section were elements universally appreciated.\n\n## Making tough choices\n\nThese insights left us with one lingering question. Should we split the navigation across a top and left bar or move it all into one sidebar? We were down to two unique layouts but torn on which worked best. We had similar concepts with a few visual differences, but the key differentiator was the layout. So we devised a research plan with tasks specific to each user persona to observe how these participants adapted to these new concepts.\n\n|  Codename: [Element Reswizzle](https://www.figma.com/proto/PMIznpz7POtRKTiurKfZSF/Vision-for-Navigation?page-id=1475%3A60336&node-id=1624%3A78006&viewport=871%2C342%2C0.23&scaling=contain&starting-point-node-id=1624%3A78006&hotspot-hints=0&hide-ui=1)| Codename: [Super Sidebar](https://www.figma.com/proto/PMIznpz7POtRKTiurKfZSF/Vision-for-Navigation?page-id=1833%3A120024&node-id=1833%3A120025&viewport=454%2C513%2C0.25&scaling=scale-down&starting-point-node-id=1833%3A120025&hotspot-hints=0&hide-ui=1)\n| --- | --- |\n|  ![Homepage of two-story](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/two-story-home.png)| ![Homepage of ranch](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/ranch-home.png) |\n|  ![Issue list in two-story](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/two-story-issues.png) | ![Issue list in ranch](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/ranch-issues.png) |\n\nWe learned from our testing that the Super Sidebar was preferred as it allowed for more intuitive navigation between projects without losing context. Super Sidebar supported mature and new GitLab users better in their most common workflows. In comparison, only mature GitLab users found the Element Reswizzle easier. However, the Element Reswizzle offered elements, like icons and tool tips, that users would like to see included in Super Sidebar. \n\nWe chose to iterate and use the layout of the Super Sidebar while including aspects that were useful from Element Reswizzle.\n\n## Planning the big move\n\nWe had tackled the big questions around the scaffolding but hadn't solidified the specifics. We also needed to define color choices, font size and weight, spacing, alignment, icon options, organization of items, and placement of features. The finer details must work seamlessly and feel right, or the scaffolding around the product will fail to demonstrate its value due to a mediocre user experience. We created an  [epic](https://gitlab.com/groups/gitlab-org/-/epics/9044) to house all the work we'd try to accomplish before overhauling the core navigation experience.\n\n## Pouring the foundation\n\nEach milestone brought new design challenges and trade-off decision-making. We knew the direction, but it was impossible to change everything in a single milestone. We wanted to ensure the navigation was functional first because the structure is what we were most concerned about getting right. \n\n![First time groups appeared in the super sidebar](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/porting-functionality.png)\n\nWe first [added critical contexts](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/111186) like your work, groups, and projects while unpacking the rest of the feature set. Focusing on the foundation first allowed us to get a sense of the flow of our new house before settling in.\n\nWe had team members start trying out an alpha experience early on. Some things might seem right in a design but feel off once in production. An example of this is how users switch contexts. Initially, we created a method built into the navigation sidebar but discovered it was confusing.\n\n> \"I wouldn't expect the rest of the nav to disappear when I uncollapse the project view. I would expect it to push the other content down rather than taking over all content in the panel.\" - [comment from our feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/403059#note_1350452712)\n\n| Before | After |\n| :---: | :---: |\n| ![Context switcher before](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/context-switcher-before.png) | ![Context switcher after](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/context-switcher-after.png) |\n\nWe pivoted by adding more layering with dropdown disclosure to give a sense of movement. It's not the perfect solution, but it's a good iteration that holds us over until we can design a better experience.\n\n## Getting ready to show\n\n![Screenshot of the new navigation](https://about.gitlab.com/images/blogimages/overhauling-the-navigation/premier.png)\n\nHoning the navigation will take numerous rounds of feedback, several more iterations, and plenty of patience. A home is never quite finished neither is the navigation of a platform like GitLab. Before the 16.0 release, we focused on squeezing in as many [UX improvements](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?scope=all&state=merged&label_name%5B%5D=group%3A%3Afoundations&milestone_title=16.0&label_name%5B%5D=UX) and  [bug fixes](https://gitlab.com/gitlab-org/gitlab/-/merge_requests?label_name%5B%5D=group%3A%3Afoundations&label_name%5B%5D=type%3A%3Abug&milestone_title=16.0&scope=all&state=merged) as possible to improve upon our prior iterations. This has brought us to a navigation experience that works beautifully. We are excited to share it with everyone. We are confident that GitLab will become more usable and beloved with each new milestone. Try out the overhauled navigation experience today, and share your thoughts with us in our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/409005).",[682,723,9],{"slug":1465,"featured":6,"template":686},"overhauling-the-navigation-is-like-building-a-dream-home","content:en-us:blog:overhauling-the-navigation-is-like-building-a-dream-home.yml","Overhauling The Navigation Is Like Building A Dream Home","en-us/blog/overhauling-the-navigation-is-like-building-a-dream-home.yml","en-us/blog/overhauling-the-navigation-is-like-building-a-dream-home",{"_path":1471,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1472,"content":1477,"config":1483,"_id":1485,"_type":13,"title":1486,"_source":15,"_file":1487,"_stem":1488,"_extension":18},"/en-us/blog/path-to-decomposing-gitlab-database-part1",{"title":1473,"description":1474,"ogTitle":1473,"ogDescription":1474,"noIndex":6,"ogImage":926,"ogUrl":1475,"ogSiteName":672,"ogType":673,"canonicalUrls":1475,"schema":1476},"Decomposing the GitLab backend database, Part 1: Designing and planning","A technical summary of the yearlong project to decompose GitLab's Postgres database. This first part focuses on the initial designing and planning of the project.","https://about.gitlab.com/blog/path-to-decomposing-gitlab-database-part1","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Decomposing the GitLab backend database, Part 1: Designing and planning\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dylan Griffith\"}],\n        \"datePublished\": \"2022-08-04\",\n      }",{"title":1473,"description":1474,"authors":1478,"heroImage":926,"date":1480,"body":1481,"category":787,"tags":1482},[1479],"Dylan Griffith","2022-08-04","\nRecently we finished [migrating the GitLab.com monolithic Postgres database to two independent databases: `Main` and `CI`](/blog/splitting-database-into-main-and-ci/). After we decided how to split things up, the project took about a year to complete.\n\nThis blog post on decomposing the GitLab backend database is part one in a three-part series. The posts give technical details about many of the challenges we had to\novercome, as well as links to issues, merge requests, epics, and developer-facing documentation.\nOur hope is that you can get as much detail as you want about how we work on complex projects at GitLab.\n\nWe highlight the most interesting details, but anyone undertaking a similar\nproject might learn a lot from seeing all\nthe different trade-offs we evaluated along the way.\n\n- \"Decomposing the GitLab backend database, Part 1\" focuses on the initial design and planning of the project.\n- [Part 2](/blog/path-to-decomposing-gitlab-database-part2/) focuses on the\nexecution of the final migration.\n- [Part 3](/blog/path-to-decomposing-gitlab-database-part3/) highlights some interesting technical challenges we had to solve along the way, as well as some surprises.\n\n## How it began\n\nBack in early 2021, GitLab formed a \"database sharding\" team in an effort to\ndeal with our ever-growing monolithic Postgres database. This database stored\nalmost all the data generated by GitLab.com users, excluding git data and some other\nsmaller things.\n\nAs this database grew over time, it became a common source of\nincidents for GitLab. We knew that eventually we had to move away from a single\nPostgres database. We were already approaching the limits of what we could do\non a single VM with 96 vCPU and continually trying to vertically scale this VM\nwould eventually not be possible. Even if we could vertically scale forever,\nmanaging such a large Postgres database just becomes more and more difficult.\n\nEven though our database architecture has been monolithic for a long time, we already made use of many scaling techniques, including:\n\n- Using Patroni to have a pool of replicas for read-only traffic\n- Using PGBouncer for pooling the vast number of connections across our application fleet\n\n![Database architecture before decomposition](https://about.gitlab.com/images/blogimages/2022-07-15-path-to-decomposing-gitlab-database/phase0.png)\n\nThese approaches only got us so far and ultimately would never fix the scaling\nbottleneck of the number of writes that need to happen, because all writes need to\ngo to the primary database.\n\nThe original objective of the database sharding team was to find a viable way\nto horizontally shard the data in the database. We started with exploring\n[sharding by top-level namespace][sharding_by_top_level_namespace_poc_epic]. This approach had some very complicated problems to solve, because the application\nwas never designed to have strict tenancy boundaries around top-level\nnamespaces. We believe that ultimately this will be a good way to split and\nscale the database, but we needed a shorter term solution to our scaling\nproblems.\n\nThis is when we evaluated different ways to extract certain tables into a\nseparate database. This approach is often referred to as \"vertical\npartitioning\" or \"functional decomposition.\" We assumed this extraction would likely\nbe easier, as long as we found a set of tables with loose coupling to the rest\nof the database. We knew it would require us to remove all joins to the rest of the\ntables (more on that later).\n\n## Figuring out where most write activity occurs\n\nWe did [an analysis][analysis_of_decomposition_tables] of:\n\n- Where the bulk of our data was stored\n- The write traffic (since ultimately the number of writes was the thing we were trying to reduce)\n\nWe learned that CI tables (at the time) made up around 40% to 50% of our write traffic. This seemed like a\nperfect candidate, because splitting the database in half (by write traffic) would be\nthe optimal scaling step.\n\nWe analyzed the data by splitting the database the following ways:\n\n| Tables group   | DB size (GB) | DB size (%) | Reads/s   | Reads/s (%) | Writes/s | Writes/s (%) |\n|----------------|--------------|-------------|-----------|-------------|----------|--------------|\n| Webhook logs   | 2964.1       | 22.39%      | 52.5      | 0.00%       | 110.0    | 2.82%        |\n| Merge Requests | 2673.7       | 20.20%      | 126073.4  | 1.31%       | 795.4    | 20.40%       |\n| CI             | 4725.0       | 35.69%      | 1712843.8 | 17.87%      | 1909.2   | 48.98%       |\n| Rest           | 2876.3       | 21.73%      | 7748488.5 | 80.82%      | 1083.6   | 27.80%       |\n\nChoosing to split the CI tables from the database was partly based on instinct.\nWe knew the CI tables (particularly `ci_builds` and\nrelated metadata) were already some of the largest tables in our database. It\nwas also a convenient choice because the CI tables were already prefixed with\n`ci_`. In the end, we realized only three tables were CI tables that weren't\nprefixed with `ci_`. You can see the up-to-date list of tables and their respective\ndatabase in [`gitlab_schemas.yml`][gitlab_schemas_yml].\n\nThe next step was to see how viable it actually was.\n\n## Proving it can work\n\nThe [first proof-of-concept merge request][initial_poc_mr_for_ci_decomposition] was created\nin August 2021. The proof-of-concept process involved:\n\n- Separating the database and seeing what broke\n- Fixing blockers and marking todo's until we ended up with the application \"pretty much working\"\n\nWe never merged this proof of concept, but we progressively broke out changes into smaller merge requests\nor issues assigned to the appropriate teams to fix.\n\n![Screenshot of large proof-of-concept MR](https://about.gitlab.com/images/blogimages/2022-07-15-path-to-decomposing-gitlab-database/poc-mr-scale.png)\n\n## Chasing a moving target\n\nWhen tackling a large-scale architecture change, you might find\nyourself chasing a moving target.\n\nTo split the database, we had to change the application. Our code depended on all\nthe tables being in a single database. These changes took almost a year.\n\nIn the meantime, the application was constantly evolving\nand growing, and with contributions from many engineers who weren't necessarily\nfamiliar with the CI decomposition project. This meant that we couldn't just\nstart fixing problems. We knew we would likely find new problems being\nintroduced at a faster rate than we could remove them.\n\nTo solve this problem, we took an approach that was inspired by\n[how we handle new RuboCop rules](https://docs.gitlab.com/ee/development/contributing/style_guides.html#resolving-rubocop-exceptions).\nThe idea is to implement static or dynamic analysis to detect these\nproblems. Then we use this information to generate an allowlist of exceptions.\nAfter we have this allowlist of exceptions, we prevent any new violations from being created\n(as any new violations will fail the pipeline).\n\nThe result was a clear list to work on and visibility into our progress.\n\nAs part of making the application compatible with CI decomposition, we needed to\nbuild the following:\n\n- [Multiple databases documentation][docs_multiple_databases] taught\n  developers how to write code that is compatible with multiple databases.\n- [Cross-join detection][mr_cross_join_detection] analyzed all SQL queries\n  and raised an error if the query spanned multiple databases.\n- [Cross-database transaction detection][mr_cross_db_transaction_detection]\n  analyzed all transactions and raised an error if queries were sent to two\n  different databases within the context of a single transaction.\n- [Query analyzer metrics][mr_query_analyzer_metrics] analyzed all SQL queries\n  and tracked the different databases that would be queried (based on table\n  names). These metrics, which were sampled at a rate of 1/10,000 queries, because they are\n  expensive to parse, were sent to Prometheus. We used this data to get a sense\n  of whether we were whittling down the list of cross-joins in production.\n  It also helped us catch code paths that weren't covered by tests but were\n  executed in production.\n- [A Rubocop rule for preventing the use of\n  `ActiveRecord::Base`][mr_rubocop_rule_ar_base] ensured that we always\n  used an explicit database connection for Main or CI.\n\n## Using Rails multiple database support\n\nWhen we began this project, there were many improvements being added to Rails to\nsupport multiple databases. We wanted to make use of as much of this Rails\nbuilt-in support as possible to minimize the amount of custom database\nconnection logic we had to maintain.\n\nOne considerable challenge with this was our existing\n[custom database load balancing logic](https://docs.gitlab.com/ee/administration/postgresql/database_load_balancing.html).\nThe development of this complex implementation spans a long period of time, and\nit was designed differently to how Rails connections were managed in the new\nmulti-database support.\n\nIn the end, were able to use parts of Rails multiple database support, but\n[we still hope to one day remove our custom logic and only use what is supported by Rails][epic_to_move_to_native_rails_multiple_dataabase_support].\n\n## Implementing loose foreign keys\n\nThere were still some foreign keys that existed between CI and non-CI tables.\nWe needed a way to remove these keys but still keep the functionality of cascading\ndeletes.\n\nIn the end, [we implemented a solution][lfk_mr]\nwe call [\"loose foreign keys\"][lfk_docs]. This solution provides similar functionality and\nsupport for cascading `NULLIFY` or `DELETE` when a parent record is deleted in\nPostgres. It's implemented using Postgres on delete triggers, so it guarantees all\ndeletes (including bulk deletes) will be handled. The trigger writes to another\n\"queue\" table in Postgres, which then is picked up by a periodic Sidekiq worker\nto clean up all the impacted child records.\n\nWhen implementing this solution, we also considered the option of using\n[`ActiveRecord` `before_destroy` callbacks](https://apidock.com/rails/ActiveRecord/Callbacks/before_destroy).\nHowever they couldn't give us the same guarantees as Postgres foreign keys,\nbecause they can be intentionally or accidentally skipped.\n\nIn the end, the \"loose foreign keys\" solution also helped to solve another problem\nwe have, where very large cascading deletes cause timeouts and user experience issues.\nBecause it's asynchronous, we could easily control timing and batch sizes to never\nhave database timeouts and never overload the database with a single large\ndelete.\n\n## Mirroring namespaces and projects\n\nOne of the most difficult dependencies between CI and Main features in GitLab\nis how CI Runners are configured. Runners are assigned to projects and groups\nwhich then dictates which jobs they will run. This meant there were many join\nqueries from the `ci_runners` table to the `projects` and `namespaces` tables.\nWe solved most of these issues by refactoring our Rails code and queries, but\nsome proved very difficult to do efficiently.\n\nTo work around this issue, [we implemented][mr_namespace_project_mirroring] a mechanism to\n[mirror the relevant columns on `projects` and `namespaces` to the CI database][docs_ci_mirrored_tables].\n\nIt's not ideal to have to duplicate data that must be kept up-to-date like\nthis, but while we expected this may be necessary in a few places, it turns out\nthat we only ended up doing this for those two tables. All other joins could be\nhandled without mirroring.\n\nAn important part of our mirroring architecture is periodic\n[consistency checking][mr_namespace_project_mirroring_consistency_check].\nEvery time this process runs, it takes a batch of the mirrored rows and compares them\nwith the expected values. If there is a discrepancy, it schedules them to be fixed.\nAfter it's done with this batch, it updates a cursor in Redis to be used for the\nnext batch.\n\n## Creating a phased rollout strategy\n\nA key part of ensuring our live migration went as smooth as possible was by\nmaking it as small as possible. This was quite difficult as the migration from\n1 database to 2 databases is a discrete change that seems hard to break up into\nsmaller steps that can be rolled out individually.\n\nOne [early insight][initial_migration_plan_mr] was that we could actually reconfigure GitLab.com ahead of\ntime so that the Rails application behaved as though it was talking to two\nseparate databases long before we actually split the databases. Basically the\nidea was that the Rails processes already had two separate database connections,\nbut ultimately they were going to the same database. We could even break things\nout further since our read-only connections are designed to read from slightly\ndelayed replicas. So we could already have read-only connections going to the\nnewly created CI read-only replicas before the migration.\n\n![Database architecture before final migration step](https://about.gitlab.com/images/blogimages/2022-07-15-path-to-decomposing-gitlab-database/phase4.png)\n\nThese insights led to our [seven-phase migration process][phased_migration_epic].\nThis process meant that by the time we got to the final migration on production\n(Phase 7), we were already incredibly confident that the application would work\nwith separate databases and the actual change being shipped was just trivial\nreconfiguration of a single database host. This also meant that all phases\n(except for Phase 7) had a very trivial rollback process, introduced very\nlittle risk of incident and could be shipped before we were finished with every\ncode change necessary to make the application support two databases.\n\nThe seven phases were:\n\n1. Deploy a Patroni cluster\n2. Configure Patroni standby cluster\n3. Serve CI reads from CI standby cluster\n4. Separate write connections for CI and Main (still going to the same primary host)\n5. Do a staging dry run and finishing the migration plan\n6. Validate metrics and additional logging\n7. Promote the CI database and send writes to it\n\n## Using labels to distribute work and prioritize\n\nNow that we had a clear set of phases we could prioritize our work. All issues\nwere assigned [scoped labels](https://docs.gitlab.com/ee/user/project/labels.html#scoped-labels)\nbased on the specific phase they corresponded to. Since the work spanned many\nteams in development and infrastructure, those teams could use the\nlabel to easily tell which issues needed to be worked on first. Additionally,\nsince we kept an up-to-date timeline of when we expected to ship each phase,\neach team could use the phase label to determine a rough deadline of when that\nwork should get done to not delay the project. Overall there were at least 193\nissues over all phases. Phase 1 and 2 were mostly infrastructure tasks tracked\nin a different group and with different labels, but the other phases contained\nthe bulk of the development team requirements:\n\n1. [8 Phase 3 issues](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=ci-decomposition%3A%3Aphase3)\n1. [78 Phase 4 issues](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=ci-decomposition%3A%3Aphase4)\n1. [7 Phase 5 issues](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=ci-decomposition%3A%3Aphase5)\n1. [64 Phase 6 issues](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=ci-decomposition%3A%3Aphase6)\n1. [34 Phase 7 issues](https://gitlab.com/gitlab-org/gitlab/-/issues/?sort=created_date&state=opened&label_name%5B%5D=ci-decomposition%3A%3Aphase7)\n\n## Continue reading\n\nYou can read more about the final migration process and results of the migration in [Part 2](/blog/path-to-decomposing-gitlab-database-part2/).\n\n[initial_poc_mr_for_ci_decomposition]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67486\n[initial_migration_plan_mr]: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84588\n[lfk_mr]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69165\n[lfk_docs]: https://docs.gitlab.com/ee/development/database/loose_foreign_keys.html\n[epic_to_move_to_native_rails_multiple_dataabase_support]: https://gitlab.com/gitlab-org/gitlab/-/issues/296870\n[phased_migration_epic]: https://gitlab.com/groups/gitlab-org/-/epics/6160\n[sharding_by_top_level_namespace_poc_epic]: https://gitlab.com/groups/gitlab-org/-/epics/5838\n[analysis_of_decomposition_tables]: https://gitlab.com/groups/gitlab-org/-/epics/5883#summary-of-impact\n[gitlab_schemas_yml]: https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/database/gitlab_schemas.yml\n[docs_ci_mirrored_tables]: https://docs.gitlab.com/ee/development/database/ci_mirrored_tables.html\n[mr_cross_join_detection]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/68620\n[mr_cross_db_transaction_detection]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/67213\n[mr_query_analyzer_metrics]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/73839\n[mr_rubocop_rule_ar_base]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/64937\n[mr_namespace_project_mirroring]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/75517\n[mr_namespace_project_mirroring_consistency_check]: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81836\n[docs_multiple_databases]: https://docs.gitlab.com/ee/development/database/multiple_databases.html\n",[876,9],{"slug":1484,"featured":6,"template":686},"path-to-decomposing-gitlab-database-part1","content:en-us:blog:path-to-decomposing-gitlab-database-part1.yml","Path To Decomposing Gitlab Database Part1","en-us/blog/path-to-decomposing-gitlab-database-part1.yml","en-us/blog/path-to-decomposing-gitlab-database-part1",{"_path":1490,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1491,"content":1496,"config":1501,"_id":1503,"_type":13,"title":1504,"_source":15,"_file":1505,"_stem":1506,"_extension":18},"/en-us/blog/path-to-decomposing-gitlab-database-part2",{"title":1492,"description":1493,"ogTitle":1492,"ogDescription":1493,"noIndex":6,"ogImage":926,"ogUrl":1494,"ogSiteName":672,"ogType":673,"canonicalUrls":1494,"schema":1495},"GitLab database decomposition: Final migration and results","This is the second in our three-part technical summary of the yearlong project to decompose GitLab's Postgres database.","https://about.gitlab.com/blog/path-to-decomposing-gitlab-database-part2","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Decomposing the GitLab backend database, Part 2: Final migration and results\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dylan Griffith\"}],\n        \"datePublished\": \"2022-08-04\",\n      }",{"title":1497,"description":1493,"authors":1498,"heroImage":926,"date":1480,"body":1499,"category":787,"tags":1500},"Decomposing the GitLab backend database, Part 2: Final migration and results",[1479],"\n\n_This blog post is part 2 in a three-part series about decomposing the GitLab backend database. It focuses on the final migration\nprocess and highlights the results we achieved after the migration. If you want to read about the design and planning phase, check out [part 1](/blog/path-to-decomposing-gitlab-database-part1/)._\n\n## Deciding between zero downtime and full downtime\n\nEarly on in the project we thought it would be necessary for the migration to\nbe \"zero downtime\" or \"near-zero downtime\". We [came up with this plan][initial_migration_plan_mr]\nearly on which involved (in summary):\n1. The entire database would be replicated (including non-CI tables) using\n   Patroni cascading/standby replication to a dedicated CI Patroni cluster.\n   Replication only lags by at most a few seconds.\n2. Read traffic for CI tables could be split ahead of time to read from the CI\n   replicas.\n3. Write traffic would be split ahead of the migration into CI and Main by\n   sending these through separate dedicated PGBouncer proxies. Initially CI\n   writes still go to the Main database since the CI cluster is just a standby.\n   These proxies would be the thing we reconfigured during the live migration\n   to point at the CI cluster.\n4. At the time of migration we would pause writes to the CI tables by pausing\n   the CI PGBouncer.\n5. After pausing writes to the CI database we'd capture the current LSN\n   position in Postgres of the Main primary database (now expect no more writes\n   to CI tables to be possible).\n6. After that we wait until the CI database replication catches up to that\n   point.\n7. Then we promote the CI database to accept writes (remove the cascading\n   replication).\n8. Then we reconfigure writes to point to the CI database by updating the write\n   host in the CI PGBouncer.\n9. The migration is done.\n\n![Database architecture actual final migration step](https://about.gitlab.com/images/blogimages/2022-07-15-path-to-decomposing-gitlab-database/phase4to7.png)\n\nThis approach (assuming that the CI replicas were only delayed by a few\nseconds) would mean that, at most, there would be a few seconds where CI writes\nmight result in errors and 500s for users. Many failures would likely already\nbe retried since much of CI write traffic goes via asynchronous (Sidekiq)\nprocesses that automatically retry.\n\nIn the end we didn't use this approach because:\n\n1. This approach didn't have an easy-to-implement rollback strategy. Data that\n   was written to CI tables during the migration would be lost if we rolled\n   back to just the Main database.\n2. The period of a few seconds where we expect to see some errors might make it\n   difficult for us to quickly determine the success or failure of the\n   migration.\n3. There was no hard business requirement to avoid downtime.\n\nThe [migration approach we ended up using][phase7_summary_epic] took two\nhours of downtime. We stopped all GitLab services that could read or write\nfrom the database. We also blocked user-level traffic at the CDN (Cloudflare) to allow us\nto do some automated and manual testing before opening traffic back up to\nusers. This allowed us to prepare a [slightly more straightforward rollback procedure][rollback_issue],\nwhich was:\n\n1. Reconfigure all read-only CI traffic back to the Main replicas\n2. Reconfigure all read-write CI traffic (via PGBouncer) back to the Main\n   primary database\n3. Increment the Postgres sequences for all CI tables to avoid overlapping with\n   data we created in our testing\n\nUltimately having a simple rollback mechanism proved very useful in doing many\npractice runs on staging.\n\n## Rehearsing the migration process\n\nBefore executing the final migration on GitLab.com, we executed seven rehearsals\nwith rollback and one final migration on our staging environment. In these\npractice runs, we discovered many small issues that would have likely caused\nissues in the production environment.\n\nThese rehearsals also gave all the participants an opportunity to perfect their steps\nin the process to minimize delays in our production rollout. This practice\nultimately allowed us to be quite confident in our timeline of at most two hours of downtime.\n\nIn the end, we finished the migration in 93 minutes, with a few small delays caused by\nsurprises we did not see in staging.\n\nThe rehearsal process was very time-consuming and a vast effort to execute in\nthe context of GitLab, where we all [work\nasynchronously](https://about.gitlab.com/company/culture/all-remote/asynchronous/)\nand across different timezones. However, it proved to be essential to the success of\nthis project.\n\n## Preparing for production migration\n\nOne week before our the final migration on production we prepared a production\nreadiness review issue for final approval from executives. This was a good\nopportunity to highlight all the preparation and validation we'd done to give\nus confidence in the plan. This also encouraged us to do extra validation where\nwe might expect to see questions or concerns about the plan.\n\nSome highlights from this review included:\n\n1. The amount of practice runs we'd done including details about the problems\n   we'd seen and resolved in staging\n2. Metrics which we'd observed to prove all the queries were using the right\n   database connections already\n3. Details about how long we'd been running without issues in local development\n   with all GitLab developers running with two databases by default\n4. Details about the rollback strategy we would use if necessary and how we\n   tested this rollback strategy in staging as well as some production\n   validation\n\n## Tracking the results\n\nAfter we completed the rollout we tracked\n[performance improvements across some metrics we expected to improve][performance_improvements_tracking_issue].\n\nThe data showed:\n\n- We decreased the CPU utilization of our primary database server, giving us much more headroom.\n\n  ![CPU peaks before and after decomposition shows smaller peaks after](https://about.gitlab.com/images/blogimages/2022-07-15-path-to-decomposing-gitlab-database/cpu-post-decomposition-improvement.png)\n\n- We can free around 9.2TiB out of 22TiB from our Main database by truncating the CI tables.\n- We can free around 12.5TiB out of 22TiB from our CI database by truncating the Main tables.\n- We significantly reduced the rate of dead tuples on our Main database.\n- We significantly reduced vacuuming saturation. Before decomposition the Main database\n  maximum vacuuming saturation was up to 100%, with the average closer to 80%. After\n  decomposition, vacuuming saturation has stabilized at around 15% for\n  both databases.\n\n  ![Vacuum saturation before and after decomposition shows a decrease after decomposition](https://about.gitlab.com/images/blogimages/2022-07-15-path-to-decomposing-gitlab-database/vacuum-saturation-post-decomposition.png)\n\n- We reduced the average query duration for our Sidekiq PGBouncer query\n  pool by at least a factor of 5 once we scaled up connection limits due to our\n  increased headroom. Previously we needed to throttle connections for\n  asynchronous workloads to avoid overloading the primary database.\n\n  ![Average active query duration by workload shows a decrease after scaling connections after decomposition](https://about.gitlab.com/images/blogimages/2022-07-15-path-to-decomposing-gitlab-database/pgbouncer-active-query-duration-by-workload.png)\n\n## Continue reading\n\nYou can read more about some interesting technical challenges and surprises we\nhad to deal with along the way in\n[part 3](/blog/path-to-decomposing-gitlab-database-part3/).\n\n[initial_migration_plan_mr]: https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/84588\n[performance_improvements_tracking_issue]: https://gitlab.com/gl-retrospectives/sharding-group/-/issues/18\n[phase7_summary_epic]: https://gitlab.com/groups/gitlab-org/-/epics/7791\n[rollback_issue]: https://gitlab.com/gitlab-org/gitlab/-/issues/361759\n",[876,9],{"slug":1502,"featured":6,"template":686},"path-to-decomposing-gitlab-database-part2","content:en-us:blog:path-to-decomposing-gitlab-database-part2.yml","Path To Decomposing Gitlab Database Part2","en-us/blog/path-to-decomposing-gitlab-database-part2.yml","en-us/blog/path-to-decomposing-gitlab-database-part2",{"_path":1508,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1509,"content":1514,"config":1518,"_id":1520,"_type":13,"title":1521,"_source":15,"_file":1522,"_stem":1523,"_extension":18},"/en-us/blog/path-to-decomposing-gitlab-database-part3",{"title":1510,"description":1511,"ogTitle":1510,"ogDescription":1511,"noIndex":6,"ogImage":926,"ogUrl":1512,"ogSiteName":672,"ogType":673,"canonicalUrls":1512,"schema":1513},"Decomposing the GitLab backend database, Part 3: Challenges and surprises","This is the final installment in our three-part series about our yearlong project to decompose GitLab's Postgres database.","https://about.gitlab.com/blog/path-to-decomposing-gitlab-database-part3","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Decomposing the GitLab backend database, Part 3: Challenges and surprises\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dylan Griffith\"}],\n        \"datePublished\": \"2022-08-04\",\n      }",{"title":1510,"description":1511,"authors":1515,"heroImage":926,"date":1480,"body":1516,"category":787,"tags":1517},[1479],"\n_This blog post is part 3 in a three-part series. It focuses on some interesting\nlow-level challenges we faced along the way, as well as some surprises we found during\nthe migration._\n\n- To read about the design and planning phase, check out [part 1](/blog/path-to-decomposing-gitlab-database-part1/).\n- To read about how we executed the actual migration and our results, check out [part 2](/blog/path-to-decomposing-gitlab-database-part2/).\n\n## The challenge with taking GitLab.com offline\n\nOne key part of our migration process was to take all systems offline that\ncould potentially talk to the database. This may seem as simple as \"shutting\ndown the servers\" but given the scale and complexity of GitLab.com's\ninfrastructure this proved to be really quite complex. Here is just a subset of\nthe different things we had to shut down:\n\n1. Kubernetes pods corresponding to web, API, and Sidekiq services\n2. Cron jobs across various VMs\n\n## Surprises along the way\n\nEven though we had rehearsed the migration many times in staging, there were\nstill some things that caught us off-guard in production. Luckily, we had\nallocated sufficient buffer time during the migration to resolve all of these\nduring the call:\n\n1. Autovacuum on our largest CI tables take a long time and can run at any\n   time. This delayed our migration as we needed to gain table locks for our\n   [write block\n   triggers](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/83211).\n   Adding these triggers requires a `ShareRowExclusiveLock` which cannot be\n   acquired while the autovacuum is running for that table. We disabled\n   some manual vacuum processes we were aware of ahead of the call but\n   autovacuum can happen at any time and our `ci_builds` table just happen to\n   have autovacuum at the time we were trying to block writes to this table. To\n   work around this we needed to temporarily disable autovacuum for the\n   relevant tables and then find the `pid` for the autovacuum process and\n   terminate this which allowed our triggers to be successfully added.\n2. Sometimes a long-running SSH session by an SRE or developer can leave open a\n   surprising database connection that needs to be tracked down and closed.\n3. Cron jobs can be run on various hosts that start rails processes or database\n   connections at any time. We had many examples that were created with\n   different purposes for database maintenance over the years, and we missed at\n   least one in our practice runs. They weren't as easy to detect on staging as\n   they may not all be configured on staging, or they run a lot faster on\n   staging. Also, our staging runs all happened on week days, but our\n   production migration happened on a weekend where it seemed we were\n   deliberately running some database maintenance workloads during low\n   utilization hours.\n4. Our Sentry client-side error tracking caused us to overload our Sentry\n   server due to many of users leaving open GitLab browser tabs. As\n   the browser tabs periodically make asynchronous requests to GitLab and get\n   errors (since GitLab.com was down), they then send all these errors to Sentry\n   and this overloaded our Sentry error server to the point we couldn't load it\n   to check for errors. This was quickly diagnosed based on the URL all the\n   requests were sent to, but it did delay our migration as checking for new\n   errors was key to determining success or failure of the migration.\n\n## Cascading replication doubles latency (triples in our case)\n\nA key initial step in our phased rollout was to move all read-only CI traffic\nto dedicated CI replicas. These were cascading replicas from the main Patroni\ncluster. Furthermore, we made the decision to create the standby cluster leader\nas a replica of another replica in the Main Patroni cluster. Ultimately this\nmeant the replication process for our CI replicas was\n`Main Primary -> Main Replica -> CI Standby Leader -> CI Replica`.\n\nThis change meant that our CI replicas had roughly three times as much latency\ncompared with our Main replicas, which previously served CI read-only traffic.\nSince our read-only load balancing logic is based on users sticking to the primary\nuntil a replica catches up with the last write that they performed, users\nmight end up sticking to the primary longer than they previously would have.\nThis may have served to increase our load on the primary database after rolling\nout Phase 3.\n\nWe never measured this impact, but in hindsight it is something we\nshould have factored in and benchmarked with our gradual rollout of Phase 3.\nAdditionally, we should have considered mitigating this issue by having the `CI\nStandby Leader` replicating straight from the `Main Primary` or adding the `CI\nStandby Leader` to the pool of replicas that we could service CI read-only\ntraffic.\n\n## Re-balancing PGBouncer connections incrementally without saturating anything\n\n[Phase 4 of our rollout][phase4_change_request] turned out to be one of the\ntrickiest parts of the migration. Since we wanted all phases (where possible)\nto be rolled out incrementally we needed some way to [solve for\nincrementally re-balancing connection pool limits][phase4_gradual_rollout_issue]\nfrom `GitLab -> PGBouncer -> Postgres` without exceeding the total connection\nlimit of Postgres or opening too many connections to Postgres that might\nsaturate CPU. This was difficult because all the connection limits were very\nwell tuned, and we were close to saturation across all these limits.\n\nThe gradual rollout of traffic for Phase 4 looked like:\n\n```mermaid\ngraph LR;\n    PostgresMain[(PostgresMain - Limit K max_connections)]\n    GitLabRails-->|100-X % of CI queries|PGBouncerMain\n    GitLabRails-->|X% of CI queries|PGBouncerCi\n    PGBouncerMain-->|Limit N pool_size|PostgresMain\n    PGBouncerCi-->|Limit M pool_size|PostgresMain\n```\n\nWe wanted to gradually increase X from 0-100. But this presented a problem, because\nthe number of connections to the `PostgresMain` DB will change\nwith this number.\n\nWe assume it has some initial limit `K` connections, and we\nassume this limit is deliberately just high enough to handle the current\nconnections from `PGBouncerMain` and not overload the CPU. We need to carefully\ntune `N` and `M` `pool_size` values across the separate PGBouncer processes to\navoid overloading the limit K, and we also need to avoid saturating the\nPostgres server CPU with too much traffic. At the same time, we need to ensure\nthere are enough connections to handle the traffic to both PGBouncer pools.\n\nWe addressed this issue by taking very small steps during low\nutilization hours (where CPU and connection pools weren't near saturation) and\ndoing very detailed analysis after each step. We would wait a day or so to figure out how\nmany connections to move over with the following steps, based on the number of\nconnections that were used by the smaller step. We also used what data we had\nearly on from table-based metrics to get an insight into how many connections\nwe thought we'd need to move to the CI PGBouncer pool.\n\nIn the end, we did need to make small adjustments to our estimates along the way\nas we saw saturation occur, but there was never any major user-facing saturation\nincidents, as the steps were small enough.\n\n## Final thoughts\n\nWe're very happy with the results of this project overall.\n\nA key objective of this project, which was hard to predict, was how the complexity of\nan additional database might impact developer productivity. They can't do\ncertain types of joins and there is more information to be aware of.\nHowever, many months have now passed, and it seems clear now that the complexity is mostly abstracted by Rails models. With continued large number of developers contributing, we have seen\nlittle-to-no impact on productivity.\n\nCombining this success with the huge scalability headroom we've gained, we believe this was a great decision for GitLab.\n\n## More reading\n\nThis blog series contains many links to see our early designing, planning, and\nimplementation of various parts of this project. GitLab's\n[transparency value](https://handbook.gitlab.com/handbook/values/#transparency)\nmeans you can read all the details and get a sense of what it's like to work on\nprojects like this at GitLab. If you'd like to know more or something was\nunclear please leave a comment, so we can make sure we share all our learnings.\n\n[phase4_change_request]: https://gitlab.com/gitlab-com/gl-infra/production/-/issues/6440\n[phase4_gradual_rollout_issue]: https://gitlab.com/gitlab-org/gitlab/-/issues/347203\n",[876,9],{"slug":1519,"featured":6,"template":686},"path-to-decomposing-gitlab-database-part3","content:en-us:blog:path-to-decomposing-gitlab-database-part3.yml","Path To Decomposing Gitlab Database Part3","en-us/blog/path-to-decomposing-gitlab-database-part3.yml","en-us/blog/path-to-decomposing-gitlab-database-part3",{"_path":1525,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1526,"content":1532,"config":1539,"_id":1541,"_type":13,"title":1542,"_source":15,"_file":1543,"_stem":1544,"_extension":18},"/en-us/blog/placebo-lines-on-the-pipeline-graph",{"title":1527,"description":1528,"ogTitle":1527,"ogDescription":1528,"noIndex":6,"ogImage":1529,"ogUrl":1530,"ogSiteName":672,"ogType":673,"canonicalUrls":1530,"schema":1531},"Placebo Lines on the Pipeline Graph","Have you noticed the connecting lines missing on your pipelines lately? Here's why","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679507/Blog/Hero%20Images/ci-cd.png","https://about.gitlab.com/blog/placebo-lines-on-the-pipeline-graph","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Placebo Lines on the Pipeline Graph\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sam Beckham\"}],\n        \"datePublished\": \"2021-05-11\",\n      }",{"title":1527,"description":1528,"authors":1533,"heroImage":1529,"date":1535,"body":1536,"category":764,"tags":1537},[1534],"Sam Beckham","2021-05-11","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nHave you ever pressed the close door button on the elevator, in the hope that you'll save a few precious seconds?\nOr got frustrated at the person stood next to you at the cross-walk, neglecting to press the button?\nWell, maybe they know something you don't, or perhaps you know this already.\nMany buttons in our society lie to us.\n[David McRaney](https://youarenotsosmart.com/2010/02/10/placebo-buttons/) dubbed these, \"Placebo buttons\" and they're everywhere.\nThose elevator doors won't close any faster and the cross-walk button has no effect on the lights.\nThe only lights they control are the lights on the buttons themselves.\nThey give you the feedback you crave, but that's all they're doing.\n\nThese placebos aren't constrained to the physical world, they're prevalent in [UI design](/blog/the-evolution-of-ux-at-gitlab/) too.\nFrom literal placebo buttons like [YouTube's downvote](https://www.quora.com/Does-downvoting-a-comment-on-YouTube-even-do-anything), to more subtle effects like Instagram always [pretending to work](https://www.fastcompany.com/1669788/the-3-white-lies-behind-instagrams-lightning-speed), or progress bars that have a [fixed animation](https://www.theatlantic.com/technology/archive/2017/02/why-some-apps-use-fake-progress-bars/517233/).\nThey're everywhere if you know where to look.\n\nAt GitLab, we created a placebo of our own in one of our core features; the pipeline graph.\n\nThose of you who have used our pipeline graph, will be familiar with its appearance.\nThere's a series of jobs, grouped by stages, connected by a series of lines depicting the relationships between the jobs.\nBut these lines might be lying to you.\nThese lines are indiscriminately drawn between each job in a stage, regardless of their relationship.\nThese lines are placebos.\n\n![The old pipeline rendering with lines connecting every job in a stage](https://about.gitlab.com/images/blogimages/placebo-lines_old-graph.png)\n\nThis wasn't a problem to begin with.\nA basic pipeline has several jobs across a handful of stages.\nJobs in each stage would run parallel to each other, but each stage would run sequentially.\nIn the image shown above, all the jobs in the test stage would trigger at the same time. Once those jobs had finished, all the jobs in the build stage would trigger.\nWe used rudimentary CSS to draw lines connecting each job in one stage to each job in the next.\nThese lines weren't calculated based on their connections, but still reflected the story they were telling.\n\nSince the introduction of `needs` relationships in [v12.2](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/47063), pipelines got a bit more complicated.\nNow you could configure a job in a later stage to trigger as soon as a job in an earlier stage completed.\nLooking at our old example, we could set the API deployment to run as soon as our spec tests passed.\nThis skips the remaining tests and the entire build stage, turning our lines into pretty little liars.\n\nWe had many internal discussions about these lines, and how to show the relationships between jobs.\nThere's the [`needs` visualization](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/#needs-visualization), which does an excellent job of displaying these relationships, but the main pipeline graph was still inaccurate.\nFor the past few months, we've been [refactoring the pipeline graph](https://gitlab.com/gitlab-org/gitlab/-/issues/276949), giving it a new lease of life and fixing some of its issues along the way.\nOne of those issues were the faked lines.\nIn the new version, we can accurately draw lines between jobs.\nLines that actually depict the relationships jobs have with each other.\nNow the lines no-longer lie!\n\n![The newer pipeline graph showing the correct needs links between jobs](https://about.gitlab.com/images/blogimages/placebo-lines_new-graph.png)\n\nThe above image shows an unreleased version of the pipeline graph.\nYou can see the lines drawn between the jobs to show that the `deploy:API` job can start as soon as the `rspec` job is successful.\nSomething the old lines (shown earlier in this post) would have been unable to depict.\n\nOne unfortunate downside of this is that these lines can be quite expensive to calculate.\nThey're actual DOM nodes, drawn deliberately and placed precisely.\nOn smaller graphs this isn't a problem, but some of our initial tests have found pipelines with a potential 8000+ job connections.\nThat kind of calculation would grind the browser to a halt, and nobody wants that.\n\nAt GitLab, we believe in boring solutions.\nWe make the simple change that sets us on the path towards where we want to be.\nShip it, get feedback, and iterate.\nSo that's what we did.\nIn the first phase of this rollout, we shipped the new pipeline graph with no lines connecting the jobs.\nWe don't have to worry about the expensive calculations, and we still get to roll out the refactored pipeline graph.\n\n![The current (v13.11) pipeline graph showing no links between jobs](https://about.gitlab.com/images/blogimages/placebo-lines_current-graph.png)\n\nWe know some of you will miss them, but fear not.\nBoring solutions are just technical debt if you don't iterate on them.\nSo the [improved lines are coming](https://gitlab.com/groups/gitlab-org/-/epics/4509) in a future release, along with several other improvements to the pipeline graph.\nWe're already starting to roll out the new [Job Dependencies](https://gitlab.com/gitlab-org/gitlab/-/issues/298973) view which shows the jobs in a (much closer to) execution order.\nStay tuned for more updates, and watch [Sarah Groff Hennigh Palermo's talk](https://www.youtube.com/watch?v=R2EKqKjB7OQ) for the technical side of this effort and a deeper dive into some of the decisions we made.\n",[1538,1417,768,9],"CI",{"slug":1540,"featured":6,"template":686},"placebo-lines-on-the-pipeline-graph","content:en-us:blog:placebo-lines-on-the-pipeline-graph.yml","Placebo Lines On The Pipeline Graph","en-us/blog/placebo-lines-on-the-pipeline-graph.yml","en-us/blog/placebo-lines-on-the-pipeline-graph",{"_path":1546,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1547,"content":1552,"config":1557,"_id":1559,"_type":13,"title":1560,"_source":15,"_file":1561,"_stem":1562,"_extension":18},"/en-us/blog/polishing-gitlabs-ui-a-new-color-system",{"title":1548,"description":1549,"ogTitle":1548,"ogDescription":1549,"noIndex":6,"ogImage":1008,"ogUrl":1550,"ogSiteName":672,"ogType":673,"canonicalUrls":1550,"schema":1551},"Polishing GitLab’s UI: A new color system","Senior UX Designer Pedro Moreira da Silva takes us on a deep dive into how the UX team improved the GitLab UI’s color palette.","https://about.gitlab.com/blog/polishing-gitlabs-ui-a-new-color-system","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Polishing GitLab’s UI: A new color system\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pedro Moreira da Silva\"}],\n        \"datePublished\": \"2018-03-29\",\n      }",{"title":1548,"description":1549,"authors":1553,"heroImage":1008,"date":1554,"body":1555,"category":787,"tags":1556},[1173],"2018-03-29","\nWe receive a lot of feedback from our users and the broader community. After\nhearing that there is a perceived lack of consistency and quality in GitLab’s\nUI, we decided to take a look at our _color palette_.\n\n\u003C!-- more -->\n\nAesthetic aspects like this are a fundamental part of the UI. If we don’t get\nthese right, everything else in the UI won’t feel, look, or behave correctly.\nLike a house, these aesthetics are the foundation upon which everything else is\nbuilt.\n\nOur color palette had various issues, so we started by:\n\n- [building a better palette][ce#28614] that aligned with our goals,\n- and [defining a color priority system][ce#31094] that helped us move forward.\n\n## Why start with colors?\n\nThere are many aesthetic aspects to a UI. So why tackle colors first? Well…\n\n- **Colors are easy to change**: it’s just a matter of changing simple values in\n  our [`variables.scss`](https://gitlab.com/gitlab-org/gitlab-ce/blob/1553a34dbff167978f5dc81cc3a21e0b3b2b2bfa/app/assets/stylesheets/framework/variables.scss#L14)\n  file.\n- **Color changes don’t affect layout**: we weren’t reinventing the wheel, so\n  these changes wouldn’t influence the layout and spacing between elements like\n  typography can.\n\nAnd, more subjectively, colors have a huge impact on the perception of a UI.\nIt’s said that 90 percent of information entering the brain is visual and color\nis an attention-grabbing device.\n\n## Issues with the previous color palette\n\n![Previous color palette](https://about.gitlab.com/images/blogimages/polishing-gitlabs-ui-a-new-color-system/prev-palette.png)\n\n### It didn’t extend the brand colors\n\nThey weren’t in line with our [brand colors](https://gitlab.com/gitlab-com/gitlab-artwork/blob/9b07772f44a9fa51f395a95928a6e41c61a5b1cb/colors),\nwith the most obvious example being the pinkish-red normally associated with\nnegative aspects like errors or irreversible actions. We already have a red from\nour brand, so why use a different one?\n\n### There were too many similar colors\n\nWith so many colors, it wasn’t easy to tell them apart. They were so similar\nthat they no longer brought value to the table, just more guesswork and\nmaintenance.\n\n### There wasn’t enough contrast\n\nMany of our color combinations did not meet the contrast ratios defined in the\n[Web Content Accessibility Guidelines (WCAG)][wcag-contrast].\n\nNote that some of these issues were also applicable to grayscale colors (also\ncalled “achromatic”).\n\n## Building a better palette\n\nAt GitLab, we’ve done a lot of things while standing on the shoulders of giants,\naligning with our company value of [boring solutions](https://handbook.gitlab.com/handbook/values/#boring-solutions).\nAs such, one of our initial thoughts was to use an existing color palette,\nsomething that could save us time and maybe serve as the basis for our work.\n\nWe soon found [Open color](https://yeun.github.io/open-color/), an open source\ncolor scheme optimized for UI. It has 13 hues, each with 10 levels of\nbrightness, totaling 130 different colors. All of the values are there, it would\nbe easy for our Frontend team to get started by importing it as a dependency.\nThis was starting to look very promising and we were getting excited about this\nquick start.\n\nHowever, the more we thought about our current needs and goals, the more we\nrealized that this approach wasn’t going to work for us. Existing color palettes\nusually had too many colors for our needs and the ones we did need, would have\nto be tweaked to align with our brand colors. All of the upsides of using an\nexisting color palette were now irrelevant.\n\nWe went back to the drawing board, starting with defining the goals we wanted\nour new color palette to achieve:\n\n- Align with and extend our brand colors\n- Have only the hues that we need, the colors that have meaning in the UI\n- Be accessible by passing the WCAG\n\n### 1. Extending the brand\n\nThe first step in creating our new color palette was inspired by “[Add Colors To Your Palette With Color Mixing][viget-article],”\nwhere we used [ColorSchemer Studio](http://www.colorschemer.com/osx_info.php)\nto generate this color wheel from the [three brand colors](https://gitlab.com/gitlab-com/gitlab-artwork/blob/9b07772f44a9fa51f395a95928a6e41c61a5b1cb/colors)\nand the [primary purple used on this site](https://gitlab.com/gitlab-com/www-gitlab-com/blob/9c4a9b653f013483d5053c1da30cba6d4bb96bd5/source/stylesheets/_variables.scss#L16):\n\n{: .text-center}\n![Color wheel generated from the brand colors](https://about.gitlab.com/images/blogimages/polishing-gitlabs-ui-a-new-color-system/color-wheel.png){:style=\"width:350px\"}\n\nInitial colors were separated by even intervals of hue and manually tweaked. In\nthe image above, the matching brand colors are next to the wheel for reference.\n\n### 2. Cutting the rainbow\n\nThen, we generated tints and shades for some of the hues in that color wheel:\ngreen, blue, purple, red and orange.\n\n{: .text-center}\n![Tints and shades](https://about.gitlab.com/images/blogimages/polishing-gitlabs-ui-a-new-color-system/tints-shades.png){:style=\"width:451px\"}\n\nThese were first obtained from the [Material Design Palette Generator](http://mcg.mbitson.com/)\nand then tweaked manually using [Colorizer](http://colorizer.org/) and Eric\nMeyer’s [Color Blender](https://meyerweb.com/eric/tools/color-blend). The dark\norange colors are a good example of manual tweaking as they initially looked\nvery “muddy.”\n\nIt’s important to consider the number of tints and shades that you need, as that\naffects the flexibility when applying those colors. Our guiding principle here\nwas to provide clear and visible contrast between each step of the scale. If we\nhad steps that were too similar, the difference wouldn’t be noticeable, which\nmeant that there was no value in having those colors.\n\nWe didn’t want all of the colors of the rainbow, just the ones that _carry\nmeaning effectively_. We want to be able to communicate states and actions by\napplying colors to elements in the UI (e.g. informational elements are\nassociated with blue). If you have too many similar colors in a UI, like green\nand lime, you’re expecting too much not only of your users but also of your\nteam. On the one hand, most of your users won’t notice the difference between\ncolors when placed in a complex UI, so they also won’t pick up the different\nmeanings. On the other hand, your team will have more work learning, working\nwith, and maintaining unnecessary colors.\n\nAdditionally, we shouldn’t rely on color alone to communicate something, so\nthat’s also another point for not having too many similar colors. This is\nactually one of the success criteria of the WCAG about the [use of color](https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-without-color.html):\n\n> Color is not used as the only visual means of conveying information,\n> indicating an action, prompting a response, or distinguishing a visual\n> element.\n\n### 3. Colors for everyone\n\nUsing a small set of colors which allows for better memorization and recognition\nis already a good step towards a more usable product, but it’s not enough.\n\n[Evaluating, testing, and prioritizing accessibility problems](https://gitlab.com/groups/gitlab-org/-/epics/31)\nis one of our main initiatives here at GitLab. Establishing contrast between\ntext and background is one of the key aspects of accessibility and, as we saw\nbefore, our previous color palette didn’t meet the [WCAG contrast\nratios][wcag-contrast]. So, as we were defining our new color palette, we\ncontinually tested the colors using the [WebAIM Color Contrast Checker](https://webaim.org/resources/contrastchecker/).\n\nAlong the way, we hit a problem: combinations of _white_ text over _green_ or\n_orange_ backgrounds did not pass **WCAG level AA for small text**. This was an\nissue because we wanted to keep a uniform “vibrancy” and “pop” throughout all\ncolors. While the colors looked uniform to our human eye, the WCAG test didn’t\n“see” them as we did. Would we be forced to “break” this visual consistency and\nuse darker shades for those colors? Not only that, but this would render them too\ndark to _carry meaning effectively_. In the following example, the “success”\nmeaning of green or the “warning” meaning of orange become less immediate as\ntheir contrast increases.\n\n![Warning and success elements can be more or less noticeable but that affects the result of the WCAG contrast tests](https://about.gitlab.com/images/blogimages/polishing-gitlabs-ui-a-new-color-system/problematic-colors.png)\n\nWe found an interesting take on this at the [Google Design](https://design.google/)\nwebsite, which intentionally uses colors that at least pass **AA for large\ntext**:\n\n> Due to this site’s purpose being a source for visual design reference\n> and inspiration, we felt it was acceptable not to target a stronger color\n> contrast level. — [Behind the Code — Google Slash Design Accessibility](http://www.instrument.com/articles/google-slash-design-accessibility)\n\nConsidering our audience and user base, should we be rigid and enforce **AA\nlevel for small text**? As a first step towards better color contrasts, we\ndecided to set our minimum at **AA for large text**, even for _small text_. For\ngrays, we [tested and tweaked their contrast against light gray backgrounds][ce#36675],\nas that is a common color used to differentiate regions in the UI.\n\n{: .text-center}\n![All tints and shades with corresponding WCAG levels, including grays](https://about.gitlab.com/images/blogimages/polishing-gitlabs-ui-a-new-color-system/tints-shades-wcag.png){:style=\"width:567px\"}\n\n## Color priorities\n\nSo, after all this work, we introduced a wide range of color tints and shades\nwith the new color palette. The problem was that there was no guidance for using\nthem. Some color decisions are fairly quick and intuitive, but we wanted to\nstandardize and make the color selection process as objective as possible for\neveryone, even developers. We want to give people the chance to make a decision\nwithout imposing approval or reviews by the UX team. We want to be [lean, efficient, and focus on results](https://handbook.gitlab.com/handbook/values/).\n\nSome questions that we should be able to answer:\n\n- “I need to use one blue, which shade should I pick?”\n- “This UI component needs three contrasting shades of green. Can I pick\n  whichever I want?”\n\nThe [Material Design colors](https://material.io/guidelines/style/color.html)\nhave been a great source of inspiration for us. They follow the numeric naming\nconventions used by the [CSS `font-weight` property](https://www.w3.org/TR/css-fonts-3/#font-weight-prop),\nwhere a higher value equals a higher degree of blackness. So, we’ve named our\ncolors from the lightest (**50**) to the darkest (**950**).\n\nOn top of this naming scheme, we’ve defined a system of color priorities. This\nis similar to how different font weights are used to create contrasting\ntypography that communicates hierarchy.\n\nWe can apply this same logic to colors, as seen in the image below, by tagging\nthem according to their priority: from **1** to **4**. If you need guidance, the\npriorities can help you make better choices. When choosing how to apply color to\na UI component:\n\n- You start at priority **1**, which is the medium weight **500**. There’s only\n  one shade with priority 1 per color (the “default” shade).\n- For more shades of the same color, you could then choose from the next\n  priority level, number **2**, which can either be **300** (lighter) or **700**\n  (darker). And so forth for even lighter or darker shades.\n\n![All tints and shades with corresponding priorities, names, and WCAG levels, including grays](https://about.gitlab.com/images/blogimages/polishing-gitlabs-ui-a-new-color-system/color-priorities-system.png)\n\n## What’s next\n\nAlong the way, we’ve learned that [mixing colors and defining color palettes](https://books.google.com/books?id=R4qwDQAAQBAJ)\nis not only science, nor only art, it’s a subjective balance on the human mind.\nColor harmony depends on many factors, like culture, age, social status, or even\nthe [designer’s intent](http://www.aic-color.org/journal/v1/jaic_v1_review.pdf).\n\nWe’ll have to see how people use the 11 tints and shades and how they’re applied\nin our [Design System][ds]. This is a constant evolution, and we’re always\niterating (as we should be).\n\nNext, we’re going to review our [color meaning guidelines](https://design.gitlab.com/)\nand be more active in their usage, not only in the product but also in our\n[Design System][ds] and [pattern library](https://gitlab.com/gitlab-org/gitlab-design/blob/master/gitlab-elements.sketch).\n\nA new color palette and a color priority system are seemingly small steps\ntowards a better user experience throughout GitLab, but they do make a big\ndifference, for our users, our team, and every contributor. This is the first\ninitiative to polish our UI styles, next we’re implementing our new [type scale](https://gitlab.com/gitlab-org/gitlab-ce/issues/24310)\n– which will deserve a dedicated blog post.\n\nIf you have any questions, feel free to [post a comment on the community forum](https://forum.gitlab.com/new-topic?tags=blog-feedback),\n[tweet at us](https://twitter.com/gitlab), or join the discussion on the\nfollowing issues:\n\n- [Change chromatic/full colors to a more harmonious palette][ce#28614]\n- [Define color priorities][ce#31094]\n- [Define a pure gray color scale][ce#36675]\n",[876,9,682,725],{"slug":1558,"featured":6,"template":686},"polishing-gitlabs-ui-a-new-color-system","content:en-us:blog:polishing-gitlabs-ui-a-new-color-system.yml","Polishing Gitlabs Ui A New Color System","en-us/blog/polishing-gitlabs-ui-a-new-color-system.yml","en-us/blog/polishing-gitlabs-ui-a-new-color-system",{"_path":1564,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1565,"content":1571,"config":1577,"_id":1579,"_type":13,"title":1580,"_source":15,"_file":1581,"_stem":1582,"_extension":18},"/en-us/blog/product-development-management",{"title":1566,"description":1567,"ogTitle":1566,"ogDescription":1567,"noIndex":6,"ogImage":1568,"ogUrl":1569,"ogSiteName":672,"ogType":673,"canonicalUrls":1569,"schema":1570},"Version control and collaborating for product development management","Gitlab provides collaboration functionalities to product teams that work not only with source code but also graphic assets.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681632/Blog/Hero%20Images/blog-pdm-image.png","https://about.gitlab.com/blog/product-development-management","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Version control and collaborating for product development management\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"William Arias\"}],\n        \"datePublished\": \"2020-10-02\",\n      }",{"title":1566,"description":1567,"authors":1572,"heroImage":1568,"date":1574,"body":1575,"category":764,"tags":1576},[1573],"William Arias","2020-10-02","\n{::options parse_block_html=\"true\" /}\n\n\n\nFor Designers working with Developers or Product Managers it's frustrating to create a file in one tool, manually export the file, create a prototype in another tool, and use separate software or channels to handoff the designs to developers, the feedback exchange happens not in the context of the design but gets diluted in emails or messaging platforms, making it harder to retake the context after some time has passed.\nTo address those pains mentioned above, Gitlab counts with tools to bridge the communication, collaboration and bring together different roles, using capabilities such as Design Management combined with easy to install plugins like Gitlab Figma Plugin, Developers, Designers, Product Managers and in general any participant role of a project can provide early feedback on any-fidelity designs and open discussions that ultimately lead a team to be more efficient and create awesome products.\n\n\n\nWatch this short video to learn how to leverage Gitlab Design Capabilities along with robust Version Control and collaboration\n\n\u003Ciframe width=\"560\" height=\"315\" src=\"https://www.youtube.com/embed/YtbHkCzxFW4\" frameborder=\"0\" allow=\"accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture\" allowfullscreen>\u003C/iframe>\n\n\nCover image by [Pexels](https://pixabay.com/photos/action-figure-art-color-cute-1853285/) on [pixabay](https://pixabay.com/)\n{: .note}\n\n",[9,1538],{"slug":1578,"featured":6,"template":686},"product-development-management","content:en-us:blog:product-development-management.yml","Product Development Management","en-us/blog/product-development-management.yml","en-us/blog/product-development-management",{"_path":1584,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1585,"content":1591,"config":1596,"_id":1598,"_type":13,"title":1599,"_source":15,"_file":1600,"_stem":1601,"_extension":18},"/en-us/blog/quantifying-ux-positioning-of-the-clone-button",{"title":1586,"description":1587,"ogTitle":1586,"ogDescription":1587,"noIndex":6,"ogImage":1588,"ogUrl":1589,"ogSiteName":672,"ogType":673,"canonicalUrls":1589,"schema":1590},"Quantifying UX: Positioning the clone button","We wanted to move the clone button on the project overview page. Here's how user testing helped us make the right choices.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749672622/Blog/Hero%20Images/positioning-clone-button.jpg","https://about.gitlab.com/blog/quantifying-ux-positioning-of-the-clone-button","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Quantifying UX: Positioning the clone button\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matej Latin\"}],\n        \"datePublished\": \"2019-07-26\",\n      }",{"title":1586,"description":1587,"authors":1592,"heroImage":1588,"date":1593,"body":1594,"category":787,"tags":1595},[951],"2019-07-26","\nWe recently redesigned GitLab's project overview page in an effort to make it easier to read. We wanted\nto make it simple for users to understand what the project is about and to get a quick overview of\nits status and activity. We considered moving the clone button further down the page,\nbut decided to put a smaller version in the header instead. The logic behind this decision:\n*Things further down the page are harder to find.*\n\n![GitLab's project overview before the most recent redesign](https://about.gitlab.com/images/blogimages/clone-button-positioning/01.jpg){: .medium.center}\n\nThe original project overview page. Lack of structure and an unclear information architecture were\n  two major problems.\n  {: .note.text-center}\n\nWe know one of the main things users want to do on the project overview page is *clone the project*.\nWe were already changing the UI so we would hide both clone URLs (HTTPS and SSH) behind a\ndedicated “clone” button, but we were concerned that change would have a negative\nimpact on the discoverability of the cloning options.\n\n![Redesigned project overview page](https://about.gitlab.com/images/blogimages/clone-button-positioning/02.jpg){: .medium.center}\n\nThe redesigned project overview page that is currently live.\n{: .note.text-center}\n\nWe received some negative feedback after the change but nothing that was too serious. The feedback was mostly about\nhaving to make an additional click to get to what the user wants. We concluded\nit was a compromise we could live with.\n\n## Moving the clone button\n\nBut after a while, we started receiving more feedback and suggestions\nto [move the clone button down to the file tree control area](https://gitlab.com/gitlab-org/gitlab-ce/issues/60022).\nThe initial suggestion was made because the recent redesign of the project overview page made\nthe clone button completely disappear from the repository page. Removing it from\nthe file tree section in one place removed it from all occurrences of this UI pattern.\n\n![New position for the clone button](https://about.gitlab.com/images/blogimages/clone-button-positioning/03.jpg){: .medium.center}\n\nThe proposal suggested we move the clone button down to the file tree controls.\n{: .note.text-center}\n\nI remembered the negative feedback we received for our most recent change so I wanted to\nmake our decision with some research. I quickly created a [UsabilityHub](https://usabilityhub.com) click test\nthat would tell us if the discoverability of the button worsened by moving it further down the page. The test was\nsimple: show the new design and ask the participants one\nquestion – *Where would you click to copy (and sync) this repository to your local machine?*\nOur UX research team helped me shape the question so that it wasn’t leading (we couldn’t use\nthe word “clone”). We would also run a control test with the live design – the one where\nthe clone button is in the header – so that we could have a baseline for comparison.\n\n![The click test](https://about.gitlab.com/images/blogimages/clone-button-positioning/click-test.gif){: .medium.center}\n\nThis is what solving a click test looked like.\n{: .note.text-center}\n\nAs I was working on the test, I thought it was going to further validate the recent change where\nwe moved the clone button to the header. It makes sense: If a dark blue button is on the\ntop right on a page, it’s easier to notice than if it’s further down or possibly below the fold.\nBut then I remembered that other Git platforms (most notably GitHub) have the clone button in the same\nplace we were considering. The test went live and I had no idea what to expect. We soon collected\naround 40 answers to each of the two variations and we felt that was enough to draw conclusions.\n\nThe results were surprising.\n\n![The results of the test](https://about.gitlab.com/images/blogimages/clone-button-positioning/04.jpg){: .medium.center}\n\nThe results of the new design on the left and the current one on the right.\n{: .note.text-center}\n\n| Version | Correct answers | Time required |\n| ------- | ---- | --------------|\n| New | 98%    | 15s         |\n| Current | 84%    | 21s         |\n\nAlmost all participants (98%) answered correctly in the new design compared to 84% in the current design.\nAnd in the new design it took them six seconds less to answer – 15 seconds instead of 21. So this means it\nmakes sense to move the clone button to the file tree controls and reintroduce it on the repository page.\nIt’s a win-win. No compromises there. But what can we do when the repository of a project\nis empty? We show different information on that page when a repository is empty and the layout of\nthe page is slightly different too.\n\n## Cloning an empty repository\n\nSo we solved one part of the problem and now it was time to solve the other part. When the\nrepository of a project is empty we show instructions on how to use it.\nCloning instructions are included as well but there’s no button in the cloning instructions or\nanywhere close. So far we didn’t really need one as we had one in the header.\n\n![Current empty repository page layout](https://about.gitlab.com/images/blogimages/clone-button-positioning/05.jpg){: .medium.center}\n\nCurrent empty repository project overview page.\n{: .note.text-center}\n\nBut moving that button down to the file tree controls now meant we wouldn’t have a button in\nthe header anymore. This same scenario applies to the empty repository too! So what should we do? What\nwould happen if we completely removed it?\n\n![Empty repository page without the clone button](https://about.gitlab.com/images/blogimages/clone-button-positioning/06.jpg){: .medium.center}\n\nEmpty repository project overview page without the clone button. Will removing\n  it have a profoundly negative effect on user experience?\n  {: .note.text-center}\n\nThis was another question we could answer with a quick test. I created two variations of the\ntest – one with the button in the header (current design) and one without it (new design). We would\nshow one of the variations to a participant and ask: *Where would you find the\ninformation for copying (and syncing) this repository to your local machine?*\n\nYou’re probably thinking the result of this test should be obvious – the variation\nwith the button should win. We were thinking that too, but we wanted to see what the difference was.\nWe wanted to quantify it so we could make an informed decision. If the results were really\nbad, we would consider adding a clone button to the instructions area. This solution felt a bit\nodd so we wanted to make sure it was the right thing to do.\n\n![Results of the second test](https://about.gitlab.com/images/blogimages/clone-button-positioning/07.jpg){: .medium.center}\n\nResults of the new design (without the button) on the left and the current design (with the button)\n  on the right.\n  {: .note.text-center}\n\nAnd yes, the results were what we expected. Just over three-quarters of users (77%) answered\ncorrectly in the current design and it took them 16 seconds. Removing the button altogether meant\nonly 50% of users found the cloning information and it took them 37 seconds. That’s 21 seconds longer!\nWe concluded removing the button had a very negative impact on user experience so we decided\nto introduce a clone button in the instructions area.\n\n| Version | Correct answers | Time required |\n| ------- | ---- | --------------|\n| New | 50%    | 37s         |\n| Current | 77%    | 16s         |\n\n![New design for the empty repository page](https://about.gitlab.com/images/blogimages/clone-button-positioning/08.jpg){: .medium.center}\n\nIn the end, we decided to add the clone button on top of the instructions sections, where\n  all other buttons already are.\n  {: .note.text-center}\n\nThe solution is [currently being implemented by a member of our awesome\ncommunity](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/27754) and we’re looking forward\nto seeing this change live!\n\nRead my previous [Quantifying UX blog post about redesigning GitLab's settings pages](/blog/quantifying-ux-validating-the-redesign-of-gitlabs-settings-pages/).\n\nCover image by [David Travis](https://unsplash.com/@dtravisphd?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[876,682,9],{"slug":1597,"featured":6,"template":686},"quantifying-ux-positioning-of-the-clone-button","content:en-us:blog:quantifying-ux-positioning-of-the-clone-button.yml","Quantifying Ux Positioning Of The Clone Button","en-us/blog/quantifying-ux-positioning-of-the-clone-button.yml","en-us/blog/quantifying-ux-positioning-of-the-clone-button",{"_path":1603,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1604,"content":1610,"config":1615,"_id":1617,"_type":13,"title":1618,"_source":15,"_file":1619,"_stem":1620,"_extension":18},"/en-us/blog/quantifying-ux-validating-the-redesign-of-gitlabs-settings-pages",{"title":1605,"description":1606,"ogTitle":1605,"ogDescription":1606,"noIndex":6,"ogImage":1607,"ogUrl":1608,"ogSiteName":672,"ogType":673,"canonicalUrls":1608,"schema":1609},"Quantifying UX: How we validated the redesign of GitLab's settings pages","A GitLab senior UX designer shares how we determined whether a recent redesign improved the overall experience for users.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683361/Blog/Hero%20Images/user-testing-validating-redesign.jpg","https://about.gitlab.com/blog/quantifying-ux-validating-the-redesign-of-gitlabs-settings-pages","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Quantifying UX: How we validated the redesign of GitLab's settings pages\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matej Latin\"}],\n        \"datePublished\": \"2019-03-13\",\n      }",{"title":1605,"description":1606,"authors":1611,"heroImage":1607,"date":1612,"body":1613,"category":298,"tags":1614},[951],"2019-03-13","\nThere are three main settings pages in GitLab: group settings, project settings, and admin settings. Shortly after I joined GitLab, the group settings page was redesigned to match a recent change that was implemented for the project settings, to “tidy up” all content into expandable sections. The idea was well intended, because these settings pages can be extremely long, full of diverse content and forms, and they’re very hard to read. It’s also difficult to find information when everything is simply “out there.”\n\nThe group and project settings pages were both redesigned in a short amount of time. Both are critical to using GitLab, which means that many users engage with them. This is great, because when that’s the case, we get lots of feedback after introducing changes. Unfortunately, in this case, the feedback was negative. [Users began to tell us that it was even harder to find the setting](https://gitlab.com/gitlab-org/gitlab-ce/issues/41230) they needed after the change was introduced. Instead of scrolling through the page and scanning it for relevant content, they now had to expand the sections and look for it there. The labels of these sections weren’t descriptive, so they often had to resort to guessing.\n\n![GitLab's project settings page](https://about.gitlab.com/images/blogimages/validate-redesign/project-settings.jpg){: .large.center}\n\n## Improvements to the settings pages\n\nI came up with some somewhat basic changes that could lead to significant improvements. In the issue titled [Improve settings pages design by prioritizing content: Discovery](https://gitlab.com/gitlab-org/gitlab-ce/issues/47405) I suggested we:\n* Prioritize the content by following the 80/20 principle (what do most users look for on these pages?).\n* Improve the labels for the expandable sections by making them descriptive.\n* Make the titles clickable (instead of just having the “expand/collapse” button) and\n* Shift content around if needed.\n\nThe 80/20 principle, also known as the [Pareto principle](https://en.wikipedia.org/wiki/Pareto_principle), suggests that 80 percent of effects come from 20 percent of causes. Further research suggests that this principle can be commonly observed in pretty much anything. So, in our case, applying the principle means: Can we prioritize the 20 percent of content that 80 percent of users look for?\n\nThis meant that we needed to rethink the information architecture (IA) of the page. If we introduce a section with prioritized content, as suggested in the improvements above and illustrated below, could we take some of the content that is commonly searched for and move it into that section?\n\n![Project settings page redesign concept](https://about.gitlab.com/images/blogimages/validate-redesign/redesign-concept.jpg){: .large.center}\n\nSoon after the discovery issue in milestone 11.2, I came up with a redesign that would accomplish all of the above. We started with the Group settings because it’s the simplest settings page, with the least amount of content. It took us longer than originally anticipated to implement the changes, and we shipped in 11.5, a little under three months later.\n\n![Redesigned project settings page](https://about.gitlab.com/images/blogimages/validate-redesign/group-settings-redesigned.jpg){: .large.center}\n\n## Some thoughts on designers conducting their own UX research\n\nIdeally, I would have done some UX research/validation before implementation to see if the new designs are actually better. But in this case, the changes were mostly general best practices in terms of UI design and information architecture, so I was confident that they were all going to result in improvements.\n\nBut I wanted to quantify the results and confirm whether they were actually better, and if so, by how much? Confidence in design is good (and even required sometimes), but we should never replace measurement of results with it. Besides, the group settings redesign was a pilot: if all turned out well, we would redesign project settings and admin settings in a similar fashion, so I wanted to be 100 percent sure and ran the test.\n\nIn addition, the UX department at GitLab has been striving to get into a position where designers can conduct their own UX research. We want designers to conduct research in a quick way that allows them to get the results they need to move forward. This can be done with some guidance from the UX research department, but it is not necessary for them to always be 100 percent involved.\n\n### Why should designers do their own research?\n\nIn this particular example, the validation was done after the implementation of the redesign, but ideally, this type of research would be done before a single line of code was written. Even sooner, it can be done on the same day that the designer mocked up the UI solution. The greatest benefit of doing this is that it eliminates waiting and speeds up the cycle of feedback. A lot. Instead of waiting for weeks for something to get implemented, a designer creates a test by themselves, coordinates with UX research, get participants to solve the test, and analyzes the results – all in the same day.\n\n## How do we validate UI design and IA changes?\n\nIn this case, the redesign introduced mostly UI and information architecture (IA) changes. How do you test these kind of changes, especially when you work remotely? The answer is surprisingly simple: Create two “click tests” on [Usability Hub](https://usabilityhub.com/): One for the design of the page as it is now (original) and one for the redesign. Most users complained that they didn’t know which section contained the item they were looking for. This was the most important problem that needed to be solved, so I came up with a simple test: show the participants the design (either original or the redesign) and ask them questions which they answered by clicking on a design. For example, they would see the following (the redesign):\n\n![Redesign of settings pages](https://about.gitlab.com/images/blogimages/validate-redesign/test-redesign.jpg){: .medium.center}\n\nAnd they would answer the following questions:\n\n* Where do you think you can change who can see the details of this group?\n* Where do you think you can add an extra layer of security for signing in?\n* Where do you think you can change the URL of this group?\n\nEach of these three questions were followed up by two additional ones:\n\n* How easy/difficult was it to find?\n* How confident are you that the setting is in the section you selected?\n\n![Test redesign follow up](https://about.gitlab.com/images/blogimages/validate-redesign/test-redesign-followup.jpg){: .medium.center}\n\nThe participants responded with a rating of 1 to 5 for each of the follow-up questions. With the main questions, we measured the time required to answer (click) and whether the answer was correct or not. The follow-up questions helped us measure perceived difficulty and confidence.\n\n### Assumptions to validate\n\nWe wanted to validate the following assumptions:\n\n| Assumption | Validated/invalidated |\n| ------ | ------ |\n| Users will need less time to find the settings | ✅ / ❌   |\n| A greater number of users will click on the correct areas | ✅ / ❌  |\n| Users will be more confident in their section choices (new compared to old) | ✅ / ❌  |\n| The perceived difficulty of the tasks will improve | ✅ / ❌ |\n\nWe decided that if three out of four of those assumptions were validated we would consider the redesign a success. You can preview the tests at the following links (feel free to complete them, but they’re not collecting results anymore):\n* [Original](https://app.usabilityhub.com/preview/87c510cf7078)\n* [Redesign](https://app.usabilityhub.com/preview/fc581c732b7e)\n\n## Results\n\nWe shared our tests on Twitter and with [GitLab First Look](/community/gitlab-first-look/), our UX Research mailing list. We received more than 600 responses, and the results were evenly distributed between the original versus the redesign. The findings weren’t really surprising, but they validated our redesigns. We knew our work improved the experience of our users and we could now apply a similar approach to the other settings pages.\n\n| Version | Task | Time required | Correct answers | Confidence (mean)* | Perceived difficulty (mean)* |\n| ------- | ---- | --------------| ----------------|-------------------|-----------------------------|\n| Original| 1    | 19.4s         | 77%             | 3.6               | 2.1                         |\n| Redesign| 1    | 25.9s         | 78%             | 4.1               | 1.9                         |\n| Original| 2    | 14.6s         | 34%             | 3.2               | 2.4                         |\n| Redesign| 2    | 8.7s          | 97%             | 4.1               | 1.9                         |\n| Original| 3    | 6.4s          | 49%             | 3.9               | 1.9                         |\n| Redesign| 3    | 16.1s         | 92%             | 3.7               | 2.5                         |\n\n*Confidence: higher is better*\n\n*Perceived difficulty: lower is better*\n\n*I only counted the correct answers for confidence and perceived difficulty.\n\nOriginal test: 389 participants — [Results](https://app.usabilityhub.com/tests/87c510cf7078/results/e20614040355) \u003Cbr>\nRedesign test: 266 participants — [Results](https://app.usabilityhub.com/tests/fc581c732b7e/results/b016819adc5a)\n\n![Results heatmap](https://about.gitlab.com/images/blogimages/validate-redesign/results-heatmap.jpg){: .shadow.medium.center}\n\n*\u003Csmall>The heatmap feature in Usability Hub allowed us to see that the majority of users were clicking in the correct area, so they were finding what they were looking for.\u003C/small>*\n\nBy running such tests, we now have data that can help us quantify the user’s experience – in other words, we can measure the design’s impact. It took some users longer to find what they were looking for in the redesign, but their confidence in the correctness of their answer improved and the tasks were also perceived as less difficult.\n\nMost encouraging was the huge difference in how many respondents answered correctly compared to the original. We saw an increase from 34 to 97 percent in the second question and 49 to 92 percent in the third question, which proved that the redesign solves the problem that most users complained about: finding things.\n\nIf we look back to our assumptions, we validated three out of four, fulfilling the success criteria that we established at the start. The only assumption that wasn’t validated was that \"Users will need less time to find the settings.\" It took the participants longer to answer two out of the three questions.\n\n| Assumption | Validated/invalidated |\n| ------ | ------ |\n| Users will need less time to find the settings | ❌   |\n| A greater number of users will click on the correct areas | ✅  |\n| Users will be more confident in their section choices (new compared to old) | ✅  |\n| The perceived difficulty of the tasks will improve | ✅ |\n\n## What’s next?\n\nWe want to continue building on this success and improve all settings pages. Unfortunately, the project settings redesign did not make it into 11.7, but we are hopeful it will be included in one of the next few releases. We will then proceed to improve the other settings pages, as well as other improvements, such as [adding inline search](https://gitlab.com/gitlab-org/gitlab-ce/issues/50145). You can follow our progress through the [Improve and align settings pages UX](https://gitlab.com/groups/gitlab-org/-/epics/196) epic.\n\nAs we move forward, we want to do more of this kind of validation/research. We want to come to a place where designers have enough time and confidence in doing their own UX research and do it before implementation starts, in a single milestone, so we can keep moving fast and shipping more awesome things. If you have UX research skills and experience and want to work at GitLab, [check out our Careers page](/jobs/).\n\nYou can also read more about [how we conduct remote UX research at GitLab](/blog/conducting-remote-ux-research/).\n\nCover image by [Alvaro Reyes](https://unsplash.com/photos/qWwpHwip31M?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/user-test?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)",[876,682,9],{"slug":1616,"featured":6,"template":686},"quantifying-ux-validating-the-redesign-of-gitlabs-settings-pages","content:en-us:blog:quantifying-ux-validating-the-redesign-of-gitlabs-settings-pages.yml","Quantifying Ux Validating The Redesign Of Gitlabs Settings Pages","en-us/blog/quantifying-ux-validating-the-redesign-of-gitlabs-settings-pages.yml","en-us/blog/quantifying-ux-validating-the-redesign-of-gitlabs-settings-pages",{"_path":1622,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1623,"content":1629,"config":1634,"_id":1636,"_type":13,"title":1637,"_source":15,"_file":1638,"_stem":1639,"_extension":18},"/en-us/blog/redesigning-our-docs",{"title":1624,"description":1625,"ogTitle":1624,"ogDescription":1625,"noIndex":6,"ogImage":1626,"ogUrl":1627,"ogSiteName":672,"ogType":673,"canonicalUrls":1627,"schema":1628},"Redesigning the GitLab docs","We're working on improving our documentation site usability and discoverability. Check out what's changed and get a sneak peek at the refinements coming to docs.gitlab.com.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670050/Blog/Hero%20Images/homepage-cover-image.png","https://about.gitlab.com/blog/redesigning-our-docs","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Redesigning the GitLab docs\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Susan Tacker\"},{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2021-02-12\",\n      }",{"title":1624,"description":1625,"authors":1630,"heroImage":1626,"date":1274,"body":1632,"category":1155,"tags":1633},[1631,742],"Susan Tacker","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2021-03-03.\n{: .note .alert-info .text-center}\n\nFor a product like GitLab, great documentation isn’t just nice to have – it’s a must. \n\nAs a complete DevOps platform, GitLab brings a sprawling tooling ecosystem into a single experience so that teams can build software faster and with greater confidence. Part of our responsibility is to help users quickly understand how to complete standard tasks, while giving them insight into the larger possibilities of the product and which features they might take advantage of next.\n\nOver the past year, we’ve worked really hard to understand our docs experience. We started by assessing the sheer amount of content that’s available on [docs.gitlab.com](https://docs.gitlab.com/) (equal to two copies of \"War and Peace\"!) and then we began user research to discover how well that content meets our users’ needs.\n\n**Wow, did we learn a lot!** While 96% of participants thought our content was useful, research confirmed what we suspected: we have some problems with site usability and information discoverability. That was good news, because these things are fixable. In this blog post, you’ll learn more about what’s in process, what we’ve already addressed, and what we plan to do next.\n\n## What we’re working on now\n\nLet’s start by covering what we’re working on now, since these are nice refinements that we’re really excited about.\n\n### It’s always about the homepage\n\nA website’s homepage is where users first orient themselves and look for important information. And, frankly, our homepage just isn’t doing that job well. While we’ve made iterative improvements over the past year (we'll talk about those in a minute), we know it’s time for a major overhaul. That's why we’re so excited to see the improvements we’ve made in collaboration with senior product designer, [Jeremy Elder](/company/team/#jeldergl), come to fruition.\n\nHere's our current home page.\n\n![Current homepage](https://about.gitlab.com/images/blogimages/redesigning-our-docs/homepage-current.png){: .shadow.medium.center}\nCurrent homepage\n{: .note.text-center}\n\nOur [homepage redesign](https://gitlab.com/gitlab-org/gitlab-docs/-/issues/916) focuses on: \n\n- Helping users find what they need more quickly by elevating search and removing extraneous content to simplify the design\n- Highlighting key areas that users typically want to get started \n- Making installation instructions easy to find\n- Aligning the top navigation with accessibility guidelines\n\n![Homepage coming soon](https://about.gitlab.com/images/blogimages/redesigning-our-docs/homepage-coming-soon.png){: .shadow.medium.center}\nIn progress (better usability and visual appeal)\n{: .note.text-center}\n\n### Type scales matter\n\n> \"Sometimes I get emotional over fonts.\" - Kanye West\n\nIt’s OK, Kanye – we understand. Fonts make us emotional sometimes, too. Unfortunately, our current type scale makes us feel sad. :( \n\nHere's what it looks like now:\n\n![Type scale before](https://about.gitlab.com/images/blogimages/redesigning-our-docs/typescale-before.png){: .shadow.medium.center}\nCurrent type scale\n{: .note.text-center}\n\nHere's a peek at how we’re [updating it](https://gitlab.com/gitlab-org/gitlab/-/issues/300424#note_497435628) to be more modern, easier to scan, and better themed. \n\n![Type scale after](https://about.gitlab.com/images/blogimages/redesigning-our-docs/typescale-after.png){: .shadow.medium.center}\nComing soon!\n{: .note.text-center}\n\n## What we’ve already done\n\nAs mentioned before, we didn’t just start this refinement process – we’ve been making iterative changes for a while. Those changes aren’t as impactful as what we’re working on now, but they’re still worth mentioning.\n\n### Fixed our alert box madness\n\nAlert boxes, including notes, tips, and warnings, provide important information that we want you to know. That doesn’t mean they should be visually overwhelming. And when you overuse them, making it seem like everything is important, then nothing is.  (Confession time: One of our pages included 40 notes.)\n\nSo, we [reduced the number of “Notes”](https://gitlab.com/gitlab-org/technical-writing/-/issues/255) in our documentation by 25%, and we toned down the colors of notes, tips, and warnings to be less “in your face.” \n\n![Before and after of alert boxes](https://about.gitlab.com/images/blogimages/redesigning-our-docs/notecolor.png){: .shadow.medium.center}\nAlert box refinement\n{: .note.text-center}\n\n### Improved topic scanning with better use of fonts and white space\n\nGood use of fonts and white space can provide visual cues that help users more quickly identify related information. This is especially important for scanning large amounts of content.\n\nThe most egregious example of elements that needed to change was our headings.\n\n![Before headings](https://about.gitlab.com/images/blogimages/redesigning-our-docs/Headings1111.png){: .shadow.medium.center}\nEarlier version of headings\n{: .note.text-center}\n\nTo begin making improvements, we removed the borders from every heading level except H1, refined how we used margins, and made better use of font weight and size to distinguish levels H2 and smaller. Our headings will continue to improve in the type scale work we’re doing now, but in the spirit of early iteration, we didn’t let perfect be the enemy of better.\n\n![After headings](https://about.gitlab.com/images/blogimages/redesigning-our-docs/Headings1309.png){: .shadow.medium.center}\nCurrent version of headings\n{: .note.text-center}\n\nAlso, the leading in our bulleted lists (which appear frequently in technical docs) was… weird. Every line of text had equal spacing, making it difficult to see what information belonged together. There was too much space between the introductory sentence and the bullets that followed. \n\nNot anymore!\n\n![Refined bullets](https://about.gitlab.com/images/blogimages/redesigning-our-docs/bulletspacing.png){: .shadow.medium.center}\nFixed leading, margin, and enumeration\n{: .note.text-center}\n\n### Toned down visual noise of images\n\nWe also realized that our images were too visually pronounced. So, we removed drop shadows and reduced the size of the margins surrounding images.\n\n![Images are toned down](https://about.gitlab.com/images/blogimages/redesigning-our-docs/padding2.png){: .shadow.medium.center}\nRemoved drop shadow and reduced margin\n{: .note.text-center}\n\n## What’s up next\n\nWe’re excited about the improvements we’ve already made and what’s in process now, but there’s still more to do. Based on the same user research that guided our visual design enhancements, our [Documentation Roadmap](https://gitlab.com/groups/gitlab-org/-/epics/4602) includes back- and front-end changes to continue to improve the docs experience for the GitLab community. \n\nAs always, we value your feedback, so please continue to let us know how we’re doing!\n",[9,1097,682],{"slug":1635,"featured":6,"template":686},"redesigning-our-docs","content:en-us:blog:redesigning-our-docs.yml","Redesigning Our Docs","en-us/blog/redesigning-our-docs.yml","en-us/blog/redesigning-our-docs",{"_path":1641,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1642,"content":1648,"config":1653,"_id":1655,"_type":13,"title":1656,"_source":15,"_file":1657,"_stem":1658,"_extension":18},"/en-us/blog/remote-design-sprints",{"title":1643,"description":1644,"ogTitle":1643,"ogDescription":1644,"noIndex":6,"ogImage":1645,"ogUrl":1646,"ogSiteName":672,"ogType":673,"canonicalUrls":1646,"schema":1647},"How to facilitate remote design sprints","Use these tips to help solve big design problems with stakeholders across multiple time zones.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749683129/Blog/Hero%20Images/remotedesign.png","https://about.gitlab.com/blog/remote-design-sprints","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to facilitate remote design sprints\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily Bauman\"}],\n        \"datePublished\": \"2023-08-23\",\n      }",{"title":1643,"description":1644,"authors":1649,"heroImage":1645,"date":1650,"body":1651,"category":787,"tags":1652},[720],"2023-08-23","Recently, our research showed that our [Environments feature](https://about.gitlab.com/handbook/engineering/development/ops/deploy/environments/), which is part of the [Deploy stage](https://about.gitlab.com/direction/#devsecops-stages) of the software development lifecycle, was experiencing lower adoption rates and facing some usability challenges. Leaning on the evidence, [Viktor Nagy](https://gitlab.com/nagyv-gitlab), product manager for Environments, and I soon realized that we needed to look beyond a few small fixes and rethink our direction. We needed a design sprint. Below we share the process for creating your own remote design sprint.\n\n## What is a design sprint?\nDesign sprint is a term most people working in tech have heard in passing, but the meaning and purpose behind running one is often lost. A design sprint is a process for solving big problems through design, prototyping, and assessing ideas with customers. It's a method for developing a hypothesis, prototyping an idea, and testing it rapidly with as little investment as possible. Essentially, it's a great tool to align a team under a common goal, and answer the question: Are we on the right track to making a product that users will want to use?\n\nObvious benefits apart, why would a team want to spend the time going through this process? There are multiple selling points, but the main one is they help reduce time and money spent during the product lifecycle. A design sprint is a time-boxed way to get clear answers before investing in any development resources. It also brings the team together and gets everyone on the same page from the very beginning. This helps move the project forward even after the sprint concludes. \n\n## How we run remote design sprints\n[Jake Knapp](https://jakeknapp.com/sprint) created the design sprint process at Google in 2010, and during his time there he refined the process to be what it is today. Design sprints were originally designed to take place in person over five days, but over the past few years they have gone through continuous adjustments and refinements to adapt to remote practices. A more recent example being the four-day sprint we ran with the team.\n\n![](https://about.gitlab.com/images/blogimages/designsprint-diagram.png)\nDesign sprint diagram showing the four-day breakdown\n\nThe big question here is how do we go about developing a process for GitLab that works across time zones, runs partially asynchronously, and works remotely? \n\nDesign sprints were originally run in a conference room, with everyone together. If you needed an answer, the facilitator was right there at the front, able to answer questions or help with activities. Things get significantly more complicated when everyone is located on different continents. But with all this, we managed to figure out a successful process through a bit of trial and error, and some of the following tips will help anyone run a successful sprint in a remote setting. \n\n### 1. Thorough planning is the secret ingredient\nEven an in-person, fully synchronous design sprint requires preparation. In a well-planned design sprint, the process does most of the heavy lifting and gets you the right results in the end. So, when it comes to running a sprint that plays across time zones, remotely and asynchronously, the importance of planning increases tenfold. \n\nThe first thing a team needs to do before starting a design sprint is to answer some important questions:\n- What is the problem for the customer/user?\n- Why is it important for the business/technology?\n- What evidence do we have that this is a problem worth solving?\n- What research insights do we already have about the design problem?\n\nWith answers to all these questions, the team now has established goals and objectives to sprint towards. The clarity around this ensures everyone starts on the same page, and is working toward a common purpose.  \n\n### 2. Set the time expectations\nDesign sprints can be demanding in terms of the mental capacity and attention participants are required to dedicate to them. Advance capacity planning helps participants to be more present and engaged, and to bring their best ideas to the table. This is only possible if they account for the time required to spend on the sprint in advance. It also gives the facilitator a chance to answer any questions related to the sprint and set the expectations ahead of time.  \n\nPart of this includes understanding how the team's time zones can impact asynchronous activities. It is good to look into the following: \n- Review time zones and ensure sprint participants don't have to wake up too early or stay up too late. Sometimes this can be challenging and that's when leaning on the asynchronous aspect of communication is important. Tools like this [time zone converter](https://www.timeanddate.com/worldclock/converter.html) can help make this process easier.\n- Depending on how far time zones are spread, some people may finish their day hours before others even start. Therefore, a one-day window likely isn't enough of a time box for a task/activity. A practical window can span 48 hours in some cases, meaning each day of the design sprint could potentially take two days.\n- Ensure activities or announcements are assigned and communicated at the start of day in the earliest timezone. These are best shared both in Slack, and in the issue for the respective day. \n- Account for unforeseen reasons for participants' unavailability as there will always be aspects we cannot control. \n\n### Partnership is key\nRunning a design sprint is not a one-person job. To ensure smooth operation and get the best results, the product designer and product manager need to team up. A strong partnership between the two can make the process of planning and running a sprint less overwhelming. The split in responsibilities can look something like this:\n- Product can help define business and product goals, and reach out to users and team members to participate. \n- Design can help facilitate and plan the sprint, and guide ideation and prototyping. Design also can diligently plan for testing the concepts that come out of the sprint. \n\n### Tools and tips\nWith all the planning complete, the biggest task is to facilitate and guide the team through a sprint process. Running a sprint involves using various sets of tools for different activities to ensure everything runs smoothly. During the sprint with the Environments team we took advantage of the following:\n- GitLab issues to outline the activities and expectations for each day and serve as a single source of truth \n- Mural boards to collaborate on activities such as 'How Might We's', ideation, and prototyping\n- Zoom to meet synchronously, along with a Slack Channel for asynchronous updates\n- Google Drive to share files, such as the lightning talk recordings\n\nAs a facilitator, I also took advantage of GitLab's asynchronous culture to pre-record videos such as our Sprint Kickoff and Activity Walkthroughs so participants could go through these in their own time during each day.\n\n### Celebrate the wins\nOnce the sprint week has concluded and the team has landed on an experience or feature they want to move forward with, it's time to celebrate the wins! \n\nDesign sprints can be a lot of work, and it's great to look back on what all has been accomplished. Find ways to share those wins through team channels such as Slack and weekly meetings, or go even broader with blogs or social media posts. Who knows, this might also encourage other teams to test out the design sprint process as well!\n\n## Support at GitLab for design sprints\n[A remote design sprint](https://gitlab.com/groups/gitlab-org/ci-cd/deploy-stage/environments-group/-/epics/1) helped the Environments team to come together and make a contribution to solving a large problem. We were able to come out of the sprint with a clear concept to move forward with and a shared understanding around what the future of environments at GitLab could be. I was motivated to further document the resources that came out of this activity and make it accessible to the team. We landed on [a design sprint process](https://about.gitlab.com/handbook/product/ux/design-sprint/) that can be shared, re-used, and built upon by other designers. Not only were we able to solve something that fit what we had been looking for this whole time, but the team came together during the process and built it up together.",[682,9],{"slug":1654,"featured":6,"template":686},"remote-design-sprints","content:en-us:blog:remote-design-sprints.yml","Remote Design Sprints","en-us/blog/remote-design-sprints.yml","en-us/blog/remote-design-sprints",{"_path":1660,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1661,"content":1667,"config":1674,"_id":1676,"_type":13,"title":1677,"_source":15,"_file":1678,"_stem":1679,"_extension":18},"/en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab",{"title":1662,"description":1663,"ogTitle":1662,"ogDescription":1663,"noIndex":6,"ogImage":1664,"ogUrl":1665,"ogSiteName":672,"ogType":673,"canonicalUrls":1665,"schema":1666},"Synchronous collaboration as a remote designer at GitLab","Find out how GitLab Designers collaborate synchronously within an all-remote company!","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669715/Blog/Hero%20Images/synchronous-collaboration-as-a-remote-designer.jpg","https://about.gitlab.com/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Synchronous collaboration as a remote designer at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Alexis Ginsberg\"},{\"@type\":\"Person\",\"name\":\"Becka Lippert\"},{\"@type\":\"Person\",\"name\":\"Matej Latin\"},{\"@type\":\"Person\",\"name\":\"Holly Reynolds\"}],\n        \"datePublished\": \"2020-04-01\",\n      }",{"title":1662,"description":1663,"authors":1668,"heroImage":1664,"date":1671,"body":1672,"category":764,"tags":1673},[1669,1670,951,1312],"Alexis Ginsberg","Becka Lippert","2020-04-01","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nMany designers out there may find themselves new to the remote life within the past couple of months. This post just scratches the surface of how designers collaborate at Gitlab, and some ideas may work a bit differently in a post-COVID world, but hopefully you can find some inspiration for your day-to-day work. \n\nWorking as a designer at GitLab means being a Remote Designer with a capital R. GitLab has no “main” office. We have teammates working from their home office or coworking spaces all around the globe. Some of us don’t even have one home base, preferring to travel the world while working. \n\nAs designers at GitLab, we may not be able to physically get together near the Nespresso machine to chat about our days, or grab a conference room for a quick whiteboard session around the latest design challenge we are solving, but we still find ways to stay in sync. Are you thinking about NSYNC now? Good.\n\nFinding creative ways to collaborate synchronously with all teammates across GitLab is a worthy challenge to be solved, and we are always experimenting and iterating on the best ways to do this! We have found that [synchronous collaboration](/company/culture/all-remote/collaboration-and-whiteboarding/) has to be a bit more intentional, but if time and space is made for it, it can be just as––if not more––fun and productive! Here are some ways the GitLab design team has worked to create that space for synchronous collaboration...\n\n\n## 👯 Pair designers\n\nEvery six months or so, each individual designer is paired with another GitLab designer who is intentionally dedicated to a different[ stage group](https://about.gitlab.com/handbook/product/categories/). We are given the freedom to coordinate how we choose and can collaborate as much or as little as we feel comfortable with. The trend seems to be 30 minutes to an hour either each week or every other week. \n\n**_Alexis:_** I personally look forward to my weekly Zoom meeting with my pair, and we usually aim for an hour but sometimes go over time since we love chatting with each other. We have an agenda of items both of us hope to cover, but also make sure we have time to catch up as people and coworkers, which is especially important to me as a remote designer (sometimes you just want to show off your dog or talk about the latest Netflix show you are binging!).\n\nThe agenda items are usually split evenly between us so that we can dedicate half of the time to a design, research, or process challenge we are working through, and the other half giving feedback. We are encouraged to work in the tools we feel most productive in so sometimes we will be walking through a design in Sketch, Figma, Axure, Mural, or even a quick sketch on paper or iPad.\n\nAs our team grows larger, getting this time to really dive into the design challenges of another stage group is very important. It helps me focus on the holistic journey users have within GitLab, rather than just “my” specific corner of the product. Every designer at GitLab shines in their own way, and this is just another way for us to learn from each other! \n\n\n## ☕ Coffee chats, 1-1s with other designers, and stage specific syncs\n\nWe've already touched on the importance of remembering that although we are remote designers, we have the support of an entire team around the world. In no other place is this more apparent at GitLab than in coffee chats, one-on-one syncs, and syncs with stage specific teams. \n\n**_Alexis:_** We can opt in to random coffee chats with anyone at GitLab, but as a designer magic happens often when just chatting through challenges with other designers. Working remotely means more time to focus, and the formal process of asking to schedule time with others can sometimes feel like you are asking permission to steal focus time away from their day. If all designers agree to set aside time each week that is dedicated to chatting with each other, it helps take that guilty feeling out of the equation and feels more like an informal time to chat and explore designs (that \"turn around in your chair to chat with the coworker next to you\" feeling), rather than another faceless Google Calendar invite.\n\nWe do this in a few ways, either through recurring 1-1s with other designers (including the pair system), recurring small group syncs with other designers in our stage group, and somewhat larger recurring syncs with designers in our [section](https://about.gitlab.com/handbook/product/categories/#hierarchy). They are all useful and full of collaboration to varying degrees.\n\nThe smaller and more specific the syncs get, the more day-to-day-design and feedback-specific the collaboration gets, which is great, because designers in one product area need to be able to support each other frequently on related work. \n\nLarger syncs are perfect for getting a broader understanding of what other designers outside of your stage are up to and for aligning on broader GitLab Design priorities affecting our section.\n\n**_Becka:_** The larger syncs also help discover overlap that you may not know exists, such as similar challenges or new use cases for a component in the [design system](https://design.gitlab.com/).\n\n**_Matej:_** Based on my experience so far, having a recurring 1-1 call with other designers from my stage group can be even better than the option to do it spontaneously in an office environment. And that’s mostly because of how we do it. \n\nThese calls are always at the same time on the same day of the week. We have a Google Doc for the agenda, so we can prepare in advance. Often, when I work on something, I remember that my fellow designer from my group probably knows more about the topic, so I just open that agenda doc and add an item to it so that we talk about it the next time we meet. This way, I don’t interrupt them with Slack messages or ad-hoc calls. \n\nAll this combined, it leads to scheduled, time-boxed calls where participants are prepared in advance and everyone gets so much value out of it. We borrow ideas, prototypes, pieces of UI. We can go into details of why our teams are working on the things that they’re working on. If we relied solely on group status update calls we wouldn’t be able to do that. \n\nIt’s also a great way to socialize and build relationships with other designers, as we often talk about stuff that isn’t work related. We’ve only been doing this for two months in the [Growth](https://about.gitlab.com/handbook/product/categories/#growth-stage) group, but I've already saved hours of wasted time working on things others already did. I also got to know the designers much better, which makes collaboration easier, more likely, and also more enjoyable. \n\nWhen it comes down to it, we are all GitLab Designers and need to not only understand and empathize for each other's work, but also for each other as people who like each other and are working toward the same goals!\n\n\n## 🎬 UX Showcase and UX Weekly\n\nOur largest opportunities for synchronous collaboration are our UX Weekly meeting and the [UX Showcase](https://about.gitlab.com/handbook/product/ux/ux-department-workflow/ux-showcase/). These syncs aim to capture as many designers across time zones as possible, which is a great chance to interact with faces you may not see on your screen often.\n\n**_Alexis:_** Our team has grown substantially over the last year, so having a weekly time to catch up with each other at a department level has also grown more important. The UX Weekly is a time for any and all GitLab designers to discuss any updates they have made to Pajamas (our design system), process changes, OKRs, exciting ideas, or [workshops](https://about.gitlab.com/blog/async-sketching/) designers are tinkering on that they think may benefit others – basically any team updates in general. \n\nGrowth of our department (and GitLab as a whole) has also inspired us to find new ways to stay transparent and visible about the work we are doing. This promotes cross-team collaboration both inside and outside of design. \n\nEvery two weeks product designers are encouraged to dive deeply into problems they are solving at the [UX Showcase](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz), making sure to touch on things like business goals, customer goals, and constraints. Four stage groups present per session for fifteen minutes at a time, giving us an hour to highlight work we are excited about sharing broadly on [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A/videos) for anyone to watch! What we present and the format in which we share is not prescribed, so designers can get creative about how to use that fifteen minutes allotted to their stage group (or at least as creative as sharing a screen on Zoom will allow!).\n\nThe part of the UX Showcase I enjoy the most is understanding the journeys my fellow designers go through and what processes they find most beneficial when creating solutions alongside their teammates in Product and Engineering. I also love the Slacks I get from other GitLabbers after presenting, asking to learn more about the work I am doing because they have feedback or to collaborate on something they are working on that is similar. The most exciting pings I get are from coworkers I am unfamiliar with, because that means we are empowering everyone to learn about and contribute feedback to our user experience!\n\n\n## 🤝 Collaboration with Product Managers \n\nA strong relationship with our partners in Product Management is important for any designer, and this is no different even for those of us who don’t have to walk into an office every day. \n\n**_Alexis:_** One of my favorite weekly meetings is when my team’s product designers and product managers all get together in the middle of the week for a 45-minute sync on Zoom. The first item on our agenda is for each of us to go over our goal of the week. These goals can be very personal or something we are hoping to accomplish professionally that week. I personally really enjoy learning more about what my teammates hopes and dreams are, even if those hopes are just to finish the repairs on their guest bathroom (this seems to be a big priority on our team for some reason!).\n\nWe spend the rest of the time going over our agenda items, such as in-flight research, issues that need collaboration, questions that we need clarification on, and then the good ole’ board walking time (going through our Kanban board of open issues in the current milestone) where we see how prioritized work is going. Usually we don’t get to the last agenda item, because we are busy walking through a design together or collaborating on some research items in Mural. This is fine though, because we have other times set aside to talk about priorities, and this is something that is easy to do asynchronously as well.\n\nA recurring theme I hear from product managers is that working with designers is one of their favorite parts of their jobs, and that they would never want to lose that just because we aren’t co-located. Luckily for all of us, most designers at GitLab are now aligned to one group with one dedicated product manager, so we can really focus on making that working relationship great! \n\nMy product manager and I take an hour out of our busy schedules each week to hop on Zoom and sync up. We use our agenda (are you sensing a theme here?) as our guide to walk through priority design issues that require collaboration or scope clarification. I prefer to drop sketches and mocks into a Mural board that we share, so that I can share my screen and allow him to follow along and make comments as I walk through ideas. Sometimes he will even share sketches with me, which I will then add and build on. This time helps us collaborate and get to know each other outside of regular conversations in Slack and [issues](https://docs.gitlab.com/ee/user/project/issues/). \n\n\n## 💻 Collaboration with Engineering\n\nAnother very important relationship for product designers to nurture is with our friends in Engineering. Designers and engineers at GitLab usually work together asynchronously, often in issues or [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/). Many of the usual touchpoints between these teams - like stand up, retros, brainstorms, and reviews - are effortlessly asynchronous. Instead of distancing us as designers from the engineers we team up with, this just allows us to make the time we do set aside for synchronous work more focused and intentional. Sometimes we may even sneak in a board game or two.\n\n**_Alexis:_** My team has weekly syncs between designers and Engineering Managers to discuss ideas for experience improvements and gather feedback or known constraints around designs. Product managers will also join and help facilitate any pivots or tradeoffs we may need to make while walking through our planned priority work. We also have a larger meeting to discuss big picture updates or retro type items, like processes we think could improve our workflow. \n\nThese (at least) weekly syncs are important in keeping our teams running smoothly, but my favorite engineering syncs are the impromptu one-on-one review and pair sessions I have with teammates. If asynchronous reviews or ideation seem to be going back and forth for a long time, nothing is better for unblocking a teammate than a quick synchronous Zoom call. Usually, what starts with one of us being confused by something the other is working on ends up in us chatting on a call and learning from each other as we share our screens and work through tough challenges together. The best part of these is that if our time zones are very different, we get to say, “Go have some coffee and have a great morning!” and “Get out of the office and have a good night!” at the end of the same meeting.\n\n\n## 🔬 Collaborating with users and the UX Research team\n\nHaving a solid understanding of users and being able to empathize with their frustrations and desires is so important to us. In fact, we even have a team dedicated just to UX Research! As with most organizations, though, GitLab Product Designers also need to have a passion for research and will often wear that “research hat” themselves.\n\n**_Alexis:_** Conducting research as a remote designer has surprisingly not differed as much as I expected from my time as a designer working in an office. Usually we start everything with a synchronous kickoff chat between the person requesting research, the researcher, and anyone else interested in the research project to capture objectives. This is also documented more formally in an issue, so we can iterate together asynchronously and have a single source of truth to refer back to. The planning and scripting can either be done in GitLab itself, or in a Google Document where we collaborate asynchronously.\n\nPrototyping or setting up testing environments is done in GitLab or any tool we feel comfortable will be most effective for the user. We schedule time with participants and conduct the interviews themselves through Zoom, which is something many would be familiar with. Those who join the call take notes and chime in as needed. If anything, this may feel less intimidating to participants, as we are all just friendly faces in a small Zoom box,  rather than people staring at them in person. Many times, users will remark on something going on in our home office, and that acts as an icebreaker and takes pressure off of the situation (I always get comments on my yellow chair and terrible wall art for example).\n\nThe synthesis aspect of research is where things get interesting, although I would imagine organizations that aren’t remote are also catching on to some of the remote techniques I am about to describe. We take the insights captured in Google Docs and GitLab issues and map them out in Mural. These synchronous sessions in Mural help us feel like we are all together at a whiteboard doing some good old fashioned affinity mapping - even more so if we are all doing this on a Zoom call and chatting as we work. Add a few stakeholders to the call, and it is a remote research synthesis party!\n\n## ⚖️ Why synchronous vs asynchronous?\n\nThis post highlights and focuses on some of the ways the GitLab team collaborates synchronously across time zones and teams, but the flipside of this is asynchronous collaboration, which is how we Get Things Done™️ a majority of the time. It is even one of our [values](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication). There are of course pros and cons to each way of collaborating!\n\n**_Holly_**: One of the challenges of being a remote organization is that we all simply can’t be available at the same time. In addition to collaboration, inclusion is also one of our values. Asynchronous communication allows us to ensure that [everyone has a chance](https://handbook.gitlab.com/handbook/values/#bias-towards-asynchronous-communication) to have a say, regardless of their schedule or timezone. \n\nHowever, we recognize that asynchronous communication is not without its challenges. Because async conversations happen in a page or document rather than a real-time setting, they can slip off the radar of participants. This can result in a stall in productivity. We have to be intentional about managing conversations we want and need to be a part of. This may include using [To-Dos](https://docs.gitlab.com/ee/user/todos.html), tagging others when we need feedback, applying group labels, and assigning items to ourselves, so that we are notified when a change occurs.\n\nAsynchronous communication also gives everyone a chance to pause, reflect and respond to ideas proactively, rather than reactively. This is great, particularly for introverts such as myself, but can at times lead to overthinking in discussions. We strongly believe that everyone can contribute and should feel empowered to do so, but we also recognize the need to move the work forward. Some of the ways we manage this are through asking questions and seeking to understand one another’s views, but also setting timelines (as needed) and goals for what we want to accomplish within a certain time frame.\n\nFinally, asynchronous communication allows the history of our collaboration to be preserved. We’ve grown exponentially this past year in a very short period of time. With so many new faces and great ideas coming in, it’s more important than ever for us to be able to refer to the historical conversations surrounding why certain decisions have been made. This enables us to move forward with insights starting from the original idea all the way through to production.\n\nWith all of these great benefits, though, sometimes problems can be particularly complex and need a quick answer or require real-time visual collaboration. We have a rule that if a conversation goes back and forth asynchronously more than 3 times, we move to a synchronous conversation, usually in Zoom or Slack. We record as many of our meetings and video chats as possible, so that others can still have an opportunity to catch up and provide feedback. And we recognize that as human beings, we are social creatures. Sometimes we simply need to hear someone’s voice, see their body language to fully understand a situation, or to just have a human connection. In these cases, we embrace the benefits of synchronous communication.\n\nFor more details on how we collaborate remotely in general, feel free to add [this blog](https://about.gitlab.com/blog/designing-in-an-all-remote-company/) to your reading list!\n\n\n## 💡 Tips and things to keep in mind when meeting\n\nYou may have a friend of a friend who has a horror story about video calls with coworkers. Mishaps can happen to the best of us (especially those of us with cats), and we understand that at GitLab. Here are a few of the things we keep in mind to make synchronous collaboration as seamless an experience as possible:\n\n**_Becka_**: Keep an agenda! One of the coolest things about GitLab meetings is that there’s always an agenda attached, so you can see what will be covered. Anyone on the call is empowered and encouraged to add items to the agenda, whether it’s to draw attention to an issue, invite feedback, or discuss something process oriented as a group. We can always add “Read-only” items at the top if there are a lot of agenda items, if the discussion can take place asynchronously, or if it’s more of an FYI (“Thank you so much to Alexis for starting this awesome blog post [linked to doc] about remote work!”). \n\nHaving a meeting agenda completed in advance (and often elaborated upon during the meeting), lets attendees come prepared and gives everyone a chance to be heard. If you decide that the other agenda items are higher priority, you can always add yours to the bottom of the list and feel good knowing that if time runs up, it will automatically be moved up as higher priority in the following meeting. \n\nFinally, agenda items are a great place to revisit to-dos from weeks prior, to find links to issues that were discussed, and a great single source of truth for meeting notes that all can contribute to.\n\n**_Becka:_** Mute your mic when you aren’t speaking to avoid frustration and perhaps embarrassment. 👀\n\n**_Holly:_** Remote work can blur the lines between personal and professional, but we are all human and things just happen sometimes! If anything, this can create bonding moments.\n\n**_Alexis:_** Many of our [collaboration values](https://handbook.gitlab.com/handbook/values/#collaboration) are around being kind to each other. This can translate to video calls and collaborative workspaces, too! Build any sessions with easy collaboration in mind. Give each other space to respond, and listen to each other. Pause often to allow other people to chime in with thoughts or ideas without interruption. Read the room as you typically would in person. One thing that really helps with this is turning your camera on during meetings, so that others can see your face and read your body language. I know sometimes it is tempting to join with your camera off, but trust me - it helps!\n\nAnother way you can be kind to others is by scheduling meetings with a 5-minute buffer at the end. So, for example, instead of blocking 30 minutes of time with someone, schedule them for 25 minutes. There is nothing worse having back-to-back meetings without time for making coffee, taking a bio break, or just walking around and stretching (hopefully toward some place that has a snack you can bring with you to the next meeting). \n\n**_Matej:_** If you need to collaborate often with the same teammates, schedule your syncs as recurring in a consistent cadence and have an agenda. This allows participants to be intentional in advance about what they’d like to cover during that set time, so they can understand expectations and be prepared - which enables everyone to collaborate on more items!\n\n**_Alexis and Holly:_** Lean into the fact that most coworkers may only be seeing your upper half and anything behind you, and fill that space with your personality (we like to wear outrageously silly sweaters or put our favorite art behind us)! Dogs or family walking behind you or interacting with the camera to say hi to colleagues is not only accepted at GitLab but encouraged. Working outside of an office means that coworkers can get to know you outside of the office “version” of you, if that is something you feel comfortable with.\n\n\n## 🦊 How do you do remote?\n\nFeel free to ping us on Twitter at [@gitlab](https://twitter.com/gitlab?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor) with any remote synchronous collaboration tips and tricks in your toolbox that you think our team could learn from. See you in GitLab! \n\n###### [Alexis Ginsberg](https://gitlab.com/uhlexsis) (Chicago, IL, USA GMT-5), [Holly Reynolds](https://gitlab.com/hollyreynolds) (Roswell, Georgia, USA GMT-4), [Becka Lippert](https://gitlab.com/beckalippert) (Austin, TX, USA - and looking forward to working outside of the States when possible and responsible -  GMT-5), [Matej Latin](https://gitlab.com/matejlatin) (Ljubljana, Slovenia GMT+2)\n\nCover image by [Sincerely Media](https://unsplash.com/photos/ylveRpZ8L1s) on [Unsplash](https://www.unsplash.com)\n{: .note}\n",[9,682,725,683,811],{"slug":1675,"featured":6,"template":686},"synchronous-collaboration-as-a-remote-designer-at-gitlab","content:en-us:blog:synchronous-collaboration-as-a-remote-designer-at-gitlab.yml","Synchronous Collaboration As A Remote Designer At Gitlab","en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab.yml","en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab",{"_path":1681,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1682,"content":1688,"config":1694,"_id":1696,"_type":13,"title":1697,"_source":15,"_file":1698,"_stem":1699,"_extension":18},"/en-us/blog/the-evolution-of-ux-at-gitlab",{"title":1683,"description":1684,"ogTitle":1683,"ogDescription":1684,"noIndex":6,"ogImage":1685,"ogUrl":1686,"ogSiteName":672,"ogType":673,"canonicalUrls":1686,"schema":1687},"The Evolution of UX at GitLab","What did it look like to work in User Experience (UX) at GitLab over the last several years? Take a peek into our time machine.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679527/Blog/Hero%20Images/timeline.png","https://about.gitlab.com/blog/the-evolution-of-ux-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The Evolution of UX at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Austin Regnery\"}],\n        \"datePublished\": \"2021-05-04\",\n      }",{"title":1683,"description":1684,"authors":1689,"heroImage":1685,"date":1690,"body":1691,"category":764,"tags":1692},[1460],"2021-05-04","\n\nSince hiring our first designer at GitLab in 2014, there have been numerous milestones for the product and our organization. It's easy to get lost in the day-to-day and lose sight of the accomplishments that brought us to where we are today, so let's look back to remind ourselves of how far we've come.\n\nNielsen Norman Group breaks down the progression of UX Maturity into eight stages ([1-4](https://www.nngroup.com/articles/ux-maturity-stages-1-4/) & [5-8](https://www.nngroup.com/articles/ux-maturity-stages-5-8/)). This retrospective looks into our perception of how the UX department has evolved over the last several years. It is by no means a perfect evaluation, but it illustrates our journey thus far.\n\n## 2014-2016 (UX maturity stages 1-3)\n\nThe first designer at GitLab was hired in September of 2014, with the audacious goal to uplift the UI design of GitLab away from vanilla Bootstrap. With that came a more intensive demand on UX to bring cohesion to the incoming development changes. Working with a limited capacity was an expected growing pain and necessary for evolving the maturity of our UX at GitLab.\n\nIn mid-2016, the workload on UX did not slow down, as GitLab continued to emphasize improvement to the existing UI and new features. Our UX team grew from 1 to 6 people, including the hiring of our first UX manager and UX researcher. UX moved to the Engineering department to better align the two practices, focusing on speed of iteration. The team's growth brought some changes to our UI design tooling (moving from Antetype to Sketch).\n\n**Fun product milestones**\n- CI grew beyond jobs (back then \"builds\") into the [pipelines](https://about.gitlab.com/releases/2016/05/22/gitlab-8-8-released/)\n- [Review Apps](https://about.gitlab.com/blog/introducing-review-apps/) released\n- [Better empty states](https://about.gitlab.com/blog/gitlab-ux-update/) began to appear\n- We implemented our [first redesign of site navigation](https://about.gitlab.com/blog/navigation-redesign/)\n\n![Image of GitLab builds in 2016 compared to pipelines in 2021](https://about.gitlab.com/images/blogimages/ux-evolution/pipelines-side.png){: .shadow}\n\nBuilds in 2016 (left) vs pipelines in 2021 (right) \n{: .note.text-center}\n\n## 2017-2018 (UX maturity stages 4-5)\n\nEmphasis on setting the foundations for the future of UX at GitLab started to come into play, and the team grew to 12 people. We began documenting our personas, [why we use them](https://about.gitlab.com/blog/the-importance-of-ux-personas/), and insights from UX research in our handbook. [Category Maturity Scorecards](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/) established a mechanism to evaluate our UX. We took our first steps towards the [Pajamas Design System](https://design.gitlab.com/). We also made a shift to allow better cross-functional collaboration by [restructuring our organization into stage groups](https://about.gitlab.com/blog/configure-post/). These things helped keep the UX tightly integrated as GitLab began to expand to a more holistic DevOps solution.\n\n**Fun product milestones**\n- [Navigation overhauled again](https://about.gitlab.com/blog/unveiling-gitlabs-new-navigation/)\n- GitLab grew its product scope from Dev to [DevOps](https://about.gitlab.com/blog/from-dev-to-devops/)\n- Launched a research program, [GitLab First Look](https://about.gitlab.com/community/gitlab-first-look/), for invites to usability tests, user interviews, surveys, and more\n- [Custom illustrations and icons](/blog/illustrations-and-icons-on-gitlab-com/) started making their way into the product, replacing the FontAwesome icon library\n- [Color system](https://design.gitlab.com/product-foundations/colors) introduced, read more on [why we focused on colors](https://about.gitlab.com/blog/polishing-gitlabs-ui-a-new-color-system/)\n- [WebIDE](https://about.gitlab.com/blog/introducing-gitlab-s-integrated-development-environment/) reached [HackerNews #1](https://news.ycombinator.com/item?id=17321921)\n\n![Image of GitLab left navigation in (left) vs 2021 (right)](https://about.gitlab.com/images/blogimages/ux-evolution/nav-side-by-side.png){: .shadow}\n\nGitLab left navigation in 2016 (left) vs 2021 (right)\n{: .note.text-center}\n\n## 2019-2020 (UX maturity stages 6-7)\n\nThings started to boom as the UX department grew to nearly the 60 individuals that we have today. This growth brought our ratio of Product Designers to Product Managers closer to our goal of a balanced 1:1 ratio. Increasing the presence of UX made it possible to embed into cross-functional teams. Broader department changes helped support this scale by incorporating the design system into our quarterly Objectives and Key Results while also switching to more web app tooling (Figma and Mural). Expanding our tools created space to focus on UX debt, actionable insights, and our [System Usability Scale](https://about.gitlab.com/handbook/product/ux/performance-indicators/system-usability-scale/). Tech writing became a part of the UX department. We dedicated a team to the Pajamas Design System. The use of whiteboarding for collaboration became more of a common practice to solve complex problems. Additionally, [pairing designers](https://about.gitlab.com/blog/designing-in-an-all-remote-company/) helped support our all remote culture. \n\nWe also began to place a heavier emphasis on research, and it became much more critical in decision-making. For example, the introduction of [UX Scorecards](/handbook/product/ux/ux-scorecards/) helped quickly identify and prioritize usability issues and Product Designers started regularly conducting their own research. It was also valuable for us to invest in our user research tooling (Dovetail, Qualtrics, and UserTesting.com) for getting feedback from participants in unmoderated and moderated research sessions.\n\n**Fun product milestones**\n- Figma [plugin](https://www.figma.com/community/plugin/860845891704482356/GitLab) was shipped to tie Figma into the GitLab workflow\n- [Design Management](https://about.gitlab.com/releases/2019/08/22/gitlab-12-2-released/) added into GitLab Issues\n\n\n![Image of GitLab in 2015 vs 2021](https://about.gitlab.com/images/blogimages/ux-evolution/old-v-new.png){: .shadow}\n\nGitLab in 2015 (left) vs 2021 (right)\n{: .note.text-center}\n\n## Looking forward\n\nAs the demand for DevOps tooling has grown, GitLab has followed suit. GitLab used to look a lot different in many ways, but our UI is only the surface of the evolution of UX at GitLab. Our team continually is looking inwards for ways to improve and automate small bits of work. We don't try to conquer everything at once, instead embracing the spirit of iteration the best we can. We're still filling the gaps in our UX Maturity, but it is a journey that we will build together as we work towards the ever-elusive User-Driven corporation (Stage 8).\n\n> You can read more about [how we operate as a UX department](https://about.gitlab.com/handbook/product/ux/#how-we-work) in our handbook.\n\nA previous [UX Showcase presentation](https://docs.google.com/presentation/d/1TGwSz2ctX2uLEKEh0pCEwDPzX21WPt9amDBNFsjJI2g/edit#slide=id.g7f2750be29_0_0) inspired this blog. Check out the showcase on our Unfiltered YouTube Channel. Thank you for the great presentation Dimitrie Hoekstra ([GitLab](https://gitlab.com/dimitrieh), [Twitter](https://twitter.com/dimitrieh)).\n\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n    \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/97bcgynw_zY\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n\n\n",[682,9,1097,723,1693],"production",{"slug":1695,"featured":6,"template":686},"the-evolution-of-ux-at-gitlab","content:en-us:blog:the-evolution-of-ux-at-gitlab.yml","The Evolution Of Ux At Gitlab","en-us/blog/the-evolution-of-ux-at-gitlab.yml","en-us/blog/the-evolution-of-ux-at-gitlab",{"_path":1701,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1702,"content":1708,"config":1713,"_id":1715,"_type":13,"title":1716,"_source":15,"_file":1717,"_stem":1718,"_extension":18},"/en-us/blog/two-questions-we-ask-ux-designers-in-job-interviews",{"title":1703,"description":1704,"ogTitle":1703,"ogDescription":1704,"noIndex":6,"ogImage":1705,"ogUrl":1706,"ogSiteName":672,"ogType":673,"canonicalUrls":1706,"schema":1707},"2 Questions we ask UX designers in job interviews (and why)","UX designer interviews are quite simple at GitLab. There are no trick questions – but here are two 'basic' ones that tell us a lot about you.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678794/Blog/Hero%20Images/ux-interviews.jpg","https://about.gitlab.com/blog/two-questions-we-ask-ux-designers-in-job-interviews","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"2 Questions we ask UX designers in job interviews (and why)\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matej Latin\"}],\n        \"datePublished\": \"2018-10-25\",\n      }",{"title":1703,"description":1704,"authors":1709,"heroImage":1705,"date":1710,"body":1711,"category":298,"tags":1712},[951],"2018-10-25","\nAs of 2022, we have updated our internal interview process for Product Designers to include a consistent set of questions for every candidate at each phase of the process. This will help us create fairness and improve the quality of our evaluation process. The following questions are no longer part of our interview process. You can read about our [current hiring process in our Product Designer job family](https://handbook.gitlab.com/job-families/product/product-designer/#hiring-process). \n{: .alert .alert-info .note}\n\nWe won’t ask you how many golf balls fit in a bus or how many times a day a clock’s hands overlap – nothing like what Google became famous for. While there's some value in seeing how candidates react to curve-ball questions, they don't really add much to a 45-minute interview. We also won't ask you to attend an all-day session with a series of interviewers.\n\nI think the [hiring process](https://handbook.gitlab.com/job-families/product/product-designer/#hiring-process) at GitLab is way simpler and more efficient. A successful candidate has to go through four stages of interviewing before receiving an offer. Altogether, we spend around 2-3 hours with them, so we need to ask the right questions to be efficient.\n\nI'm so confident in the efficiency of these questions that I’m completely okay with sharing these publicly. What you answer matters less than how you answer them.\n\n## 1. Can you speak to the difference between information architecture, interaction design, usability, and user research?\n\nI was asked this when was interviewing for the Senior UX designer position at GitLab. I wasn’t expecting such a ‘basic’ question, but I immediately realized how ingenious it is.\n\nHere’s what’s so brilliant about it: We're testing if the candidate has solid foundations for being a UX designer. With enough experience, explaining these terms should be a piece of cake, whereas struggling can be a red flag. Even if a candidate doesn’t have a formal education, they should be able to provide descriptions with their own words and ideally throw in snippets from their past experience.\n\nWe don’t focus on the correctness of the answer so much as the body language and level of confidence the candidate shows when replying. Someone who’s not experienced in these UX basics can Google the terms before the interview and even prepare notes but we’ll pick that up. The lack of confidence will be obvious in their body language, their voice, and the words they use to describe the terms. Candidates who lack experience all tend to use similar, generic descriptions for these terms and seem to talk a lot, but don’t actually say much.\n\n> We don’t focus on the correctness of the answer so much as the body language and level of confidence the candidate shows when replying\n\n## 2. Pick an application you like/dislike and explain why.\n\nThis may seem like another basic question but it’s great for finding out what kind of a designer and person the candidate is. This is what we're looking for:\n\n### Passion\n\nWe’re interested in your opinion about the product as a designer, and we want to see if you talk about it with passion. If you love the product, the passion will be clear through the words you use to describe it and whether your eyes light up when you talk about it. The same applies for a product that you dislike: you should dislike it with passion.\n\nThis question tells us immediately if the candidate is passionate about being a designer or not. I’m often surprised at how many designers out there became designers only because it’s hip or well paid. These are not good reasons for becoming a designer – passion for creating things that improve people’s lives is.\n\n### Attention to detail\n\nWe want to see examples of candidates talking about small visual design and UI details; about seemingly insignificant but delightful UX solutions that can make a user’s day. The way a candidate talks about visual design gives us an insight into candidate’s skills in this area (what they notice, what they learn and how they use and adapt elements in their own work). We’re looking for well-rounded people who can cover the whole design process.\n\nIf they talk about things that aren’t good, we want to hear how they would improve them. Everyone can criticize; few can find good and feasible solutions. In most cases, I really don’t need to see the app that the candidate talks about. The way they describe it usually tells me enough to make a judgement. Good candidates describe things so well that I can imagine them without looking at the product.\n\n> Everyone can criticize; few can find good and feasible solutions\n\nCommunication in design work is key, so being able to accurately describe the problems or the delightful things in a product or an app is a good indicator of those skills.\n\n### User’s point of view\n\nAs a designer, you should always consider other users and how they experience things. This can be the crucial point of the interview. If you only describe the app from your point of view and based on your experience, it will be a potential red flag. You shouldn’t have to conduct user testing to imagine what other people could have problems with. For example: are certain UI elements or the font size really small? This could be a serious problem for older people or people with certain health conditions. Does the app behave consistently? If not, it could cause usability problems. These are the sorts of things that we want to hear our candidates talk about – empathy for users is key.\n\n### Bonus points\n\nI have to give bonus points to candidates that take the initiative and offer to share their screen or show me their phone to show me the app they talk about. The candidate is in a challenging moment, outside of their comfort zone, and it’s reassuring to see them take the initiative in such occasions.\n\n## Our interviews aren’t tricky\n\nIf you’re a passionate designer with an appropriate level of experience for the position, that will be clear from how you speak about design and how you think about user problems. I prefer to see passion and commitment to the design profession than a formal education and numerous years of experience in a non-challenging environment. We look for well-rounded and passionate people with a wide range of skills matching their experience. If you think you’re a good match, you’re welcome to [check out our careers page](/jobs/). We look forward to meeting you in our interviews. Good luck!\n\nCover image by [Kaleidico](https://unsplash.com/photos/26MJGnCM0Wc?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/search/photos/sketch?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[876,682,9,1117],{"slug":1714,"featured":6,"template":686},"two-questions-we-ask-ux-designers-in-job-interviews","content:en-us:blog:two-questions-we-ask-ux-designers-in-job-interviews.yml","Two Questions We Ask Ux Designers In Job Interviews","en-us/blog/two-questions-we-ask-ux-designers-in-job-interviews.yml","en-us/blog/two-questions-we-ask-ux-designers-in-job-interviews",{"_path":1720,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1721,"content":1727,"config":1733,"_id":1735,"_type":13,"title":1736,"_source":15,"_file":1737,"_stem":1738,"_extension":18},"/en-us/blog/using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts",{"title":1722,"description":1723,"ogTitle":1722,"ogDescription":1723,"noIndex":6,"ogImage":1724,"ogUrl":1725,"ogSiteName":672,"ogType":673,"canonicalUrls":1725,"schema":1726},"Using web components to encapsulate CSS and resolve design system conflicts","How we used web component technologies like the Shadow DOM to make it easy to incrementally adopt our new design system, Slippers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679537/Blog/Hero%20Images/slippers-sys.jpg","https://about.gitlab.com/blog/using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Using web components to encapsulate CSS and resolve design system conflicts\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Tyler Williams\"}],\n        \"datePublished\": \"2021-05-03\",\n      }",{"title":1722,"description":1723,"authors":1728,"heroImage":1724,"date":1730,"body":1731,"category":787,"tags":1732},[1729],"Tyler Williams","2021-05-03","\n\n## The goal: A new design for the GitLab blog\n\nIn March 2021, the [Digital Experience team](/handbook/marketing/digital-experience/) deployed a new and improved design for the GitLab blog. This design change affected more than 1,300 blog posts. It is the largest exercise to date for [our design system, Slippers](https://gitlab.com/gitlab-com/marketing/digital-experience/slippers-ui). It presented challenges due to the age and size of the GitLab blog. We wanted to live up to GitLab's [iteration value](https://handbook.gitlab.com/handbook/values/#iteration): \"Do the smallest thing possible and get it out as quickly as possible\".\n\n## The major challenge: Incrementally adopting a new design system with conflicting CSS\n\n[Slippers uses Tailwind CSS](https://gitlab-com.gitlab.io/marketing/inbound-marketing/slippers-ui/?path=/story/tailwind-css--page), which comes with its own set of base styles, called [Preflight](https://tailwindcss.com/docs/preflight). Preflight acts like normalizing styles (it's built on top of [modern-normalize](https://github.com/sindresorhus/modern-normalize)), which is useful for new projects, or projects making a full transition. In our case, Preflight is a hurdle because it has to work alongside our existing CSS.\n\nWe explored some out-of-the-box solutions, such as enabling the Tailwind [!important configuration](https://tailwindcss.com/docs/configuration#important), or using a [very specific selector strategy](https://tailwindcss.com/docs/configuration#selector-strategy).\n\nWe got very close to our desired outcome in both cases, but a problem remained:\n\nCritical legacy components required the old CSS. Those old styles were getting past `!important` and selector strategies because they applied to attributes we had not specified in our Tailwind utilities. Resolving those conflicts would take too much time and manual effort. We wanted a more [efficient](https://handbook.gitlab.com/handbook/values/#efficiency) solution, so we focused on two things: Identifying an ideal state for our CSS and finding a better CSS encapsulation. The goal was to prevent existing styles from affecting new components, and new styles from affecting old components.\n\n## The solution: CSS encapsulation with web components\n\n[Web component technologies](https://developer.mozilla.org/en-US/docs/Web/Web_Components) offered a compelling solution to the requirement that we use the old CSS. We used the [shadow DOM](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_shadow_DOM) to encapsulate CSS. [Templates and slots](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_templates_and_slots) allowed us to use existing HTML, ERB, and HAML templates. [Custom elements](https://developer.mozilla.org/en-US/docs/Web/Web_Components/Using_custom_elements) brought it all together.\n\nIn the [top-level blog template](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/sites/uncategorized/source/includes/cms/blog_post/slippers-blog-post.erb), we placed a [template tag for the blog post markup](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/77190/diffs#5667df8046398e47cb04d02fcc386420afc7ab57_35_28). The `template` tag is valid HTML – meaning our templating engine can process everything inside it. We can use `partial` tags and `yield` as expected and they become part of the template. The output below shows what that looks like (some classes omitted for brevity):\n\n```erb\n\u003Ctemplate id=\"slp-blog\">\n  \u003Cmain class=\"slpBlog\">\n    \u003Cheader class=\"slpBlog__header\">\n      \u003C%= partial \"includes/cms/blog_post/slp-blog-avatar\", locals: { author: author } %>\n      \u003C%= partial \"includes/cms/blog_post/slp-tags\" %>\n      \u003Chr/>\n    \u003C/header>\n    \u003Carticle class=\"slpBlog__article\">\n      \u003C% if current_page.data.image_title %>\n        \u003Cimg alt=\"\" src=\"\u003C%= current_page.data.image_title %>\" width=\"100%\"/>\n      \u003C% end %>\n      \u003C%= yield %>\n    \u003C/article>\n    \u003Caside class=\"slpBlog__aside\">\n      \u003C%= partial \"includes/cms/blog_post/slp-social-follow\" %>\n      \u003Cslot name=\"non-slippers-aside-items\">\u003C/slot>\n    \u003C/aside>\n    \u003Cfooter class=\"slpBlog__footer\">\n      \u003Chr/>\n      \u003C%= partial \"includes/cms/blog_post/slp-related-content\" %>\n      \u003Cslot name=\"non-slippers-footer-items\">\u003C/slot>\n      \u003Chr/>\n    \u003C/footer>\n  \u003C/main>\n\u003C/template>\n\u003Cscript src=\"/javascripts/slippers-blog.js\" type=\"text/javascript\">\u003C/script>\n```\n\nThe top-level template loads [`source/javascripts/slippers-blog.js`](https://gitlab.com/gitlab-com/www-gitlab-com/-/blob/master/source/javascripts/slippers-blog.js) inside the `body` of the document, which blocks rendering until the script finishes loading. `source/javascripts/slippers-blog.js` imports Slippers CSS as a variable [using webpack loader syntax](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/77190/diffs#5b5ceecb366e6e69e99e2bae290c68bae177fc17_0_2). With the CSS stored as a variable, we can inject it into the [custom element definition](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/77190/diffs#5b5ceecb366e6e69e99e2bae290c68bae177fc17_0_6).\n\nNext, we register `slp-blog` as a custom element. When the DOM parses the markup, it will either render the blog post template or, in the rare circumstance our JavaScript didn't load, it will fail. If it fails, we fall back to the [`yield` output in the light DOM](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/77190/diffs#5667df8046398e47cb04d02fcc386420afc7ab57_35_55) to make sure critical content is never lost. In these cases, our static site generator already rendered the template, so the images and text of the blog post remain accessible to the visitor.\n\nHere's what that JavaScript looks like:\n\n```js\nimport Vue from 'vue/dist/vue.min.js'\nimport Slippers from 'slippers-ui/dist/slippersComponents.common.js'\n\n// eslint-disable-next-line import/no-webpack-loader-syntax\nconst css = require(\"!raw-loader!sass-loader!../stylesheets/slippers.css.scss\").default;\n\n// Some event handlers and other requirements omitted for brevity\n\nexport function initializeSlippersWebComponent() {\n    if (window.customElements) {\n        customElements.define('slp-blog',\n            class extends HTMLElement {\n                constructor() {\n                    super();\n                    const template = document.getElementById('slp-blog').content;\n                    const shadowRoot = this.attachShadow({ mode: 'open' });\n                    shadowRoot.innerHTML = `\u003Cstyle>${css}\u003C/style>`;\n                    shadowRoot.appendChild(template.cloneNode(true));\n                }\n            });\n    }\n}\n```\n\nIf the script successfully loads, the light DOM content generated by our fallback `yield` statement is thrown away when the custom component is rendered. This is why we use an inline script tag beforehand - to avoid a [flash of unstyled content](https://en.wikipedia.org/wiki/Flash_of_unstyled_content#:~:text=A%20flash%20of%20unstyled%20content,before%20all%20information%20is%20retrieved.).\n\nFinally, we can use [slots to render non-Slippers items](https://gitlab.com/gitlab-com/www-gitlab-com/-/merge_requests/77190/diffs#5667df8046398e47cb04d02fcc386420afc7ab57_40_59). Slotted elements get CSS from the light DOM, so our preexisting [partials and other included templating](https://gitlab.com/gitlab-com/www-gitlab-com/-/tree/master/sites/uncategorized/source/includes/blog) will still work as expected.\n\nOur custom element and its slots look something like this:\n\n```erb\n\u003Cslp-blog>\n  \u003C%= yield %>\n  \u003Cdiv slot=\"non-slippers-aside-items\">\n    \u003C%= partial \"includes/newsletter-signup.html\" %>\n  \u003C/div>\n  \u003Cdiv slot=\"non-slippers-footer-items\">\n    \u003C% unless current_page.data.install_cta == false %>\n      \u003C%= partial \"includes/blog/try\" %>\n    \u003C% end %>\n    \u003C% if ci_environment? %>\n      \u003C%= partial \"includes/blog/comments\" %>\n    \u003C% end %>\n  \u003C/div>\n\u003C/slp-blog>\n```\n\n## Results: Rapid iteration with minimal tradeoffs\n\nOur solution has some tradeoffs:\n\n1. We added complexity to the build process for our blog posts.\n1. Web components have wide browser support, but that's only a recent development. The best practices around these tools are still being debated.\n1. Technically, we added client-side rendering to our statically generated site, meaning we're giving up some of the static site benefits to achieve our CSS encapsulation.\n\nThose tradeoffs are worth it in the end. We achieved near-perfect CSS encapsulation which allowed us to iterate on Slippers and ship the blog template efficiently. We have reasonable fallbacks in place to preserve critical content for people who can't or won't load JavaScript to read our posts. Web components are the future, and we're excited to use them responsibly.\n",[9,876],{"slug":1734,"featured":6,"template":686},"using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts","content:en-us:blog:using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts.yml","Using Web Components To Encapsulate Css And Resolve Design System Conflicts","en-us/blog/using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts.yml","en-us/blog/using-web-components-to-encapsulate-css-and-resolve-design-system-conflicts",{"_path":1740,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1741,"content":1747,"config":1752,"_id":1754,"_type":13,"title":1755,"_source":15,"_file":1756,"_stem":1757,"_extension":18},"/en-us/blog/why-do-gitlab-designers-contribute-to-the-codebase",{"title":1742,"description":1743,"ogTitle":1742,"ogDescription":1743,"noIndex":6,"ogImage":1744,"ogUrl":1745,"ogSiteName":672,"ogType":673,"canonicalUrls":1745,"schema":1746},"Why do GitLab designers contribute to the codebase?","This article is not another blog post about whether designers should code. Instead, it's the perspective of a GitLab designer learning to contribute.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679556/Blog/Hero%20Images/insights.png","https://about.gitlab.com/blog/why-do-gitlab-designers-contribute-to-the-codebase","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why do GitLab designers contribute to the codebase?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Austin Regnery\"}],\n        \"datePublished\": \"2021-03-17\",\n      }",{"title":1742,"description":1743,"authors":1748,"heroImage":1744,"date":1749,"body":1750,"category":764,"tags":1751},[1460],"2021-03-17","\n\n\n\nWorking with engineering in the past used to feel so foreign to me. I never truly understood all the complexities of collaborative software development, and in full transparency, I still don’t. However, using GitLab has taught me how to contribute to the success of our product. \n\n## We believe everyone can contribute\n\nAt GitLab, one of our [goals](https://about.gitlab.com/company/mission/#goals) is to ensure that everyone can contribute to GitLab the application and the company. To help share this working knowledge, everyone that works at GitLab must add themselves to the [team page](https://about.gitlab.com/company/team/). Conquering this development task can be daunting because there are new terms and lots of steps. However, our [documentation](https://about.gitlab.com/handbook/git-page-update/#12-add-yourself-to-the-team-page) does a great job of helping reduce the barrier of entry.\n\n## Develop shared empathy\n\nI never had access to the codebase in previous product teams because it was far too time-consuming to get a build environment configured on my computer. For GitLab, this is a requirement so that I can review changes before they go to production. During onboarding, I invested a decent amount of time setting up the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/master/README.md) (gdk) on my computer. It was a challenge, but now I know why getting developers up and running can be incredibly complex. I can even more greatly appreciate the [GitPod integration](https://docs.gitlab.com/ee/integration/gitpod.html), which does all the heavy lifting of setup for you in minutes.\n\n![GitPod + GitLab = Love](https://about.gitlab.com/images/blogimages/why-do-gitlab-designers-contribute-to-the-codebase/teaser-gitlab-gitpod.jpg)\nSource: [GitLab Support for Gitpod is Here](https://www.gitpod.io/blog/gitlab-support/) \n{: .note.text-center}\n\nOnce my setup was ready to go, I was able to jump in. When I started at GitLab there was a [quarterly goal](https://gitlab.com/groups/gitlab-org/-/epics/3914) to migrate our button components to the new front-end we were using. I migrated several buttons, but [the one I am most proud of](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/46990) required me to step into an area of GitLab I was completely unfamiliar with. I had to get a niche button to verify that my changes were correct, which required me to learn how to get [Terminal working in the GitLab WebIDE](https://docs.gitlab.com/ee/user/project/web_ide/#interactive-web-terminals-for-the-web-ide). Then, I reached out to other designers and team members to get my [runners](https://docs.gitlab.com/runner/) to function correctly. This helped me understand more complex areas of GitLab better than just reading the documentation. It is one thing to read about something, and a totally different beast to make something work yourself.\n\nThis idea of [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding) is something we uphold as a sub-value at GitLab. By using GitLab to contribute to GitLab the application and company, we put ourselves in our users’ shoes. If we don’t like something then we are that much more motivated to change it. \n\n## Diversify skill sets\n\nAs a designer, I want to have a functional understanding of the frontend framework I am designing within. Having the basics down allowed me to communicate expectations, minimize assumptions, and ask insightful questions. Working through the initial learning curve has helped me tremendously in the coming months for scoping designs and working alongside engineering. \n\nSometimes rather than just sending a mockup to my engineers, I’ll open a Merge Request to propose a change instead. For example, I could have asked them to update the border color of a table, but I discovered removing an extra CSS class would fix the problem; submitting that change was much faster than creating a mockup and chatting about it asynchronously.\n\nIt's much easier to get input from engineers if you are talking about something specific in the codebase, instead of something more nebulous like border colors. Engineers will have to dig into the codebase to reference what is there, so help save them a step if you can. Discussing an explicit change is actionable, which is why we say [everything starts with a merge request](https://about.gitlab.com/handbook/communication/start-with-a-merge-request).\n\n> ### \"It's much easier to get input from engineers if you are talking about something specific in the codebase.\"\n\nDoing smaller and simpler changes made me comfortable trying more complex ideas like [replacing label colors with common names](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/50393). Each merge request taught me something new. I learned more about keeping my code formatting clean, writing good commit messages, and how to resolve failing pipelines. All things that contributors to GitLab must learn at some point in time.\n\nAs I learn about the different nuances that come with various pages in GitLab, I rely less on asking questions because I can look them up myself. For example, it is not always visually identifiable in the GitLab UI if a page is coded in HAML or Vue. Before I suggest a change or even start designing in some cases, I look for these differences in the codebase. Touching HAML can be more complicated than working with the Vue components documented in Pajamas.\n\nFor User Research, I can use these small changes for [Short Tests](https://help.usertesting.com/hc/en-us/articles/360055473112-Short-Tests-Beta-) instead of using complex prototypes in Figma. Using research to drive decision-making can help reduce subjective bias for implementing an idea.\n\n![Comparing a change before and after in a Merge Request](https://about.gitlab.com/images/blogimages/why-do-gitlab-designers-contribute-to-the-codebase/before-after.png)\nTesting a live environment can be useful for validating changes - [View Merge Request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51753) \n{: .note.text-center}\n\nNot only can I make more informed design decisions, but I can also contribute ideas that others are excited about. I am actively working on two:\n\n- [Add UX reviewer/maintainer to Danger bot](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/51127)\n- [Add a shortcut for collapsible section markdown](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/54938)\n\nI started working on both ideas while I was between meetings, and I have continued to progress them along ad-hoc. It has been fun to see some of my ideas make it into GitLab, but I also have a nice collection of [scrapped ideas](https://gitlab.com/dashboard/merge_requests?scope=all&utf8=%E2%9C%93&state=closed&author_username=aregnery).\n\n## Conclusion\n\nI have already come a long way from making my first Merge Request at GitLab. I thought I knew the basics of git, but going through this process helped me get my feet wet with more complex development and working in a single repository. I learned about having others review and approve my changes, the magic of seeing checkmarks for all pipelines, and finally, the Merge Request badge turning from Open to Merged.\n\nIf you are interested in learning how I create small merge requests, then watch this walkthrough of my process.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n    \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/PnxHQGpFD1w\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n",[682,9,723,811,1417],{"slug":1753,"featured":6,"template":686},"why-do-gitlab-designers-contribute-to-the-codebase","content:en-us:blog:why-do-gitlab-designers-contribute-to-the-codebase.yml","Why Do Gitlab Designers Contribute To The Codebase","en-us/blog/why-do-gitlab-designers-contribute-to-the-codebase.yml","en-us/blog/why-do-gitlab-designers-contribute-to-the-codebase",{"_path":1759,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1760,"content":1766,"config":1772,"_id":1774,"_type":13,"title":1775,"_source":15,"_file":1776,"_stem":1777,"_extension":18},"/en-us/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team",{"title":1761,"description":1762,"ogTitle":1761,"ogDescription":1762,"noIndex":6,"ogImage":1763,"ogUrl":1764,"ogSiteName":672,"ogType":673,"canonicalUrls":1764,"schema":1765},"Why GitLab is the right design collaboration tool for the entire team","Design collaboration in GitLab creates a single source of truth and makes product teams more efficient","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681792/Blog/Hero%20Images/train-station.jpg","https://about.gitlab.com/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why GitLab is the right design collaboration tool for the entire team\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matthew Nearents\"}],\n        \"datePublished\": \"2020-11-30\",\n      }",{"title":1761,"description":1762,"authors":1767,"heroImage":1763,"date":1769,"body":1770,"category":764,"tags":1771},[1768],"Matthew Nearents","2020-11-30","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\u003C!-- Intro -->\n\nAs designers, the combination of design and handoff tools in our tool belt often fail to enable the rest of the product team to collaborate efficiently. These tools can also lack integration with the [DevOps tools](/topics/devops/) the developers and product managers use for issue tracking, code reviews, and implementation reviews. Any efficiency we perceive in our handoff toolsets is probably due to habituation and individual familiarity.\n\nIn the early 1900s, the Canfranc International Railway Station was built to spur trade and travel between Spain and France. However, the railway had one major flaw: the difference in rail gauge used by the French and Spanish made it impossible for a train to pass through the station. Travelers and all of their cargo had to be unloaded and transferred to a new train in order to continue the journey. It was a painfully slow process for everyone involved. The station never became profitable and was closed shortly after opening.\n\nI love this metaphor because on one hand the passengers could travel successfully from one country to the other. But on the other hand, the trip was very inefficient and lengthy. In a similar vein, our design handoff tools are much like the railway with its different rail gauges: we can force them to function together successfully, but they fail at creating efficient workflows.\n\n### Multiple sources of truth creates confusion\n\nDesign and handoff tools have improved dramatically in recent years — both in the UI and features — but a good workflow is more than an impressive set of tools. These tools fall short by creating new sources of truth: additional places to find assets, code, and conversations, which in turn forces us to adopt even more tools to integrate them together such as chat, email, kanban boards, and wikis. Let’s look at an example:\n\n- A designer creates a wireframe in Sketch.\n- The design is posted to InVision. \n- The InVision link is posted in Slack to make the team aware of the wireframe. \n- The developers go to InVision and have conversations about the designs.\n- Meanwhile, other conversations are happening in DevOps tools.\n- Decisions in meetings are also being documented in a wiki.\n- Other random conversations are also happening via email.\n \n![A diagram showing the inefficiency of design collaboration without GitLab](https://about.gitlab.com/images/blogimages/2020-design-management-gitlab/diagram1.jpg){: .shadow}\nAn example flow using a disparate set of collaboration tools.\n{: .note.text-center}\n\nThe problem with multiple sources of truth is it’s almost impossible to piece together the history of a design. If the final deliverable fails to meet client or stakeholder expectations, it’s tough to know what caused the departure. Because conversations are happening in several different places, the evolution of that feature is muddled and results in conflicts and confusion about who was responsible for each decision. Some teams have adopted additional tools to maintain decision logs as a band-aid solution for this problem.\n\nWith all the commotion, incorporating feedback accurately and completely into a design becomes extremely tedious. The multiple sources of truth usually present incompatible information creating a complex web of confusion. Nobody enjoys the embarrassment of presenting a design to stakeholders or executives that lacks the feedback a team promised to incorporate. It makes teams look incompetent. But really they’re just victims of bad processes.\n\nSo what’s the solution to this problem? Abandon these disparate tools and move your designs to GitLab. GitLab believes [Design should be part of the DevOps lifecycle](/blog/is-devops-for-designers/), not separate from it, and handles everything post-Figma or Sketch. This creates a single source of truth with a set of handoff and collaboration tools teams are familiar with. Your toolset can be much smaller, creating efficiency and saving time, training, and money.\n\n### Design collaboration in GitLab\n\nIn GitLab, teams do the majority of their work in [issues](https://docs.gitlab.com/ee/user/project/issues/). Issues are like tickets or stories, and have multiple purposes, from getting down a rough idea before you forget, to spec’ing out fully fledged features, to reporting bugs and everything in between. With GitLab’s Figma and Sketch plugins, anyone can instantly upload designs, diagrams, or basically anything straight to a specific issue. That way, conversations about the design happen in the same issue where the whole team is discussing implementation. When a design is uploaded to an issue, the team will automatically be notified. No need to paste a link in Slack or email.\n\nAdditionally, when developers propose changes to the code, through GitLab’s [merge request](https://docs.gitlab.com/ee/user/project/merge_requests/) feature, [designers will be able to post the relevant designs directly to the merge request](https://gitlab.com/gitlab-org/gitlab/-/issues/281055), with a link back to the original issue. Using the merge request, designers can compare their designs to the implemented code since merge requests often generate [review apps](https://docs.gitlab.com/ee/ci/review_apps/) - a test environment where you can preview coded features without having to configure an environment yourself.\n\n![A diagram showing the efficiency of design collaboration with GitLab](https://about.gitlab.com/images/blogimages/2020-design-management-gitlab/diagram2.jpg){: .shadow}\nAn example workflow using Figma (or Sketch) and GitLab.\n{: .note.text-center}\n\n### A single source of truth For the entire team\n\nTeams are much more efficient when everyone can work within the same tool at the same time throughout the entire process to produce a single source of truth. So, although GitLab can be a little intimidating for a designer at first, having a single source of truth means no more lost feedback or decision juggling acts. Everyone is on the same page and teams can focus less on process and more on building great products.\n\nWe’re constantly working to make GitLab easier, more appealing and more fun for teams to use. The best way to move GitLab in the right direction is to use it and give feedback. GitLab is eager to hear from its customers. So although the individual pieces of GitLab might not look as attractive as InVision or Zeplin, when they come together teams can work efficiently, decisions can be more easily tracked, and our customers enjoy better products because of it.\n\nSo what are you waiting for? [Sign in](https://gitlab.com/users/sign_in) to your GitLab account or [create a new one](https://gitlab.com/users/sign_up). Also, download our [Figma](https://www.figma.com/community/plugin/860845891704482356/GitLab) or [Sketch](https://gitlab.com/gitlab-org/gitlab-sketch-plugin) plugins to start uploading your designs to GitLab. \n\nRelevant links\n- [Figma Plugin Installation Video](https://youtu.be/KR2nuehGtrU)\n- [GitLab Figma Plugin Epic](https://gitlab.com/groups/gitlab-org/-/epics/3449)\n- [Design Management Documentation](https://docs.gitlab.com/ee/user/project/issues/design_management.html)\n- [Category Direction Page](/direction/plan/design_management/)\n\n\u003C!-- image: https://unsplash.com/photos/dmH3NWhYTHQ -->\n\nCover image by [Michał Parzuchowski](https://unsplash.com/@mparzuchowski?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/train-station?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[811,9,682],{"slug":1773,"featured":6,"template":686},"why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team","content:en-us:blog:why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team.yml","Why Gitlab Is The Right Design Collaboration Tool For The Whole Team","en-us/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team.yml","en-us/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team",{"_path":1779,"_dir":243,"_draft":6,"_partial":6,"_locale":7,"seo":1780,"content":1786,"config":1792,"_id":1794,"_type":13,"title":1795,"_source":15,"_file":1796,"_stem":1797,"_extension":18},"/en-us/blog/async-sketching",{"title":1781,"description":1782,"ogTitle":1781,"ogDescription":1782,"noIndex":6,"ogImage":1783,"ogUrl":1784,"ogSiteName":672,"ogType":673,"canonicalUrls":1784,"schema":1785},"Running an Asynchronous Sketch Workshop for UX","How to generate ideas with team members in multiple time zones","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749669734/Blog/Hero%20Images/sketch-cover.jpg","https://about.gitlab.com/blog/async-sketching","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Running an Asynchronous Sketch Workshop for UX\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jacki Bauer\"},{\"@type\":\"Person\",\"name\":\"Inchul Yoo, Sunjung Park\"}],\n        \"datePublished\": \"2020-03-27\",\n      }",{"title":1781,"description":1782,"authors":1787,"heroImage":1783,"date":1235,"body":1790,"category":764,"tags":1791},[1788,1789],"Jacki Bauer","Inchul Yoo, Sunjung Park","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\nMany companies that normally work together in person have been suddenly thrust into an all-remote world. That can be scary for anyone, but especially for UX designers who rely heavily on face-to-face collaboration with their cross-functional peers.\n\nIf you’re in this situation, you may be thinking: How can I ideate without a whiteboard? How do I lead my team through sketching exercises without paper? WHAT DO I DO WITH ALL OF MY SHARPIES AND STICKY NOTES?!\n\nAt GitLab, our entire company is all remote and globally distributed. We’re used to finding ways to sketch, think and brainstorm asynchronously, so we can accommodate team members who live in time zones all over the world.\n\nYou need just a few ingredients.\n## Clear, simple guidelines and instructions\nGuidelines are really important in any design thinking activity, but when you’re asynchronous, they become extra important, because participants can’t ask clarifying questions or observe what others are doing. So it’s the designer’s role to communicate the activity’s purpose and goal, along with clear instructions and a sense of psychological safety. \n\nAnd just like with in-person activities, you also might want to provide timing advice. For example, consider how you want an individual's ideas to influence others. You might want to give everyone a day to ideate and then ask everyone to drop in their ideas at the same time, so they don’t inadvertently influence each other. Or, you might ask people to intentionally play off the ideas of others. It’s ultimately up your judgement about the goals of the session.\n\n\n## Shared understanding of context\nThe team should already understand some basics about the product or context they work in and the audience they are designing for. If you’re working with a newly formed team, you might try a couple synchronous workshops to get everyone on the same page.\n\n\n## A place for everyone to contribute their ideas\nThis one is easy. There are a lot of tools you can use, including Mural, Google Drive, or even \nSlack. At GitLab, we use Mural, and we also work within our own product to run collaborative design sessions. \n\nAll you need is a place where team members can quickly and easily add text, photos of sketches, images, or even videos, and then freely discuss them. To encourage creativity, you’ll likely want to pick a tool that offers flexibility. \u2028\u2028\u2028\n\n![Illustration of a sketch and chat windows](https://about.gitlab.com/images/blogimages/sketching-session.jpg){: .shadow.medium.center}\n\n## Facilitate team communication\nWhen a team meets in person, they get a lot of non-verbal feedback that can be really useful. People might smile at each other, nod when they hear a good idea, or sigh when someone suggests something that won’t work.\n\nIt’s important to offer a way to surface these reactions when you can’t use immediate nonverbal communication. As the team shares their ideas, provide supportive comments (that will encourage others to do the same). You might also use emojis to enhance communication.\n\n## Step just a little outside your comfort zone\nThis last one is important in any kind of design thinking environment. If you’re a designer working with a product or a client team, it’s likely that many (or most) of the participants in your sessions are not designers. Some participants might hate drawing, and some might be terrified of the idea of uploading something they drew to the internet. \n\nThis is where it helps to work with a team that has already established some rapport. As the designer and session leader, it’s also your job to set a relaxed and casual tone and a low bar for participation. \n\nAt GitLab we say “Everyone can contribute,” and we value action and results over perfection. Let people know it’s OK to not be perfect. As an example, this is how one designer at GitLab set the rules for her team sketching session:\n\n**Rules for the game**\n*  This is a 10-minute activity in total. You don't have to spend more than 5 minutes for each round.\n*  Let's not think about layouts such as the top-header, GitLab logo, and left menu.\n*  There are no right or wrong answers.\n*  It doesn't have to be beautiful. (You will be surprised to see how ugly mine is.)\n*  For round 2, you don't need to fill in all the blanks if it is hard for you. It's not an exam. :-)\n\nTo see this method in action, you can read through this [issue](https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/4944) from February 2020. Believe it or not, this team was doing this exercise for the first time!\n\nCover image by [Mounzer Awad](https://unsplash.com/@mounzaw_) on [Unsplash](https://unsplash.com/s/photos/sketching)\n{: .note}\n\n",[811,9,683,725,682],{"slug":1793,"featured":6,"template":686},"async-sketching","content:en-us:blog:async-sketching.yml","Async Sketching","en-us/blog/async-sketching.yml","en-us/blog/async-sketching",7,[665,691,710,732,752,774,795,818,839],1753981632617]