[{"data":1,"prerenderedAt":2109},["ShallowReactive",2],{"/en-us/blog/tags/ux/":3,"navigation-en-us":20,"banner-en-us":450,"footer-en-us":467,"UX-tag-page-en-us":677},{"_path":4,"_dir":5,"_draft":6,"_partial":6,"_locale":7,"content":8,"config":11,"_id":13,"_type":14,"title":15,"_source":16,"_file":17,"_stem":18,"_extension":19},"/en-us/blog/tags/ux","tags",false,"",{"tag":9,"tagSlug":10},"UX","ux",{"template":12},"BlogTag","content:en-us:blog:tags:ux.yml","yaml","Ux","content","en-us/blog/tags/ux.yml","en-us/blog/tags/ux","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":446,"_type":14,"title":447,"_source":16,"_file":448,"_stem":449,"_extension":19},"/shared/en-us/main-navigation","en-us",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":377,"minimal":408,"duo":427,"pricingDeployment":436},{"config":25},{"href":26,"dataGaName":27,"dataGaLocation":28},"/","gitlab logo","header",{"text":30,"config":31},"Get free trial",{"href":32,"dataGaName":33,"dataGaLocation":28},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com&glm_content=default-saas-trial/","free trial",{"text":35,"config":36},"Talk to sales",{"href":37,"dataGaName":38,"dataGaLocation":28},"/sales/","sales",{"text":40,"config":41},"Sign in",{"href":42,"dataGaName":43,"dataGaLocation":28},"https://gitlab.com/users/sign_in/","sign in",[45,89,187,192,298,358],{"text":46,"config":47,"cards":49,"footer":72},"Platform",{"dataNavLevelOne":48},"platform",[50,56,64],{"title":46,"description":51,"link":52},"The most comprehensive AI-powered DevSecOps Platform",{"text":53,"config":54},"Explore our Platform",{"href":55,"dataGaName":48,"dataGaLocation":28},"/platform/",{"title":57,"description":58,"link":59},"GitLab Duo (AI)","Build software faster with AI at every stage of development",{"text":60,"config":61},"Meet GitLab Duo",{"href":62,"dataGaName":63,"dataGaLocation":28},"/gitlab-duo/","gitlab duo ai",{"title":65,"description":66,"link":67},"Why GitLab","10 reasons why Enterprises choose GitLab",{"text":68,"config":69},"Learn more",{"href":70,"dataGaName":71,"dataGaLocation":28},"/why-gitlab/","why gitlab",{"title":73,"items":74},"Get started with",[75,80,85],{"text":76,"config":77},"Platform Engineering",{"href":78,"dataGaName":79,"dataGaLocation":28},"/solutions/platform-engineering/","platform engineering",{"text":81,"config":82},"Developer Experience",{"href":83,"dataGaName":84,"dataGaLocation":28},"/developer-experience/","Developer experience",{"text":86,"config":87},"MLOps",{"href":88,"dataGaName":86,"dataGaLocation":28},"/topics/devops/the-role-of-ai-in-devops/",{"text":90,"left":91,"config":92,"link":94,"lists":98,"footer":169},"Product",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/solutions/",[99,124,148],{"title":100,"description":101,"link":102,"items":107},"Automation","CI/CD and automation to accelerate deployment",{"config":103},{"icon":104,"href":105,"dataGaName":106,"dataGaLocation":28},"AutomatedCodeAlt","/solutions/delivery-automation/","automated software delivery",[108,112,116,120],{"text":109,"config":110},"CI/CD",{"href":111,"dataGaLocation":28,"dataGaName":109},"/solutions/continuous-integration/",{"text":113,"config":114},"AI-Assisted Development",{"href":62,"dataGaLocation":28,"dataGaName":115},"AI assisted development",{"text":117,"config":118},"Source Code Management",{"href":119,"dataGaLocation":28,"dataGaName":117},"/solutions/source-code-management/",{"text":121,"config":122},"Automated Software Delivery",{"href":105,"dataGaLocation":28,"dataGaName":123},"Automated software delivery",{"title":125,"description":126,"link":127,"items":132},"Security","Deliver code faster without compromising security",{"config":128},{"href":129,"dataGaName":130,"dataGaLocation":28,"icon":131},"/solutions/security-compliance/","security and compliance","ShieldCheckLight",[133,138,143],{"text":134,"config":135},"Application Security Testing",{"href":136,"dataGaName":137,"dataGaLocation":28},"/solutions/application-security-testing/","Application security testing",{"text":139,"config":140},"Software Supply Chain Security",{"href":141,"dataGaLocation":28,"dataGaName":142},"/solutions/supply-chain/","Software supply chain security",{"text":144,"config":145},"Software Compliance",{"href":146,"dataGaName":147,"dataGaLocation":28},"/solutions/software-compliance/","software compliance",{"title":149,"link":150,"items":155},"Measurement",{"config":151},{"icon":152,"href":153,"dataGaName":154,"dataGaLocation":28},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[156,160,164],{"text":157,"config":158},"Visibility & Measurement",{"href":153,"dataGaLocation":28,"dataGaName":159},"Visibility and Measurement",{"text":161,"config":162},"Value Stream Management",{"href":163,"dataGaLocation":28,"dataGaName":161},"/solutions/value-stream-management/",{"text":165,"config":166},"Analytics & Insights",{"href":167,"dataGaLocation":28,"dataGaName":168},"/solutions/analytics-and-insights/","Analytics and insights",{"title":170,"items":171},"GitLab for",[172,177,182],{"text":173,"config":174},"Enterprise",{"href":175,"dataGaLocation":28,"dataGaName":176},"/enterprise/","enterprise",{"text":178,"config":179},"Small Business",{"href":180,"dataGaLocation":28,"dataGaName":181},"/small-business/","small business",{"text":183,"config":184},"Public Sector",{"href":185,"dataGaLocation":28,"dataGaName":186},"/solutions/public-sector/","public sector",{"text":188,"config":189},"Pricing",{"href":190,"dataGaName":191,"dataGaLocation":28,"dataNavLevelOne":191},"/pricing/","pricing",{"text":193,"config":194,"link":196,"lists":200,"feature":285},"Resources",{"dataNavLevelOne":195},"resources",{"text":197,"config":198},"View all resources",{"href":199,"dataGaName":195,"dataGaLocation":28},"/resources/",[201,234,257],{"title":202,"items":203},"Getting started",[204,209,214,219,224,229],{"text":205,"config":206},"Install",{"href":207,"dataGaName":208,"dataGaLocation":28},"/install/","install",{"text":210,"config":211},"Quick start guides",{"href":212,"dataGaName":213,"dataGaLocation":28},"/get-started/","quick setup checklists",{"text":215,"config":216},"Learn",{"href":217,"dataGaLocation":28,"dataGaName":218},"https://university.gitlab.com/","learn",{"text":220,"config":221},"Product documentation",{"href":222,"dataGaName":223,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":225,"config":226},"Best practice videos",{"href":227,"dataGaName":228,"dataGaLocation":28},"/getting-started-videos/","best practice videos",{"text":230,"config":231},"Integrations",{"href":232,"dataGaName":233,"dataGaLocation":28},"/integrations/","integrations",{"title":235,"items":236},"Discover",[237,242,247,252],{"text":238,"config":239},"Customer success stories",{"href":240,"dataGaName":241,"dataGaLocation":28},"/customers/","customer success stories",{"text":243,"config":244},"Blog",{"href":245,"dataGaName":246,"dataGaLocation":28},"/blog/","blog",{"text":248,"config":249},"Remote",{"href":250,"dataGaName":251,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":253,"config":254},"TeamOps",{"href":255,"dataGaName":256,"dataGaLocation":28},"/teamops/","teamops",{"title":258,"items":259},"Connect",[260,265,270,275,280],{"text":261,"config":262},"GitLab Services",{"href":263,"dataGaName":264,"dataGaLocation":28},"/services/","services",{"text":266,"config":267},"Community",{"href":268,"dataGaName":269,"dataGaLocation":28},"/community/","community",{"text":271,"config":272},"Forum",{"href":273,"dataGaName":274,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":276,"config":277},"Events",{"href":278,"dataGaName":279,"dataGaLocation":28},"/events/","events",{"text":281,"config":282},"Partners",{"href":283,"dataGaName":284,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":286,"textColor":287,"text":288,"image":289,"link":293},"#2f2a6b","#fff","Insights for the future of software development",{"altText":290,"config":291},"the source promo card",{"src":292},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758208064/dzl0dbift9xdizyelkk4.svg",{"text":294,"config":295},"Read the latest",{"href":296,"dataGaName":297,"dataGaLocation":28},"/the-source/","the source",{"text":299,"config":300,"lists":302},"Company",{"dataNavLevelOne":301},"company",[303],{"items":304},[305,310,316,318,323,328,333,338,343,348,353],{"text":306,"config":307},"About",{"href":308,"dataGaName":309,"dataGaLocation":28},"/company/","about",{"text":311,"config":312,"footerGa":315},"Jobs",{"href":313,"dataGaName":314,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":314},{"text":276,"config":317},{"href":278,"dataGaName":279,"dataGaLocation":28},{"text":319,"config":320},"Leadership",{"href":321,"dataGaName":322,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":324,"config":325},"Team",{"href":326,"dataGaName":327,"dataGaLocation":28},"/company/team/","team",{"text":329,"config":330},"Handbook",{"href":331,"dataGaName":332,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":334,"config":335},"Investor relations",{"href":336,"dataGaName":337,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":339,"config":340},"Trust Center",{"href":341,"dataGaName":342,"dataGaLocation":28},"/security/","trust center",{"text":344,"config":345},"AI Transparency Center",{"href":346,"dataGaName":347,"dataGaLocation":28},"/ai-transparency-center/","ai transparency center",{"text":349,"config":350},"Newsletter",{"href":351,"dataGaName":352,"dataGaLocation":28},"/company/contact/","newsletter",{"text":354,"config":355},"Press",{"href":356,"dataGaName":357,"dataGaLocation":28},"/press/","press",{"text":359,"config":360,"lists":361},"Contact us",{"dataNavLevelOne":301},[362],{"items":363},[364,367,372],{"text":35,"config":365},{"href":37,"dataGaName":366,"dataGaLocation":28},"talk to sales",{"text":368,"config":369},"Get help",{"href":370,"dataGaName":371,"dataGaLocation":28},"/support/","get help",{"text":373,"config":374},"Customer portal",{"href":375,"dataGaName":376,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":378,"login":379,"suggestions":386},"Close",{"text":380,"link":381},"To search repositories and projects, login to",{"text":382,"config":383},"gitlab.com",{"href":42,"dataGaName":384,"dataGaLocation":385},"search login","search",{"text":387,"default":388},"Suggestions",[389,391,395,397,401,405],{"text":57,"config":390},{"href":62,"dataGaName":57,"dataGaLocation":385},{"text":392,"config":393},"Code Suggestions (AI)",{"href":394,"dataGaName":392,"dataGaLocation":385},"/solutions/code-suggestions/",{"text":109,"config":396},{"href":111,"dataGaName":109,"dataGaLocation":385},{"text":398,"config":399},"GitLab on AWS",{"href":400,"dataGaName":398,"dataGaLocation":385},"/partners/technology-partners/aws/",{"text":402,"config":403},"GitLab on Google Cloud",{"href":404,"dataGaName":402,"dataGaLocation":385},"/partners/technology-partners/google-cloud-platform/",{"text":406,"config":407},"Why GitLab?",{"href":70,"dataGaName":406,"dataGaLocation":385},{"freeTrial":409,"mobileIcon":414,"desktopIcon":419,"secondaryButton":422},{"text":410,"config":411},"Start free trial",{"href":412,"dataGaName":33,"dataGaLocation":413},"https://gitlab.com/-/trials/new/","nav",{"altText":415,"config":416},"Gitlab Icon",{"src":417,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203874/jypbw1jx72aexsoohd7x.svg","gitlab icon",{"altText":415,"config":420},{"src":421,"dataGaName":418,"dataGaLocation":413},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1758203875/gs4c8p8opsgvflgkswz9.svg",{"text":423,"config":424},"Get Started",{"href":425,"dataGaName":426,"dataGaLocation":413},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":428,"mobileIcon":432,"desktopIcon":434},{"text":429,"config":430},"Learn more about GitLab Duo",{"href":62,"dataGaName":431,"dataGaLocation":413},"gitlab duo",{"altText":415,"config":433},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":435},{"src":421,"dataGaName":418,"dataGaLocation":413},{"freeTrial":437,"mobileIcon":442,"desktopIcon":444},{"text":438,"config":439},"Back to pricing",{"href":190,"dataGaName":440,"dataGaLocation":413,"icon":441},"back to pricing","GoBack",{"altText":415,"config":443},{"src":417,"dataGaName":418,"dataGaLocation":413},{"altText":415,"config":445},{"src":421,"dataGaName":418,"dataGaLocation":413},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":451,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":452,"button":453,"image":458,"config":462,"_id":464,"_type":14,"_source":16,"_file":465,"_stem":466,"_extension":19},"/shared/en-us/banner","is now in public beta!",{"text":454,"config":455},"Try the Beta",{"href":456,"dataGaName":457,"dataGaLocation":28},"/gitlab-duo/agent-platform/","duo banner",{"altText":459,"config":460},"GitLab Duo Agent Platform",{"src":461},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":463},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":468,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":469,"_id":673,"_type":14,"title":674,"_source":16,"_file":675,"_stem":676,"_extension":19},"/shared/en-us/main-footer",{"text":470,"source":471,"edit":477,"contribute":482,"config":487,"items":492,"minimal":665},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":472,"config":473},"View page source",{"href":474,"dataGaName":475,"dataGaLocation":476},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":478,"config":479},"Edit this page",{"href":480,"dataGaName":481,"dataGaLocation":476},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":483,"config":484},"Please contribute",{"href":485,"dataGaName":486,"dataGaLocation":476},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":488,"facebook":489,"youtube":490,"linkedin":491},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[493,516,572,601,635],{"title":46,"links":494,"subMenu":499},[495],{"text":496,"config":497},"DevSecOps platform",{"href":55,"dataGaName":498,"dataGaLocation":476},"devsecops platform",[500],{"title":188,"links":501},[502,506,511],{"text":503,"config":504},"View plans",{"href":190,"dataGaName":505,"dataGaLocation":476},"view plans",{"text":507,"config":508},"Why Premium?",{"href":509,"dataGaName":510,"dataGaLocation":476},"/pricing/premium/","why premium",{"text":512,"config":513},"Why Ultimate?",{"href":514,"dataGaName":515,"dataGaLocation":476},"/pricing/ultimate/","why ultimate",{"title":517,"links":518},"Solutions",[519,524,526,528,533,538,542,545,549,554,556,559,562,567],{"text":520,"config":521},"Digital transformation",{"href":522,"dataGaName":523,"dataGaLocation":476},"/topics/digital-transformation/","digital transformation",{"text":134,"config":525},{"href":136,"dataGaName":134,"dataGaLocation":476},{"text":123,"config":527},{"href":105,"dataGaName":106,"dataGaLocation":476},{"text":529,"config":530},"Agile development",{"href":531,"dataGaName":532,"dataGaLocation":476},"/solutions/agile-delivery/","agile delivery",{"text":534,"config":535},"Cloud transformation",{"href":536,"dataGaName":537,"dataGaLocation":476},"/topics/cloud-native/","cloud transformation",{"text":539,"config":540},"SCM",{"href":119,"dataGaName":541,"dataGaLocation":476},"source code management",{"text":109,"config":543},{"href":111,"dataGaName":544,"dataGaLocation":476},"continuous integration & delivery",{"text":546,"config":547},"Value stream management",{"href":163,"dataGaName":548,"dataGaLocation":476},"value stream management",{"text":550,"config":551},"GitOps",{"href":552,"dataGaName":553,"dataGaLocation":476},"/solutions/gitops/","gitops",{"text":173,"config":555},{"href":175,"dataGaName":176,"dataGaLocation":476},{"text":557,"config":558},"Small business",{"href":180,"dataGaName":181,"dataGaLocation":476},{"text":560,"config":561},"Public sector",{"href":185,"dataGaName":186,"dataGaLocation":476},{"text":563,"config":564},"Education",{"href":565,"dataGaName":566,"dataGaLocation":476},"/solutions/education/","education",{"text":568,"config":569},"Financial services",{"href":570,"dataGaName":571,"dataGaLocation":476},"/solutions/finance/","financial services",{"title":193,"links":573},[574,576,578,580,583,585,587,589,591,593,595,597,599],{"text":205,"config":575},{"href":207,"dataGaName":208,"dataGaLocation":476},{"text":210,"config":577},{"href":212,"dataGaName":213,"dataGaLocation":476},{"text":215,"config":579},{"href":217,"dataGaName":218,"dataGaLocation":476},{"text":220,"config":581},{"href":222,"dataGaName":582,"dataGaLocation":476},"docs",{"text":243,"config":584},{"href":245,"dataGaName":246,"dataGaLocation":476},{"text":238,"config":586},{"href":240,"dataGaName":241,"dataGaLocation":476},{"text":248,"config":588},{"href":250,"dataGaName":251,"dataGaLocation":476},{"text":261,"config":590},{"href":263,"dataGaName":264,"dataGaLocation":476},{"text":253,"config":592},{"href":255,"dataGaName":256,"dataGaLocation":476},{"text":266,"config":594},{"href":268,"dataGaName":269,"dataGaLocation":476},{"text":271,"config":596},{"href":273,"dataGaName":274,"dataGaLocation":476},{"text":276,"config":598},{"href":278,"dataGaName":279,"dataGaLocation":476},{"text":281,"config":600},{"href":283,"dataGaName":284,"dataGaLocation":476},{"title":299,"links":602},[603,605,607,609,611,613,615,619,624,626,628,630],{"text":306,"config":604},{"href":308,"dataGaName":301,"dataGaLocation":476},{"text":311,"config":606},{"href":313,"dataGaName":314,"dataGaLocation":476},{"text":319,"config":608},{"href":321,"dataGaName":322,"dataGaLocation":476},{"text":324,"config":610},{"href":326,"dataGaName":327,"dataGaLocation":476},{"text":329,"config":612},{"href":331,"dataGaName":332,"dataGaLocation":476},{"text":334,"config":614},{"href":336,"dataGaName":337,"dataGaLocation":476},{"text":616,"config":617},"Sustainability",{"href":618,"dataGaName":616,"dataGaLocation":476},"/sustainability/",{"text":620,"config":621},"Diversity, inclusion and belonging (DIB)",{"href":622,"dataGaName":623,"dataGaLocation":476},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":339,"config":625},{"href":341,"dataGaName":342,"dataGaLocation":476},{"text":349,"config":627},{"href":351,"dataGaName":352,"dataGaLocation":476},{"text":354,"config":629},{"href":356,"dataGaName":357,"dataGaLocation":476},{"text":631,"config":632},"Modern Slavery Transparency Statement",{"href":633,"dataGaName":634,"dataGaLocation":476},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":636,"links":637},"Contact Us",[638,641,643,645,650,655,660],{"text":639,"config":640},"Contact an expert",{"href":37,"dataGaName":38,"dataGaLocation":476},{"text":368,"config":642},{"href":370,"dataGaName":371,"dataGaLocation":476},{"text":373,"config":644},{"href":375,"dataGaName":376,"dataGaLocation":476},{"text":646,"config":647},"Status",{"href":648,"dataGaName":649,"dataGaLocation":476},"https://status.gitlab.com/","status",{"text":651,"config":652},"Terms of use",{"href":653,"dataGaName":654,"dataGaLocation":476},"/terms/","terms of use",{"text":656,"config":657},"Privacy statement",{"href":658,"dataGaName":659,"dataGaLocation":476},"/privacy/","privacy statement",{"text":661,"config":662},"Cookie preferences",{"dataGaName":663,"dataGaLocation":476,"id":664,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":666},[667,669,671],{"text":651,"config":668},{"href":653,"dataGaName":654,"dataGaLocation":476},{"text":656,"config":670},{"href":658,"dataGaName":659,"dataGaLocation":476},{"text":661,"config":672},{"dataGaName":663,"dataGaLocation":476,"id":664,"isOneTrustButton":91},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":678,"featuredPost":2089,"totalPagesCount":2107,"initialPosts":2108},[679,706,730,751,777,797,816,837,857,878,897,919,941,961,981,1000,1019,1037,1057,1076,1095,1115,1136,1155,1176,1195,1214,1233,1252,1273,1295,1314,1332,1351,1370,1389,1409,1429,1448,1468,1488,1507,1526,1546,1566,1586,1605,1624,1644,1664,1682,1701,1720,1739,1758,1777,1796,1816,1836,1854,1874,1895,1915,1935,1954,1974,1992,2012,2031,2051,2071],{"_path":680,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":681,"content":689,"config":699,"_id":702,"_type":14,"title":703,"_source":16,"_file":704,"_stem":705,"_extension":19},"/en-us/blog/5-problems-you-can-help-us-solve-right-now",{"title":682,"description":683,"ogTitle":682,"ogDescription":683,"noIndex":6,"ogImage":684,"ogUrl":685,"ogSiteName":686,"ogType":687,"canonicalUrls":685,"schema":688},"5 UX problems you can help us fix right now","“We spent 40 hours talking to 20 of you. Now we’ve got some issues we’d like your help on.”","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682386/Blog/Hero%20Images/pexels-sevenstorm-juhaszimrus-704767.jpg","https://about.gitlab.com/blog/5-problems-you-can-help-us-solve-right-now","https://about.gitlab.com","article","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 UX problems you can help us fix right now\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ben Leduc-Mills\"}],\n        \"datePublished\": \"2022-07-25\",\n      }",{"title":682,"description":683,"authors":690,"heroImage":684,"date":692,"body":693,"category":694,"tags":695},[691],"Ben Leduc-Mills","2022-07-25"," \n\nWe’ve all been there. You’re sailing along, being productive, and wham! Something inexplicably awful disrupts your workflow. You ask yourself, “How could _anyone_ think this was a good idea?” Maybe it’s a bug, slow performance, or bad design. One of the reasons we conduct [user experience research at GitLab](/handbook/product/ux/ux-research/) is to find these problems and report back to our teams so they can fix them. \n\n![Grumpy cat looking over computer](https://about.gitlab.com/images/blogimages/hhh13-tEMU4lzAL0w-unsplash__1_.jpg)\nWe've all been there\n{: .note.text-center}\n\nWith a product as rich and complex as GitLab, we find _a lot_ of problems. So many, in fact, we often can't fix them as fast as you find them. ([Although we do try!](/releases/2022/05/22/gitlab-15-0-released/#bug-fixes)) The great thing about GitLab is that [**everyone** can contribute](/company/mission/). This is the first in a new series of blog posts where the UX researchers at GitLab transform their findings into some great first contributions that community members can explore. \n\nWe recently spent 2 hours each with 20 people who use GitLab, going through specific tasks related to branch and merge request operations, and, predictably, we found plenty of things to work on (although this research focused on the code creation and review process) - you can check out the full report 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%2FmF555KKsf1m1UyyXbWxXu2%2FBenchmarking-Slides%3Fnode-id%3D943%253A12915%26scaling%3Dscale-down%26page-id%3D40%253A124%26starting-point-node-id%3D943%253A12915\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\n\nWithout further ado, here are five issues we would **love** your contributions on:\n\n1. [Show more branches in the drop down menu while reverting a merge request.](https://gitlab.com/gitlab-org/gitlab/-/issues/358218) \n1. [Increase the discoverability of the insert suggestion feature.](https://gitlab.com/gitlab-org/gitlab/-/issues/368716) \n1. [Fix data loss when switching from inline to side-by-side view on MR creation page.](https://gitlab.com/gitlab-org/gitlab/-/issues/358217) \n1. [Show selected labels within the dropdown menu.](https://gitlab.com/gitlab-org/gitlab/-/issues/322945) \n1. [Improve clarity of text-only buttons -- Move 'mark as draft' onto new line](https://gitlab.com/gitlab-org/gitlab/-/issues/358437) \n\nWondering where to start? Check out [this blog post](/blog/first-time-open-source-contributor-5-things-to-get-you-started/) and [our development guide](/community/contribute/development/) and become an all-star contributor! \n\nNeed guidance or help? Feel free to leave a comment directly on one of the issues linked above, or find support in the \"get help\" section [in our contributing guide](/community/contribute/#getting-help).\n\nContributing to an open source project also brings a ton of proven benefits you might not expect:\n\n- Contributing is one of the most efficient ways to learn, as it is learning by doing and [being guided by merge request coaches](https://handbook.gitlab.com/job-families/expert/merge-request-coach/). Contributing has been proven time and time again to be the best form of learning!\n- Public exposure and explicit appreciation from the open source community, which helps build your public profile And show your expertise ... you never know when that resume might come in handy! 😊 \n- You're in for a treat: **first-time** contributors receive GitLab swag, **regular** contributors (5 MRs or more) are eligible for the [GitLab Heroes program](/community/heroes), and **top** contributors may be invited to join the [GitLab Core team](/community/core-team/).\n\nAnd not only is this beneficial for you, but also for your employer (if you are employed). Because you are growing and learning at a rapid speed from the best, you will get a faster turnaround time when integrating a feature into the platform since you know how the system works. You will get more value from the most precious resource in the universe, time 🕐. Take advantage of this experience today. We are convinced of the benefits and we hope you and/or your employer are too now. Let's aim for the moon together. 🚀 \n\n1,2,3...**let's go!**\n\nCover image by [SevenStorm JUHASZIMRUS](https://www.pexels.com/@sevenstormphotography/) on [Pexels](https://www.pexels.com/photo/123-let-s-go-imaginary-text-704767/)\n{: .note}\n","open-source",[696,269,697,698,9],"contributors","open source","research",{"slug":700,"featured":6,"template":701},"5-problems-you-can-help-us-solve-right-now","BlogPost","content:en-us:blog:5-problems-you-can-help-us-solve-right-now.yml","5 Problems You Can Help Us Solve Right Now","en-us/blog/5-problems-you-can-help-us-solve-right-now.yml","en-us/blog/5-problems-you-can-help-us-solve-right-now",{"_path":707,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":708,"content":714,"config":724,"_id":726,"_type":14,"title":727,"_source":16,"_file":728,"_stem":729,"_extension":19},"/en-us/blog/a-deep-dive-into-the-security-analyst-persona",{"title":709,"description":710,"ogTitle":709,"ogDescription":710,"noIndex":6,"ogImage":711,"ogUrl":712,"ogSiteName":686,"ogType":687,"canonicalUrls":712,"schema":713},"A deep dive into the Security Analyst persona","See how we created our new Security Analyst persona, and how we are already putting it to use.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663736/Blog/Hero%20Images/a-deep-dive-into-the-security-analyst-persona.jpg","https://about.gitlab.com/blog/a-deep-dive-into-the-security-analyst-persona","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A deep dive into the Security Analyst persona\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Andy Volpe\"}],\n        \"datePublished\": \"2019-02-12\",\n      }",{"title":709,"description":710,"authors":715,"heroImage":711,"date":717,"body":718,"category":719,"tags":720},[716],"Andy Volpe","2019-02-12","\nAs GitLab grows, so does our need for new, more area-specific personas. Recently, as part of our [effort to create personas](/blog/personas-and-empathy-building/), I was given a chance to craft one. As the UX designer for [the Secure team](/handbook/engineering/development/sec/secure/) here at GitLab, I jumped at the opportunity to learn more about security professionals, and how we may create products and features to meet their needs. Throughout the entire process, I gained a greater sense of empathy and a deeper understanding of the needs, goals, and pain points of security professionals. The result was our new [Security Analyst Persona, Sam](https://handbook.gitlab.com/handbook/product/personas/#sam-security-analyst). However, I will add a caveat that this is not the end of the process, but the beginning of how we can better support security professionals with new features and functionality that address their specific needs. You can peruse the highlights and the persona itself below, and let us know what you think by tweeting us [@gitlab](https://twitter.com/gitlab)!\n\n## The research\n\nHere are some takeaways from the [10 interviews](https://gitlab.com/gitlab-org/ux-research/issues/97) I conducted to create the Security Analyst persona.\n\nWe’ve learned that the Security Analyst is a bit of a generalist when it comes to their day-to-day tasks. From the research, I found that there isn’t one specific task that defines their day, but a grouping of tasks under the umbrella of security. I’ve written the summary of the persona to reflect the somewhat general nature of the Security Analysts' role:\n\n>\"I wear lots of hats, but the majority of my time is spent monitoring and flagging events, running down high-priority tasks and working with other teams to implement new systems.\"\n\n### What motivates a Security Analyst?\n\nSecurity Analysts strive for order in the chaos and, based on our research, are taking steps to achieve that order. One specific example:\n\n>When I’m monitoring my dashboards, I want to see everything I am monitoring in one tool, so I can do my job easier and more efficiently.\n\nMoving between different tools and dashboards was identified as a significant problem area for Security Analysts. They found it hard to create a workflow that was conducive to remediating security issues while having to work across multiple tools.\n\nAnother motivation I found during the research was that Security Analysts desire to be more proactive than reactive in their work. I’ve summarized this by adding the objective below:\n\n>When security testing, I want to be more proactive than reactive, so I can anticipate potential threats or vulnerabilities before the bad guys do.\n\nBy being more proactive or shifting left in their work, Security Analysts are able to identify and remediate potential vulnerabilities before they become a problem or even lead to an attack.\n\n### What are some of the frustrations Security Analysts have?\n\n>I’m frustrated I don’t have the resources to complete this project to its specifications.\n\nand\n\n>I’m frustrated when I know how to fix a security issue but the red tape at my company doesn’t allow me to in a timely manner.\n\nA common theme seen throughout the research was that of constrained resources and time. Often we found that security teams were small in comparison to other teams within their organization. This resource discrepancy leads to work being done at such a pace that the project can’t be completed to its specifications or in a timely manner.\n\n### How are we using the security Analyst persona at GitLab?\n\nWe are all-in on making the Security Persona a first-class persona here at GitLab. Recently we launched the [Group-level Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/), which allows security professionals to monitor all their projects, in one view, for vulnerabilities, and gives them the ability to take action on those vulnerabilities right from the dashboard itself.\n\nAside from security dashboards, we are constantly dreaming up more security features and enhancements that will help users keep their instances, groups, and projects secure. You can [see our roadmap here](/direction/#future-releases) for more on what's coming.\n\n## The persona\n\n![Sam, Security Analyst persona](https://about.gitlab.com/images/blogimages/security-analyst-persona.png){: .shadow.center}\n\nKeep an eye out for the rest of our series on the [new personas](https://handbook.gitlab.com/handbook/product/personas/)!\n\n[Photo](https://unsplash.com/photos/z55CR_d0ayg) by [Andrew Neel](https://unsplash.com/@andrewtneel) on Unsplash\n{: .note}\n","security",[721,722,719,9,723],"testing","inside GitLab","workflow",{"slug":725,"featured":6,"template":701},"a-deep-dive-into-the-security-analyst-persona","content:en-us:blog:a-deep-dive-into-the-security-analyst-persona.yml","A Deep Dive Into The Security Analyst Persona","en-us/blog/a-deep-dive-into-the-security-analyst-persona.yml","en-us/blog/a-deep-dive-into-the-security-analyst-persona",{"_path":731,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":732,"content":738,"config":745,"_id":747,"_type":14,"title":748,"_source":16,"_file":749,"_stem":750,"_extension":19},"/en-us/blog/a-tale-of-two-editors",{"title":733,"description":734,"ogTitle":733,"ogDescription":734,"noIndex":6,"ogImage":735,"ogUrl":736,"ogSiteName":686,"ogType":687,"canonicalUrls":736,"schema":737},"A tale of two file editors","How UX Research revealed unexpected patterns in how people use two GitLab file editors: the single-file editor and the Web IDE.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668339/Blog/Hero%20Images/a-tale-of-two-editors.jpg","https://about.gitlab.com/blog/a-tale-of-two-editors","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"A tale of two file editors\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2020-09-01\",\n      }",{"title":733,"description":734,"authors":739,"heroImage":735,"date":741,"body":742,"category":743,"tags":744},[740],"Emily von Hoffmann","2020-09-01","\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-11-13.\n{: .alert .alert-info .note}\n\nThis study began the way many do – with a conundrum and a theory.\n\nThe [Create: Editor](https://handbook.gitlab.com/handbook/product/categories/#editor-group) group originally had the goal of deprecating the single-file editor in favor of the new and improved [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/). But after looking into usage data, we discovered that [the single-file editor was being used at higher rates](https://www.youtube.com/watch?v=3iPNyfVNO1U&feature=youtu.be) than the Web IDE, and in fact had quadruple the page views. This was a concerning discovery with the potential of becoming a real inflection point, raising questions like: Do we have a discoverability problem, or do we have a usability problem? Has our investment in the Web IDE been moving us in the wrong direction?\n\n![Web IDE pageviews](https://about.gitlab.com/images/blogimages/web-ide-pageviews.png){: .medium.center}\n\n![Single-file editor pageviews](https://about.gitlab.com/images/blogimages/single-file-editor-pageviews.png){: .medium.center}\n\nAs you can see above, the single-file editor significantly outperforms the Web IDE in terms of page views. The single-file editor also receives more visitors who are coming to and from merge requests.\n\n## Our theory\n\nWe initially thought the single-file editor got more usage than the Web IDE due to discoverability problems. Since people should be able to accomplish everything they need within the Web IDE, maybe they just don’t know it exists. Or, maybe the “edit” button on the single-file editor seems like the obvious choice for what people want to do, whereas “Web IDE” sounds more complicated. There’s also always a nagging concern that people have tried the Web IDE and found it to be a bad experience, opting instead to stick with the alternative.\n\n## Our research plan\n\nWe developed a survey to hammer out whether people know how to edit a file in GitLab, why they choose the editor they do, and why, if ever, they choose the other one.\nFor reference, here’s what they both look like:\n\n### Exhibit A: Single-file editor\n\n![Gif of Single-file editor in action](https://about.gitlab.com/images/blogimages/single-file-editor-ezgif.gif){: .shadow.center}\n\n### Exhibit B: Web IDE\n\n![Gif of Web IDE in action](https://about.gitlab.com/images/blogimages/web-ide-ezgif.gif){: .shadow.center}\n\n## Results\n\nAfter reviewing the survey results, we started seeing clear patterns that indicate people actually have distinct use cases for each editor. They’re not using the single-file editor because they can’t find the Web IDE; they’re purposefully selecting an editor based on the complexity of what they need to accomplish.\nPeople prefer the single-file editor when they need to make very simple changes to a single file. It’s aptly named in that sense! Alternatively, people choose the web IDE when they want to edit multiple files, or when they want to make changes that require context from other files. These changes might include hotfixes, creating templates, and making changes related to GitLab CI files.\n\nWe also learned that people want the ability to edit in context. Today, people choose an editing mode and then switch between screens to navigate to other project areas, which isn’t the best experience. What people really want is the ability to toggle editors and easily access navigation while in the Web IDE:\n\n> \"Let me toggle between editors (e.g. if I start with Editor and realize I need to edit another file, I can switch to Web IDE – with any changes made carried over).\"\n\n## What’s next\n\nI love this study because it so clearly demonstrates the value of research. Had we gone ahead with our original theory, we would have been solving a perceived discoverability problem that people aren’t really having. Instead, we disproved our theory and have several proposed improvements already in the works.\nInstead of removing the single-file editor in favor of promoting the Web IDE, we’ll explore a simplified editing workflow that [consolidates the Edit and Web IDE buttons](https://gitlab.com/gitlab-org/gitlab/-/issues/221247) so that a dropdown allows people to choose their preferred mode. You can see mockups for the next potential iterations below.\n\n| Description | Mock |\n| ------ | ------ |\n| Web IDE option chosen (default) | ![Web IDE chosen by default](https://about.gitlab.com/images/blogimages/web-ide-chosen-by-default.png) |\n| Edit option chosen | ![Edit chosen by default](https://about.gitlab.com/images/blogimages/file-chosen-by-default.png) |\n| Dropdown | ![Dropdown lets you choose](https://about.gitlab.com/images/blogimages/dropdown-choose-your-editor.png) |\n\nWhat do you think about the proposed change? Come talk to us on [Twitter](https://twitter.com/gitlab/), and join our [UX research program](/community/gitlab-first-look/) to participate in future studies.\n\n## Read more about UX at GitLab\n\n- [How holistic UX design increased GitLab.com free trial signups](/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups/)\n- [How we created a dark UI for GitLab's Web IDE](/blog/creating-a-dark-ui-for-gitlabs-web-ide/)\n- [Designing in an all-remote company](/blog/designing-in-an-all-remote-company/)\n\n[Katherine Okpara](/company/team/#katokpara) contributed to this post.\n\nCover image by Gastón Blaquier on [Unsplash](https://unsplash.com/photos/_foeAxTQ5H0).","insights",[9,722],{"slug":746,"featured":6,"template":701},"a-tale-of-two-editors","content:en-us:blog:a-tale-of-two-editors.yml","A Tale Of Two Editors","en-us/blog/a-tale-of-two-editors.yml","en-us/blog/a-tale-of-two-editors",{"_path":752,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":753,"content":759,"config":771,"_id":773,"_type":14,"title":774,"_source":16,"_file":775,"_stem":776,"_extension":19},"/en-us/blog/async-sketching",{"title":754,"description":755,"ogTitle":754,"ogDescription":755,"noIndex":6,"ogImage":756,"ogUrl":757,"ogSiteName":686,"ogType":687,"canonicalUrls":757,"schema":758},"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":754,"description":755,"authors":760,"heroImage":756,"date":763,"body":764,"category":765,"tags":766},[761,762],"Jacki Bauer","Inchul Yoo, Sunjung Park","2020-03-27","\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","unfiltered",[767,768,769,770,9],"collaboration","design","remote work","UI",{"slug":772,"featured":6,"template":701},"async-sketching","content:en-us:blog:async-sketching.yml","Async Sketching","en-us/blog/async-sketching.yml","en-us/blog/async-sketching",{"_path":778,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":779,"content":785,"config":791,"_id":793,"_type":14,"title":794,"_source":16,"_file":795,"_stem":796,"_extension":19},"/en-us/blog/avoiding-burnout-as-product-designers",{"title":780,"description":781,"ogTitle":780,"ogDescription":781,"noIndex":6,"ogImage":782,"ogUrl":783,"ogSiteName":686,"ogType":687,"canonicalUrls":783,"schema":784},"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","\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":780,"description":781,"authors":786,"heroImage":782,"date":788,"body":789,"category":743,"tags":790},[787],"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",[9,768,769],{"slug":792,"featured":6,"template":701},"avoiding-burnout-as-product-designers","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":798,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":799,"content":805,"config":810,"_id":812,"_type":14,"title":813,"_source":16,"_file":814,"_stem":815,"_extension":19},"/en-us/blog/beautifying-of-our-ui",{"title":800,"description":801,"ogTitle":800,"ogDescription":801,"noIndex":6,"ogImage":802,"ogUrl":803,"ogSiteName":686,"ogType":687,"canonicalUrls":803,"schema":804},"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":800,"description":801,"authors":806,"heroImage":802,"date":807,"body":808,"category":743,"tags":809},[787],"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",[9,768],{"slug":811,"featured":6,"template":701},"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":817,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":818,"content":824,"config":831,"_id":833,"_type":14,"title":834,"_source":16,"_file":835,"_stem":836,"_extension":19},"/en-us/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience",{"title":819,"description":820,"ogTitle":819,"ogDescription":820,"noIndex":6,"ogImage":821,"ogUrl":822,"ogSiteName":686,"ogType":687,"canonicalUrls":822,"schema":823},"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":819,"description":820,"authors":825,"heroImage":821,"date":827,"body":828,"category":829,"tags":830},[826],"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",[768,9,770,829,496],{"slug":832,"featured":6,"template":701},"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":838,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":839,"content":845,"config":851,"_id":853,"_type":14,"title":854,"_source":16,"_file":855,"_stem":856,"_extension":19},"/en-us/blog/beautifying-our-ui",{"title":840,"description":841,"ogTitle":840,"ogDescription":841,"noIndex":6,"ogImage":842,"ogUrl":843,"ogSiteName":686,"ogType":687,"canonicalUrls":843,"schema":844},"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":840,"description":841,"authors":846,"heroImage":842,"date":848,"body":849,"category":301,"tags":850},[847],"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",[9,770,768],{"slug":852,"featured":6,"template":701},"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":858,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":859,"content":865,"config":872,"_id":874,"_type":14,"title":875,"_source":16,"_file":876,"_stem":877,"_extension":19},"/en-us/blog/building-a-ux-research-insights-repository",{"title":860,"description":861,"ogTitle":860,"ogDescription":861,"noIndex":6,"ogImage":862,"ogUrl":863,"ogSiteName":686,"ogType":687,"canonicalUrls":863,"schema":864},"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":860,"description":861,"authors":866,"heroImage":862,"date":868,"body":869,"category":870,"tags":871},[867],"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",[9,768],{"slug":873,"featured":6,"template":701},"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":879,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":880,"content":886,"config":891,"_id":893,"_type":14,"title":894,"_source":16,"_file":895,"_stem":896,"_extension":19},"/en-us/blog/conducting-remote-ux-research",{"title":881,"description":882,"ogTitle":881,"ogDescription":882,"noIndex":6,"ogImage":883,"ogUrl":884,"ogSiteName":686,"ogType":687,"canonicalUrls":884,"schema":885},"Conducting remote UX research at GitLab","Learn about the different kinds of UX research we conduct at GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666775/Blog/Hero%20Images/cover.jpg","https://about.gitlab.com/blog/conducting-remote-ux-research","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Conducting remote UX research at GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah O’Donnell\"}],\n        \"datePublished\": \"2017-12-20\",\n      }",{"title":881,"description":882,"authors":887,"heroImage":883,"date":888,"body":889,"category":870,"tags":890},[867],"2017-12-20","GitLab is a [remote-only](http://www.remoteonly.org/) organization and just like our [team](/company/team/), our users are spread across the globe. Conducting remote UX research allows us to quickly connect with GitLab users anywhere in the world. It provides us with the opportunity to gather insight into users’ behaviors, motivations and goals when using GitLab. This helps us to determine what features should be built and how they should behave. But how do we do all this remotely?\n\n\u003C!-- more -->\n\nThese are some of the remote UX research methods we use at GitLab.\n\n## Card sorting\n\nCard sorting is a research method for discovering how people understand and categorize information. Each card represents an item or a topic and we ask users to group the cards in a way that makes sense to them. We may also ask them to help us label these groups.\n\nCard sorting can be used to:\n\n- Help design the information architecture of your application\n- Establish what information should be on a page and in what order that information should appear\n- Provide a ranking for items or topics based on a set criteria\n\nWhen analyzing a card sort, we look for common patterns such as which cards appear together the most and which cards are labeled in a similar way.\n\nAt GitLab, we’re currently using card sorting to restructure the sidebar navigation at a project and group level. We want to understand how you, our users, would expect our features to be grouped and classified. Our aim is to improve the ease and the speed at which you navigate around GitLab. We conduct remote card sorting via [Optimal Workshop](https://www.optimalworkshop.com/).\n\n## First-click testing\n\nFirst-click testing explores what users click on first when completing a task within an interface. It tells us whether users are able to find what they’re looking for quickly and easily. This research method is based on the principle that users are two to three times more likely to find what they are looking for if their initial click is correct, rather than a click in the wrong direction.\n\nWe’ve used first-click testing at GitLab to quickly evaluate multiple design ideas against one another. We share our designs with users via [UsabilityHub](https://usabilityhub.com/). We measure whether users take the correct path and how long it takes them to decide where to click. A slower click time would suggest a user has hesitated about where to click.\n\nFirst-click testing is great for providing an indication of whether a design is intuitive to users and helps us to quickly narrow down multiple design concepts.\n\n## Surveys\n\nSurveys are used to investigate the opinions or experiences of users by asking them questions through an online form. A survey invites people to share open and honest feedback. Some people find them less intimidating than other forms of research as there is the option to remain anonymous when providing answers. They also allow us to track how the attitudes and behaviors of our users change over time.\n\nWe’ve used surveys to understand our users and form [personas](https://design.gitlab.com/), to generate new ideas for future GitLab improvements and to help measure users’ satisfaction with our existing features.\n\n## User interviews\n\nIf you take part in a user interview at GitLab, you’ll usually be speaking one on one with a UX researcher. In order to do this, you’ll need a desktop or laptop computer and a headset with a microphone.\n\nWe find that most of our users like to talk with us on their lunch break at their work station, whether situated at home or in an office. We love this, as it provides some insight into the environment in which you use GitLab.\n\nOften our interviews are focused on you! We’ll ask you to chat about things such as your background, occupation and experience with GitLab. Sometimes we might have a particular topic we’d like to discuss, such as how you’ve incorporated GitLab into your workflow. We’ll always tell you our intentions ahead of the call so you have time to think about what you’d like to contribute to the discussion. We also welcome you to share your screen with us during the call. We understand that it is sometimes easier to show and demonstrate something than it is to just talk about it!\n\nWe’ve used feedback from user interviews to:\n\n- Inform our [personas](https://docs.gitlab.com/ee/development/ux_guide/users.html)\n- Follow up on survey answers\n- Understand and develop objectives and goals for features\n\n## Usability testing\n\nUsability testing is a technique used to evaluate a product by testing it with representative users. Usability testing can be divided into two categories: moderated and unmoderated research.\n\n**Moderated**\n\nIf you participate in moderated usability testing at GitLab, you’ll complete a series of tasks whilst being observed by one of our UX researchers. In order to see what you're doing, we'll ask you to share your screen with us. We use [Zoom](https://zoom.us/) to run our moderated usability testing sessions.\n\nAs you use GitLab, we’ll ask you to try and think out loud: tell us what you’re looking at, what you’re trying to do and what you’re thinking. We’re interested in hearing your honest feedback. Sound scary? It really isn’t! It’s important to remember that we’re testing GitLab, not you. You can’t say or do anything wrong during a study.\n\nModerated research allows for conversation between a user and the UX researcher, because both are online simultaneously. It gives the researcher the opportunity to ask a user follow-up questions regarding something they’ve said or done. Subsequently, moderated research provides us with a lot of in-depth qualitative research about our users’ needs. It can help us to uncover usability problems that we weren’t aware of and to generate solutions to solve these problems.\n\n**Unmoderated**\n\nUnlike moderated research, unmoderated research doesn't involve any conversation between a user and a UX researcher. Instead, unmoderated usability testing sessions are completed alone by a user. As users can complete sessions at their own convenience and studies can be run simultaneously, they're good for collecting data quickly.\n\nWe use [Validately](https://validately.com/) to serve the tasks to you and to record your actions. We then analyze the data collected asynchronously. It is, however, still very helpful to us if you try and think out loud while you’re completing tasks.\n\nUnmoderated research can provide some qualitative data. However, as there’s no opportunity to ask users follow-up questions related to their actions, the study should focus on a few specific elements or relatively minor changes. Unmoderated research is usually better at addressing specific quantitative questions, such as:\n\n- What percentage of users successfully completed the task?\n- How long did it take users to complete the task?\n\nAs a researcher cannot view an unmoderated usability testing session until it's completed, there's a risk of a study being unusable if the user didn't complete the tasks as specified or if they ran into technical difficulties.\n\nWe conduct both moderated and unmoderated usability testing sessions at GitLab to test new features and changes to existing features.\n\n## How can I get involved?\n\nWe’re always looking for people to participate in our research, whether you're a GitLab user or not. You can get involved by signing up for [GitLab First Look](/community/gitlab-first-look/), a comprehensive research program that will help us ship the features and fixes you need to do your best work.  Besides being instrumental in shaping the future of GitLab, you’ll have the opportunity to earn gift cards and win awesome tech prizes by sharing your feedback with us.\n",[769,722,9],{"slug":892,"featured":6,"template":701},"conducting-remote-ux-research","content:en-us:blog:conducting-remote-ux-research.yml","Conducting Remote Ux Research","en-us/blog/conducting-remote-ux-research.yml","en-us/blog/conducting-remote-ux-research",{"_path":898,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":899,"content":905,"config":913,"_id":915,"_type":14,"title":916,"_source":16,"_file":917,"_stem":918,"_extension":19},"/en-us/blog/continuously-improving-ci-lovability",{"title":900,"description":901,"ogTitle":900,"ogDescription":901,"noIndex":6,"ogImage":902,"ogUrl":903,"ogSiteName":686,"ogType":687,"canonicalUrls":903,"schema":904},"Continuously Improving CI to Lovable...again!","A transparent commentary on our Verify:Continuous Integration offering, covering how the landscape has changed and the product strategy that will carry us to Lovable.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749681907/Blog/Hero%20Images/CI-lovable.jpg","https://about.gitlab.com/blog/continuously-improving-ci-lovability","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Continuously Improving CI to Lovable...again!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Jackie Porter\"}],\n        \"datePublished\": \"2021-02-22\",\n      }",{"title":900,"description":901,"authors":906,"heroImage":902,"date":908,"body":909,"category":765,"tags":910},[907],"Jackie Porter","2021-02-22","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n## What is it to be loved?\n\nAt GitLab, we use a [maturity](https://about.gitlab.com/direction/maturity/) rating to signal the readiness of a product category's capabilities for use by customers. The rating is evaluated by a scoring methodology called [Category Maturity Scorecard](https://about.gitlab.com/handbook/product/ux/category-maturity/category-maturity-scorecards/). In 2017, GitLab declared Continuous Integration \"Lovable\" after delivering significant feature functionality and becoming a [CI leader](https://about.gitlab.com/blog/gitlab-leader-continuous-integration-forrester-wave/). \n\nIn the [Verify Stage](/direction/ops/#verify), we have been able to maintain a lead against our competition by adding advanced feature functionality, relying on our [Single DevOps Platform](/solutions/devops-platform/), and executing on a strong vision. As the tides have been changing and as a practitioner of transparency, we [articulate when we change our mind](https://handbook.gitlab.com/handbook/values/#articulate-when-you-change-your-mind), especially when we learn new facts. \n\nIn a recent [opportunity canvas](https://about.gitlab.com/handbook/product/product-processes/#opportunity-canvas), we explored the adoption hurdles that prevent Source Code Management Enterprise users from adopting Verify functionality. We explored all potential features as candidates for adoption across Verify categories - CI, Testing, Pipeline Authoring, and Runner. \n\nIn this blog we will dive into they key takeways that help answer the question of what is it to be loved and how the expectations have shifted over time, and what the path to Lovable maturity looks like for Verify:Continuous Integration! \n\n## Key learnings from the research \n\nWe spent 6 weeks interviewing and collecting insights from across our customers to learn about their adoption journey with GitLab. These were the main learnings informing our approach. \n\n### GitLab is loved by developers \n\nAcross each organization, we learned that the experience for the developer was resoundingly positive and the leaders at these organizations appreciated this. The happiness of their engineering teams was and will continue to be extremely important to them, but the fact that GitLab was a significant contributing factor in developer job satisfaction was a reward on its own. \n\n### GitLab has some challenges with performance of minimal viable changes that are expected to work at a higher finish\n\nEnterprises are often larger, mature organizations shipping their own enterprise class solution. When faced with serving their needs, we learned they have a low tolerance for experimentation and a high expectation for polished features. This means a Premium or Ultimate tier offering needs to completely solve the problem and delight the user, not partially solve the problem. With our MVC and iterative methodology, we have historically shipped first and second iterations of features that may have solved the needs for individuals or small teams in small or medium-sized businesses. Although, with the expanding budgets as well as focus on developer productivity, organizations are looking for tools that will solve problems the best way possible, as comprehensively as possible. \n\n### GitLab's visibility into jobs at scale is painful, which also makes the management of diagnosing problems even more challenging \n\nWe learned a common question that organizations are unable to answer is around trends for passed and failed jobs. This is particularly relevant for projects that have over 100,000 pipelines and 300 jobs in single pipeline. Today in GitLab, there is no view where they can answer a question like how many times a particular job has failed; is it failing more often lately; does it fail at the same time each day; and other job behaviors of interest. Even filtering the job view is not possible today. So, for an organization that is looking to use GitLab at scale, it could be really challenging to easily triage and diagnose problems with their pipelines. \n\n## Path to Lovable \n\nIn the [Verify 1H Direction](/direction/ops/#verify), we identify a key piece of our strategy is to future-proof ourselves by investing in the core areas driving CI today. These top focuses include: \n\n1. [Artifacts](https://gitlab.com/groups/gitlab-org/-/epics/5125) - these are essential assets for your jobs and pipelines, getting these performant will help users take advantage of features like parent-child pipelines. \n1. [Variables](https://gitlab.com/groups/gitlab-org/-/epics/5124) - permissions and behaviors in pipelines are controlled by variables. Enabling these to work as designed will unlock the flexibility users have been looking for in their pipelines. \n\nBe sure to stay up to date on the [What's Next & Why Section](https://about.gitlab.com/direction/verify/continuous_integration/#whats-next--why) of Continuous Integration's Direction page, which will link to specific scheduled issues. \n\nBeyond this push for usability, in the 2H, we plan to tackle the challenges of visibility in diagnosing jobs via [gitlab&5022](https://gitlab.com/groups/gitlab-org/-/epics/5022) and piplelines activities in [gitlab&5071](https://gitlab.com/groups/gitlab-org/-/epics/5071), which you can see more information about in the [Maturity Plan](https://about.gitlab.com/direction/verify/continuous_integration/#maturity-plan) for Continuous Integration.\n",[911,9,912],"CI","features",{"slug":914,"featured":6,"template":701},"continuously-improving-ci-lovability","content:en-us:blog:continuously-improving-ci-lovability.yml","Continuously Improving Ci Lovability","en-us/blog/continuously-improving-ci-lovability.yml","en-us/blog/continuously-improving-ci-lovability",{"_path":920,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":921,"content":927,"config":935,"_id":937,"_type":14,"title":938,"_source":16,"_file":939,"_stem":940,"_extension":19},"/en-us/blog/creating-a-dark-ui-for-gitlabs-web-ide",{"title":922,"description":923,"ogTitle":922,"ogDescription":923,"noIndex":6,"ogImage":924,"ogUrl":925,"ogSiteName":686,"ogType":687,"canonicalUrls":925,"schema":926},"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":922,"description":923,"authors":928,"heroImage":924,"date":931,"body":932,"category":870,"tags":933},[929,930],"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",[934,9,768,723],"webcast",{"slug":936,"featured":6,"template":701},"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":942,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":943,"content":949,"config":955,"_id":957,"_type":14,"title":958,"_source":16,"_file":959,"_stem":960,"_extension":19},"/en-us/blog/deep-dive-into-gitlabs-ux-design-process",{"title":944,"description":945,"ogTitle":944,"ogDescription":945,"noIndex":6,"ogImage":946,"ogUrl":947,"ogSiteName":686,"ogType":687,"canonicalUrls":947,"schema":948},"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":944,"description":945,"authors":950,"heroImage":946,"date":952,"body":953,"category":870,"tags":954},[951],"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",[722,9,934,768],{"slug":956,"featured":6,"template":701},"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":962,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":963,"content":969,"config":975,"_id":977,"_type":14,"title":978,"_source":16,"_file":979,"_stem":980,"_extension":19},"/en-us/blog/designing-alerts-and-incidents",{"title":964,"description":965,"ogTitle":964,"ogDescription":965,"noIndex":6,"ogImage":966,"ogUrl":967,"ogSiteName":686,"ogType":687,"canonicalUrls":967,"schema":968},"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":964,"description":965,"authors":970,"heroImage":966,"date":972,"body":973,"category":765,"tags":974},[971],"Amelia Bauerly","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://handbook.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",[9,768,722],{"slug":976,"featured":6,"template":701},"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":982,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":983,"content":989,"config":994,"_id":996,"_type":14,"title":997,"_source":16,"_file":998,"_stem":999,"_extension":19},"/en-us/blog/designing-for-developers",{"title":984,"description":985,"ogTitle":984,"ogDescription":985,"noIndex":6,"ogImage":986,"ogUrl":987,"ogSiteName":686,"ogType":687,"canonicalUrls":987,"schema":988},"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":984,"description":985,"authors":990,"heroImage":986,"date":991,"body":992,"category":743,"tags":993},[951],"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",[768,9],{"slug":995,"featured":6,"template":701},"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":1001,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1002,"content":1008,"config":1013,"_id":1015,"_type":14,"title":1016,"_source":16,"_file":1017,"_stem":1018,"_extension":19},"/en-us/blog/designing-in-an-all-remote-company",{"title":1003,"description":1004,"ogTitle":1003,"ogDescription":1004,"noIndex":6,"ogImage":1005,"ogUrl":1006,"ogSiteName":686,"ogType":687,"canonicalUrls":1006,"schema":1007},"How we work 100% remote in Product Design","UX is such a collaborative activity. How do you work effectively when everyone is remote?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679473/Blog/Hero%20Images/designing-in-an-all-remote-company.jpg","https://about.gitlab.com/blog/designing-in-an-all-remote-company","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we work 100% remote in Product Design\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2020-03-27\",\n      }",{"title":1003,"description":1004,"authors":1009,"heroImage":1005,"date":763,"body":1010,"category":1011,"tags":1012},[847],"\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2020-04-02.\n{: .alert .alert-info .note}\n\nIn 2019, GitLab’s all-remote UX team grew from fewer than 15 team members to almost 60.\n\nHiring at that velocity meant we interviewed a lot of great product designers, UX researchers, and technical writers. One of the most common questions I personally heard in interviews was, “UX is such a collaborative activity. How do you work effectively when everyone is remote?”\n\nIt’s a fair question. As UX practitioners, we’re often used to getting in a room with our product team to brainstorm ideas and work through problems. So, how do you keep everyone engaged and informed without that face-to-face time?\n\nHonestly, there is no perfect answer, and we’re still figuring it out every day. We tend to try new ideas as pilot programs and then adopt them more broadly when they prove to be successful. And just like we [iterate on our product](https://handbook.gitlab.com/handbook/values/#iteration), we also iterate on our processes, making them better over time.\n\nIn that spirit, here are a few things we’ve tried that have helped to encourage collaboration and connection both within our UX department and with our cross-functional peers.\n\n## Pair designers\n\nWhen I joined as GitLab’s UX director, I spent my first few weeks just talking with the team to understand what was working well and where they needed more support.\n\nA recurring theme was that product designers felt they lacked design peers to partner with. They were getting good feedback from their product managers and engineering partners, but it was different than the support they knew they’d get from another designer.\n\nBecause we’re all remote, the product designers were hesitant to just randomly reach out to another designer, because they didn’t know if they’d interrupt that person’s workflow. They couldn’t just look across the aisle to see if someone was busy. And without a consistent partner, they’d need to give a lot of additional context about the problem they were solving.\n\nWe addressed this by piloting a Pair Designer program where every product designer is assigned a design peer in their same time zone who works on a different part of the product. For six months, this is their go-to person for ideation sessions and quick, on-the-spot design feedback. After six months, we swap pairs to give people more exposure to different ideas, working styles, and product areas.\n\nPair designers are encouraged to work together however they’re comfortable. Some agree to meet for a weekly sync over video, others meet every two weeks, some contact each other ad hoc, and some meet primarily asynchronously.\n\nWe received very positive feedback on the pilot, so we’ve continued this program, and we’re now on our third rotation. It’s been a great way for designers from all over the world to learn from each other. Here’s a quote from one of our designers:\n\n> “I have loved working with each of my 'pairs'’ in UX! Usually we meet once a week for 30 minutes to an hour and spend about half the time each talking about something that is top of mind for us. Sometimes it is just discussing some process or higher level stuff; most of the time we are sharing our screens in Zoom and walking through Sketch, Figma, Axure, someone's branch, etc. to talk through design challenges we are having. The most exciting part of this to me is getting to really dive into a space that I don't get as much exposure to -- also getting to know another designer and having that dedicated time just for us.” [Alexis Ginsberg](/company/team/#uhlexsis), senior product designer at GitLab\n\n## Synchronous kick-off sessions\n\nAt GitLab, we try to work as asynchronously as possible. This is important for a few reasons.\n\nMost importantly, we’re all remote and [globally distributed in 67 countries](/company/team/), so face-to-face meetings aren’t always feasible across varied time zones. Also, we find that asynchronous communication is often faster than meetings. Lastly, by defaulting to asynchronous communication, we always have documentation of the decisions we’ve made and why we made them. Those are some great reasons to default to written communication.\n\nThat said, when a design project first begins, we’ve found that it can be helpful to get everyone together to ask questions, discuss the problem, ideate on possible solutions, and discuss constraints. Depending on the project’s complexity, this can happen very quickly (30 minutes), though bigger problems may take longer.\n\nWhen we have synchronous kick off sessions, we record them and post them to [GitLab Unfiltered](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A), so that anyone who can’t attend still has access to the information. We also document the outcome in a [GitLab issue](https://docs.gitlab.com/ee/user/project/issues/index.html#issues), so that information doesn’t get lost. Lastly, we quickly move from synchronous to asynchronous activities for the reasons noted above.\n\n## Video walkthroughs\n\nAt GitLab, we believe that design is collaborative. That's why we try to involve our team members as early as possible and throughout the entire process. One way to keep our team up to date without having to set up a meeting is to record short videos where we walk them through our designs, preferably in the form of a prototype.\n\n> “If a picture is worth 1000 words, a prototype is worth 1000 meetings.” [Tom & David Kelley](https://blog.prototypr.io/a-prototype-is-worth-1000-meetings-b9ec8107befc)\n\nIn these videos, we lay out the rationale behind our designs and also offer information about other options we thought about and decided against. In certain situations, it also makes sense to add additional background about our long-term vision.\n\nOne of the many positive outcomes from this approach is that even team members who have only been minimally involved are now empowered to provide feedback, add their own ideas, or provide us with additional information about the amount of work our ideas will require.\n\n## UX Showcase\n\nWhen a company is widely distributed, it can be hard to keep up with all of the amazing work that’s happening. Staying updated on changes is especially important in a company like GitLab, where we all work on the same product. We need to understand what other designers are doing and how they are doing it, so we can create seamless workflows that maintain consistency throughout the UI.\n\nIn our biweekly UX Showcase, four product designers each take 15 minutes to share recent work. We have no restrictions on what they share or how they share it. It can be work in progress or something that recently moved to production. Similarly, the \"presentation\" can be as simple as walking through a [GitLab issue](https://docs.gitlab.com/ee/user/project/issues/index.html#issues) or a more elaborate Google Slides deck. The point isn’t to be fancy – it’s just to share information in an easy-to-understand and compelling way.\n\nPersonally, I learn so much from seeing designers talk through the problem they were trying to solve, why it was important, how they solved it, the challenges they encountered along the way, and why the final solution ended up the way it did.\n\nI’m so proud of the work that I see our team doing. It’s as motivating as it is educational.\n\nBut the value of the UX Showcase isn’t just to the UX team. We record the showcases and post them in a [YouTube playlist on GitLab Unfiltered](https://www.youtube.com/playlist?list=PL05JrBw4t0Kq89nFXtkVviaIfYQPptwJz), so that anyone in the company (or the world) can watch, if they’re interested. We also make sure to post links to the videos in a variety of Slack channels, so that our cross-functional peers can watch at their convenience.\n\n## Asynchronous sketching exercises\n\nMost people think about sketching sessions as synchronous and co-located. But at GitLab, we have team members who live in time zones across the world, and we’ve had success at inviting team members to sketch, think, and brainstorm asynchronously.\n\nThis does require a team to already have a good level of trust and a shared understanding of the problem space, but it can be a really efficient way to bring out the team’s creativity, regardless of where in the world they work.\n\nIf you’re interested and would like to see an example, you can learn more in this detailed [blog post](/blog/async-sketching/).\n\n## Slack channel for UX coworking\n\nSometimes designers just want a quick, ad hoc collaboration session, and their Pair Designer may not be immediately available. For times like these, we have a Slack channel dedicated to UX coworking.\n\nIn this channel, designers can ask whether anyone is available for a quick ideation or feedback session. They can also post work in progress to get quick feedback. This has been a great way to promote on-the-spot collaboration within the team.\n\n## Design documentation\n\nThe most important thing to remember when designing remotely is: document, document, document!\n\nAt GitLab, we document our design decisions and rationale in GitLab issues. We even launched a new feature category recently called [Design Management](https://docs.gitlab.com/ee/user/project/issues/design_management.html) that lets designers upload images and invite comments in the same platform that product managers and developers use to do their daily work. We’re adding new features in this category that will make this more and more effective over time.\n\nWhen it comes to UX process, we document everything in our handbook. That means when someone wants to understand how we research, design, and write about our product, the information is always available and up to date. Everyone at GitLab has a shared responsibility to keep this content clear, current, and easy to use.\n\n## All-remote design works!\n\nFor teams that are used to collaborating in person, it can seem like a big leap to go all remote. As someone who has practiced UX in a variety of models – 100% in person, a hybrid of remote and in person, and all remote – what I can say is: It works!\n\nIn my experience, the least effective model is hybrid. Nothing is worse than being one of the few people on video while the rest of the team works in a room together. Your voice just doesn’t get heard.\n\nWe know that we can’t design a great product without close collaboration from our cross-functional peers. When you’re all remote, you have to make a conscious effort to involve peers in your design process early and often. While that takes an extra level of thoughtfulness in an all-remote team, the improved outcomes are worth it.\n\nCover image by [Christina @ wocintechchat.com](https://unsplash.com/@wocintechchat) on [Unsplash](https://unsplash.com/)\n{: .note}\n","culture",[9,770,769],{"slug":1014,"featured":6,"template":701},"designing-in-an-all-remote-company","content:en-us:blog:designing-in-an-all-remote-company.yml","Designing In An All Remote Company","en-us/blog/designing-in-an-all-remote-company.yml","en-us/blog/designing-in-an-all-remote-company",{"_path":1020,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1021,"content":1026,"config":1031,"_id":1033,"_type":14,"title":1034,"_source":16,"_file":1035,"_stem":1036,"_extension":19},"/en-us/blog/discovering-gitlabs-personas",{"title":1022,"description":1023,"ogTitle":1022,"ogDescription":1023,"noIndex":6,"ogImage":986,"ogUrl":1024,"ogSiteName":686,"ogType":687,"canonicalUrls":1024,"schema":1025},"Discovering GitLab’s personas","Our User Experience (UX) Researcher updates us on the progress of GitLab’s personas","https://about.gitlab.com/blog/discovering-gitlabs-personas","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Discovering GitLab’s personas\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarah O’Donnell\"}],\n        \"datePublished\": \"2017-06-08\",\n      }",{"title":1022,"description":1023,"authors":1027,"heroImage":986,"date":1028,"body":1029,"category":870,"tags":1030},[867],"2017-06-08","\n\nBack in January, I explained [why GitLab uses personas in product development](/blog/the-importance-of-ux-personas/). At the time, we were still in the process of discovering who GitLab’s personas were. To make sure that the needs and expectations of our users were met, we asked them to complete a survey to share their views with us. Since then, the results have been analyzed resulting in the first iteration of our personas. In this post, I’d like to share more about the survey which contributed to GitLab’s personas.\n\n## Survey design\n\nThe survey contained a mixture of open-ended and closed-ended questions.\n\nWe chose to use open-ended questions as this was the first survey we had produced which aimed to explore users’ motivations and experiences of using GitLab. We wanted to give participants the freedom to answer questions in their own words and avoid leading them towards answers that they wouldn’t have necessarily selected with close-ended questions.\n\nStudies have shown that people tend to focus more on earlier (primacy effect) or later (recency effect) options, with less time spent evaluating middle options. This suggests  the order in which we present questions to our users may affect the way they respond to them. For example, for the question of ‘Why do you contribute to open source tools?’, there were 10 possible answers users could select from, ranging from ‘To give back to the community’ to ‘To resolve issues I experience with the tool’. To ensure each answer received an equal opportunity to be selected, the ordering of the answers was shuffled between each user. This way, no option remained in the middle of the list and the risk of an option being overlooked due to its position was reduced. Where possible, other closed-ended questions received the same treatment, reducing bias and ensuring a fair distribution of responses.\n\nIn terms of choosing what questions to ask, we asked multiple people working in different teams across GitLab, how they would describe GitLab users. We wanted to be able to test their assumptions, along with our own. Using these assumptions, we formed research questions. Research questions are the goals and objectives of your study, rather than the questions which appear in your survey. They help you to clearly define what it is you want to find out from your survey before you even begin writing it. Once we had our research questions, we wrote the survey to directly address them.\n\nTo ensure that we could extract the information we required from the survey questions, we wanted to make sure that every respondent would interpret the questions the way we had intended. We asked colleagues to complete the survey to see if their answers differed from the true intent of the questions. Any ambiguous wording was amended. The survey was then incrementally shared externally with users. This allowed us to further monitor answers, while also checking the survey for bugs (For example, are users able to submit their answers?).\n\n## Responses\n\nWe were interested in primarily hearing from engaged GitLab users, so the survey was advertised on GitLab’s blog, social media accounts and via the UX webcast. The survey received just over 500 responses over a 50 day period.\n\n## Analysis\n\nSurveys are by no means perfect, they only capture the views of people who feel comfortable sharing information in this way. In brief, the users who chose to respond to the survey could be very different from those who chose not to respond, thus creating selection bias.\n\nMore than 100,000 organizations and millions of users are using GitLab, therefore a sample size of just over 500 people may seem relatively small. In order to identify users who could be underrepresented, it was important to explore who the respondents of the survey were. By comparing the differences between respondents versus nonrespondents, it was easy to identify where the weaknesses were in the data collected and to determine what needed further research. Equally so, it also highlighted the strengths of the data and what could be reported on with near certainty.\n\nSome of the attributes we compared between respondents and nonrespondents included:\n\n - Length of time using GitLab\n - GitLab edition (Community vs Enterprise)\n - Size of organization (for users who used GitLab at work)\n - Job role\n\n We also examined demographic and background information, such as age, location, and programming experience/qualifications.\n\n\n## Results\n\nWe added the newly-formed personas to GitLab's [handbook](https://handbook.gitlab.com/handbook/product/personas/#user-personas).\n\nDon’t feel you’re accurately represented? Don’t worry! The personas are very much a work in progress and we will continue to add to them based on further insights revealed from user interviews, usability testing and future surveys.\n\nWant to share your experiences of GitLab with me? Join [GitLab First Look](/community/gitlab-first-look/) and help us build an even better picture of who GitLab’s users really are!\n{: .alert .alert-gitlab-orange}\n",[9],{"slug":1032,"featured":6,"template":701},"discovering-gitlabs-personas","content:en-us:blog:discovering-gitlabs-personas.yml","Discovering Gitlabs Personas","en-us/blog/discovering-gitlabs-personas.yml","en-us/blog/discovering-gitlabs-personas",{"_path":1038,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1039,"content":1045,"config":1051,"_id":1053,"_type":14,"title":1054,"_source":16,"_file":1055,"_stem":1056,"_extension":19},"/en-us/blog/e-factor-productivity",{"title":1040,"description":1041,"ogTitle":1040,"ogDescription":1041,"noIndex":6,"ogImage":1042,"ogUrl":1043,"ogSiteName":686,"ogType":687,"canonicalUrls":1043,"schema":1044},"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":1040,"description":1041,"authors":1046,"heroImage":1042,"date":1048,"body":1049,"category":870,"tags":1050},[1047],"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](https://handbook.gitlab.com/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",[722,9,768],{"slug":1052,"featured":6,"template":701},"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":1058,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1059,"content":1065,"config":1070,"_id":1072,"_type":14,"title":1073,"_source":16,"_file":1074,"_stem":1075,"_extension":19},"/en-us/blog/five-things-we-learned-from-you-in-recent-ux-research",{"title":1060,"description":1061,"ogTitle":1060,"ogDescription":1061,"noIndex":6,"ogImage":1062,"ogUrl":1063,"ogSiteName":686,"ogType":687,"canonicalUrls":1063,"schema":1064},"5 Things we learned from you in recent UX research","How you use Snippets, whether to rename Auto DevOps, how to improve our billing process, and more.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680847/Blog/Hero%20Images/seven-things-we-learned-from-you-in-recent-ux-research.jpg","https://about.gitlab.com/blog/five-things-we-learned-from-you-in-recent-ux-research","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Things we learned from you in recent UX research\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2019-10-21\",\n      }",{"title":1060,"description":1061,"authors":1066,"heroImage":1062,"date":1067,"body":1068,"category":765,"tags":1069},[740],"2019-10-21","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nThis past quarter, the UX research team was charged with supporting some big [OKRs](https://about.gitlab.com/company/okrs/):\n\n* [Create](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4932) products and experiences that users love and value.\n* Complete at least 5 qualitative interviews per Product Manager — part of scaling UX research across the org, which we’ll [continue](https://gitlab.com/gitlab-org/gitlab-design/issues/665) next quarter.\n* [Implement](https://gitlab.com/gitlab-org/ux-research/issues/362) a pilot of customer satisfaction surveys.\n\nThroughout all of it, researchers continued working to learn more about each [stage group](https://about.gitlab.com/handbook/product/categories/). Here are some of the highlights.\n\n### 1. Snippets can be an extremely useful knowledge base\n\n[Using Snippets](https://gitlab.com/gitlab-org/ux-research/issues/339) to share commonly used code throughout an organization (fixes, install scripts, social icons, etc) can be beneficial for consistency, saving time on searching for solutions, and onboarding new or junior team members.\n\n[Group-level Snippets](https://gitlab.com/gitlab-org/gitlab/issues/15958), [Multi-file Snippets](https://gitlab.com/gitlab-org/gitlab/issues/14340), and [Version control for Snippets](https://gitlab.com/gitlab-org/gitlab/issues/14228) are highly upvoted issues in GitLab’s issue tracker.\n\nCheck out the [full results](https://gitlab.com/groups/gitlab-org/-/epics/2030).\n\n\n\n### 2. After considering other options, you prefer the name “Auto DevOps”\nWe surveyed nearly 200 developers to evaluate 4 terms: ‘Auto Config’, ‘Auto Pipelines’, ‘NoOps’, and ‘Auto DevOps’ (our existing name). The term that did best both in terms of 1) allowing users to accurately predict what the feature does and 2) was considered appropriate for the feature’s definition (i.e. a feature that automatically detects, builds, tests, deploys, and monitors you applications) was Auto DevOps, with Auto Pipelines as a very close second. Consequently, it was decided to stick with Auto DevOps.\n\n[Full results](https://gitlab.com/gitlab-org/ux-research/issues/243#note_224667453)\n\n### 3. You wanted a new flow for enabling security checks\nBased on insights gathered in a previous usability study around users’ mental model, the Secure team created a new flow for enabling security checks, which allows users to configure security checks from the UI itself. We then tested the new flow and saw significant improvement - all participants were able to complete the task, as opposed to only 1 out of 5 before the new design was created. Yay for evidence-based design!\n\n[Full results](https://docs.google.com/presentation/d/1blpG78sBTNYcFyP1DH4gNjmJSB8SGm4xMgVtOe9UXLo/edit)\n\n\n### 4. Logs contain rich data, and you need a better way to manage it\n\n\nLogs are captured for a number of reasons: audit/compliance, security (to monitor against abuse/attacks), and for troubleshooting when things go wrong. Logs are able to capture more information than metrics, but because they capture so much more information, users need a way of managing them, searching through them, and surfacing insights.\n\nAnother interesting finding: You use tracing when things aren’t running as expected and you want to find out what’s going on “under the hood.” It’s underutilized compared to logging.\n\n\n[Full results](https://gitlab.com/gitlab-org/ux-research/issues/276)\n\n### 5. Our billing processes just aren't cutting it\n\nOur billing processes are optimized for large orgs, but don’t support the needs of small businesses as effectively or efficiently. Additionally, our true-up policy is not transparent. We saw customers mistakenly expect adding users to be automatically prorated, often leading to surprise charges at renewal time.\n\nFinally, we have an opportunity to help more customers self-serve. self-managed customers must contact GitLab every time they want to add users to their license, creating friction for customers and taking up valuable support/sales time.\n\n[Full results](https://gitlab.com/groups/gitlab-org/-/epics/1963)\n\n## Join GitLab First Look\nDid you recognize some of the above as your own needs and wants? Or did you disagree with everything completely?! Either way, we want to hear from you.\n\nYou can participate in interviews, surveys, beta tests, and more from the comfort of your own computer 💻✨Your feedback is incredibly important to us, and we hope you consider joining our research program, [GitLab First Look](https://about.gitlab.com/community/gitlab-first-look/).\n\n\nThis round-up was compiled using [research and analysis](https://docs.google.com/presentation/d/1nDFgGQpr6gLQ6wp8UC0WIdb_ZNWGSDCk1Dt8-dliduw/edit#slide=id.g651551733c_6_0) by Katherine Okpara, Tali Lavi, Amelia Bauerly, Iain Camacho, Eileen Ruberto, Lorie Whitaker, and Jeff Crow\n{: .note}\n",[9],{"slug":1071,"featured":6,"template":701},"five-things-we-learned-from-you-in-recent-ux-research","content:en-us:blog:five-things-we-learned-from-you-in-recent-ux-research.yml","Five Things We Learned From You In Recent Ux Research","en-us/blog/five-things-we-learned-from-you-in-recent-ux-research.yml","en-us/blog/five-things-we-learned-from-you-in-recent-ux-research",{"_path":1077,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1078,"content":1084,"config":1089,"_id":1091,"_type":14,"title":1092,"_source":16,"_file":1093,"_stem":1094,"_extension":19},"/en-us/blog/friends-dont-let-friends-add-options-to-code",{"title":1079,"description":1080,"ogTitle":1079,"ogDescription":1080,"noIndex":6,"ogImage":1081,"ogUrl":1082,"ogSiteName":686,"ogType":687,"canonicalUrls":1082,"schema":1083},"Friends don't let friends add options to code","Creating optional features burdens users and applications – here's how we avoid adding options.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678953/Blog/Hero%20Images/options.jpg","https://about.gitlab.com/blog/friends-dont-let-friends-add-options-to-code","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Friends don't let friends add options to code\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Suri Patel\"}],\n        \"datePublished\": \"2018-12-10\",\n      }",{"title":1079,"description":1080,"authors":1085,"heroImage":1081,"date":1086,"body":1087,"category":870,"tags":1088},[951],"2018-12-10","\nSometimes, when trying to make it easier to work in an application, our instinct is to add\noptional features that users can enable if their situations require a specific functionality.\nOur intentions may be good, but these actions can actually cause _more_ problems, since we invite users\n to second-guess their choices by adding extra steps into the user experience.\n\n## The disadvantages of a [choose your own adventure](https://en.wikipedia.org/wiki/Choose_Your_Own_Adventure) model\n\nOne of the most celebrated aspects of [open source](/solutions/open-source/)\nis the freedom that allows developers to brighten a user’s day by adding an\noptional feature that may not be for everyone, but allows a small portion of users\nto engage with a project in a specific way. While it may seem like a great idea\nto cater to individual needs, there are several disadvantages to making something\nan option.\n\n### It creates more work for developers\n\nCreating extra options means more work for both frontend and backend teams.\nThese features add additional code, tests, and documentation for each setting,\nand the various states alter the UI. Adding options hurts you in every step of\nthe development process.\n\n### It places a burden on the user to choose\n\nWhen we solve problems by including options, we force a user to think about the\nfunction and consider its purpose and drawbacks, placing a burden on them to\ncontrol how they use an application. A user hesitates and has to make a decision\nabout whether this is something that should be enabled. After all, if an option\nsignificantly enhanced the user experience, then wouldn’t it have been automatically\nintegrated?\n\n### It makes future functionality more difficult to implement\n\nThere's also the long-term impact of additional options. Just one extra option can lead to one of two\npaths, which might influence other parts of an application. So, every\ntime we add an option, the number of states of the application doubles. That's\nexponential growth and it adds up quickly, making it harder to diagnose errors. Multiple\noptions can lead to the creation of states of which we’re unaware, so\nit’s harder for the user to understand how an application should behave, because\nthey don't know whether errors are due to an option or not. And, if it is an\noption causing the error, _which_ option is the problem?\n\n## How we avoid adding options: Bask in the glow of iteration\n\nSo, how do you know if a feature should be optional or not? At GitLab, we ship\nthe first [iteration](https://handbook.gitlab.com/handbook/values/#iteration) and keep delivering based on\nuser feedback. Some of the features that we anticipated may never roll out,\nbecause users didn’t request them. Iteration allows us to reduce the scope of\ndevelopment and avoid including features that aren’t popular or useable.\n\nWhenever users need something new, try to create a solution that's acceptable\nfor the most number of people. Rely on your development and operations teams to\nprovide feedback and ask them to relate to the end user. Conducting\n[UX research](/handbook/product/ux/ux-research/#ux-research) with your users\nalso helps identify pain points and needs.\n\nTeams are continually constrained by development capacity, and adding options to\napplications can absorb previous time and effort. We suggest shipping your\napplication without an option and waiting to see whether people request it or\nmake a\n[feature proposal](https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name%5B%5D=feature+proposal)\nfor it. In the end, our role is to solve users’ problems, and our goal is to\nidentify the underlying cause of a challenge and fix it in a way that doesn't\nneed an option.\n\n[Cover image](https://unsplash.com/photos/pKeF6Tt3c08) by [Brendan Church](https://unsplash.com/@bdchu614) on Unsplash\n{: .note}\n",[722,9,697,723],{"slug":1090,"featured":6,"template":701},"friends-dont-let-friends-add-options-to-code","content:en-us:blog:friends-dont-let-friends-add-options-to-code.yml","Friends Dont Let Friends Add Options To Code","en-us/blog/friends-dont-let-friends-add-options-to-code.yml","en-us/blog/friends-dont-let-friends-add-options-to-code",{"_path":1096,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1097,"content":1102,"config":1109,"_id":1111,"_type":14,"title":1112,"_source":16,"_file":1113,"_stem":1114,"_extension":19},"/en-us/blog/future-merge-requests-realtime-collab",{"title":1098,"description":1099,"ogTitle":1098,"ogDescription":1099,"noIndex":6,"ogImage":883,"ogUrl":1100,"ogSiteName":686,"ogType":687,"canonicalUrls":1100,"schema":1101},"The future of merge requests: Real-time collaboration","We want to hear your thoughts on the future of merge requests and code review.","https://about.gitlab.com/blog/future-merge-requests-realtime-collab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The future of merge requests: Real-time collaboration\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Pedro Moreira da Silva\"}],\n        \"datePublished\": \"2019-12-19\",\n      }",{"title":1098,"description":1099,"authors":1103,"heroImage":883,"date":1105,"body":1106,"category":870,"tags":1107},[1104],"Pedro Moreira da Silva","2019-12-19","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2019-12-20.\n{: .alert .alert-info .note}\n\nWe want to share some of the work we’ve been doing in the [Source Code](https://handbook.gitlab.com/handbook/product/categories/#source-code-group) part of the product and get feedback on what could be the future of [merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/) and [code review](/direction/create/code_review/).\n\n**Perhaps the best way is to walk you through a short visual story. You can** [**watch the recording (28 min)**](https://www.youtube.com/watch?v=KpdvIU6hv94) **or** [**jump to its text version**](#context) **below. In the end, if you’d like to share your thoughts, you can do so on the** [**feedback issue**][feedback-issue].\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/KpdvIU6hv94\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## Context\n\nIf you haven’t been following along our work on merge requests, let’s set the scene:\n1. In the next releases of GitLab, we’re shipping [**performance**](https://gitlab.com/groups/gitlab-org/-/epics/1417) **and** [**navigation**](https://gitlab.com/gitlab-org/gitlab/issues/33813) **improvements**, based on the user experience research we’ve been doing.\n1. We have also an exciting [**new Sourcegraph integration**](/blog/sourcegraph-code-intelligence-integration-for-gitlab/) which levels up the merge request interface allowing you to navigate code, jumping to definitions or finding references.\n1. **Other improvements** we’ve shipped over the past year include [multiple assignees](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html#multiple-assignees), [multiple approval rules](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#multiple-approval-rules), [code owners](https://docs.gitlab.com/ee/user/project/codeowners/), and [suggest changes][suggest-changes] – all of these were based on research and user feedback (your feedback).\n\nThese are nice improvements but they are iterating on what we already have and are not substantially changing the code review workflow. Today’s merge request experience is pretty similar to what it was five years ago – we’ve improved it a lot but its fundamental structure is the same.\n\nWe’ve been hearing feedback from users and customers about how we might improve merge requests to solve harder problems and that may require rethinking what we’ve come to accept as the default. **The merge request is a significant place, where people collaborate, where knowledge is shared, where people grow in their skills, where code quality is ensured and improved.** As a result, significant time is spent in the merge request interface. So, we’ve been asking ourselves:\n\n> _How can we significantly decrease the cycle time, increase the efficiency of code review, and create better ways of collaborating?_\n\nTo simplify our approach, we have defined **three key questions** that have also surfaced through research and our own usage:\n1. **Catch up**: Understanding where the merge request is since I last looked at it, what needs my attention, what’s changed, and helping me review that difference more efficiently after first reviewing it.\n1. **Real time collaboration**: Many teams are in the same location or same time zone and have significant overlap. Even here at GitLab, an [all-remote company](/company/culture/all-remote/), most people who work together share a few of hours of overlap and are sometimes looking at the same things. So if people are coming to the same merge request, and working on it at the same time, how can we make that more efficient?\n1. **External discussions**: Working remotely, through [asynchronous communication](https://handbook.gitlab.com/handbook/communication/#introduction), is how we mainly communicate at GitLab. It’s something that we do quite well, but sometimes it’s better to work synchronously by just getting on a call and solve confusions, communicate, sketch things out, and then document those decisions. But unfortunately, the merge request doesn’t provide a natural way to do that. We use Zoom, we use Google Docs, and then we try to summarize in merge requests or issues. What if we could integrate all of that into the merge request?\n\nTo explain what we’ve been thinking about and how we could answer these questions, here is a **short visual story**. The following images are very low-fidelity mockups so that we can focus on ideas rather than dwelling on the details.\n\n## 1. Catch up\n\n> The story starts with me, as a reviewer, coming into a merge request and looking at my personal area at the top right corner.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step1.png){: .shadow.medium.center}\n\n> I can immediately see what has happened since I last reviewed the merge request: Two files with new changes to review and one comment that needs my attention. This comment may be someone that mentioned me, someone that replied to one of my comments, or maybe someone that resolved a thread I’m participating in.\n\n## 2. Smarter suggestions\n\n> I click the speech bubble icon to jump to that comment, where Katherine, the merge request author, and James, another reviewer, are participating. Hmm, this discussion is getting a bit convoluted... but since they are in other timezones, I’ll reply with my thoughts so they can read them in their own time. It also looks like we need specific expertise here. When I start @-mentioning, I see that André was the person who last changed this line of code (and he’s also a code owner of this file). He might have an idea why this was changed, so I’ll mention him in my comment.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step2.png){: .shadow.medium.center}\n\nToday in GitLab we already suggest people who are involved in the merge request or conversation, but this idea brings in new data and more clearly highlights why people are relevant.\n\n## 3. Real time collaboration\n\n> Meanwhile, I notice that Katherine and James are **looking at this merge request right now**, by seeing their avatars popping up at the top of the merge request – _very similar to how you would see someone in Google Docs looking at the same document that you are_. I also get a notification saying that Katherine mentioned me in a comment and that James is now replying to one of my comments.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step3.png){: .shadow.medium.center}\n\nI can see people interacting with the merge request in real time, I can notice their presence, but I’m not seeing what they’re typing or collaborating directly with them – we’re just going about doing our tasks separately. **The way we work may change if we expect an immediate response.** For example, if you notice someone is online, you might ask more open-ended questions because you know that the other person can respond more quickly versus writing a longer response that seeks to conclude the discussion faster. And this is helpful not only for people that work distributed and asynchronously but also for people that work in the same time zone, in the same location, in the same office, or even in the same room.\n\n**These presence indicators create certain expectations and give a sense of progress to the merge requests as well.** When you’re waiting on a code review, you don’t know if someone has looked at it or if the reviewers are close to finishing the review. This can save people from interrupting one another. This provides a sense of progress without needing someone to take an active measure to find out if progress is being made. This is important because progress is one of those things that we all want to feel when we’re waiting on someone or something else.\n\n> Back to the story... This is great timing! Since we’re all online maybe it’s time we jump on a call to clear up the discussions together and get back on track.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step4.png){: .shadow.medium.center}\n\n> By using this dropdown button next to the avatars, I can immediately start a shared session or invite the other participants to a video call, using Zoom (one of our favorite tools here at GitLab). Starting a Zoom meeting also starts a collaborative shared session in the merge request. **In the shared session we can follow each other and write comments together in real time.** I can now follow James and Katherine and see which files they are looking at, in which lines they’re commenting, and also what they’re writing, in real time. I can also ask to be followed if I want to focus all of the participants’ attention to a specific comment or file. I can even copy a link to this shared session and share it via our chat tool or email so that others can join without having to find the merge request.\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step5.png){: .shadow.medium.center}\n\nBut the most important thing is the ability to **co-author and collaborate in real time on comments in the merge request**. Not only commenting on the changes but also in the merge request overview (comments that are not attached to specific lines). You can collaborate while you’re in a video call, on the phone, or just in the office next to each other.\n\n## 4. External discussions\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step6.png){: .shadow.medium.center}\n\n> Collaborating in real time on the merge request allowed us to quickly reach a consensus. **And we could easily record everything we discussed in GitLab, instead of using separate tools.** Before ending the shared session, we add a joint comment with a summary and next steps.\n\nWe know that some teams do code reviews in meeting rooms, projecting the changes and all reviewing it together. Everyone’s got their laptops but they’re sort of looking at the same thing, but not quite. These abilities would allow everyone to take notes collaboratively, creating an interesting way of documenting. This is just one use case, there are likely many more use cases that we can solve here.\n\nYou'll notice that it looks a lot like a Google Doc, but on a merge request in GitLab. From a user experience standpoint, we must try to use metaphors and patterns that people have seen and used in other common tools. **Looking and behaving like Google Docs is a good thing because people can immediately relate and understand what these cursors and avatars mean.** But it’s about understanding these paradigms, not accepting them blindly. We strive to study and see if they fit into the situation at hand and if the users recall using this metaphor for this purpose. Using [boring solutions](https://handbook.gitlab.com/handbook/values/#boring-solutions) is part of our values at GitLab.\n\nToday we use Google Docs to take notes during our meetings but maybe this can replace the need to have all of these different tools open simultaneously while we’re on a video call. You can use your preferred tools, like a projector, to collaborate better depending on your work setting and what works best for you and your team, but in the end **everything is recorded in the same tool, in the same integrated environment that is GitLab.** There is no data duplication and it stops teams from using tools like Google Docs to record information that then gets replicated in merge requests and issues, instead the information can go directly into the single source of truth where the decision and discussion are relevant. If we can work out how to do this properly on merge requests we can perhaps apply it to issues and epics as well.\n\n## 5. Record decisions\n\n> Finally, in the shared session we realized that one of the changes must be documented for posterity so that we can prevent mistakes and clarify our decision. So I come back to the comment to commit it to the code base. **This adds the comment directly to the source file as a code comment.**\n\n![](https://about.gitlab.com/images/blogimages/future-merge-requests-realtime-collab/step7.png){: .shadow.medium.center}\n\nOne thing that we see happening a lot at GitLab and in other companies is people explaining a decision or why we shouldn’t touch this specific part of the code, in writing. This valuable content is usually left in comments, emails, or chat messages, when it should be a _code comment_. **Code comments allow explanations, decisions, and rationale to be left for posterity so that future authors can be aware of them.**\n\nOur [suggest changes feature][suggest-changes] in merge requests allows you to include suggestions as part of your line comments. These suggestions can then be applied directly to the file where the comment was made, replacing its contents with the suggestion. With the idea of \"Commit as file comment,\" this is slightly different, as you’d be applying the comment to the file itself, as a code comment.\n\nMoving the explanation into the actual file rather than leaving it as a comment in the merge request **makes it accessible wherever the code goes**. It’s in the Git repository, it has a timestamp, it’s part of the repository history, and it’s even in your desktop IDE. It means that if you refactor your repository, split this module out into another repository, the comment follows that line of code.\n\n## Conclusion\n\n**We’re not entirely sure how these ideas will be executed, if all of them are viable, or if they’re even good ideas.** That is why we’d love to hear your thoughts on the [**feedback issue**][feedback-issue]. Share with us what you like, what you don’t like, and what other ideas you have for code review. This short story doesn’t mean that we’re going through with these ideas but that we think they are possible directions to solve those big problems that we’ve been seeing with code review at GitLab.\n\nIf you visualize the communication tools as a spectrum, right now GitLab’s merge requests are similar to email: you’re sending \"emails\" you’re receiving \"emails\" and it’s not a real time discussion, you’re not seeing what other people are typing, you don’t know when you’re going to get a response. On the other end of the spectrum is Google Docs: You see exactly what people are typing in real time, and expectations are more clear. Somewhere closer to Google Docs, you have Slack, which as a chat tool is very much focused on synchronous communication (although it can also be used for asynchronous communication). **We want to be in the middle of this communication tools spectrum, not like a Google Doc, always on, always real time, but we also don’t want to stay as an \"email client for collaborating on code.\"** We want to be smarter than that, enabling collaboration at the right moments.\n\nOne question that has been raised is **privacy**: People feel concerned about revealing when they’re looking at a merge request. Privacy is also a big concern in the sense of \"peer pressure,\" people changing their behaviors because they know they can be observed by others. We have to find some middle ground between people that opt to be more private and quietly observe things, versus people that opt for maximum efficiency and prefer collaborating in real time when everyone is in the merge request. Another concern is how to **avoid interrupting** people's flow. We anticipate that these are some of the interesting challenges we will have to wrestle with and balance against helping teams work most efficiently.\n\nThese concerns are one of the main reasons why we are sharing our ideas. We realized that these are some of our blind spots and that there could be others, so **we need** [**your feedback**][feedback-issue]. There also might be other, even more amazing, crazy ideas that we haven’t thought of yet which would take merge requests to an exciting new place. **So don’t limit your feedback to the ideas that we’ve come up with, feel free instead to share ideas that you think would make the merge request an even better place to work and get your job done.**\n\nIf you’re interested in our macro strategy and plans of how we’re going to help you better manage, plan, and create in GitLab, take a look at our [Dev strategy](/blog/dev-strategy-review/).\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>  \nHelp shape the future of code review - [Share your feedback][feedback-issue]\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\nCover image by [Mitchell Luo](https://unsplash.com/@mitchel3uo) on [Unsplash](https://unsplash.com/photos/H3htK85wwnU)\n{: .note}\n\n[feedback-issue]: https://gitlab.com/gitlab-org/gitlab/issues/36119\n[suggest-changes]: https://docs.gitlab.com/ee/user/discussions/#suggest-changes\n",[1108,767,9],"code review",{"slug":1110,"featured":6,"template":701},"future-merge-requests-realtime-collab","content:en-us:blog:future-merge-requests-realtime-collab.yml","Future Merge Requests Realtime Collab","en-us/blog/future-merge-requests-realtime-collab.yml","en-us/blog/future-merge-requests-realtime-collab",{"_path":1116,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1117,"content":1123,"config":1130,"_id":1132,"_type":14,"title":1133,"_source":16,"_file":1134,"_stem":1135,"_extension":19},"/en-us/blog/gitlab-dark-mode-is-getting-a-new-look",{"title":1118,"description":1119,"ogTitle":1118,"ogDescription":1119,"noIndex":6,"ogImage":1120,"ogUrl":1121,"ogSiteName":686,"ogType":687,"canonicalUrls":1121,"schema":1122},"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":1118,"description":1119,"authors":1124,"heroImage":1120,"date":1127,"body":1128,"category":829,"tags":1129},[1125,1126,930],"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",[768,9,829,496],{"slug":1131,"featured":91,"template":701},"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":1137,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1138,"content":1143,"config":1149,"_id":1151,"_type":14,"title":1152,"_source":16,"_file":1153,"_stem":1154,"_extension":19},"/en-us/blog/gitlab-design-library",{"title":1139,"description":1140,"ogTitle":1139,"ogDescription":1140,"noIndex":6,"ogImage":883,"ogUrl":1141,"ogSiteName":686,"ogType":687,"canonicalUrls":1141,"schema":1142},"Scaling design: The start of system thinking","How we began the process of introducing a design system to GitLab.","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":1139,"description":1140,"authors":1144,"heroImage":883,"date":1146,"body":1147,"category":870,"tags":1148},[1145],"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",[768,9,722],{"slug":1150,"featured":6,"template":701},"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":1156,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1157,"content":1163,"config":1170,"_id":1172,"_type":14,"title":1173,"_source":16,"_file":1174,"_stem":1175,"_extension":19},"/en-us/blog/gitlab-for-designers",{"title":1158,"description":1159,"ogTitle":1158,"ogDescription":1159,"noIndex":6,"ogImage":1160,"ogUrl":1161,"ogSiteName":686,"ogType":687,"canonicalUrls":1161,"schema":1162},"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":1158,"description":1159,"authors":1164,"heroImage":1160,"date":1166,"body":1167,"category":301,"tags":1168},[1165],"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](https://handbook.gitlab.com/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",[767,722,9,768,1169],"DevOps",{"slug":1171,"featured":6,"template":701},"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":1177,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1178,"content":1184,"config":1189,"_id":1191,"_type":14,"title":1192,"_source":16,"_file":1193,"_stem":1194,"_extension":19},"/en-us/blog/gitlab-iconography-where-mvc-meets-visual-design",{"title":1179,"description":1180,"ogTitle":1179,"ogDescription":1180,"noIndex":6,"ogImage":1181,"ogUrl":1182,"ogSiteName":686,"ogType":687,"canonicalUrls":1182,"schema":1183},"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":1179,"description":1180,"authors":1185,"heroImage":1181,"date":1186,"body":1187,"category":301,"tags":1188},[930],"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",[768,770,9],{"slug":1190,"featured":6,"template":701},"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":1196,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1197,"content":1203,"config":1208,"_id":1210,"_type":14,"title":1211,"_source":16,"_file":1212,"_stem":1213,"_extension":19},"/en-us/blog/gitlab-ux-2020-year-in-review",{"title":1198,"description":1199,"ogTitle":1198,"ogDescription":1199,"noIndex":6,"ogImage":1200,"ogUrl":1201,"ogSiteName":686,"ogType":687,"canonicalUrls":1201,"schema":1202},"GitLab UX 2020 Year in Review","2020 was a difficult but productive year. Let's take a look back.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749664102/Blog/Hero%20Images/gitlab-values-cover.png","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":1198,"description":1199,"authors":1204,"heroImage":1200,"date":1205,"body":1206,"category":829,"tags":1207},[847],"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",[9,768,722,698],{"slug":1209,"featured":6,"template":701},"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":1215,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1216,"content":1222,"config":1227,"_id":1229,"_type":14,"title":1230,"_source":16,"_file":1231,"_stem":1232,"_extension":19},"/en-us/blog/gitpod-desktop-app-personal-activities",{"title":1217,"description":1218,"ogTitle":1217,"ogDescription":1218,"noIndex":6,"ogImage":1219,"ogUrl":1220,"ogSiteName":686,"ogType":687,"canonicalUrls":1220,"schema":1221},"Why we built GitDock, our desktop app to navigate your GitLab activities","Life is full of moving parts. We get it. And that's why we created GitDock so you can keep track of all things GitLab right from your desktop.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/gitpod-desktop-app-personal-activities","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we built GitDock, our desktop app to navigate your GitLab activities\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Marcel van Remmerden\"},{\"@type\":\"Person\",\"name\":\"Jeremy Elder\"}],\n        \"datePublished\": \"2021-10-05\",\n      }",{"title":1217,"description":1218,"authors":1223,"heroImage":1219,"date":1224,"body":1225,"category":870,"tags":1226},[929,930],"2021-10-05","\n\nKeeping track of everything that is happening in your GitLab projects and groups can be quite overwhelming. Often times you care about not only one project, but multiple ones. Even worse, these projects might even belong to different groups, making everything more complex.\n\nAs an example, product designers at GitLab might work on all of these different projects over the course of just one week:\n\n- [gitlab-org/gitlab](https://gitlab.com/gitlab-org/gitlab) (our product)\n- [gitlab-com/www-gitlab-com](https://gitlab.com/gitlab-com/www-gitlab-com) (our handbook)\n- [gitlab-org/gitlab-design](https://gitlab.com/gitlab-org/gitlab-design/) (space for discussions)\n- [gitlab-org/gitlab-services/design.gitlab.com](https://gitlab.com/gitlab-org/gitlab-services/design.gitlab.com) (our design system)\n- [gitlab-org/ux-research](https://gitlab.com/gitlab-org/ux-research) (research studies)\n\n## User-centric vs. project-centric navigation\n\nOne of our product design managers ([@jackib](https://gitlab.com/jackib)) created a visualization that shows the current project-centric navigation model that we have in place.\n\n![Project-centric navigation](https://about.gitlab.com/images/blogimages/2021-10-05-gitdock/project-centric-navigation.png)\n\nThis model puts the burden of keeping track of your activities and the work you care about on the user. We would rather look for opportunities where we can enable a more user-centric navigation.\n\n![User-centric navigation](https://about.gitlab.com/images/blogimages/2021-10-05-gitdock/user-centric-navigation.png)\n\n## Why do we care about this?\n\nUsers already have different ways to stay up to date, for example email notifications, our \"to-dos,\" or custom systems they have set up for themselves. However, when we ran a UX research study, we noticed these tools often times only show a small subset of the things that users are curious about or the tools have to be checked multiple times during the day.\n\nA short summary of the main points we learned from this study:\n\n- Maintainers care about what happened to their project since they last looked at it.\n- Users repeatedly check their pipelines to see the results.\n- Often times users need to jump back into issues/MRs they have recently contributed to.\n\n## What is GitDock?\n\nGitDock is a desktop app you can install on your macOS/Windows/Linux machine (download [latest release](https://gitlab.com/mvanremmerden/gitdock/-/releases)). When installed, you will have an icon on your menu bar that brings up a small window.\n\n![GitDock](https://about.gitlab.com/images/blogimages/2021-10-05-gitdock/gitdock-window.png)\n\nFrom there you will have direct access to the following information:\n\n- The last pipelines you triggered\n- Your recently viewed GitLab objects (MRs, Issues, Epics, etc...)\n- Favorite projects\n- Your most recent comments\n- Bookmarked items\n\nGitDock also sends you a system notification whenever a pipeline completes, or when a new to-do was created for you.\n\nAll of these features try to put the user at the center. You can see me walk through all functionality in this overview video:\n\n[![YouTube video](https://about.gitlab.com/images/blogimages/2021-10-05-gitdock/gitdock-youtube.png)](https://www.youtube.com/watch?v=WkVS38wo4_w)\n\nYou can also see the entire code in our [GitDock](https://gitlab.com/mvanremmerden/gitdock) project and download the [newest release for your machine](https://gitlab.com/mvanremmerden/gitdock/-/releases). \n\n## Why didn't we make this part of our Web UI?\n\nThe main goal for GitDock is to help us learn how users want to navigate in this more user-centric approach. We decided to build this [minimum viable change (MVC)](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc) in a separate product as it allowed us to move faster and use a few shortcuts, e.g. relying on the local browser history for the recently viewed items instead of storing these in our database. It also permitted us to cut some corners on performance as our API is not yet optimized for this approach. Here's one way example of how it's not optimized: getting the last pipeline you triggered requires three API calls to different endpoints.\n\nOne other advantage is that it gives us a space to test new ideas that we are curious about without having to fully commit to them (e.g. bookmarks).\n\n## What are the next steps?\n\nWe want to use the learnings and data from this project to help us [build a better start page for GitLab](https://gitlab.com/gitlab-org/gitlab/-/issues/225331). Right now this page is configurable and can show you different content, but almost 99% of users keep the default \"Your projects\" list as start page. We don't think users do this because it is truly the most useful option, and we want to create a better experience for this.\n\nThat's why we are still looking for feedback. Let us know what you think about GitDock and what other content would be helpful for you in a start page, or other navigation feature.\n",[722,9,1169],{"slug":1228,"featured":6,"template":701},"gitpod-desktop-app-personal-activities","content:en-us:blog:gitpod-desktop-app-personal-activities.yml","Gitpod Desktop App Personal Activities","en-us/blog/gitpod-desktop-app-personal-activities.yml","en-us/blog/gitpod-desktop-app-personal-activities",{"_path":1234,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1235,"content":1241,"config":1246,"_id":1248,"_type":14,"title":1249,"_source":16,"_file":1250,"_stem":1251,"_extension":19},"/en-us/blog/hey-icons-lighten-up",{"title":1236,"description":1237,"ogTitle":1236,"ogDescription":1237,"noIndex":6,"ogImage":1238,"ogUrl":1239,"ogSiteName":686,"ogType":687,"canonicalUrls":1239,"schema":1240},"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":1236,"description":1237,"authors":1242,"heroImage":1238,"date":1243,"body":1244,"category":301,"tags":1245},[930],"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",[768,770,9],{"slug":1247,"featured":6,"template":701},"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":1253,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1254,"content":1260,"config":1267,"_id":1269,"_type":14,"title":1270,"_source":16,"_file":1271,"_stem":1272,"_extension":19},"/en-us/blog/how-holistic-ux-design-increased-gitlab-free-trial-signups",{"title":1255,"description":1256,"ogTitle":1255,"ogDescription":1256,"noIndex":6,"ogImage":1257,"ogUrl":1258,"ogSiteName":686,"ogType":687,"canonicalUrls":1258,"schema":1259},"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":1255,"description":1256,"authors":1261,"heroImage":1257,"date":1262,"body":1263,"category":1264,"tags":1265},[1047],"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",[9,768,1266,722],"growth",{"slug":1268,"featured":6,"template":701},"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":1274,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1275,"content":1281,"config":1289,"_id":1291,"_type":14,"title":1292,"_source":16,"_file":1293,"_stem":1294,"_extension":19},"/en-us/blog/how-i-transitioned-from-frontend-to-ux",{"title":1276,"description":1277,"ogTitle":1276,"ogDescription":1277,"noIndex":6,"ogImage":1278,"ogUrl":1279,"ogSiteName":686,"ogType":687,"canonicalUrls":1279,"schema":1280},"How I transitioned from frontend to UX","One GitLab team-member shares how switching from a frontend engineer to a UX designer has been a rewarding experience.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679015/Blog/Hero%20Images/frontendux.jpg","https://about.gitlab.com/blog/how-i-transitioned-from-frontend-to-ux","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How I transitioned from frontend to UX\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Annabel Dunstone Gray\"}],\n        \"datePublished\": \"2018-10-05\",\n      }",{"title":1276,"description":1277,"authors":1282,"heroImage":1278,"date":1284,"body":1285,"category":1011,"tags":1286},[1283],"Annabel Dunstone Gray","2018-10-05","\nWhen I joined GitLab over two and a half years ago as a frontend engineer, I brought with\nme a background in photography and an interest in art and design. In my last year\nof university, I worked at an art museum, and I’ve always gravitated towards the\nmore design-y aspects of frontend. For each release, my assigned deliverables\nwere usually focused on redesigns, and while I enjoy that type of work, what I\nreally wanted to do was to help shape the look and feel of GitLab, rather than\nimplementing the designs of others.\n\n## Making the first move\n\nAt GitLab, we're lucky to have the opportunity to [transfer](/handbook/people-group/promotions-transfers/#department-transfers)\nto a different department, if our interests or career goals change. I spoke with\nmy frontend manager about my passions and shared my desire to start learning and\nworking with the UX team. I then spoke with [Sarrah](/company/team/#SVesselov),\nthe UX Manager, about the next steps, and I started working through online\ntutorials, getting up to speed on Sketch, and attending the UX weekly calls.\nOnce I acquired the necessary technical skills, I joined the [Plan](/direction/#plan)\nteam, which is focused mostly on the prioritization of ideas, allocation of\nresources, scheduling, and tracking. It’s an area I’m really excited about, and\nwe’re working on some incredibly useful management features (like [improved issue boards](https://gitlab.com/gitlab-org/gitlab-ce/issues/48847), [sub-epics](https://gitlab.com/gitlab-org/gitlab-ee/issues/7327), and [value stream management](https://gitlab.com/groups/gitlab-org/-/epics/229)) that will help make\nGitLab an even more powerful tool.\n\nAs a frontend engineer, I was fortunate to have developed many transferable\nskills which helped me tackle this new challenge. Attention to detail is one\nskill that has been particularly useful when working on a new feature. Since\nI’m new to UX, I’ve found it really helpful to have a technical background,\nespecially considering that GitLab is such a technical product.\n\n## Advice to others\n\n![Me and my daughter attending a frontend meeting.](https://about.gitlab.com/images/blogimages/annabelandbaby.jpg){:.shadow.small.right.wrap-text}\n\nIf you’re interested in making a similar transition, I encourage you to speak\nwith your manager. I wish I’d done so sooner. I discussed my interests early\nlast year, but after having a baby, I had this idea that I\nshould stay in my current role, as I would never have time to learn a whole new\npractice. While I definitely don’t have any free time (I don’t know if you’ve\nheard – babies are quite time consuming), I’m so happy to be on the UX team, even\nthough I have a lot of catching up to do. Everyone in both frontend and UX has\nbeen incredibly supportive of my switching teams, and I’m learning a lot as I go\nalong. For now, I’ve got the best of both worlds – 50 percent of my time is focused on\nstyling-related frontend issues and reviewing the CSS in merge requests, while\nthe other 50 percent is working on UX issues.\n\nBy the way, we're hiring for loads of positions, across the company – [check out our current job openings](/jobs/).\n\n[Cover image](https://unsplash.com/photos/aLGiPJ4XRO4) by [Bharath](https://unsplash.com/@xen0m0rph), licensed under [CC X](https://unsplash.com/license).\n{: .note}\n",[9,1287,1288,722],"frontend","careers",{"slug":1290,"featured":6,"template":701},"how-i-transitioned-from-frontend-to-ux","content:en-us:blog:how-i-transitioned-from-frontend-to-ux.yml","How I Transitioned From Frontend To Ux","en-us/blog/how-i-transitioned-from-frontend-to-ux.yml","en-us/blog/how-i-transitioned-from-frontend-to-ux",{"_path":1296,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1297,"content":1302,"config":1308,"_id":1310,"_type":14,"title":1311,"_source":16,"_file":1312,"_stem":1313,"_extension":19},"/en-us/blog/how-non-engineers-experience-gitlab",{"title":1298,"description":1299,"ogTitle":1298,"ogDescription":1299,"noIndex":6,"ogImage":1200,"ogUrl":1300,"ogSiteName":686,"ogType":687,"canonicalUrls":1300,"schema":1301},"Uncovering the diverse needs of non-engineering GitLab users","This post describes how the System Usability Scale (SUS) uncovered opportunities to improve the GitLab user experience for non-engineering users.","https://about.gitlab.com/blog/how-non-engineers-experience-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Uncovering the diverse needs of non-engineering GitLab users\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erica Huang\"}],\n        \"datePublished\": \"2020-10-26\",\n      }",{"title":1298,"description":1299,"authors":1303,"heroImage":1200,"date":1305,"body":1306,"category":765,"tags":1307},[1304],"Erica Huang","2020-10-26","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nI discovered UX research when I was looking for my next opportunity early this year as a researcher. The field's initial impression intrigued me, so I spent the following weeks learning from online courses, books, and other UX researchers. I started networking and asking for informational interviews. One particular conversation with [Katherine Okpara](https://gitlab.com/katokpara), UX Researcher at GitLab, led to a capstone project. We discussed the System Usability Scale (SUS) survey that is run quarterly at GitLab and uncovered an opportunity to better the user experiences for GitLab users in non-engineering roles.\n\n### Understanding the problem\nAfter taking a closer look at the trends and themes from the survey data, I learned that many non-engineer GitLab users are having difficulties working in GitLab. Most feedback came from users in product management, product design, academic research, and executive leadership.\n\nBased on the SUS feedback, I hypothesized that non-engineer GitLab users take longer to learn how to use the tools in GitLab. They may be overwhelmed by the many features of GitLab and have less experience with competitor tools.\n\n> With all the Auto- and advanced DevOps features creeping in constantly, it becomes harder to use Gitlab as a simple git repository system with issues/MR/wiki/simple CI for small non-DevOps teams…\n\nMany engineers expressed their frustrations with persuading or teaching their non-engineer colleagues to use GitLab.\n\n> I've been using GitLab for more than four years, so it's obvious and intuitive to me, but I am finding coworkers new to GitLab are increasingly unable to figure out some of the features on their own. As a specific example, we had someone propose to use a different code review tool, but when I showed them how to do a side-by-side diff and view the file tree, they were OK with it. These features are obvious to me as I've watched them get added over time, but I think the cues for them may be too subtle to new users.\n\nAfter considering these challenges, I believed that non-engineer users would benefit from a tailored onboarding experience.\n\n### Defining goals and objectives\n\nThrough this project, my goal was to understand these users' needs and pain points and identify ways to improve their user experience with GitLab, especially during the onboarding process. I set out to answer these questions:\n- What are the areas of GitLab particularly challenging for non-engineer users?\n- How long does it currently take non-engineer users to get comfortable with GitLab?\n- What do users need to learn during onboarding to use GitLab more easily?\n\n### Conducting interviews with GitLab users\nTo get a deeper understanding of the user experiences, I wanted to interview diverse groups of roles and get as many sides of the story possible. I started close to home and spoke with GitLab employees who use GitLab every day for work.\nFrom this set of interviews, I learned that:\n- The majority of the participants expressed frustration with using the Search function.\n- The majority of the participants utilized other tools such as Figma and Google Docs to complete their work.\n\nThe next step was to conduct interviews with external GitLab users to ensure that I was forming a balanced perspective. I recruited participants by sending a screener to the GitLab First Look research panel and experimented with recruiting outside sources such as Reddit and LinkedIn.\n- All of the participants proposed the need for a better workflow\n- Some participants would like a more robust approval system that easily tracks the project and its members.\n\n### Leveraging secondary research\nDue to recruiting constraints, I could not interview as many external users as needed to gain a full picture of their experiences. To conclude everything I learned so far, I decided to look into data from previous GitLab research projects and analyze findings according to the themes observed in each set of data.\nFrom this secondary research, I learned that needs of non-engineer GitLab users were diverse depending on their specific roles:\n- Many researchers expressed that they want the ability to reorganize and customize their GitLab UI.\n- Executives said that the page layouts and overall structure are too complex and affect how they navigate the site.\n- Many product managers expressed that GitLab features are inefficient and incomplete for task management and tracking.\n- Many non-engineer GitLab users want a documentation feature separate from Wiki.\n\n### Synthesizing findings from interview and survey data\nOverall, many non-engineer GitLab users suggested improved onboarding and better help documentation to help them get used to new features. These users are overwhelmed by GitLab features and want to customize the feature menu they see.\n\nI also saw a trend of users having trouble finding what they need from using the search function. Additionally, these users are more likely to supplement missing features with other services (i.e., Jira, Trello, Google Docs, MURAL, Figma).\n\n### What's next?\nI now have a better idea of the challenges and needs of diverse groups of people who use GitLab. To invest in critical areas that would improve the GitLab experience for non-engineers, I recommend the following next steps:\n- Stakeholder Interviews: Present findings to the stakeholder and get their perspectives. Understand whether the research insights are consistent with business needs and outline potential deliverables.\n- Usability Test: Learn about the users' behaviors in action. How are non-engineering users navigating between features? Where do they experience challenges, and where do they experience delight?\n- A/B Testing: Compare the current UI design to a design iteration that results from the findings.\n\n### What I learned\nUnfortunately, research projects don't always go as planned, so researchers will need to be adaptable. Adequate documentation will allow researchers to revisit past projects to collect secondary research for instances like these. It will also make it easier for stakeholders to access research projects without going through researchers each time.\n\n### About the guest author\nErica's background is in academic research and psychology. Her curiosity about human behavior and emotions steered her in the direction of research. Her favorite ways of learning are through her own experience and from listening to other people's stories.\n",[9,698],{"slug":1309,"featured":6,"template":701},"how-non-engineers-experience-gitlab","content:en-us:blog:how-non-engineers-experience-gitlab.yml","How Non Engineers Experience Gitlab","en-us/blog/how-non-engineers-experience-gitlab.yml","en-us/blog/how-non-engineers-experience-gitlab",{"_path":1315,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1316,"content":1321,"config":1326,"_id":1328,"_type":14,"title":1329,"_source":16,"_file":1330,"_stem":1331,"_extension":19},"/en-us/blog/how-to-improve-communication-remote-designer",{"title":1317,"description":1318,"ogTitle":1317,"ogDescription":1318,"noIndex":6,"ogImage":883,"ogUrl":1319,"ogSiteName":686,"ogType":687,"canonicalUrls":1319,"schema":1320},"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":1317,"description":1318,"authors":1322,"heroImage":883,"date":1323,"body":1324,"category":765,"tags":1325},[1104],"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://handbook.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://handbook.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://handbook.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://handbook.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://handbook.gitlab.com/handbook/communication/#simple-language) **and terms that everyone understands** (see [ubiquitous language](https://handbook.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://handbook.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",[767,768,769,9],{"slug":1327,"featured":6,"template":701},"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":1333,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1334,"content":1340,"config":1345,"_id":1347,"_type":14,"title":1348,"_source":16,"_file":1349,"_stem":1350,"_extension":19},"/en-us/blog/how-we-utilize-user-stories-as-a-collaborative-design-tool",{"title":1335,"description":1336,"ogTitle":1335,"ogDescription":1336,"noIndex":6,"ogImage":1337,"ogUrl":1338,"ogSiteName":686,"ogType":687,"canonicalUrls":1338,"schema":1339},"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":1335,"description":1336,"authors":1341,"heroImage":1337,"date":763,"body":1343,"category":765,"tags":1344},[1342],"Rayana Verissimo","\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://handbook.gitlab.com/handbook/product/personas/#rachel-release-manager), [DevOps Engineers (Devon)](https://handbook.gitlab.com/handbook/product/personas/#devon-devops-engineer), [Software Developers (Sasha)](https://handbook.gitlab.com/handbook/product/personas/#sasha-software-developer), and [Development Team Leads (Delaney)](https://handbook.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](https://handbook.gitlab.com/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",[9,768,767,722,768],{"slug":1346,"featured":6,"template":701},"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":1352,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1353,"content":1358,"config":1364,"_id":1366,"_type":14,"title":1367,"_source":16,"_file":1368,"_stem":1369,"_extension":19},"/en-us/blog/how-we-uxd-our-secure-ux-team",{"title":1354,"description":1355,"ogTitle":1354,"ogDescription":1355,"noIndex":6,"ogImage":1200,"ogUrl":1356,"ogSiteName":686,"ogType":687,"canonicalUrls":1356,"schema":1357},"How we UX'd our Secure UX team structure","The Secure UX team's approach toward collaboration, authorship, information discovery and team structure.","https://about.gitlab.com/blog/how-we-uxd-our-secure-ux-team","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we UX'd our Secure UX team structure\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Kyle Mann\"},{\"@type\":\"Person\",\"name\":\"Andy Volpe\"}],\n        \"datePublished\": \"2019-10-11\",\n      }",{"title":1354,"description":1355,"authors":1359,"heroImage":1200,"date":1361,"body":1362,"category":301,"tags":1363},[1360,716],"Kyle Mann","2019-10-11","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nAt GitLab, change is part of our DNA. We embrace constant iteration and evolution in our product and our company.\n\nThis year, much of the change we’ve experienced has been due to company growth. We’ve literally doubled in size, increasing from around 400 to over 800 team members in a very short period of time. Naturally, that growth brought changes to how we organize our product teams. What were once small, interdisciplinary stage groups quickly grew to become multiple, dedicated teams within each Stage. For example, in Secure, we saw the creation of three separate teams, all with dedicated Engineering resources and Product Managers.\n\nOn the UX team structure side of things, we knew we needed to support our Stage by creating a similar division of responsibilities. But questions kept coming up: How would we divide our efforts while still creating an integrated experience? And how could we address some gaps that were already becoming more evident as we scaled?\n\nWe decided to treat this problem like we do any other UX challenge. First, we clearly identified the problem:\n\n```\nHow might we maintain our effectiveness as a design team within an evolving company structure?\n```\n\nWith the problem identified, we began iterating through solutions and identifying subtasks and processes that helped to solve it.\n\nSomething we learned early on is that what we create today will likely be outdated next week... and we’re okay with that! Problem solving for scale and unknown change is difficult. Something that works with a team of 3 might not work with a team of 6. We were going to have to be flexible. We didn’t come out with exact answers or a silver bullet, but we did discover some best practices that helped along the way.\n\n## Taking the guess work out of UX\n\nUXers are a curious bunch. We’re always asking questions: who are our users, what problems are we solving, and why are we solving them? (And then we ask why again.) The purpose of these questions is to help remove guesswork from our proposed solutions. We wanted to approach solving this problem in the same way.\n\nSo, we started by putting together a [foundations document](https://gitlab.com/gitlab-org/gitlab-design/issues/333) that asked all of the usual questions. Then, we shared it cross-functionally, so anyone could contribute to the answers and add more questions.\n\nWe learned that we knew some things, but there was also a lot that we didn't know. That’s OK, because what you don't know can sometimes be more important than what you do know. Open questions can serve as a checklist of information to uncover.\n\nAsking (and answering some of) the questions in our foundations document resulted in the first iteration of our [Secure UX page](https://about.gitlab.com/handbook/product/ux/stage-group-ux-strategy/secure/). This page will grow over the next year, as we get to know our users and problem space through [research](https://gitlab.com/groups/gitlab-org/-/epics/1611), [UX Scorecards](https://about.gitlab.com/handbook/product/ux/ux-scorecards/), cross-stage collaboration, and talking with users. The key insights we gain will continue to inform our handbook page for shared team awareness.\n\nAndy:\n_\"Having this document in place helped us take inventory across the entire Stage of where the knowledge gaps exist and focus our efforts toward uncovering critical information.\"_\n\nKyle:\n_“When I joined the team, the foundations document project was a great way to peel the different layers of our product, drive conversation, and better understand cross-functional motivations. I’m elated that other stage groups have adopted the process and found it helpful!“_\n\n## Getting to know your team\n\nEarly on, we realized that we needed to have more face-to-face time than we were accustomed to. We met this challenge by having weekly 1:1s with each other and maintaining a consistent cycle of coffee chats with our Stage group counterparts. (It’s a little like doing user research to understand pain points and possible areas of confusion.)\n\nWhen a team is rapidly growing, it's crucial to embrace collaboration and transparency. Surfacing challenges early allows for opportunities to emerge before a problem does.\n\nFor us, there was no shortage of hard conversations and growing pains, but that was when real growth and progress happened.\n\nMaintaining and cultivating relationships with the team and the Stage has enabled us to have more productive conversations. As an unexpected result, we work more effectively asynchronously now more than ever and rely less on ad-hoc chats and meetings. But we still have our coffee chats and 1:1s. We aren't giving those up!\n\nKyle:\n_\"Sharing your vulnerabilities with each other is a powerful way to bring you closer together and evolve your team’s relationships. Establishing mutual trust compounds the effects of collaborative efforts and can be the difference between success and failure of a project.\"_\n\nAndy:\n_\"It's refreshing to be able to know and understand teammates’ thought processes, decision tendencies, and the way they like to communicate. It was a challenge, at first, adjusting to more synchronous communication and collaboration, but the results speak for themselves.\"_\n\n## Sharing work and splitting work\n\nSomething we realized after becoming a two-designer Secure UX team was that we were both trying to become experts on a diverse range of security topics. It’s an intrinsic trait of designers that we want to \"know all the things,\" so we can be informed when making design decisions.\n\nUnexpectedly, though, we were overlapping each other's work, which meant we weren't finding success or collaborating well.\n\nBy not having a dedicated area of focus within the Secure Stage, we each had conflicting views and approaches to the same features. We were continually \"rebasing\" our design and exploration work because of UX conflicts that manifested.\n\nSo we hired a UX manager.\n\nJust kidding!!! But when our new manager, [Valerie](https://about.gitlab.com/company/team/?department=ux-department#vkarnes), joined our team, she was able to guide us toward creating areas where we would have ownership.\n\nCoincidentally, the engineering team also split within the stage groups at this same time, giving us the opportunity to create dedicated areas of focus and align better with our counterparts.\n\nWe started the task of creating separate UX areas by running a quick brainstorming session with the Secure UX team (just like we do at the beginning of a new project). From there, we looked at the areas our Stage categories were meant to cover, and we began aggregating that information into this [mural board](https://app.mural.co/invitation/mural/gitlab2474/1560787085910?sender=avolpe0924&key=3738c3db-031c-44ba-b542-d7da00aa4bca). It was the same affinity mapping process we use to look for commonalities in research findings or stakeholder requirements..\n\nWhat the affinity map helped us quickly see was: while there were areas of clear ownership where we could split work, there were areas where we needed to share work, too. This [issue](https://gitlab.com/gitlab-org/gitlab-design/issues/458) summarizes what we learned.\n\n### Shared work\n\nHere’s the work that we decided to share:\n\n- Interacting with vulnerabilities\n- Status, reporting, and metrics for vulnerabilities\n- Information architecture and inter-stage experiences\n\nThese areas are core to the Secure experience, and they benefit from collaborative design work and exploration.  But the benefits don’t end with our product UX—they help our team work better together, too:\n\n- We gain an established common purpose.\n- Our trust grows as we get to know each other better.\n- We fail and succeed together.\n- We have more opportunities to create new and unique solutions.\n- We gain visibility into how another designer may have solved a similar problem in the past.\n\nBy sharing work, we’re also able to improve our onboarding experience for new product designers. When new teammates join, we work together to find a shared issue that will help them better understand the product and that they can contribute to without much domain knowledge.\n\nFor example, when [Becka](https://about.gitlab.com/company/team/?department=protect-ux-team#beckalippert) and [Camellia](https://about.gitlab.com/company/team/?department=secure-ux-team#cam.x) recently joined the team, we purposely chose [shared issues](https://gitlab.com/dashboard/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=Secure%20UX%3A%3AShared) as excellent shadow opportunities. These serve as great introductions into the Stage and the security field and will help build their foundational knowledge in both.\n\nThese shared issues help everyone obtain a richer contextual understanding of the design problems we are solving for as a team. In the end, our product and experience will benefit as a result.\n\n### Split work\n\nWhile shared work has its advantages, so does splitting our efforts to focus on specific domains and features. The benefits we've seen:\n\n- We can work closely and consistently with engineers.\n- We’re able to grow our domain knowledge about a particular area.\n- We experience less of the friction caused by context switching.\n- We’re better able to envision and create an end-to-end experiences for our users.\n\nSplit work doesn't mean solo work, necessarily. The GitLab UX team hosts weekly group design feedback sessions where designers share their work and the UX team offers feedback. Our UX Director often says, \"I learn the most about our product in these sessions!\" We definitely agree.\n\nThat’s why we also do our best to share work during cross-functional meetings and asynchronously on our [Secure UX](https://www.youtube.com/playlist?list=PL05JrBw4t0KrFCe5BgUkzFrZifjforQOz) playlist on the [GitLab unfiltered YouTube](https://www.youtube.com/channel/UCMtZ0sc1HHNtGGWZFDRTh5A) channel. For us, a divide-and-conquer approach doesn't mean that other teammates aren’t involved.\n\nAn excellent example of collaborating on split work is the [UX Scorecard initiative](https://about.gitlab.com/handbook/product/ux/ux-scorecards/) in Q3 to collaborate on the new Security gates feature. This is a software composition feature (Kyle's split focus), though the MR aspect is closely related to vulnerabilities detected in the MR (Andy's split focus). In this case, Andy will conduct [#534](https://gitlab.com/gitlab-org/gitlab-design/issues/534), and Kyle will do [#533](https://gitlab.com/gitlab-org/gitlab-design/issues/533); then we'll work together on next steps and design improvement recommendations. Since each of the issues is tied to different personas, we see this is an opportunity for us to be an advocate for each unique user and focus strictly on their experience—all while working together on a cross-stage solution that benefits the feature.\n\nAndy:\n_“Having both a dedicated area of focus and shared areas of focus has given me an opportunity to dive deep into the specific niche areas of AppSec and uncover valuable insights about our users, their goals, and the technical challenges they face while still being able to see the bigger picture.”_\n\nKyle:\n_“Merging our efforts is a crucial aspect to our design process. This helps ensure our split work results in a cohesive experience for our users.”_\n\n## Putting it all together\n\nIn the next few months, we have two new designers joining Secure and another for Protect. We’re thrilled to continue evolving our team and partnering with our new teammates on a path forward. Our mission and commitment are clear: To create a best in-class security and compliance experience for our customers.\n\nThanks for reading! Any thoughts to share? Do you have stories about scaling your UX team? Tell us in the comments below!\n\n_Interested in joining the team? [We’re hiring!](https://about.gitlab.com/jobs/)_\n\n",[9,767],{"slug":1365,"featured":6,"template":701},"how-we-uxd-our-secure-ux-team","content:en-us:blog:how-we-uxd-our-secure-ux-team.yml","How We Uxd Our Secure Ux Team","en-us/blog/how-we-uxd-our-secure-ux-team.yml","en-us/blog/how-we-uxd-our-secure-ux-team",{"_path":1371,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1372,"content":1378,"config":1383,"_id":1385,"_type":14,"title":1386,"_source":16,"_file":1387,"_stem":1388,"_extension":19},"/en-us/blog/how-you-can-help-shape-the-future-of-securing-applications-at-gitlab",{"title":1373,"description":1374,"ogTitle":1373,"ogDescription":1374,"noIndex":6,"ogImage":1375,"ogUrl":1376,"ogSiteName":686,"ogType":687,"canonicalUrls":1376,"schema":1377},"How you can help shape the future of securing applications with GitLab","We want to provide the best experience in keeping your application safe after your code is in production.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668495/Blog/Hero%20Images/how-you-can-help-shape-the-future-of-securing-applications-at-gitlab.jpg","https://about.gitlab.com/blog/how-you-can-help-shape-the-future-of-securing-applications-at-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How you can help shape the future of securing applications with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Emily von Hoffmann\"}],\n        \"datePublished\": \"2019-11-14\",\n      }",{"title":1373,"description":1374,"authors":1379,"heroImage":1375,"date":1380,"body":1381,"category":301,"tags":1382},[740],"2019-11-14","This blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2019-12-09.\n\nAs part of our vision to deliver the entire DevOps lifecycle in a single application, we’re designing an experience that will allow security professionals to collaborate directly with developers. We need your help to make it the best it can be!\n\nOur newest product stage is Protect, and it’s an exciting time as we continue to define our [strategy and roadmap](/direction/govern/). The Protect UX team’s goal is to provide the best experience in keeping your application safe after your code is in production. This includes all features that help you defend your applications and cloud infrastructure by giving you the ability to identify, catalogue, manage, and remediate threats, vulnerabilities, and risks.\n\nSome of the new categories we’re planning for in 2020 include Runtime Application Self Protection, Threat Detection, User Entity and Behavioral Analytics and [more](https://handbook.gitlab.com/handbook/product/categories/#protect-section).\n\nWe have a ton of UX research planned to help us learn more about this new category, and we hope you consider adding your voice.\n\n### Our users' jobs to be done\n\nFrom what we know so far, the Protect user is responsible for maintaining the security of their company’s environments and applications. They seem to have a wide variety of job titles, including security analyst and SecOps engineer.\n\nWe aim to understand our different users’ motivations and goals by identifying their primary [jobs to be done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done). For the Protect user, these include things like:\n\n> When I make sure my company’s applications aren’t vulnerable to bad actors, I want to monitor the traffic coming to my application and detect the possibility of an attack (SQL injection attempts, XSS attempts, vulnerability scanners, etc.) so I can know what parts of the application I need to protect better.\n\n### Our recruiting challenge\n\nPerhaps because we’re best known for our origins in source code management, we usually have an abundance of participants who fit our software developer persona when we’re recruiting for studies. Newer personas like our Protect users have been more elusive by comparison — we’ve attempted studies where we couldn’t find a single human to speak with.\n\nThis is a real problem for us, as we believe strongly in evidence-based design. We want to build for your actual wants and needs as opposed to our assumptions about them.\n\n### How you can help\n\nIf any of this sounds like you, please sign up to our research program, [GitLab First Look](/community/gitlab-first-look/)! When you join, you can indicate exactly which product areas and types of research you’re interested in. We’ll send you invitations to participate when you match with studies.\n\nQuestions? Reach out to me on [twitter](https://twitter.com/EmvonHoffmann).\n\n[Sam Kerr](/company/team/#stkerr) and [Tali Lavi](/company/team/#tlavi) contributed to this post.\n\nCover image by [Rashid Khreiss](https://unsplash.com/@rush_intime) on [Unsplash](https://unsplash.com).\n",[9,722],{"slug":1384,"featured":6,"template":701},"how-you-can-help-shape-the-future-of-securing-applications-at-gitlab","content:en-us:blog:how-you-can-help-shape-the-future-of-securing-applications-at-gitlab.yml","How You Can Help Shape The Future Of Securing Applications At Gitlab","en-us/blog/how-you-can-help-shape-the-future-of-securing-applications-at-gitlab.yml","en-us/blog/how-you-can-help-shape-the-future-of-securing-applications-at-gitlab",{"_path":1390,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1391,"content":1397,"config":1403,"_id":1405,"_type":14,"title":1406,"_source":16,"_file":1407,"_stem":1408,"_extension":19},"/en-us/blog/illustrations-and-icons-on-gitlab-com",{"title":1392,"description":1393,"ogTitle":1392,"ogDescription":1393,"noIndex":6,"ogImage":1394,"ogUrl":1395,"ogSiteName":686,"ogType":687,"canonicalUrls":1395,"schema":1396},"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":1392,"description":1393,"authors":1398,"heroImage":1394,"date":1400,"body":1401,"category":870,"tags":1402},[1399],"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",[768,9,722],{"slug":1404,"featured":6,"template":701},"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":1410,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1411,"content":1417,"config":1423,"_id":1425,"_type":14,"title":1426,"_source":16,"_file":1427,"_stem":1428,"_extension":19},"/en-us/blog/inside-our-new-development-team-lead-persona",{"title":1412,"description":1413,"ogTitle":1412,"ogDescription":1413,"noIndex":6,"ogImage":1414,"ogUrl":1415,"ogSiteName":686,"ogType":687,"canonicalUrls":1415,"schema":1416},"What are the best and worst parts about being a development team lead?","Dev leads, we feel you. Here's a deep dive into our interviews with development team leads, and the new persona they informed.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668224/Blog/Hero%20Images/inside-our-new-development-team-lead-persona.jpg","https://about.gitlab.com/blog/inside-our-new-development-team-lead-persona","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What are the best and worst parts about being a development team lead?\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Katherine Okpara\"}],\n        \"datePublished\": \"2019-01-18\",\n      }",{"title":1412,"description":1413,"authors":1418,"heroImage":1414,"date":1420,"body":1421,"category":870,"tags":1422},[1419],"Katherine Okpara","2019-01-18","\nWelcome back to our series on the [new GitLab personas](https://handbook.gitlab.com/handbook/product/personas/)! I recently [wrote about what we learned from product managers during interviews](/blog/inside-our-new-product-manager-persona/) for our [UX research project to develop personas](https://gitlab.com/gitlab-org/ux-research/issues/77) for all product areas. In this post, I'll share some of the insights from our efforts to better understand development team leads, and introduce the resulting persona, [Delaney](https://handbook.gitlab.com/handbook/product/personas/#delaney-development-team-lead).\n\n## The research\n\nHere are some of the findings from my [six interviews](https://gitlab.com/gitlab-org/ux-research/issues/95) conducted for the persona.\n\nDevelopment team leads are often responsible for meeting with product managers and stakeholders to discuss scheduled feature requests, convert concepts into practical solutions, ensure that capacity is properly estimated, and assign work to developers. They are also involved in other duties such as creating design and functional specifications, writing code, documenting and automating processes, and mentoring other developers.\n\n### So, what’s the hardest part about being a development team lead?\n\nDue to the nature of their work, the challenges development team leads face often cross into several domains.\n\n#### Vague requirements and poor communication\n\nIt can be difficult to know the status of certain requirements when other team members don't update the various tools that are being used. Important information can get lost along the way, which often leads to repetitive discussions or fixing incorrect work. Many of the people we spoke with are looking for ways to have this information readily accessible and consistently communicated throughout their teams.\n\n> \"Sometimes the back and forth can be annoying, when the requirements aren’t clear and I have to go back a step to understand what is going on or a component is not what I wanted. At a previous company, the back and forth was especially drawn out since the team did not work closely together. At [my current] company, this problem isn’t as severe since I work closely with the team and can quickly ask for clarification if I need to. Working more efficiently saves a lot of time.\"\n\n####  Difficulty making accurate estimations of timeline and capacity\n\nA team lead must have a good understanding of the skillsets available on their team and use this insight to balance business objectives. In order to get a better sense of the experience levels of different team members, they often hold one-on-one meetings or conduct reviews during and after a development cycle.\n\n> \" ... This goes back to the burndown chart – if it's being used correctly, it can help you see where you’ll end up. In order for that to happen, you need your estimations to be accurate. And in order for _that_ to happen you need to figure out the accuracy of the baseline and experience of the developer. For example, someone who is more junior has less of a reference point. I have to assign extra points to stories, if there are unknown variables.\"\n\n#### Delivering on time\n\nWhen demand surpasses current capacity, it can be stressful to resolve existing problems without creating new issues that result from hasty work. It can also be difficult to explain technical limitations to stakeholders who are not involved in the development process.\n\n> \"Someone might see a code review request but feel conflicted since they only have two days left to finish their own tasks. So sometimes testers and customers are waiting on these code reviews to move forward ... The biggest thing would be having all those tickets, all of those changes, closely correlated with the actual changes in Git. 'For this particular feature, here are all the changes in Git.' You don’t have to read the codebase or fire up the whole application. You have the information all in one place and don’t need to hunt down information.\"\n\n#### Changing mindsets in organizations to adopt faster, iterative approaches\n\nSome development teams are slowed down by inefficient toolchains or outdated workflows because their organizations are resistant to change and adopting new practices. Introducing new ideas and methodologies can be an especially complex process in organizations that create products for industries with more restrictions and regulations than others.\n\n> \"Most blockers that arise are put in their own way. I would prefer to iterate while they rather plan everything out for long periods of time. Their own processes get in their way because they don’t think they can move faster. Many of their processes are filled with errors and take days or weeks. They’ve always done things a certain way and are not really willing to make a change.\"\n\n### What motivates a development team lead?\n\nOne of the biggest goals for many development team leads is the drive to continually optimize processes and deliver value to the product. They must also build a level of communication that enables them to assign tasks to the appropriate people, explain why certain feature requests are or are not feasible, and continue to implement strategic solutions.\n\n### What’s the best part about being a development team lead?\n\nThe best part of being a Development Team Lead is problem solving on a variety of levels – from tools to methodologies to team relations and more. When teams are well supported by their leaders and organizations, they are better equipped to meet the expectations that will move both the product and business forward!\n\n## The persona\n\n[![Delaney, Development Team Lead persona](https://about.gitlab.com/images/blogimages/delaney-dev-team-lead-persona.png)](https://handbook.gitlab.com/handbook/product/personas/#delaney-development-team-lead)\n\n### Want to share your experiences of GitLab with me?\n\nJoin [GitLab First Look](/community/gitlab-first-look/) and help us build an even better picture of who GitLab’s users really are!\n\n[Photo](https://unsplash.com/photos/atSaEOeE8Nk) by [Steven Lelham](https://unsplash.com/@slelham) on Unsplash\n{: .note}\n",[721,723,9],{"slug":1424,"featured":6,"template":701},"inside-our-new-development-team-lead-persona","content:en-us:blog:inside-our-new-development-team-lead-persona.yml","Inside Our New Development Team Lead Persona","en-us/blog/inside-our-new-development-team-lead-persona.yml","en-us/blog/inside-our-new-development-team-lead-persona",{"_path":1430,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1431,"content":1437,"config":1442,"_id":1444,"_type":14,"title":1445,"_source":16,"_file":1446,"_stem":1447,"_extension":19},"/en-us/blog/interesting-things-ux-is-working-on-february-2021",{"title":1432,"description":1433,"ogTitle":1432,"ogDescription":1433,"noIndex":6,"ogImage":1434,"ogUrl":1435,"ogSiteName":686,"ogType":687,"canonicalUrls":1435,"schema":1436},"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":1432,"description":1433,"authors":1438,"heroImage":1434,"date":1439,"body":1440,"category":765,"tags":1441},[847],"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",[768,770,9],{"slug":1443,"featured":6,"template":701},"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":1449,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1450,"content":1456,"config":1462,"_id":1464,"_type":14,"title":1465,"_source":16,"_file":1466,"_stem":1467,"_extension":19},"/en-us/blog/introducing-gitlab-s-integrated-development-environment",{"title":1451,"description":1452,"ogTitle":1451,"ogDescription":1452,"noIndex":6,"ogImage":1453,"ogUrl":1454,"ogSiteName":686,"ogType":687,"canonicalUrls":1454,"schema":1455},"Meet the GitLab Web IDE","Here's how we went from a proof of concept to a new feature that makes it even easier for everyone to edit inside of GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749678812/Blog/Hero%20Images/web-ide-cover.jpg","https://about.gitlab.com/blog/introducing-gitlab-s-integrated-development-environment","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Meet the GitLab Web IDE\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Dimitrie Hoekstra\"}],\n        \"datePublished\": \"2018-06-15\",\n      }",{"title":1451,"description":1452,"authors":1457,"heroImage":1453,"date":1459,"body":1460,"category":870,"tags":1461},[1458],"Dimitrie Hoekstra","2018-06-15","\n\nGitLab has been doing much more for the application development workflow than just source code management and versioning for a while – now spanning everything from [portfolio management](https://docs.gitlab.com/ee/user/group/epics/index.html#epics) to the [entire DevOps lifecycle](/blog/from-dev-to-devops/). Having everyone work from and be familiar with the same interface has many advantages.\n\nAll that code that gets automatically tested and deployed to production has a human at its source though. With the speed of innovation in today’s web development, we saw a chance to help out both new as well as seasoned developers with writing, reviewing, and committing that code with more confidence. In [GitLab 10.7](/releases/2018/04/22/gitlab-10-7-released/) we released the first iteration of our Web IDE – here's how it happened.\n\n## From experiment towards product\n\nThe original idea came from staff developer [Jacob Schatz](/company/team/#jakecodes), who observed how non-developers were having a hard time editing multiple files and getting those changes committed.\n\nAlthough having discussed implementing an Integrated Development Environment (IDE) into GitLab with our CEO [Sid](/company/team/#sytses) and VP of Product [Job](/company/team/#Jobvo) before, it was never clear how to do that and what exact problems it would solve.\n\nAt some point, it dawned on us that the repository view might be the right vessel. Jacob set up a proof of concept where he made our file viewer work in the context of a file editor. It removed the page refresh when switching between files and it approached editing from a branch perspective instead of per file. The result was the beginning of the [Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/), although it was called the \"repo editor\" at that time.\n\n![Proof of concept multi-file editor](https://about.gitlab.com/images/blogimages/webide/multifileeditor.png){: .shadow.medium.center}\n\nSetting up that proof of concept was a [tremendous amount of work](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/12198) and was time-boxed to one month. Jacob also had other responsibilities, and there was still a long way to go from concept to minimal viable product (MVP).\n\nProduct, UX, and other developers got involved to see if this could be pushed towards production. The concept solved a problem, but did it align with our vision? How could we holistically integrate this and make it a great experience? How could we get it to perform well for many different users?\n\n## The next phase\n\nIt took some time, but it was clear that we were aiming for a real integrated development experience, accessible for everyone right within the GitLab UI, without anything to install. The idea grew from the \"Repo editor\" into that of the \"Web IDE.\"\n\nGitLab itself is open source (or rather [open core](/blog/gitlab-is-open-core-github-is-closed-source/)) and relies on many open source projects for its development. Jacob had already decided that the [Monaco editor](https://microsoft.github.io/monaco-editor/) was the perfect code editor to integrate. It had already proven itself within different contexts, was great for performance, and so could be considered a [boring solution](https://handbook.gitlab.com/handbook/values/#efficiency).\n\nOur UX manager [Sarrah Vesselov](/company/team/#SVesselov) did the initial design for the concept after which it got passed on to me. It was up to our platform product manager [James Ramsay](/company/team/#jamesramsay), our frontend engineering manager [Tim Zallman](/company/team/#tpmtim), senior frontend engineer [Phil Hughes](/company/team/#iamphill), and I as the UX Designer to redefine the prototype \"multi-file editor\" into the foundation capable of supporting our vision of an Integrated Development Environment with live previews and web terminals, that enables anyone to contribute.\n\n## Iterating on user experience\n\n### An integrated editor\n\nThe original \"multi-file editor\" was about committing multiple changes at once because this was annoying when updating the handbook or docs. Often those changes touched multiple files. It was a prototype that made it easier for people to contribute.\n\nThe more we thought about this idea, the greater the possibilities became. One of GitLab's unique advantages is being an integrated product. Building an editor that was integrated with GitLab and made it easier for anyone to contribute is a natural fit. However, the starting point of a prototype in the file list and blob editor wouldn't have been enough to handle this. Decoupling this was the first actionable item.\n\n>One of GitLab's unique advantages is being an integrated product. Building an editor that was integrated with GitLab and made it easier for anyone to contribute is a natural fit.\n\nThis change, which required a lot of discussion and a considerable amount of engineering work by our developers Phil and Tim, was where the project pivoted towards its new direction. The Web IDE got a lot more screen real estate as it no longer had to make room for the project sidebar and other page elements. We decided that the Web IDE would edit one branch at a time only and conceptualized the initial Git flow into the editor. Based on existing UI paradigms and inspired by other code editors like [VSCode](https://code.visualstudio.com/) and [Atom](https://atom.io/), we arrived at the well-known, three-pane layout.\n\n\u003Cdiv class=\"compare-images-2\">\n  \u003Cimg src=\"/images/blogimages/webide/web-ide-iteration-0-concept.png\" class=\"compare-image-top shadow\" alt=\"multi file editor concept\">\n  \u003Cimg src=\"/images/blogimages/webide/web-ide-iteration-1-concept.png\" class=\"compare-image-bottom shadow\" alt=\"web ide file editor concept\">\n\u003C/div>\n\nEven seasoned developers were once beginners, and getting new people accustomed to the Git workflow continues to be notoriously hard to tackle. We decided therefore that the core of the Web IDE experience should be stable before we can venture into more advanced concepts. We set out to make the \"editing to committing\" experience as good as possible and to create a foundation on which we can expand.\n\nEven while having [these discussions](https://gitlab.com/gitlab-org/gitlab-ce/issues/44316), development never stood still. We quickly had a working version of the Web IDE that relied on the Monaco editor. Our immediate efforts pushed towards getting that to a functional, viable state.\n\n### A review state\n\nDue to the potency of the Monaco editor, it became clear we had many options to choose from as to what to develop next. A review state was high up on that list, as it should be obvious what you are going to commit. Not only that, it introduced the possibility of being able to have an integrated merge request review experience in the context of the editing experience – something that has not been possible before.\n\nThis introduced the problem of managing states. After much discussion, we decided to go for editor states instead of file-specific states. Both the user perspective as well as the technical implementation benefited from this as it reduced complexity. It meant you were either editing your files or reviewing your changes across the files you had opened.\n\n![Web IDE edit and review states](https://about.gitlab.com/images/blogimages/webide/web-ide-states.png){: .shadow.medium.center}\n\nAt this point, we are nearing the current state of the Web IDE, though in GitLab 10.8 we could finally [realize the \"editing to committing\" experience](https://gitlab.com/gitlab-org/gitlab-ce/issues/44846) that we talked about before and which was conceptualized and [prototyped](https://framer.cloud/Cojmw/index.html) while developing GitLab 10.7. This was made possible as development reached a more stable state.\n\n### Deciding on hierarchy\n\nThe new experience had several objectives. It needed to introduce a more logical hierarchy for the panes to operate in. Based on that we could decide which panes would potentially show what information and where we could fit in any future more advanced features.\n\nThe second objective was to guide the user more intuitively from editing to committing. The editing and reviewing experience up until then showed its shortcomings as it was hard to switch modes and unclear when you were doing a good job. If even seasoned developers had a hard time using it, how could people just starting out ever hope to successfully contribute making use of it?\nJames and I went through many concepts and discussed both flow and hierarchy before getting into detailed mockups. Through the iterations, it became apparent we preferred our hierarchy to act from left to right. We decided we needed a similar paradigm as the activity bar shown in VSCode. The editor became far more usable as state changes were just one click away, regardless of which state you were already using. As committing was now a separate state as well, it brought a linearity to the entire flow as seen from the activity bar.\n\nThe last significant detail, which came out of a discarded design iteration, was a button to guide the user towards committing their changes. It introduced a little section at the bottom of each state with a blue commit button and a counter so you can see how many changes you have made – essential as we repurposed the right sidebar.\n\n\u003Cdiv class=\"compare-images-3\">\n  \u003Cimg src=\"/images/blogimages/webide/web-ide-left-1.png\" class=\"compare-image-top shadow\" alt=\"web ide revised concept edit mode\">\n  \u003Cimg src=\"/images/blogimages/webide/web-ide-left-2.png\" class=\"compare-image-middle shadow\" alt=\"web ide revised concept review mode\">\n  \u003Cimg src=\"/images/blogimages/webide/web-ide-left-3.png\" class=\"compare-image-bottom shadow\" alt=\"web ide revised concept commit mode\">\n\u003C/div>\n\n*Interested to see all iterations the concepts have gone through? Check out my [Web IDE directory](https://gitlab.com/gitlab-org/gitlab-design/tree/master/progress/dimitrie/web-ide) in GitLab's open source design library where we contribute all our design files!*\n\n## Just the beginning\n\nThe current state of the Web IDE is still only the beginning. We are planning for an even better experience in the future: one where we can integrate and support more advanced features, such as a live environment to test your code against and code review discussions which are directly resolvable.\n\nIn GitLab 11.0, shipping next Friday, we will already have the following improvements: you will be able to view the latest pipeline status and the job logs directly in context, and you will be able to quickly switch between both assigned and authored merge requests without leaving the Web IDE!\n\nThis and more will inevitably lead towards more interesting design decisions to be made. Some of these concepts are uncharted territory and are sure to be valuable to further speed up development and give developers more confidence. Our hope is that this is a valuable contribution to both the open source community as well as GitLab itself.\n\nDo you have great ideas to push this effort forwards or want to contribute yourself? Check out the [issue tracker](https://gitlab.com/groups/gitlab-org/-/issues?scope=all&utf8=%E2%9C%93&state=opened&label_name[]=web%20ide)!\n",[722,1287,9],{"slug":1463,"featured":6,"template":701},"introducing-gitlab-s-integrated-development-environment","content:en-us:blog:introducing-gitlab-s-integrated-development-environment.yml","Introducing Gitlab S Integrated Development Environment","en-us/blog/introducing-gitlab-s-integrated-development-environment.yml","en-us/blog/introducing-gitlab-s-integrated-development-environment",{"_path":1469,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1470,"content":1476,"config":1482,"_id":1484,"_type":14,"title":1485,"_source":16,"_file":1486,"_stem":1487,"_extension":19},"/en-us/blog/is-devops-for-designers",{"title":1471,"description":1472,"ogTitle":1471,"ogDescription":1472,"noIndex":6,"ogImage":1473,"ogUrl":1474,"ogSiteName":686,"ogType":687,"canonicalUrls":1474,"schema":1475},"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":1471,"description":1472,"authors":1477,"heroImage":1473,"date":1479,"body":1480,"category":870,"tags":1481},[1478],"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/#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/#whats-next--why) and [long term strategy for Design Management](/direction/plan/#long-term-strategy).\n",[768,770,9],{"slug":1483,"featured":6,"template":701},"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":1489,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1490,"content":1495,"config":1501,"_id":1503,"_type":14,"title":1504,"_source":16,"_file":1505,"_stem":1506,"_extension":19},"/en-us/blog/iterate-like-a-gitlab-designer",{"title":1491,"description":1492,"ogTitle":1491,"ogDescription":1492,"noIndex":6,"ogImage":1219,"ogUrl":1493,"ogSiteName":686,"ogType":687,"canonicalUrls":1493,"schema":1494},"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":1491,"description":1492,"authors":1496,"heroImage":1219,"date":1498,"body":1499,"category":765,"tags":1500},[1497],"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",[768,9,770,698,767],{"slug":1502,"featured":6,"template":701},"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":1508,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1509,"content":1515,"config":1521,"_id":1523,"_type":14,"title":1510,"_source":16,"_file":1524,"_stem":1525,"_extension":19},"/en-us/blog/jira-importer-research",{"title":1510,"description":1511,"ogTitle":1510,"ogDescription":1511,"noIndex":6,"ogImage":1512,"ogUrl":1513,"ogSiteName":686,"ogType":687,"canonicalUrls":1513,"schema":1514},"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":1510,"description":1511,"authors":1516,"heroImage":1512,"date":1517,"body":1518,"category":765,"tags":1519},[1497],"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://handbook.gitlab.com/handbook/product/personas/#sidney-systems-administrator) or a [DevOps Engineer](https://handbook.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",[912,768,9,1520,698],"developer survey",{"slug":1522,"featured":6,"template":701},"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":1527,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1528,"content":1534,"config":1540,"_id":1542,"_type":14,"title":1543,"_source":16,"_file":1544,"_stem":1545,"_extension":19},"/en-us/blog/jobs-to-be-done-interviews",{"title":1529,"description":1530,"ogTitle":1529,"ogDescription":1530,"noIndex":6,"ogImage":1531,"ogUrl":1532,"ogSiteName":686,"ogType":687,"canonicalUrls":1532,"schema":1533},"How we use the Jobs-To-Be-Done Framework to rethink user workflow","We experimented with our methodology and this is what we learned.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749670074/Blog/Hero%20Images/jobs-to-be-done.jpg","https://about.gitlab.com/blog/jobs-to-be-done-interviews","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we use the Jobs-To-Be-Done Framework to rethink user workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Erika Feldman\"},{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2022-09-07\",\n      }",{"title":1529,"description":1530,"authors":1535,"heroImage":1531,"date":1537,"body":1538,"category":743,"tags":1539},[1536,787],"Erika Feldman","2022-09-07","\n\nThe past few years exposed us to the heights of unpredictability, and a lot of time was spent on Zoom. The pandemic showed us that planning is not enough for an organization to survive in difficult times. Companies need to be flexible enough to innovate in accordance with altered workflows if they wish to sustain and support market use cases as they evolve. Innovating and iterating at the speed of DevOps requires designers and researchers to look at the user workflow differently, outside of the content of the UI. To understand our users and how their work has changed, we zoomed out our perspective by asking users their key tasks and goals at the Stage level - instead of presenting them with a UI to work within. \n\nAt GitLab, we use the Jobs-To-Be-Done ([JTBD](/handbook/product/ux/jobs-to-be-done/)) framework to always keep room for innovation in our approach to research and customer inquiry. We believe that our users do not purchase our product because of the features and capabilities we build into it, but for what it helps them accomplish in their workflows. To capture more macro-changes in user workflows through this research, we adjusted the level of the JTBD framework to focus on the entire code integration, verification, and deployment process.  \n\nWhen we are too focused on the features and solutions we work on day after day, our frame becomes myopic, our sense of progress becomes skewed, and [Conway's law](https://en.wikipedia.org/wiki/Conway%27s_law) rears its head. Our product then reflects our organizational structure rather than the user's workflow. The JTBD framework helps us be more aware of opportunities in the competitive arena by allowing us to understand the goal of the products at a more fundamental level that can easily be missed by a superficial frame.   \n\n## Pipeline execution JTBDs\nThe [Pipeline Execution group](/handbook/engineering/development/ops/verify/pipeline-execution/) in GitLab is responsible for supporting the functionalities with respect to Continuous Integration use cases. GitLab [CI/CD](/topics/ci-cd/) offerings have come a long way over the years. This realization triggered us to start re-examining the vision we have for the Stage Group earlier this year. We wanted to make sure that we’re leaving no stone unturned. And what better place to start than revisiting our JTBDs?\n\n## Designing the research\nTo avoid cutting any corners, we decided to keep our confidence in the product and our biases aside and speak with users without talking to them about our UI. A privilege of working at GitLab is having a well-documented handbook that is a living and evolving single source of truth. We looked at the [documented process](/handbook/product/ux/jobs-to-be-done/mapping-jobs-to-be-done/) and, at the same time, made notes on our assumption around what might not have gone right the previous time we did this exercise. These are the areas we felt we could improve on:\n\n1. Making interviews more collaborative\n2. Documenting the findings without bias\n3. Helping participants tell us about the fundamental workflow level, and not at a utility level\n\n## The interview template\nWe co-created an interview deck with users to help us codify their workflows. After an introduction to the session to set them at ease, we showed them a relatively blank canvas with different stages of their workflow written on the top of the slide. We started with our GitLab Stages, falling into the Conway conunmdrum. At the end of our inquiry and co-creation of the deck templates that we use across participants, we had the following six steps: \n\n1. Define - How code is defined and how it will be integrated and verified\n1. Locate - How team members gets to know about Infrastructure-as-Code frameworks and how they should be used\n1. Execute - How the processes and frameworks are ultimately executed\n1. Monitor - How performance is monitored\n1. Modify  - How teams change existing processes or existing code\n1. Secure, Deploy, and Debrief - How teams securely release changes to production and learn from their most recent process\n\nSpeaking with users for this research activity didn't just help us identify new JTBDs, but also validate some of the [previously listed ones](/handbook/engineering/development/ops/verify/pipeline-execution/jtbd/). The same research also helped us identify opportunities related to learnability of the tool, post code-integration monitoring capabilities and discoverability of the code-verification practices set up by organization on GitLab for their teams.\n\nUsers are at the focal point of our decisons at GitLab and going forward we will continue to improve our research methods and communication practices to capture the insights in the purest form. \n\n",[698,9,829],{"slug":1541,"featured":6,"template":701},"jobs-to-be-done-interviews","content:en-us:blog:jobs-to-be-done-interviews.yml","Jobs To Be Done Interviews","en-us/blog/jobs-to-be-done-interviews.yml","en-us/blog/jobs-to-be-done-interviews",{"_path":1547,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1548,"content":1554,"config":1560,"_id":1562,"_type":14,"title":1563,"_source":16,"_file":1564,"_stem":1565,"_extension":19},"/en-us/blog/lets-all-search",{"title":1549,"description":1550,"ogTitle":1549,"ogDescription":1550,"noIndex":6,"ogImage":1551,"ogUrl":1552,"ogSiteName":686,"ogType":687,"canonicalUrls":1552,"schema":1553},"Let's all search!","We spoke with you about our search tools. Now we've got some issues we'd like your help on.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679339/Blog/Hero%20Images/AdvancedSearch.png","https://about.gitlab.com/blog/lets-all-search","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Let's all search!\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Will Leidheiser\"}],\n        \"datePublished\": \"2022-12-01\",\n      }",{"title":1549,"description":1550,"authors":1555,"heroImage":1551,"date":1557,"body":1558,"category":694,"tags":1559},[1556],"Will Leidheiser","2022-12-01","\n\nEarlier this year, our research team set out to learn how users search for GitLab content and to better understand their experience with our [global search](https://docs.gitlab.com/ee/user/search/) and [advanced search](https://docs.gitlab.com/ee/user/search/advanced_search.html) tools. We spoke with 12 GitLab users individually over the course of a four-week span to get their [feedback on our search capabilities](https://gitlab.com/groups/gitlab-org/-/epics/8193). \n\n![Getting feedback from GitLab users](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Talking_to_GitLab_users.png){: .shadow.medium.center}\nA researcher talking with GitLab users to gather their feedback.\n{: .note.text-center}\n\n## Research insights\n\nOur research identified that the discoverability of our search could be better. Some users had never tried out our search capabilities because they did not know we had a search bar inside of GitLab. The search bar [did not visually stand out](https://gitlab.com/groups/gitlab-org/-/epics/8275) to some GitLab users, so this led them to try other means (e.g., using their web browser URL history or using another external application) to find content. In addition, we learned that even long-time users of the GitLab search bar were [unaware of the kinds of content it could find](https://gitlab.com/groups/gitlab-org/-/epics/8274). As we encouraged users to try out the search tools for our study, they would uncover new information either through exposure or by reading our documentation.\n\nOur research helped the Global Search Product team at GitLab with future roadmap planning. Now, we need the support of our community to make iterative improvements to GitLab search tools. We have identified **two** actionable insight issues that you can contribute to directly to improve the search experience for all GitLab users. \n\n## Community contribution issues\n\n- In order to make the search bar stand out, we're proposing a change to [improve the contrast of the search bar](https://gitlab.com/gitlab-org/gitlab/-/issues/330925) in the GitLab navigation header. This change would greatly support the accessibility of our site and would assist users when looking for a way to search for content.\n\n![Update to improve the contrast of our search bar](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Focus.png){: .shadow.medium.center}\nA visual mock-up of improved contrast for the GitLab search bar.\n{: .note.text-center} \n\n- Improve the search experience by [providing hints](https://gitlab.com/gitlab-org/gitlab/-/issues/364402) about the kinds of content that the GitLab search bar can find. This change would prompt users with different ideas of what they can do with the search bar, so they can learn about our functionality without having to read through documentation.\n\n![Hints in the search bar](https://about.gitlab.com/images/blogimages/2022-11-21-lets-all-search/Placeholder_Options.png){: .shadow.medium.center}\nSome examples of hints that would be shown in the GitLab search bar.\n{: .note.text-center}\n\n## Let's contribute\n\nWondering where to start? Check out [this blog post](/blog/first-time-open-source-contributor-5-things-to-get-you-started) and [our development guide](/community/contribute/development/) and become an all-star contributor!\n\nNeed guidance or help? Feel free to leave a comment directly on one of the issues linked above, or find support in the \"get help\" section [in our contributing guide](/community/contribute/#getting-help).\n\n**Let's all contribute to GitLab's search!**\n",[696,269,697,698,9],{"slug":1561,"featured":6,"template":701},"lets-all-search","content:en-us:blog:lets-all-search.yml","Lets All Search","en-us/blog/lets-all-search.yml","en-us/blog/lets-all-search",{"_path":1567,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1568,"content":1574,"config":1580,"_id":1582,"_type":14,"title":1583,"_source":16,"_file":1584,"_stem":1585,"_extension":19},"/en-us/blog/navigation-research-blog-post",{"title":1569,"description":1570,"ogTitle":1569,"ogDescription":1570,"noIndex":6,"ogImage":1571,"ogUrl":1572,"ogSiteName":686,"ogType":687,"canonicalUrls":1572,"schema":1573},"How we overhauled GitLab navigation","Users weren't getting what they needed from our navigation. Here are the steps we took to turn that experience around.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682884/Blog/Hero%20Images/navigation.jpg","https://about.gitlab.com/blog/navigation-research-blog-post","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How we overhauled GitLab navigation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Ashley Knobloch\"}],\n        \"datePublished\": \"2023-08-15\",\n      }",{"title":1569,"description":1570,"authors":1575,"heroImage":1571,"date":1577,"body":1578,"category":743,"tags":1579},[1576],"Ashley Knobloch","2023-08-15","\nGitLab navigation was complex and confusing - that was the message we received from our users through issues and other feedback channels. Initially, to address these concerns, we conducted research around proposed solutions, but quickly found they wouldn't help users achieve their goals well enough to warrant implementing them. In the process of learning what wasn't working and what wouldn't work, we still didn't have clarity around *why* the navigation wasn't working. This article chronicles our journey to finding that clarity and developing navigation that is easier to use and better suited to our users' needs.\n\n## Our approach\nAs a first step, we reviewed past research and user feedback to ensure we had a solid understanding of what we had done and learned already. We found that we still needed more insight into why proposed changes weren’t receiving enough positive feedback to implement them.\n\nOur goals were straightforward:\n- understand what users are doing in GitLab\n- study how they navigate the platform\n- learn why they need certain navigation elements \n\nOur perspective shifted from validating proposed solutions to going back to revalidate the problems that exist with our navigation experience. Our hypothesis was that with a deeper understanding of our users’ behavior and mental models for how they navigate around GitLab, we could develop concepts to better match their needs and improve their overall experience.  \n\nThe scope of features in GitLab and the number of user personas across GitLab made this challenging. We have [16 personas](https://handbook.gitlab.com/handbook/product/personas/#user-personas) to represent different types of users, all with unique goals and techniques to achieve those goals. We focused our efforts on a subset of those personas that best represented usage across GitLab to ensure a holistic understanding of different user needs. We wanted to learn how navigation among different personas was similar and where it differed, what worked well with the current navigation, and what challenges users faced.\n\n## Studying key persona cohorts\nWe conducted [diary studies](https://about.gitlab.com/handbook/product/ux/ux-research/diary-studies/) with cohorts of our key personas to learn what their primary tasks and workflows were at a deeper level. This provided us with many real-world examples of how they navigate to their tasks and why. We also learned what worked well with their current workflows, what pain points existed, and what workarounds were being used (such as creating browser bookmarks, typing in the URL to pull browser history, or keeping a bunch of browser tabs open) to streamline their tasks in GitLab. \n\nWe learned that for some users, many of their primary tasks don’t require much navigation within GitLab because they use outside tools that link into GitLab through notifications (e.g., Slack and email) or use direct links through other tools. We also learned that often users’ work is quite scoped in GitLab, and they would like easier access to some of their core features without having to wade through all of the other features they don’t use. This illuminated some unmet needs that would improve their workflows, such as having the ability to customize navigation to access things important to them more quickly and streamline their path to relevant projects.\n\nLearning more about our users from a foundational perspective ensured that we had a solid base to build upon when considering changes to the navigation.\n\n## Anchoring to a North Star\nTo anchor the redesign process in user problems more broadly, a review of past feedback was analyzed that revealed three overarching themes with navigation-related feedback. These themes helped to guide the process and to remind us of the key problems we were trying to solve: \n- minimize feeling overwhelmed (ability to customize left sidebar)\n- orient users across the platform (differentiating groups and projects)\n- pick up where you left off (switching contexts)\n\nThe team continually mapped back design concepts to these themes to ensure potential solutions were rooted in user problems. \n\n## Evaluating and iterating\nNext, several navigation design concepts were developed and shared with users for feedback. Multiple rounds of [solution validation testing](https://about.gitlab.com/handbook/product/ux/ux-research/solution-validation-and-methods/) were conducted with our key personas to determine which design concepts to move forward with. The testing revealed how users felt about each design and also how well each design supported users completing core tasks. We identified a final concept that supported mature and new GitLab users with common workflows.\n\n## Understanding mental models for sidebar organization\nWe wanted to revisit our groupings in the left sidebar because we’ve heard over time that the organization can be confusing and unintuitive, especially some categories such as Operations. We needed to understand our users’ mental models for how they would group these items, and why. Learning the thought processes behind their organization was critical for us to know what changes to make that would align with user expectations. \n\nWe ran facilitated [card sort](https://about.gitlab.com/handbook/product/ux/ux-research/mental-modeling/#card-sorting) studies with our key personas to understand how they would group items in the left sidebar, and why. This helped us learn some areas that could benefit from readjusting, such as the Manage and Operate categories. We learned that users most often preferred to have analytics items together, for example, which is reflected in the Analyze tab. This insight, combined with patterns in analytics data, informed changes to the groupings in the left sidebar to better support workflows. \n\n## Launching and learning\nPrior to launching to external users, the new navigation was released to internal team members and we collected [feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/403059) to help iterate and improve the experience. \n\nNext, we launched the new navigation to external users as a toggle that could be turned on optionally. During this initial launch, a [longitudinal study](https://about.gitlab.com/handbook/product/ux/ux-research/longitudinal-studies/) was conducted with a sample of GitLab users to learn how they experienced the change in the context of their real work. Over time, the study would provide insight into adoption among the entire user base.  \n\nWe interviewed users prior to the monthlong study to learn more about their experience with the existing navigation. Then, they began using the new navigation while completing surveys and participating in interviews at checkpoints in the beginning, middle, and end of the month. This enabled us to capture their initial impressions of the new navigation, what they liked/disliked, how the new experience compared to the previous one, and if their sentiment changed over the course of the month as they continued to use the new navigation. \n\nUsers in this study found the new navigation to be an improvement from the previous one, and most preferred its features, including:\n- the ability to pin items streamlined common workflows\n- the new task-based sidebar categories in the sidebar, which they said felt more approachable, especially for newer users\n- the new navigation changes, which they said weren’t too overwhelming and felt familiar\n\nWe also learned about some opportunities to iterate and improve the new experience. For instance, some users pointed out:\n- the inability to pin entire Projects, Groups, or specific pages makes it difficult to streamline other workflows\n- some users unpin items accidentally\n- the overall lack of color can cause some features to blend in or be missed\n- it's not always easy to know what’s new in GitLab  \n\n## What’s next: Iterate, listen, and iterate again\nTo capture large-scale feedback on navigation over time, we launched a new navigation-focused quarterly survey in Q1 (February) of this year. This first quarter data established a baseline of our old navigation, and beginning in Q2 (May), we began collecting data on the new navigation experience. We will monitor this closely, and look for themes to help us learn what is working well and what may need further iteration. \n\nThis survey, along with our longitudinal study feedback and various other user feedback sources, will provide insights to help prioritize iterative improvements to the new navigation experience. Stay tuned for changes, and keep sharing [your navigation feedback](https://gitlab.com/gitlab-org/gitlab/-/issues/409005) with us!\n",[722,9,698],{"slug":1581,"featured":6,"template":701},"navigation-research-blog-post","content:en-us:blog:navigation-research-blog-post.yml","Navigation Research Blog Post","en-us/blog/navigation-research-blog-post.yml","en-us/blog/navigation-research-blog-post",{"_path":1587,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1588,"content":1594,"config":1599,"_id":1601,"_type":14,"title":1602,"_source":16,"_file":1603,"_stem":1604,"_extension":19},"/en-us/blog/navigation-state-of-play",{"title":1589,"description":1590,"ogTitle":1589,"ogDescription":1590,"noIndex":6,"ogImage":1591,"ogUrl":1592,"ogSiteName":686,"ogType":687,"canonicalUrls":1592,"schema":1593},"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":1589,"description":1590,"authors":1595,"heroImage":1591,"date":1596,"body":1597,"category":743,"tags":1598},[1419],"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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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](https://handbook.gitlab.com/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",[722,9,768],{"slug":1600,"featured":6,"template":701},"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":1606,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1607,"content":1613,"config":1618,"_id":1620,"_type":14,"title":1621,"_source":16,"_file":1622,"_stem":1623,"_extension":19},"/en-us/blog/new-typefaces-in-gitlab",{"title":1608,"description":1609,"ogTitle":1608,"ogDescription":1609,"noIndex":6,"ogImage":1610,"ogUrl":1611,"ogSiteName":686,"ogType":687,"canonicalUrls":1611,"schema":1612},"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":1608,"description":1609,"authors":1614,"heroImage":1610,"date":1615,"body":1616,"category":1264,"tags":1617},[1125,930],"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",[768,1287,697,829,770,9],{"slug":1619,"featured":6,"template":701},"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":1625,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1626,"content":1632,"config":1638,"_id":1640,"_type":14,"title":1641,"_source":16,"_file":1642,"_stem":1643,"_extension":19},"/en-us/blog/overhauling-the-navigation-is-like-building-a-dream-home",{"title":1627,"description":1628,"ogTitle":1627,"ogDescription":1628,"noIndex":6,"ogImage":1629,"ogUrl":1630,"ogSiteName":686,"ogType":687,"canonicalUrls":1630,"schema":1631},"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":1627,"description":1628,"authors":1633,"heroImage":1629,"date":1635,"body":1636,"category":870,"tags":1637},[1634],"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).",[9,829,768],{"slug":1639,"featured":6,"template":701},"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":1645,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1646,"content":1652,"config":1658,"_id":1660,"_type":14,"title":1661,"_source":16,"_file":1662,"_stem":1663,"_extension":19},"/en-us/blog/personal-profile",{"title":1647,"description":1648,"ogTitle":1647,"ogDescription":1648,"noIndex":6,"ogImage":1649,"ogUrl":1650,"ogSiteName":686,"ogType":687,"canonicalUrls":1650,"schema":1651},"GitLab user profiles have just become more personal","Find out the more about our latest additions to GitLab user profiles. You control the data that is displayed","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749682144/Blog/Hero%20Images/ben-sweet-2LowviVHZ-E-unsplash.jpg","https://about.gitlab.com/blog/personal-profile","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"GitLab user profiles have just become more personal\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Orit Golowinski\"}],\n        \"datePublished\": \"2021-09-30\",\n      }",{"title":1647,"description":1648,"authors":1653,"heroImage":1649,"date":1655,"body":1656,"category":1264,"tags":1657},[1654],"Orit Golowinski","2021-09-30","\n\nThe GitLab [user profile](https://docs.gitlab.com/ee/user/profile/) contains information about you and your GitLab activity. You can select what information to display.\n\nWe recently added a few new settings to make you user profile more personal:\n\n- [User pronouns](https://gitlab.com/gitlab-org/gitlab/-/issues/333042)\n- [User pronunciation guides](https://gitlab.com/gitlab-org/gitlab/-/issues/25742)\n- [User local times](https://gitlab.com/gitlab-org/gitlab/-/issues/335459)\n\n## User pronouns\n\nYou can now set pronouns to your GitLab user profile. The pronoun appears:\n\n- Next to your user name in your public profile.\n- On the snapshot view of your user profile when someone hovers over your name on an issue or\n  merge request.\n\nBesides being more inclusive, GitLab wants to help you use the correct pronouns when replying\nto comments to respect people's identity. You can:\n\n- Decide whether or not to add pronouns to your profile.\n- Self-identify and enter whatever pronouns you want, without having to select from a pre-defined list.\n\n[Read more](https://docs.gitlab.com/ee/user/profile/#add-your-gender-pronouns) about adding\npronouns to your profile.\n\n## User pronunciation\n\nYou can now add a pronunciation guide to your user profile. In distributed teams where team\nmembers are from different countries, it can be difficult to determine how to say someone's\nname correctly. You can now help people know how to pronounce your name.\n\n[Read more](https://docs.gitlab.com/ee/user/profile/#add-your-name-pronunciation) about adding a\npronunciation guide to your profile.\n\n## User local time\n\nYour local time is now displayed on your profile. Previously, you could set your time\nzone but your local time was not visible throughout GitLab. This improvement helps\nothers know when you are likely to be available.\n\n[Read more](https://docs.gitlab.com/ee/user/profile/#set-your-time-zone) about adding a\nlocal time zone to your profile.\n\n## Additional settings for user profiles\n\nIn the upcoming milestone, we are planning to [add your timezone to the snapshot view of the GitLab user profile](https://gitlab.com/gitlab-org/gitlab/-/issues/337935).\n\nIn GitLab, [everyone can contribute](/community/contribute/). If you would like to see even\nmore additions to user profiles, you can:\n\n- Open an [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issue%5Bmilestone_id%5D=#) with your request.\n- Upvote an existing issue. \n- Even [code it yourself](/community/contribute/development/)!\n\nCover image by [Ben Sweet](https://unsplash.com/@benjaminsweet?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](lhttps://unsplash.com/s/photos/profile?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyTextink)\n{: .note}\n\n",[770,9,696],{"slug":1659,"featured":6,"template":701},"personal-profile","content:en-us:blog:personal-profile.yml","Personal Profile","en-us/blog/personal-profile.yml","en-us/blog/personal-profile",{"_path":1665,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1666,"content":1671,"config":1676,"_id":1678,"_type":14,"title":1679,"_source":16,"_file":1680,"_stem":1681,"_extension":19},"/en-us/blog/polishing-gitlabs-ui-a-new-color-system",{"title":1667,"description":1668,"ogTitle":1667,"ogDescription":1668,"noIndex":6,"ogImage":883,"ogUrl":1669,"ogSiteName":686,"ogType":687,"canonicalUrls":1669,"schema":1670},"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":1667,"description":1668,"authors":1672,"heroImage":883,"date":1673,"body":1674,"category":870,"tags":1675},[1104],"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",[722,768,9,770],{"slug":1677,"featured":6,"template":701},"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":1683,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1684,"content":1690,"config":1695,"_id":1697,"_type":14,"title":1698,"_source":16,"_file":1699,"_stem":1700,"_extension":19},"/en-us/blog/quantifying-ux-positioning-of-the-clone-button",{"title":1685,"description":1686,"ogTitle":1685,"ogDescription":1686,"noIndex":6,"ogImage":1687,"ogUrl":1688,"ogSiteName":686,"ogType":687,"canonicalUrls":1688,"schema":1689},"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":1685,"description":1686,"authors":1691,"heroImage":1687,"date":1692,"body":1693,"category":870,"tags":1694},[1047],"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",[722,9,768],{"slug":1696,"featured":6,"template":701},"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":1702,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1703,"content":1709,"config":1714,"_id":1716,"_type":14,"title":1717,"_source":16,"_file":1718,"_stem":1719,"_extension":19},"/en-us/blog/quantifying-ux-validating-the-redesign-of-gitlabs-settings-pages",{"title":1704,"description":1705,"ogTitle":1704,"ogDescription":1705,"noIndex":6,"ogImage":1706,"ogUrl":1707,"ogSiteName":686,"ogType":687,"canonicalUrls":1707,"schema":1708},"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":1704,"description":1705,"authors":1710,"heroImage":1706,"date":1711,"body":1712,"category":301,"tags":1713},[1047],"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)",[722,9,768],{"slug":1715,"featured":6,"template":701},"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":1721,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1722,"content":1728,"config":1733,"_id":1735,"_type":14,"title":1736,"_source":16,"_file":1737,"_stem":1738,"_extension":19},"/en-us/blog/redesigning-gitlabs-navigation",{"title":1723,"description":1724,"ogTitle":1723,"ogDescription":1724,"noIndex":6,"ogImage":1725,"ogUrl":1726,"ogSiteName":686,"ogType":687,"canonicalUrls":1726,"schema":1727},"Redesigning GitLab's navigation","After a series of research and brainstorming sessions, we are excited to share with the community our redesign of GitLab's navigation.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679771/Blog/Hero%20Images/redesign-navigation-cover-image.jpg","https://about.gitlab.com/blog/redesigning-gitlabs-navigation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Redesigning GitLab's navigation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Taurie Davis\"}],\n        \"datePublished\": \"2017-07-17\",\n      }",{"title":1723,"description":1724,"authors":1729,"heroImage":1725,"date":1730,"body":1731,"category":870,"tags":1732},[1145],"2017-07-17","\n\nAt GitLab, we are taking big steps towards refining our interface in an effort to make the [idea to production](/learn/) workflow more productive. After a series of research and brainstorming sessions, we are excited to share with the community our redesign of GitLab's navigation.\n\n\u003C!-- more -->\n\n## Research and insight\n\nBack in March, we began our first of three rounds of user testing related to our navigation architecture. We knew from previous feedback that navigating GitLab's features was complex, difficult, and could be drastically improved. One of the major pitfalls we discovered in [this round](https://gitlab.com/gitlab-org/gitlab-ce/issues/29878) was confusion between global content vs. contextual content for new users when navigating. This was a large source of frustration when trying to find projects, or distinguish between your personal space and memberships.\n\n- **Global content** refers to the elements that are always available to you. Example: Your projects, issues, merge requests, and explore sections.\n\n- **Contextual content** refers to the elements that change based on the page you are viewing. Example: The content of an individual group page vs. a project page.\n\nUsing the data we gathered from our first round of testing, we began putting together common themes. This allowed us to gather questions and assumptions, which informed our next [prototype](https://gitlab-org.gitlab.io/gitlab-design/hosted/pedro/ux-research-4-navigation-usability-test-prototype-html-previews/#/screens/226216190) to test from. Our research team created a script that would walk users through a number of tasks. This script was then used to help us validate the assumptions we had made in our brainstorm session.\n\n{: .text-center}\n![Script](https://about.gitlab.com/images/blogimages/redesigning-gitlabs-navigation/script.png){: .shadow}\n\nWe [wrote up our findings from this round](https://gitlab.com/gitlab-org/ux-research/issues/5), identifying problem areas through the insight we gained by watching real users interact with our prototype. The team then set out to create a new design that addressed the interaction flaws we had identified during our testing.\n\n## Further discovery\n\nThrough a series of brainstorm sessions, the team created two new prototypes to use in testing. During [this round of testing](https://gitlab.com/gitlab-org/ux-research/issues/7), six users were shown [Prototype A](https://gitlab-org.gitlab.io/gitlab-design/hosted/chris/ux-research-7-prototype--vertical-breadcrumbs.framer/) and another six were shown [Prototype B](https://gitlab-org.gitlab.io/gitlab-design/hosted/chris/ux-research-7-prototype--horizontal-breadcrumbs.framer/). Each prototype used the same series of tasks, allowing us to track usability issues from each prototype individually, as well as compare the average time taken per task.\n\n**Prototypes A and B**\n![Prototype B](https://about.gitlab.com/images/blogimages/redesigning-gitlabs-navigation/prototypes.gif){: .shadow}\n\nDuring this third round of testing, we discovered that the majority of users were able to identify the difference between their global content from their contextual content after a few completed tasks. This was an improvement from our previous research which showed that users could finish a usability testing session without gaining an understanding of global vs. contextual content.\n\n## A shippable product\n\nFrom the data we gathered in our third and final round of testing, we began putting together a design that could be shipped in our 9.4 release. We took the most successful aspects of both prototypes and created a mockup that addressed the major pain points we discovered during all of our testing.\n\nWe knew from previous feedback and from our research that including the global navigation links on the top navigation bar was superior to hiding them in a hidden hamburger menu. Openly displaying them in the top navigation allows users to easily and quickly access the information that they revisit often.\n\n![Sidebar](https://about.gitlab.com/images/blogimages/redesigning-gitlabs-navigation/navigation-global-links-sidebar.png){: .shadow}\n\nWe also learned that including a standard breadcrumb menu helped users orient themselves. It became much easier for new and seasoned users to understand where they were located and navigate up a level.\n\n![Breadcrumb](https://about.gitlab.com/images/blogimages/redesigning-gitlabs-navigation/navigation-global-links--longer-project.png){: .shadow}\n\nKey experience decisions like these gave us a base for finalizing the foundation of the redesign. Afterwards, we began to take a closer look at the interface, add color, and define different states. Color played a key role in not only giving GitLab its own look and feel, but also further differentiating the global content from the contextual. We worked through [many iterations](https://gitlab.com/gitlab-org/gitlab-ce/issues/34402), until we nailed down an interface that used color as a guide and not as a distraction.\n\n![Final redesign](https://about.gitlab.com/images/blogimages/redesigning-gitlabs-navigation/final.png){: .shadow}\n\n## Continuing to iterate\n\nWe are excited to share our progress with the community and even more excited that this is just the beginning. There are a number of improvements that we are working on in order to further improve our navigation. A few of these features include:\n\n- Adding a fly-out drop down to the contextual navigation, making it easier and faster to reach sub menu items. [#34026](https://gitlab.com/gitlab-org/gitlab-ce/issues/34026)\n- Make the contextual sidebar collapsible to allow for more screen real estate. [#34028](https://gitlab.com/gitlab-org/gitlab-ce/issues/34028)\n- Adding multiple color palette options for differentiating instances. [#35012](https://gitlab.com/gitlab-org/gitlab-ce/issues/35012)\n- Adding content to global navigation dropdowns to allow easier access to recent projects and groups. [#35010](https://gitlab.com/gitlab-org/gitlab-ce/issues/35010)\n- Adding the contextual navigation on mobile devices. [#34036](https://gitlab.com/gitlab-org/gitlab-ce/issues/34036)\n\nYou can see our current list of issues planned for 9.5 in our [Meta: Global and contextual navigation](https://gitlab.com/gitlab-org/gitlab-ce/issues/32794) issue.\n\n## Try it yourself\n\nWe know that a UI change as large as a navigation redesign can be disruptive to workflow and habits but we hope that you will find GitLab much easier to navigate in 9.4! We actively worked to turn research and analysis into insight that would inform a more productive navigation architecture for GitLab. We have a number of improvements to make, and are including a way to turn the new navigation on and off while we continue to gather feedback and iterate in the next release. To turn the new navigation on, click your user profile dropdown and select \"Turn on new navigation\" or visit [your user preferences](https://gitlab.com/profile/preferences#new-navigation).\n\n{: .text-center}\n![Turn on new nav](https://about.gitlab.com/images/blogimages/redesigning-gitlabs-navigation/turn-on-nav.png){: .shadow}\n\n## Feedback\n\nAfter several rounds of UX research and taking into account the feedback received from the community, we believe we have a UX solution that greatly improves navigating GitLab. In addition to the roll out in 9.4 and the scheduled improvements for 9.5, we have created a [feedback issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/34917) to collect, track, and act upon further feedback from the community. We would love to hear your thoughts so don't hesitate to leave us a comment below or in the issue!\n",[9],{"slug":1734,"featured":6,"template":701},"redesigning-gitlabs-navigation","content:en-us:blog:redesigning-gitlabs-navigation.yml","Redesigning Gitlabs Navigation","en-us/blog/redesigning-gitlabs-navigation.yml","en-us/blog/redesigning-gitlabs-navigation",{"_path":1740,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1741,"content":1747,"config":1752,"_id":1754,"_type":14,"title":1755,"_source":16,"_file":1756,"_stem":1757,"_extension":19},"/en-us/blog/redesigning-our-docs",{"title":1742,"description":1743,"ogTitle":1742,"ogDescription":1743,"noIndex":6,"ogImage":1744,"ogUrl":1745,"ogSiteName":686,"ogType":687,"canonicalUrls":1745,"schema":1746},"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":1742,"description":1743,"authors":1748,"heroImage":1744,"date":1439,"body":1750,"category":1264,"tags":1751},[1749,847],"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",[768,698,9],{"slug":1753,"featured":6,"template":701},"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":1759,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1760,"content":1766,"config":1771,"_id":1773,"_type":14,"title":1774,"_source":16,"_file":1775,"_stem":1776,"_extension":19},"/en-us/blog/refining-gitlab-product-experience",{"title":1761,"description":1762,"ogTitle":1761,"ogDescription":1762,"noIndex":6,"ogImage":1763,"ogUrl":1764,"ogSiteName":686,"ogType":687,"canonicalUrls":1764,"schema":1765},"What we're doing to refine GitLab's product experience","How we're using UX Scorecards to improve GitLab's UX.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749673002/Blog/Hero%20Images/blog-experience-baselines.jpg","https://about.gitlab.com/blog/refining-gitlab-product-experience","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"What we're doing to refine GitLab's product experience\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Christie Lenneville\"}],\n        \"datePublished\": \"2019-09-05\",\n      }",{"title":1761,"description":1762,"authors":1767,"heroImage":1763,"date":1768,"body":1769,"category":301,"tags":1770},[847],"2019-09-05","\nGitLab is investing deeply in improving our user experience. Need proof? By the end of 2019, our team\nof product designers, UX researchers, and technical writers will be around 60 practitioners strong.\nThat's incredible growth for a company of our size.\n\nWhen I joined GitLab as the director of user experience back in February 2019, one of the\nstated goals was to move our team from being \"reactive\" (responding to UX requests) to being\n\"proactive\" (actively finding and solving UX problems and advocating for change). I was impressed to\nsee this perspective from our executive leadership. It's surprising how often user experience gets\nput on the backburner, despite its positive impact on customer satisfaction and company growth.\n\nBut while intentions are good, they're useless without action. So, the UX team quickly got to work to\nfigure out how we could make meaningful change.\n\n## Proactively improving UX\n\nHistorically, GitLab has focused its efforts on developing new features. With a new emphasis on\nrefining our most common and critical workflows, we needed a new approach.\n\nEnter [UX Scorecards](/handbook/product/ux/ux-scorecards/): An initiative\nby which we evaluate the current experience with quick, iterative steps to make it better,\nincluding a built-in grading rubric that helps us to properly prioritize efforts and track progress over time.\n\nUsing this methodology, we're:\n\n* Working with product managers to identify the most common and critical workflows in our product\n* Analyzing each workflow to see where it works well... and where it doesn't\n* Documenting the existing experience in videos and user journeys\n* Grading the experience on an A/B/C/D/F scale\n* Creating issues with recommendations for the proposed experience\n* Working with product management to prioritize improvements\n\nIt's a highly proactive way of moving our user experience forward.\n\n## What have we done so far?\n\nDuring Q2 of calendar year 2019, we committed to\nan OKR that focused on [working\nclosely with our product management peers to identify 15 critical workflows](https://gitlab.com/gitlab-com/www-gitlab-com/issues/4354), also\ncalled \"Jobs to be Done,\" across our entire application. This valuable, lightweight effort\nsurfaced opportunities to improve day-to-day workflows and proved out a pattern we can\napply to future workflows.\n\nHere's how we defined our grading rubric:\n\n* **A (High Quality/Exceeds):** Workflow is smooth and painless. Clear path to reach a goal.\nCreates “Wow” moments due to the process being so easy. Users would not hesitate to go through the\nprocess again.\n* **B (Meets Expectations):** Workflow meets expectations but does not exceed user needs. Users are\nable to reach the goal and complete the task. Less likely to abandon.\n* **C (Average):** Workflow needs improvement, but users can still finish completing the task. It\nusually takes longer to complete the task than it should. Users may abandon the process or try again later.\n* **D (Presentable):** Workflow has clear issues and should not have gone into production without more\nthought and testing. Users may or may not be able to complete the task. High risk of abandonment.\n* **F (Poor):** Workflow leaves users confused and with no direction of where to go next. Can sometimes\ncause users to go around in circles or reach a dead end. Very high risk of abandonment, and users\nwill most likely seek other methods to complete the task.\n\n## What workflows did we focus on?\n\nAs mentioned above, we focused first on the most used and highly impactful workflows in the product.\nOver time, we'll continue to add to this list.\n\n### Workflows with a score of C\n\n* Sign-in/register for a GitLab account **C/C** (desktop/mobile)\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=AbP9aAbW1zI)\n  * [Improvement Recommendations](https://gitlab.com/gitlab-org/ux-research/issues/217)\n* Create a Merge Request: **C/D** (desktop/mobile)\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=WOdqw_z2dwE)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/441)\n* Review changes: **C**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=CShQ0JA_BA0)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/442)\n* Identify and troubleshoot performance issues: **C**\n  * [UX Scorecard Video](https://youtu.be/nUdSqrvWeiA)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-ee/issues/11713)\n* Add my existing Kubernetes cluster: **C-**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=xAi9u2eqrSk&t=7s)\n  * [Recommendation Issues](https://gitlab.com/groups/gitlab-org/-/epics/1380)\n* Understand dependencies: **C**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=XyEf0E1e8ns)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/449)\n* Deploy to Gitlab Pages: **C**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=WiVq7pQ0RMg)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/412)\n* Set up automated testing inside GitLab: **C**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=MOJn9JQEE2s)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/480)\n\n### Workflows with a score of D\n\n* Start a GitLab trial: **D-**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=MkTOwTxsoL8)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/ux-research/issues/285)\n* Receive and configure Issue notifications and To-Do items: **D+**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=gILgNANrIhg)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design#520)\n* Have awareness of adding risk through vulnerable code: **D**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=By0td9kVsOU)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/400)\n* See security vulnerabilities all in one location for prioritization: **D**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=w623fSysQzE)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/401)\n* Approve or blacklist new licenses: **D**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=TDcIN7lu7dk)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/402)\n\n### Workflows with a score of F\n\n* Analyze the productivity of a team: **F**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=ipkmlW_GQig)\n  * [Recommendation Issues](https://gitlab.com/groups/gitlab-org/-/epics/1454)\n* Create a release and update it: **F**\n  * [UX Scorecard Video](https://www.youtube.com/watch?v=wCnpEGhS8uk)\n  * [Recommendation Issues](https://gitlab.com/gitlab-org/gitlab-design/issues/431)\n\n## What's next?\n\nOne of our [OKRs for Q3 of calendar year 2019](https://gitlab.com/groups/gitlab-org/-/epics/1676) is to\nimprove seven of these workflows by one grade letter. That means we should soon have some \"B\" grades\nmixed in with the lower scores. We also intend to validate our scores with user research since\nthis initial effort focused on\na [heuristic evaluation](https://careerfoundry.com/en/blog/ux-design/what-is-a-heuristic-evaluation-in-ux/).\n\nAt the beginning of Q3, our Product team has already prioritized refining\nthe [GitLab.com Free Trial](https://gitlab.com/groups/gitlab-org/-/epics/377) experience. They've\nalso committed to improvements for adding an existing Kubernetes cluster.\n\nWe're excited to work with our product team to prioritize refining other parts of the product\nthat are important to users. This effort should help move us closer to our goal of providing\nan [elevated user experience that customers love](/direction/maturity/index.html).\n\nCover image by [Startae](https://unsplash.com/@startaeteam) on [Unsplash](https://unsplash.com/license)\n{: .note}\n",[9,770],{"slug":1772,"featured":6,"template":701},"refining-gitlab-product-experience","content:en-us:blog:refining-gitlab-product-experience.yml","Refining Gitlab Product Experience","en-us/blog/refining-gitlab-product-experience.yml","en-us/blog/refining-gitlab-product-experience",{"_path":1778,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1779,"content":1785,"config":1790,"_id":1792,"_type":14,"title":1793,"_source":16,"_file":1794,"_stem":1795,"_extension":19},"/en-us/blog/remote-design-sprints",{"title":1780,"description":1781,"ogTitle":1780,"ogDescription":1781,"noIndex":6,"ogImage":1782,"ogUrl":1783,"ogSiteName":686,"ogType":687,"canonicalUrls":1783,"schema":1784},"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":1780,"description":1781,"authors":1786,"heroImage":1782,"date":1787,"body":1788,"category":870,"tags":1789},[826],"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.",[9,768],{"slug":1791,"featured":6,"template":701},"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":1797,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1798,"content":1804,"config":1810,"_id":1812,"_type":14,"title":1813,"_source":16,"_file":1814,"_stem":1815,"_extension":19},"/en-us/blog/revisiting-the-variables-management-workflow",{"title":1799,"description":1800,"ogTitle":1799,"ogDescription":1800,"noIndex":6,"ogImage":1801,"ogUrl":1802,"ogSiteName":686,"ogType":687,"canonicalUrls":1802,"schema":1803},"Revisiting the variables management workflow","Our users helped us identify the hurdles in the variables management experience and we used those insights to guide improvements.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098484/Blog/Hero%20Images/Blog/Hero%20Images/AdobeStock_618473457_nd5Dr8kfGdrlTWLOPmDjb_1750098483284.jpg","https://about.gitlab.com/blog/revisiting-the-variables-management-workflow","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Revisiting the variables management workflow\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Veethika Mishra\"}],\n        \"datePublished\": \"2024-02-26\",\n      }",{"title":1799,"description":1800,"authors":1805,"heroImage":1801,"date":1806,"body":1807,"category":870,"tags":1808},[787],"2024-02-26","CI/CD variables play a vital role in building and maintaining CI/CD pipelines and platforms. They are an essential part of the majority of developers’ workflows, serving a range of purposes from storing reusable information to maintaining data integrity. Given their significance, we made enhancing workflows related to CI/CD variables a priority.\nRecently, we conducted interviews with users representing different [personas](https://handbook.gitlab.com/handbook/product/personas/#list-of-user-personas) related to software development, working in teams with different structural and cultural dynamics. Our aim was to gain insights into the challenges they encounter when using and managing CI/CD variables within GitLab. The feedback helped us gain valuable perspective, guiding us toward [necessary improvements](https://gitlab.com/gitlab-org/gitlab/-/issues/418331) in these workflows. Some of the notable changes are highlighted in this blog.\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube.com/embed/gdL2cEp3kw0?si=aNmhofDU3DsnofiP\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Better management\n\n![variables management - image 1](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098505/Blog/Content%20Images/Blog/Content%20Images/image2_aHR0cHM6_1750098504762.png)\n\nEffective decision-making regarding the addition, modification, or removal of CI/CD variables hinges on understanding their purpose within a project or group. Lacking visibility into a variable's purpose can complicate these decisions. To address this challenge, we've introduced an enhancement to the variable creation process that will allow users to provide a description detailing the usage and context of a variable, reducing reliance on memory. This description will be displayed in the list, along with the other attributes of the variable. \n\n## Seamless task continuity\n\n![variables management - image 2](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098505/Blog/Content%20Images/Blog/Content%20Images/image3_aHR0cHM6_1750098504763.png)\n\nEfficiency is paramount in software development as it allows developers to make time to focus on qualitative aspects of their work. We have changed the variable creation workflow to facilitate consecutive addition or editing of multiple variables to boost efficiency. Improved, clear notifications and contextual error messages ensure users can perform tasks without the need to repeatedly open separate forms.\n\n## Enhanced error prevention\n\n![variables management - image 3](https://res.cloudinary.com/about-gitlab-com/image/upload/v1750098505/Blog/Content%20Images/Blog/Content%20Images/image1_aHR0cHM6_1750098504764.png)\n\nHow the error messages are presented and made accessible in a workflow determines their effectiveness in error resolution. We revisited the different error states users are likely to encounter during variable creation and editing workflow and identified the improvement opportunities ranging from adding new validations and help-texts to enhancing existing error-handling states.\n\n## Share your feedback\nWe believe in taking an iterative approach to better the product. We used insights from the recent user research and our best judgment when deciding on the changes, but there’s always room for improvement. Your feedback from your experience of using the changed UI for performing the tasks in your everyday work will help us understand what’s working and what isn’t, and, therefore, decide on future iterations. Please head to our [feedback issue](https://gitlab.com/gitlab-org/gitlab/-/issues/441177) to share your thoughts and suggestions on the changes made.\n\n## What’s next?\nAs we work on making the existing variables workflow more usable, we’re also making progress on the [GitLab Secret Manager](https://about.gitlab.com/direction/govern/pipeline_security/secrets_management/#overview) to provide users with a more secure method for enabling GitLab, or a component built within GitLab, to connect to other systems.\n\nThere’s an ongoing effort to [improve the variables table layout to clearly represent the visual hierarchy](https://gitlab.com/gitlab-org/gitlab/-/issues/403176) between group and project variables and enhancing the [audit history for CI variables](https://gitlab.com/gitlab-org/gitlab/-/issues/416148) to provide better visibility into activities related to variables.\n\n## Read more about our UI improvements\n- [How we overhauled GitLab navigation](https://about.gitlab.com/blog/navigation-research-blog-post/)\n- [Beautifying our UI: Giving GitLab build features a fresh look](https://about.gitlab.com/blog/beautifying-of-our-ui/)\n\n_Disclaimer: This blog contains information related to upcoming products, features, and functionality. It is important to note that the information in this blog post is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab._\n",[109,9,1809,1169],"DevSecOps",{"slug":1811,"featured":91,"template":701},"revisiting-the-variables-management-workflow","content:en-us:blog:revisiting-the-variables-management-workflow.yml","Revisiting The Variables Management Workflow","en-us/blog/revisiting-the-variables-management-workflow.yml","en-us/blog/revisiting-the-variables-management-workflow",{"_path":1817,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1818,"content":1824,"config":1830,"_id":1832,"_type":14,"title":1833,"_source":16,"_file":1834,"_stem":1835,"_extension":19},"/en-us/blog/six-key-practices-that-improve-communication",{"title":1819,"description":1820,"ogTitle":1819,"ogDescription":1820,"noIndex":6,"ogImage":1821,"ogUrl":1822,"ogSiteName":686,"ogType":687,"canonicalUrls":1822,"schema":1823},"How to Improve Company Communication","Learn here how we've streamlined and improved company communication in six ways. And now your company can too.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680960/Blog/Hero%20Images/simon-abrams.jpg","https://about.gitlab.com/blog/six-key-practices-that-improve-communication","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to Improve Company Communication\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Brinkman\"}],\n        \"datePublished\": \"2019-12-23\",\n      }",{"title":1819,"description":1820,"authors":1825,"heroImage":1821,"date":1827,"body":1828,"category":1011,"tags":1829},[1826],"Eric Brinkman","2019-12-23","\n\nRecently, we caught up with a Fortune 50 company that wanted to understand how to enact change more quickly,\nbolster its product management practice, and execute projects more efficiently. This\nled to a conversation with our CEO and co-founder [Sid Sijbrandij](/company/team/#sytses), who\nwalked through a few key GitLab practices for improving communication in the workplace. Luckily, I was able to \"shadow\" this conversation as I was participating in our [CEO shadow program](https://handbook.gitlab.com/handbook/ceo/shadow/) at the time.\nAfter the discussion, we quickly realized it made sense to share our best practices. While these power our all-remote organization, we think they're good ideas for any company to consider.\n\n## Utilize directly responsible individuals (DRIs)\n\nIn our organization, we have the concept of the [directly responsible individual](/handbook/people-group/directly-responsible-individuals/).\nAnd, as you may have guessed, that person is **directly** responsible for the decision\nthey are tasked with. This could be something routine, such as a prioritization decision\n(in this case the typical DRI is the product manager) or something bigger, such as choosing a vendor to partner with to implement product analytics. The DRI is expected to become\ninformed about options and alternatives via their team, but is ultimately the one responsible\nfor making the call. This helps because you don’t have to wait for consensus-driven decision-making.\nMost organizations are slowed down by governance teams or by a need to ensure every single person\nimpacted signs off. While it’s important to communicate, it can slow you down if you wait for everyone\nto sign off. Consider implementing DRIs to help ensure high velocity decision-making.\n\n\n\n## Make product and engineering responsibilities distinct\n\nAt many organizations, the product manager is responsible for not only setting the priorities,\nbut also must ensure those priorities are shipped on time. This leads to\nan odd situation where product is held accountable for shipping code, something that is typically\noutside of the team's control. At GitLab, we clearly outline that product is responsible for prioritizing\nand defining what is to be done and engineering is responsible for shipping the defined functionality. Setting clear boundaries around what each functional area is responsible\nfor leads to an environment where people can get away from finger pointing and back to the job they should\nhave been doing all along.\n\n## Share via InnerSourcing\n\nAt GitLab, everything is [public by default](/handbook/hiring/principles/#transparency) and there should be a documented\nreason why an issue or line of code needs to be private. Why? The answer is simple:\nby making everything public by default, everyone in the community can contribute. Now, we\nrealize public repositories and issue trackers may not be feasible for every organization,\nbut this typically doesn’t apply _inside_ the organization. InnerSourcing is a mindset shift\nthat helps organizations share code and best practices internally.\nWhen code repositories and issue trackers become open, teams have a much easier time collaborating\non problems and solutions that may be siloed. [DevOps](/topics/devops/) is all about breaking down silos and InnerSourcing\nis a great way to not only reuse code and ideas, but also encourage collaboration.\n\n## Write everything down\n\nCan you recall a time where you went to a meeting, made a decision, and then came back next week to\nfind people forgot that happened? Unfortunately, this is too common at many organizations\nand leads to unnecessary rehashing of the same information, arguments, and talking points. By writing everything down,\nit’s clear when a decision was made or a process was changed. Writing things down is a high leverage activity –\nit allows information to be documented once and then disseminated to many people with little\neffort on the part of the author. It also helps to maintain a record of what happened. At GitLab, we write things down in issues and merge requests. And for bigger things, we have a\n[handbook](https://handbook.gitlab.com/handbook/) of over 3,000 pages where we outline how the company works,\nits various processes, and our product strategy. This single source of truth is also constantly being updated because we encourage everyone to propose changes and additions to it.\n\n## Iterate, iterate, iterate\n\n[Iteration](https://handbook.gitlab.com/handbook/values/#iteration) is one of GitLab’s core values for a number of\nreasons. When you iterate, you reduce the need for coordination amongst many teams and stakeholders. The smallest change or proposal\nyou make, the fewer people you need to ask for permission. If you are going to take six months to build something, you will need to spend a lot of time getting stakeholder and executive buy-in to ensure resources\nare being leveraged appropriately. Conversely, if you are going to take two weeks to build something, less buy-in is\nrequired and it is much easier to know if you’re on the right path. In larger organizations, coordination is the\nthing that slows you down. Iterating allows for quicker feedback.\n\n## Understand the job to be done\n\nThe [jobs to be done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done)\n(J2BD) framework is popular for shifting away from correlation-based models and towards what the customer is trying to\naccomplish. We heavily utilize our user experience (UX) group to work closely with our product management team in order\nto identify and highlight the top jobs to be done. We invest heavily in user research to confirm the jobs\nto be done. The jobs are turned into scorecards which outline areas of potential improvement. These potential improvements\nare provided to product managers to consider when prioritizing features. The jobs-to-be-done framework\nis important to identify cross-service workflows such as code deployment which crosses many DevOps stages\nwithin GitLab. When you fully understand your users, you’re able to prioritize the improvements that\nmatter, leading to a better product.\n\nWhile not an exhaustive list, the six characteristics identified above are key to GitLab’s success as an [all-remote company](/company/culture/all-remote/). And all of these practices can be taken and adapated for any organization looking to strengthen communication in the workplace or considering a move to all remote.\n\nMost everything we do is publicly available, from our code to our roadmaps to our product\nmanagement processes. If you’re interested, you can find out  more in our [product handbook](/handbook/product/),\nwhich outlines other axioms and best practices for software product development. And, as always, if what you’ve just read\nresonates with you, and you’d like to join the team, let [me](https://gitlab.com/ebrinkman) know. We’ve more than tripled\nour team in 2019, and we’ll likely be doubling again in 2020.\n\nCover image by [Simon Abrams](https://unsplash.com/@flysi3000) on [Unsplash](https://unsplash.com)\n{: .note}\n\n",[722,769,9],{"slug":1831,"featured":6,"template":701},"six-key-practices-that-improve-communication","content:en-us:blog:six-key-practices-that-improve-communication.yml","Six Key Practices That Improve Communication","en-us/blog/six-key-practices-that-improve-communication.yml","en-us/blog/six-key-practices-that-improve-communication",{"_path":1837,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1838,"content":1843,"config":1848,"_id":1850,"_type":14,"title":1851,"_source":16,"_file":1852,"_stem":1853,"_extension":19},"/en-us/blog/small-experiments-significant-results-and-learnings",{"title":1839,"description":1840,"ogTitle":1839,"ogDescription":1840,"noIndex":6,"ogImage":883,"ogUrl":1841,"ogSiteName":686,"ogType":687,"canonicalUrls":1841,"schema":1842},"Small experiments, significant results and learnings","How our Growth team validates design solutions with the smallest experiments possible","https://about.gitlab.com/blog/small-experiments-significant-results-and-learnings","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Small experiments, significant results and learnings\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matej Latin\"}],\n        \"datePublished\": \"2021-04-07\",\n      }",{"title":1839,"description":1840,"authors":1844,"heroImage":883,"date":1845,"body":1846,"category":765,"tags":1847},[1047],"2021-04-07","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nA while ago, I worked closely with the Growth:Expansion team on improving the experience of inviting users to GitLab. I first went through the existing experience of a user that’s inviting their team to GitLab and found a few opportunities for improvements. The work could have ended there, but I felt uneasy about it in the days after completing it. I felt that there was more to it, so I dug in again. This time, I wanted to explore what the experience was across many users involved in the process, instead of just the inviting user.\n\n## Multi-user journey map\n\nSo instead of mapping out a single-user journey map, I mapped out the journey as it was then for all the users involved. I came up with the following:\n\n![Multi-user journey map](https://about.gitlab.com/images/blogimages/small-experiments/multi-user-journey.png)\n\nTake a look at the [multi-user journey map on Mural](https://app.mural.co/t/gitlab2474/m/gitlab2474/1588920686905/a2982098783c967cee6f7e656fffe574dec0777b).\n\nI wanted to see what it was like for non-admin users to invite their team to GitLab or assign some work to them (not all managers and leads are admin users). So a non-admin user wants to assign an issue to a team member that isn’t on GitLab yet. There are three users involved: the non-admin user trying to assign some work, the admin user who is the only one who can invite new users and the user that is being invited.\nThe main conclusion of this multi-user journey map? There are many interruptions and a lot of waiting time between the steps. Such a simple task as assigning an issue to a team member can span across days because of these interruptions.\n\nThe other conclusion of this work was that it was hard to find out how to invite users to GitLab, especially for new teams trying to adopt GitLab.\n\nSo we came up with a problem to solve:\n\n> Can we make it easier for new teams to invite their team members?\n\nand a question to answer:\n\n> Would non-admin users request invitations to their team members if they could?\n\n## Making it easier for new teams to invite their team members\nWe started with the smaller problem as it was a great candidate to do a MVC (minimal viable change) experiment and learn a lot from it. The concept of the solution was simple: increase the discoverability of the *invite members* feature. After some thought, I realized that the best place for this was the Assignee dropdown that we use on issues and merge requests. It’s at the top of the right sidebar, which means it’s quite prominent, but more importantly, it is a commonly used feature related to team management.\n\nSo we decided that the most minimal experiment we could do was to add the “Invite members” link to the bottom of that dropdown and link directly to the *Settings* → *Members* page of the project. That’s the page where admin users can invite new users.\n\n![Assignee dropdown](https://about.gitlab.com/images/blogimages/small-experiments/assignee-dropdown.png){: .small.center}\n\n[Here’s the prototype](https://www.sketch.com/s/e96544d1-f2c7-45d5-a968-23e63064432d/a/bD9885/play) of the experience we tested. After crunching the numbers of the experiment we saw the following results:\n\n- Only a 0.16% click-through rate on the “Invite members” link in the dropdown\n- But a 2% increase in namespaces with two or more users\nThis was significant because we only showed the new “Invite members” link to admin users. So the low click-through rate makes sense as the majority of users viewing the assignee are not admins and therefore did not see our test \"invite members\" option. However, even with a low click-through rate, the change in the metric that mattered most saw a 2% increase. Which is a considerable increase on its own! But we’re just getting started.\n\n## Do non-admin users want to invite their team members?\n\nNow we come to the question that we uncovered during the mapping of the multi-user journey. There’s a lot of waiting time and disruptions in the process of inviting a new user to GitLab. Especially when a non-admin user wants to do it. So we decided to run a similar experiment where we show the “Invite members” link in the assignee dropdown to non-admin users too.\nFollowing our MVC approach to conducting experiments, we wanted to run a minimal experiment that would help us answer this question. Instead of taking the time to build a complete experience for non-admin users requesting invitations from admin users, we decided to show a modal explaining that this feature isn’t available yet. We also added a link that would take the non-admin user to the *Settings* → *Members* page, where they can see who the admin is and contact them outside of GitLab (for now).\n\n![Modal not ready](https://about.gitlab.com/images/blogimages/small-experiments/modal-not-ready.png)\nIt’s not the ideal experience, but the potential for learning justified it. Plus, we only show an experiment like this to a fraction of our users. The experiment has only been running for a few weeks, so it’s too early for conclusions. But we’re seeing encouraging results already, some suggest even up to a 20% increase in namespaces with two or more users so yes, it seems that non-admin users do want to invite their team members.\n\n## Other improvements and follow-up experiments\nOne major improvement that our engineers have been working on is the “Invite members” modal. Instead of taking the user out of their workflow and into the *Settings* → *Members* page, they’ll be able to invite team members within their current workflow.\n\n![Modal invite form](https://about.gitlab.com/images/blogimages/small-experiments/modal-invite.jpg)\n\n[This is a prototype](https://www.sketch.com/s/e96544d1-f2c7-45d5-a968-23e63064432d/a/wmOa8m/play) of what the experience would be like with the invite modal.\n\n## Conclusion\n\nThese experiments are the first among many that we want to conduct. We’re also thinking about allowing non-admin users to request a free trial, activation of a feature, switching to a higher plan from their admin all while potentially giving the admin the ability to turn this functionality off and on as needed. The experiments we conducted so far are indicating that there’s a demand for non-admin users to be able to request things limited to admins. And most importantly, they were minimal experiments that led to significant results and great learnings.\n\nFor more details about these experiments check\n* [the original experiment design issue](https://gitlab.com/gitlab-org/gitlab/-/issues/217921)\n* [the follow-up experiment design issue](https://gitlab.com/gitlab-org/gitlab/-/issues/235979)\n* [the video recording of experiment and results discussion between me and Sam Awezec](https://www.youtube.com/watch?v=J5h_SNH3Nt8&ab_channel=GitLabUnfiltered) (the Product Manager of Growth:Expansion)\n\nPhoto by [Evgeni Tcherkasski](https://unsplash.com/@evgenit?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/small?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1266,722,9],{"slug":1849,"featured":6,"template":701},"small-experiments-significant-results-and-learnings","content:en-us:blog:small-experiments-significant-results-and-learnings.yml","Small Experiments Significant Results And Learnings","en-us/blog/small-experiments-significant-results-and-learnings.yml","en-us/blog/small-experiments-significant-results-and-learnings",{"_path":1855,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1856,"content":1862,"config":1868,"_id":1870,"_type":14,"title":1871,"_source":16,"_file":1872,"_stem":1873,"_extension":19},"/en-us/blog/starting-from-the-start-slippers-design-system",{"title":1857,"description":1858,"ogTitle":1857,"ogDescription":1858,"noIndex":6,"ogImage":1859,"ogUrl":1860,"ogSiteName":686,"ogType":687,"canonicalUrls":1860,"schema":1861},"Why design systems benefit everyone","Learn how the GitLab digital experience team built the Slippers design system for our marketing website.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679537/Blog/Hero%20Images/slippers-sys.jpg","https://about.gitlab.com/blog/starting-from-the-start-slippers-design-system","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why design systems benefit everyone\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Stephen McGuinness\"}],\n        \"datePublished\": \"2021-03-05\",\n      }",{"title":1857,"description":1858,"authors":1863,"heroImage":1859,"date":1865,"body":1866,"category":870,"tags":1867},[1864],"Stephen McGuinness","2021-03-05","\n\nThe [Digital Experience team](/handbook/marketing/digital-experience/) is new at GitLab, but we spent the past few months [creating Slippers, a new design system, which is a centralized location for design assets and code](https://gitlab.com/gitlab-com/marketing/digital-experience/slippers-ui). This blog post explains how we managed to build a design system in record time and accounts for how we overcame some of the challenges we encountered along the way.\n\nWe built Slippers because we needed a design system that we could rapidly iterate on and that would scale. We needed to use technologies that offered a single source of truth so our growing team could build on the repo. This process is not without its frustrations – what can work for one team might not work for the entire marketing department. In the past, discrepancies in design would happen because we didn't have a style guide.\n\nFortunately, creating a system that can respond to quick iterations can provide a solution to this complex problem. But \"simple\" in this case is misleading. We needed a new way of thinking and working. It is not enough to create a UI kit of consistent design assets for your designers to work with, doing this alone will fall at the first hurdle if it is not reflected in a coded repo. Designs will produce variations over time. Technical and design debt builds up due to small changes made over time and you end up where you started – with fragmented design and code.\n\nTime and effort as well as a vision are necessary to create a design system solution. This is the place our new team was at near the end of 2020. An already bizarre year for many, this was a great time to create a team to tackle this technical challenge head-on.\n\n## Why design systems are for everyone\n\nA common misconception of a design system is that it is for designers. You create a UI kit, hand it to developers, and you are off to the races. While a UI kit is important to the success of a system, it is just one part of what is a technical and efficient product.\n\nOur goal was to create a reusable library of assets, which included design assets (typestack, colors, spacing, grid, buttons, etc.) along with documentation on usage criteria. This is a big project that requires a lot of effort. First, we aligned around a common vision and product architecture. I want to emphasize \"product\" because this system acts as a product serving multiple teams across GitLab. Next, we rallied our team around a common goal and got to work. Our team established a set of guiding principles that would always act as our anchor for the project. [You can read more about them here](https://gitlab.com/gitlab-com/marketing/digital-experience/slippers-ui).\n\n*\"The more decisions you put off, and the longer you delay them, the more expensive they become.\"*\n\n**―[Craig Villamor](https://www.linkedin.com/in/craigvillamor), senior design director of Google Maps**\n\nWe found this quote from Craig in a [Medium post about the benefits of design systems](https://medium.com/agileactors/7-quotes-about-design-systems-that-will-inspire-you-9a89557fb26f). His remarks describe the dangers of putting off building a design system for too long. The fact is, the longer you design without a clear system and rubric, the more tech and design debt accumulates.\n\n## How we built the design system\n\nProducts exist to solve problems, so we articulated our vision with working sessions. The sessions were a platform for aligning our vision based on what we considered maintainable design and technology.\n\nOnce we aligned on our guiding principles we set about creating a roadmap. Our team decided how we wanted our product to be built, and agreed on tooling, tech stacks, and a cadence of delivery during our working sessions.\n\nWe decided on Figma for design since this was already being used within GitLab. Next, we created our core elements along with some [baseline components such as type, color, and spacing for the design system](https://www.figma.com/file/nWIOpmuMp7RZXmfTj6ujAF/Slippers_foundations?node-id=1292%3A573). We used existing pages as templates to refactor and give us a broader idea of what was and was not working. This process gave our developers time to investigate the best way to code our product and determine what shape it would take.\n\n## The value of a shared language\n\nOur engineering team started working on our tech stack and our designers started to work on what we called our \"foundations\". This can also be referred to as \"elements\". We did this in a way so we could stress-test our foundations package by refactoring existing pages with new styles that gave us an idea of the direction of our design system.\n\nNext, we applied these core elements to a select sample of pages to act as a proof of concept. We chose to edit the [homepage](https://about.gitlab.com/), [enterprise page](/enterprise/), [pricing page](/pricing/), and [entire GitLab Blog section](/blog/). We identified pain points and apply stop-gaps along the way. Since we are [results-driven](https://handbook.gitlab.com/handbook/values/#results), we used local CSS (Cascading Style Sheets) tightly coupled to the site itself. The perk of this approach is that you can deliver results quickly. After doing some UX and UI refinements on these pages, introducing new technology was easier because each of the pages are actively maintained. We used this time to learn and apply this practice to improve the system.\n\n## What's next\n\nThough the Digital Experience team has only been established for four months we've made huge inroads. We are starting to see how the Slippers design system will look once it is implemented across the entire organization.\n\nBuilding the Slippers design system is an example of a research and development (R&D) project. By laying out these foundations, we are set up for large-scale learning and success. The team is continuously gathering data for this R&D project and using it to better inform and refine our design system.\n\nAlso, since GitLab is open source, we are factoring open source values into our Slippers roadmap. We do this through posting our video updates to our partners and [public YouTube videos](https://www.youtube.com/c/GitLabUnfiltered/featured).\n\nThe reality is, this work takes time and investment. There is a herculean effort still left for us to bring the system fully to life. But already we have demonstrated the value of a design system to our leadership by delivering more than 2000 new CMS pages.\n\nEven at this very early stage the Slippers project has been rewarding and provides us with a continuous source of valuable insights. We're encouraged to push the boundaries and take calculated risks in what we learn and what we do.\n\nStay up-to-speed on our progress by checking out our [Slippers project](https://gitlab.com/gitlab-com/marketing/digital-experience/slippers-ui) and [watching our team videos on GitLab Unfiltered](https://www.youtube.com/c/GitLabUnfiltered/featured).\n\nCover photo by [Nihal Demirci](https://unsplash.com/@nihaldemirci?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/photos/0ME-BIUBmUs)\n{: .note}\n",[767,722,770,9],{"slug":1869,"featured":6,"template":701},"starting-from-the-start-slippers-design-system","content:en-us:blog:starting-from-the-start-slippers-design-system.yml","Starting From The Start Slippers Design System","en-us/blog/starting-from-the-start-slippers-design-system.yml","en-us/blog/starting-from-the-start-slippers-design-system",{"_path":1875,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1876,"content":1882,"config":1889,"_id":1891,"_type":14,"title":1892,"_source":16,"_file":1893,"_stem":1894,"_extension":19},"/en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab",{"title":1877,"description":1878,"ogTitle":1877,"ogDescription":1878,"noIndex":6,"ogImage":1879,"ogUrl":1880,"ogSiteName":686,"ogType":687,"canonicalUrls":1880,"schema":1881},"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":1877,"description":1878,"authors":1883,"heroImage":1879,"date":1886,"body":1887,"category":765,"tags":1888},[1884,1885,1047,1497],"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",[768,9,770,769,767],{"slug":1890,"featured":6,"template":701},"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":1896,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1897,"content":1903,"config":1909,"_id":1911,"_type":14,"title":1912,"_source":16,"_file":1913,"_stem":1914,"_extension":19},"/en-us/blog/the-evolution-of-ux-at-gitlab",{"title":1898,"description":1899,"ogTitle":1898,"ogDescription":1899,"noIndex":6,"ogImage":1900,"ogUrl":1901,"ogSiteName":686,"ogType":687,"canonicalUrls":1901,"schema":1902},"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":1898,"description":1899,"authors":1904,"heroImage":1900,"date":1905,"body":1906,"category":765,"tags":1907},[1634],"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",[9,768,698,829,1908],"production",{"slug":1910,"featured":6,"template":701},"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":1916,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1917,"content":1923,"config":1929,"_id":1931,"_type":14,"title":1932,"_source":16,"_file":1933,"_stem":1934,"_extension":19},"/en-us/blog/the-future-of-the-gitlab-web-ide",{"title":1918,"description":1919,"ogTitle":1918,"ogDescription":1919,"noIndex":6,"ogImage":1920,"ogUrl":1921,"ogSiteName":686,"ogType":687,"canonicalUrls":1921,"schema":1922},"The Future of the GitLab Web IDE","There are big changes in store for the Web IDE in the coming milestones.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679284/Blog/Hero%20Images/johannes-plenio-2TQwrtZnl08-unsplash.jpg","https://about.gitlab.com/blog/the-future-of-the-gitlab-web-ide","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"The Future of the GitLab Web IDE\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Eric Schurter\"}],\n        \"datePublished\": \"2022-05-23\",\n      }",{"title":1918,"description":1919,"authors":1924,"heroImage":1920,"date":1926,"body":1927,"category":1264,"tags":1928},[1925],"Eric Schurter","2022-05-23","\nWay back in April 2018, [GitLab 10.7 introduced the Web IDE](/blog/introducing-gitlab-s-integrated-development-environment/) to the world and brought a delightful multi-file editor to the heart of the GitLab experience. Our goal was to make it easier for anyone and everyone to contribute, regardless of their development experience. Since its introduction, tens of millions of commits have been made from the Web IDE, and we've added features like [Live Preview](https://docs.gitlab.com/ee/user/project/web_ide/#live-preview) and [Interactive Web Terminals](https://docs.gitlab.com/ee/user/project/web_ide/index.html#interactive-web-terminals-for-the-web-ide) to enhance the experience. Now, we're excited to share some big changes we have in store for the Web IDE in coming milestones.\n\n## What makes an IDE?\n\nOver the years, we've learned a lot about how you all are using the Web IDE. We've [compared it to our Web Editor](https://about.gitlab.com/blog/a-tale-of-two-editors/) in the repository view. We've spoken to developers, designers, product managers, and technical writers alike. Almost universally, we hear that the Web IDE is great for small changes: a quick change to a config file, an update to a Markdown file, or a typo fix in a merge request. These lightweight changes make up the vast majority of the Web IDE usage. And for those use cases, it's super convenient and intuitive.\n\n![Editing a file in the current Web IDE](https://about.gitlab.com/images/blogimages/web-ide-diff-view.png)\n\nBut to grow, and to really earn the moniker “IDE,” what are we missing? What keeps developers from making more complex changes in the Web IDE? What can we do to elevate the experience? We hear about missing features and functionality like a [collapsible file panel](https://gitlab.com/groups/gitlab-org/-/epics/2585) that supports [contextual actions](https://gitlab.com/gitlab-org/gitlab/-/issues/197775) and drag and drop or [tighter integration with merge requests](https://gitlab.com/groups/gitlab-org/-/epics/2687). We've learned that there's no single feature that's a deal-breaker for most developers; it's the sum total of a lot of little user experience gaps.\n\nThe Web IDE is built on top of the fantastic open source project, [Monaco](https://microsoft.github.io/monaco-editor/). What made Monaco a great choice as the foundation of the Web IDE is also what makes it more difficult to address all these concerns holistically. Monaco is just that: a foundation. We have to implement all these workflows and features ourselves. Meanwhile, another open source project has been laser-focused on delivering a lovable IDE on top of Monaco.\n\n## Enter VS Code\n\nYou may have heard of [Visual Studio Code](https://code.visualstudio.com/), or VS Code. With its [dominant market share](https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-integrated-development-environment), chances are pretty good that you are even using it as your primary code editor. As it happens, [VS Code](https://github.com/microsoft/vscode) core is also open sourced under the MIT license. While the core project isn't a perfect drop-in replacement for the Web IDE, our Staff Frontend Engineer, [Paul Slaughter](/company/team/#pslaughter), wanted to see if we could run it inside GitLab.\n\nTurns out, we can:\n\u003Chttps://www.youtube.com/embed/_9G45TNR7VA>\n\nIn this video Paul Slaughter, Staff FE Engineer, walks Eric Schurter, Senior Product Manager, through the VS Code Web IDE proof of concept. See parts [two](https://www.youtube.com/watch?v=oyEFNOC1_Bo&list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-&index=9), [three](https://www.youtube.com/watch?v=1mTkNxrFXec&list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-&index=8), and [four](https://www.youtube.com/watch?v=qEiXtiInFIA&list=PL05JrBw4t0KrRQhnSYRNh1s1mEUypx67-&index=7) for closer looks at extensions, performance, and customization.\n\nAs you can see in the videos above, Paul was able to build a proof of concept that brings the VS Code editing experience into the GitLab UI, running entirely in the browser. No additional infrastructure needed.\n\nNext, we asked ourselves the question: Do we want to continue to invest in implementing custom features for the Web IDE that ultimately deliver the same value as those already available in VS Code? Or do we embrace VS Code inside GitLab, and invest in extending the experience to more tightly integrate with GitLab and the DevOps workflow?\n\n## Meet the new Web IDE\n\nAs you've probably already guessed, we've decided to [replace the current Web IDE with one built on top of VS Code](https://gitlab.com/groups/gitlab-org/-/epics/7683). In the coming milestones, we will build out custom support for the features not already available in the VS Code core, and validate that the workflows you already depend on in the Web IDE are handled in the new experience. We're working with the team that builds our amazing [GitLab Workflow extension](https://marketplace.visualstudio.com/items?itemName=GitLab.gitlab-workflow) for VS Code to make it available in the browser so we can bundle it in the Web IDE, and bring all those great features along for the ride. That includes [bringing merge request comments into the Web IDE](/blog/mr-reviews-with-vs-code/) for the first time ever!\n\n## Speaking of extensions\n\nYou read that right: extensions. One of the most compelling aspects of VS Code is the massive community and library of extensions available to customize your experience and integrate with other tools. A subset of [these extensions](https://open-vsx.org/) are already compatible with a web-based instance of VS Code, and our goal is to make them available in the Web IDE so you and your teams can work as efficiently and consistently as possible. Bringing extensions into the GitLab experience is not something we're taking lightly, so we'll be evaluating the best approach for ensuring the security and privacy of your data.\n\n## With great power comes great responsibility\n\nThis transition doesn't come without tradeoffs. We know that many of you appreciate the Web IDE for its simplicity, and it's safe to say that the increase in functionality VS Code brings to the table does come with an increase in complexity. The original Web IDE was introduced as a way to ensure that everyone can contribute. In keeping with that spirit, we will invest in improvements to our [core editing component](https://gitlab.com/groups/gitlab-org/-/epics/4861) that powers the [Web Editor](https://docs.gitlab.com/ee/user/project/repository/web_editor.html), Snippets, Pipeline Editor, and code editing elsewhere in GitLab. This core component will be extended to support multi-file editing. Our hope is that it actually serves those workflows that require simple edits even better than the Web IDE ever did.\n\n## I'm ready, when can I have it?\n\nWe're all excited to start using the new Web IDE as soon as possible. We're actively working on the integration and you can expect to see it sometime in the 15.x release cycle. If you would like to provide early feedback and help us fine tune the experience, please fill out this [short survey](https://forms.gle/S1vU5vkaEjE1NPMv9) to be considered for early access.\n\n## But wait, what about the runtime stuff?\n\nRemember at the beginning of this post when I asked what makes an IDE? The critical piece of the puzzle that VS Code is still missing is a runtime environment to compile your code. Without this environment, you can't generate real-time previews, run tests, or take advantage of code completion. We're looking to tackle this problem with the newly-formed [Remote Development category](/direction/create/ide/remote_development/), but that's a topic for a whole other blog post.\n\nUntil then, happy editing!\n\n_This blog post and linked pages contain information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned in this blog post and linked pages are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._\n\nCover image by [Johannes Plenio](https://unsplash.com/@jplenio?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n",[912,1264,9,722],{"slug":1930,"featured":6,"template":701},"the-future-of-the-gitlab-web-ide","content:en-us:blog:the-future-of-the-gitlab-web-ide.yml","The Future Of The Gitlab Web Ide","en-us/blog/the-future-of-the-gitlab-web-ide.yml","en-us/blog/the-future-of-the-gitlab-web-ide",{"_path":1936,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1937,"content":1943,"config":1948,"_id":1950,"_type":14,"title":1951,"_source":16,"_file":1952,"_stem":1953,"_extension":19},"/en-us/blog/two-questions-we-ask-ux-designers-in-job-interviews",{"title":1938,"description":1939,"ogTitle":1938,"ogDescription":1939,"noIndex":6,"ogImage":1940,"ogUrl":1941,"ogSiteName":686,"ogType":687,"canonicalUrls":1941,"schema":1942},"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":1938,"description":1939,"authors":1944,"heroImage":1940,"date":1945,"body":1946,"category":301,"tags":1947},[1047],"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",[722,9,768,1288],{"slug":1949,"featured":6,"template":701},"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":1955,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1956,"content":1962,"config":1968,"_id":1970,"_type":14,"title":1971,"_source":16,"_file":1972,"_stem":1973,"_extension":19},"/en-us/blog/understand-highly-technical-spaces",{"title":1957,"description":1958,"ogTitle":1957,"ogDescription":1958,"noIndex":6,"ogImage":1959,"ogUrl":1960,"ogSiteName":686,"ogType":687,"canonicalUrls":1960,"schema":1961},"How I use analogy to design for highly technical spaces","Just how much does a designer need to know about a technical space or product to design for it?","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749668041/Blog/Hero%20Images/Understand-Highly-Technical-Spaces.jpg","https://about.gitlab.com/blog/understand-highly-technical-spaces","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How I use analogy to design for highly technical spaces\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Camellia Yang\"}],\n        \"datePublished\": \"2021-08-13\",\n      }",{"title":1957,"description":1958,"authors":1963,"heroImage":1959,"date":1965,"body":1966,"category":870,"tags":1967},[1964],"Camellia Yang","2021-08-13","\n\nAs a designer, you're lucky when you get to design an application you're familiar with, such as a supermarket app or a travel website – something we might have already used or even use every day. Most of the time, we are tasked with designing an application or technology that's unfamiliar or highly technical. Sometimes, we may not know what the application we're designing is used for, like creating an interface for an MRI machine controlled by a doctor, or a dashboard used by a professional musician – knowing what all the buttons do is already an achievement.\n\nOne of the trickiest questions for designers is understanding exactly how much you need to know how to use an application to design the best system for the user. This conundrum is typical for designers that work in a highly technical, enterprise space such as GitLab. The challenges can be exacerbated when working on Security products, but in my experience, we don't need to _fully understand_ the technology or space we are designing for, but we do need to have some idea of how it all works.\n\nThe most difficult part is deciding: How much knowledge is enough? How much do you need to know about a product to hold a conversation with users? Or be able to explain it to others in your own words?\n\nAll if those questions are reasonable criteria for designers to focus on, but I've found a more exciting strategy to motivate me to translate complex technical spaces into smart designs: Analogy.\n\n## Create analogies to aid the design process\n\nAs a designer, I like to focus on both my creative and analytical sides but thinking of scenarios that do not exist yet. For instance, I like to do some thought experiments where I'll position myself as different types of users while performing tasks, or pretend I'm a user and critique my own work.\n\nIt may be easier to show how I do this through some examples. Below, I'll give security technologies some new clothes through easy-to-remember stories that match up to what the security technology does.\n\nLet's start by looking at some of the standard security technology that we offer on GitLab:\n\n**Static application security testing (SAST)**: A testing methodology that analyses source code to find security vulnerabilities that make your organization's applications susceptible to attack.\n\n**Dynamic application security testing (DAST)**: A testing methodology that communicates with a web application through the web front-end to identify potential security vulnerabilities in the web application and architecture.\n\n**Fuzz testing**: An automated software testing technique that involves sending invalid, unexpected, or random data as inputs to a computer program in an attempt to get it to fail in some way.\n\nNow that we have an idea of the technologies in question, how might we understand them better through analogy?\n\nImagine a person is going to a hospital to check whether they're sick or not. Think of the SAST, DAST, and Fuzz testing technologies as different doctors with different specialties.\n\nSAST is a modern doctor who loves scanning. SAST can use an X-ray-like machine to see through the application's \"skin\". It can see if any bones are broken – and everything else that makes the application work. This is SAST's key advantage – it can see every detail of the scanned app and analyze it. It also has maps with predefined problems so SAST can compare and find the problems. In some ways, the SAST maps is what [Gray's Anatomy](https://www.amazon.com/Grays-Anatomy-Anatomical-Clinical-Practice/dp/0702052302), the seminal medical school textbook, is to a doctor's clinical practice.\n\nDAST, on the other hand, is more like your primary care physician. DAST doesn't need to know all of the details about how everything is doing inside your body (or the application). Instead, DAST talks with the app by asking questions and then observing and analyzing the responses. If the response is strange, wrong, or there is no response, DAST knows there are potential problems\n\nFuzz testing is the doctor that is a master of AI. Sometimes it also has a scanner like SAST, but it doesn't analyze in the same way. Fuzz testing has AI X-ray glasses that can mutate based on what it sees – potentially seeing even more. The analysis is the most personalized because of these mutated glasses: When the glasses see something suspicious at the shoulder area, it can change the lights and analyze it from the weirdest angle possible to match the individual shoulder. In other words, it adapts itself based on what was previously discovered and then digs deeper. Similarly, when Fuzz testing does not have a scanner, it has AI hearing, which allows it to change or mutate its questions based on the app's responses. It can possibly ask better questions as it scans to get more valuable answers to identify problems.\n\nI like to use people in my analogies because technology is so complicated but few things are as complex as humans. Creating stories about things that I can relate to in my daily life makes them more accessible.\n\nI hope you've found these examples to be a fun way to conceptualize challenging and highly technical topics. Next time you're designing in highly technical spaces, try building out relatable analogies and remove any fears of working in this space as a designer. One piece of advice: Always verify your analogies with professionals who have a deep understanding of the domain – no one will laugh at a passionate designer who tries to understand an unfamiliar world.\n",[719,9],{"slug":1969,"featured":6,"template":701},"understand-highly-technical-spaces","content:en-us:blog:understand-highly-technical-spaces.yml","Understand Highly Technical Spaces","en-us/blog/understand-highly-technical-spaces.yml","en-us/blog/understand-highly-technical-spaces",{"_path":1975,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1976,"content":1981,"config":1986,"_id":1988,"_type":14,"title":1989,"_source":16,"_file":1990,"_stem":1991,"_extension":19},"/en-us/blog/unveiling-gitlabs-new-navigation",{"title":1977,"description":1978,"ogTitle":1977,"ogDescription":1978,"noIndex":6,"ogImage":1591,"ogUrl":1979,"ogSiteName":686,"ogType":687,"canonicalUrls":1979,"schema":1980},"Unveiling GitLab's new navigation","A whole new way to navigate.","https://about.gitlab.com/blog/unveiling-gitlabs-new-navigation","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Unveiling GitLab's new navigation\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarrah Vesselov\"}],\n        \"datePublished\": \"2017-09-13\",\n      }",{"title":1977,"description":1978,"authors":1982,"heroImage":1591,"date":1983,"body":1984,"category":301,"tags":1985},[1165],"2017-09-13","\n\nIn 9.4 we took a big step toward [improving our navigation](/blog/redesigning-gitlabs-navigation/) here at GitLab. After several rounds of research and testing, we released our redesigned navigation under a feature flag. We chose this method so that we could continue implementing improvements discovered in our original research while gathering real-world feedback from our users.\n\n\u003C!-- more -->\n\n## We heard you!\n\nWe received an incredible number of responses in the [issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/34917) created to gather feedback. The feedback gave us valuable insight into the many different types of workflows our users have. It reaffirmed some of the decisions made and challenged us to rethink others. Using this feedback, we iterated on the navigation for two release cycles, focusing on the changes that would add the most benefit. Here are some of the high-level additions we made:\n\n### Collapsible sidebar and addition of icons – [#34028](https://gitlab.com/gitlab-org/gitlab-ce/issues/34028)\n\nFrom the beginning, we knew that the sidebar would need to be collapsible in order to maximize screen space. With the right sidebar present in issues and merge requests, we didn’t want to box you in. The addition of icons enabled us to collapse the sidebar down to a mere 50px.\n\n{: .text-center}\n![collapsible menu](https://about.gitlab.com/images/blogimages/unveiling-gitlabs-new-navigation/menu-loop.gif){: .shadow}\n\n### Flyout menu – [#34026](https://gitlab.com/gitlab-org/gitlab-ce/issues/34026)\n\nA fly-out menu has been introduced in order to reduce the number of clicks and the time necessary to access a sub-page. Now, if you want to access Issue Boards, there is no need to click on Issues and wait for the initial ‘Issue List’ to load. When hovering over a section with second-level items, the fly-out drop-down menu will appear to offer quick access to those second-level sections.\n\n{: .text-center}\n![flyout menu](https://about.gitlab.com/images/blogimages/unveiling-gitlabs-new-navigation/flyouts.png){: .shadow}\n\nWe've also adjusted the hover color of the menu items after many of you expressed that the intensity of the color was harsh and distracting. The colors changed from purple to whites and grays without sacrificing the overall contrast.\n\n### Dropdown links in top bar – [#35010]( https://gitlab.com/gitlab-org/gitlab-ce/issues/35010)\n\nNo more clicking on Projects and waiting for the Projects page to load! In order to provide quicker access to projects, a dropdown has been added to the Projects link in the top bar. The dropdown opens on click, following the behavior of the + button and personal dropdowns in the top bar.\n\n{: .text-center}\n![dropdown links](https://about.gitlab.com/images/blogimages/unveiling-gitlabs-new-navigation/dropdown-links.png){: .shadow}\n\nThe dropdown contains direct links to the different subsections of the Projects dashboard (Your Projects, Starred Projects and Explore projects). Better still, on the right-hand side of the dropdown is a list of your most frequently accessed projects. A search box allows you to navigate to your projects that are not present in the list.\n\n### Navigation color themes – [#35012](https://gitlab.com/gitlab-org/gitlab-ce/issues/35012)\n\nOn the subject of colors, one of the most requested features was the ability to change the navigation colors. Previous versions of GitLab allowed users to customize the navigation sidebar with a color theme. Many used this to differentiate between different GitLab instances. The new navigation presented the opportunity to bring back this valuable feature! The default palette will remain indigo, based on the GitLab identity. You will now be able to choose between four additional color schemes; Dark, Light, Blue, and Green.\n\n{: .text-center}\n![navigation color themes](https://about.gitlab.com/images/blogimages/unveiling-gitlabs-new-navigation/color-theme.png){: .shadow}\n\n### Improved breadcrumbs – [#35269](https://gitlab.com/gitlab-org/gitlab-ce/issues/35269)\n\nWe received a lot of feedback on the breadcrumbs. While many of you found them to be helpful, many also found them to be repetitive, inconsistent, and taking up too much overall space. We began by removing GitLab from the start of the breadcrumbs and moving all breadcrumb items onto one line. In order to improve the movement between elements in the breadcrumb, we replaced the slashes with chevrons. We also removed the action buttons from the breadcrumb bar altogether.\n\n{: .text-center}\n![action buttons moved](https://about.gitlab.com/images/blogimages/unveiling-gitlabs-new-navigation/action-remove.png){: .shadow}\n\nWhen multiple subgroups are present, we place them inside of an ellipsis button. This reduces the cognitive load while keeping them accessible. For each breadcrumb element, we have fixed the min-width and the max-width to make sure the whole breadcrumb contracts and expands according to the available space.\n\n{: .text-center}\n![breadcrumbs](https://about.gitlab.com/images/blogimages/unveiling-gitlabs-new-navigation/breadcrumbs.png){: .shadow}\n\nThe breadcrumb labels themselves are more consistent and intuitive. A list of the paths and corresponding breadcrumb titles can be found in the [issue description](https://gitlab.com/gitlab-org/gitlab-ce/issues/35269).\n\n### Reduce header height and redesign active/hover/dropdown styles – [#35424]( https://gitlab.com/gitlab-org/gitlab-ce/issues/35424)\n\nWe reduced the overall header height to give you as much vertical screen space as possible. By popular request, all global links are shown by default and collapse into the 'More' dropdown as space gets tighter. The header active/hover/dropdown styles have been redesigned with a bold new style and Todo/Issue/MR badges are centered to the icons themselves.\n\n{: .text-center}\n![active state](https://about.gitlab.com/images/blogimages/unveiling-gitlabs-new-navigation/active-states.png){: .shadow}\n\n{: .text-center}\n![notifications](https://about.gitlab.com/images/blogimages/unveiling-gitlabs-new-navigation/to-do.png){: .shadow}\n\n\n## Further iteration\n\nWe feel confident that GitLab’s overall navigation has been greatly improved over the last two releases. That is why, as of the 10.0 release, we will remove it from the feature flag and make it the only way to navigate. As always here at GitLab, everything is in draft. We will continue to monitor feedback, test, and iterate.\n\n## Upcoming efforts\n\nLooking forward, the UX team has some big things planned. In addition to improving user flows, we are working hard to increase the overall quality and polish of the UX experience. Stay tuned for a series of blog posts dedicated to explaining our processes as we work on the following key initiatives:\n\n- Change chromatic/full colors to a more harmonious palette [#28614](https://gitlab.com/gitlab-org/gitlab-ce/issues/28614)\n- Establish a proper type ramp to improve contrast and readability [#24310](https://gitlab.com/gitlab-org/gitlab-ce/issues/24310)\n- Iconography is a powerful visual cue to the user and should reflect our particular sense of style [#32894](https://gitlab.com/gitlab-org/gitlab-ce/issues/32894)\n- Architect design process for maintaining master files/symbols team-wide [#26](https://gitlab.com/gitlab-org/gitlab-design/issues/26)\n",[9,722],{"slug":1987,"featured":6,"template":701},"unveiling-gitlabs-new-navigation","content:en-us:blog:unveiling-gitlabs-new-navigation.yml","Unveiling Gitlabs New Navigation","en-us/blog/unveiling-gitlabs-new-navigation.yml","en-us/blog/unveiling-gitlabs-new-navigation",{"_path":1993,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":1994,"content":2000,"config":2006,"_id":2008,"_type":14,"title":2009,"_source":16,"_file":2010,"_stem":2011,"_extension":19},"/en-us/blog/use-cases-for-epics",{"title":1995,"description":1996,"ogTitle":1995,"ogDescription":1996,"noIndex":6,"ogImage":1997,"ogUrl":1998,"ogSiteName":686,"ogType":687,"canonicalUrls":1998,"schema":1999},"How the GitLab UX team uses epics","UX Manager Sarrah Vesselov shares how the UX team is using epics to manage their workflow.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749680187/Blog/Hero%20Images/how-ux-team-uses-epics.jpg","https://about.gitlab.com/blog/use-cases-for-epics","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How the GitLab UX team uses epics\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Sarrah Vesselov\"}],\n        \"datePublished\": \"2018-03-19\",\n      }",{"title":1995,"description":1996,"authors":2001,"heroImage":1997,"date":2002,"body":2003,"category":870,"tags":2004},[1165],"2018-03-19","\n\nOne of the challenges for UX here at GitLab is how to work iteratively, making the smallest changes possible, while maintaining a holistic view of the application. As the manager for the UX department, I was curious to see how we could use [epics](https://docs.gitlab.com/ee/user/group/epics/) to better plan and track UX efforts over time.\n\n\u003C!-- more -->\n\n## What are epics?\n\nThe term 'epic' is most commonly associated with Agile methodology. In Agile, an epic is a collection of user stories that describe a larger user flow, typically consisting of multiple features. So, what does ‘epic’ mean at GitLab? Here, epics contain a title and description, much like an issue, and allow you to attach multiple child issues to indicate hierarchy. In short, an epic is a feature that allows you to manage a portfolio of projects more efficiently and with less effort by tracking groups of issues that share a theme, across projects and milestones.\n\nWhat this meant for the UX team was that we finally had an efficient way to plan, track, and execute a group of thematically related issues. Take the merge request page for example. We have over 100 issues related to UX improvements for this feature alone! Each issue, taken on its own, represents just one piece of a much bigger picture. Epics would allow us to define the goal we have for the entire page and organize issues specific to that effort.\n\n## Getting started with epics\n\nTo get started with epics, we put together a UX strategy template. This template would be filled out and added to the epic description. The template defined the following:\n\n- **Challenges:** What user problem are we trying to solve? What business problem are we trying to solve? Are there obstacles standing in the way?\n\n- **Vision:** What do we want to achieve?\n\n- **Focus Areas:** What will we focus our attention on to have the most impact?\n\n- **Mission:** How will we achieve this goal?\n\n- **Activity/Deliverables:** What will we do and what will we deliver?\n\n- **Measure:** How will we measure success qualitatively and quantitatively?\n\nThe template also includes links to any relevant [personas](/blog/discovering-gitlabs-personas/) and [research](/blog/conducting-remote-ux-research/) we should consider when working toward the overall goal.\n\n## Creating our first epic\n\nWith the template ready to go, we chose the merge request page as our first area of focus. We started by reviewing the existing UX research for this page. It was essential to use data to understand the pain points and opportunities. We also examined the entire backlog of issues related to this page, matching existing issues to the research findings. With the significant pain points identified, we were able to fill out the template and create our very first epic.\n\n![Merge Request Epic](https://about.gitlab.com/images/blogimages/epics-ux.png){: .shadow}\n\nWith a holistic view of what we wanted to achieve, we could go back and find issues in the backlog that were critical to the vision. These issues were added to the epic and ordered according to priority. As we discover new information, we can reorder these issues to match the change in priority. As the scope expands, we can aggressively break things out into new epics for development at a later time or parallel to the existing epic. In the future, [sub-epics](https://gitlab.com/gitlab-org/gitlab-ee/issues/4282) will make this process even more fluid.\n\n![Merge Request Epic Issues](https://about.gitlab.com/images/blogimages/epic-ux-issues.png){: .shadow}\n\n*\u003Csmall>Issues are listed under the epic description. They can be easily reordered by dragging and dropping them into place.\u003C/small>*\n\nWe also set a time frame for this overall effort to be achieved. Having a set timeframe allows us to resource plan with the product team and make adjustments accordingly.\n\n## Looking ahead\n\nSo far, epics have proven to be well suited for planning long-term UX efforts. It has allowed us to maintain a holistic view of product area while still working iteratively. Epics also give other departments better visibility into what UX considers important. We are already looking beyond the merge request page and using epics to plan other efforts spanning multiple milestones. Epics are still relatively new, and there are many additions yet to come. In future releases, they will support [labeling](https://gitlab.com/gitlab-org/gitlab-ee/issues/4032), [discussions](https://gitlab.com/gitlab-org/gitlab-ee/issues/3889), [project-level epics](https://gitlab.com/gitlab-org/gitlab-ee/issues/4019), and integration with [issues](https://gitlab.com/gitlab-org/gitlab-ee/issues/4684) and [roadmaps](https://gitlab.com/gitlab-org/gitlab-ee/issues/3559).\n\n![Roadmap feature for epics](https://about.gitlab.com/images/blogimages/roadmaps.png){: .shadow}\n\nThe [Roadmap feature](https://gitlab.com/gitlab-org/gitlab-ee/issues/3559), pictured above, is set to be released in 10.5. Roadmaps offer a graphical, high level overview of an epic, or multiple epic's, goals and deliverables presented on a timeline. The blue roadmap bar and the epic list item are clickable and will navigate to that epic's detail page.\n\n## Resources\n- [Portfolio Management Roadmap](/direction/#portfolio-management-and-issue-management )\n\nPhoto by [Dmitri Popov](https://unsplash.com/) on [Unsplash](https://unsplash.com/search/photos/scale?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[2005,723,767,9],"agile",{"slug":2007,"featured":6,"template":701},"use-cases-for-epics","content:en-us:blog:use-cases-for-epics.yml","Use Cases For Epics","en-us/blog/use-cases-for-epics.yml","en-us/blog/use-cases-for-epics",{"_path":2013,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":2014,"content":2020,"config":2025,"_id":2027,"_type":14,"title":2028,"_source":16,"_file":2029,"_stem":2030,"_extension":19},"/en-us/blog/why-do-gitlab-designers-contribute-to-the-codebase",{"title":2015,"description":2016,"ogTitle":2015,"ogDescription":2016,"noIndex":6,"ogImage":2017,"ogUrl":2018,"ogSiteName":686,"ogType":687,"canonicalUrls":2018,"schema":2019},"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":2015,"description":2016,"authors":2021,"heroImage":2017,"date":2022,"body":2023,"category":765,"tags":2024},[1634],"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://handbook.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",[9,768,829,767,1287],{"slug":2026,"featured":6,"template":701},"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":2032,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":2033,"content":2039,"config":2045,"_id":2047,"_type":14,"title":2048,"_source":16,"_file":2049,"_stem":2050,"_extension":19},"/en-us/blog/why-gitlab-is-the-right-design-collaboration-tool-for-the-whole-team",{"title":2034,"description":2035,"ogTitle":2034,"ogDescription":2035,"noIndex":6,"ogImage":2036,"ogUrl":2037,"ogSiteName":686,"ogType":687,"canonicalUrls":2037,"schema":2038},"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":2034,"description":2035,"authors":2040,"heroImage":2036,"date":2042,"body":2043,"category":765,"tags":2044},[2041],"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![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/)\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",[767,768,9],{"slug":2046,"featured":6,"template":701},"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":2052,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":2053,"content":2059,"config":2065,"_id":2067,"_type":14,"title":2068,"_source":16,"_file":2069,"_stem":2070,"_extension":19},"/en-us/blog/why-i-love-contributing-to-gitlab",{"title":2054,"description":2055,"ogTitle":2054,"ogDescription":2055,"noIndex":6,"ogImage":2056,"ogUrl":2057,"ogSiteName":686,"ogType":687,"canonicalUrls":2057,"schema":2058},"Why I love contributing to GitLab","Making small meaningful changes is what it's all about.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679501/Blog/Hero%20Images/new-feature.png","https://about.gitlab.com/blog/why-i-love-contributing-to-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why I love contributing to GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Austin Regnery\"}],\n        \"datePublished\": \"2021-05-11\",\n      }",{"title":2054,"description":2055,"authors":2060,"heroImage":2056,"date":2061,"body":2062,"category":765,"tags":2063},[1634],"2021-05-11","It was mid-morning on a Tuesday in February, and I had 10 minutes in between\nmeetings. So I decided to try and solve a pain point of mine. \n\n\nYou see, I had to memorize this HTML snippet to create a collapsible section\nin GitLab Issue descriptions and comments, but I kept forgetting it. Was it\n`summary` or `section`? I could never remember.\n\n\n```html\n\n\u003Cdetails>\n\n\u003Csummary>Insert Title\u003C/summary>\n\nHidden content\n\n\u003C/details>\n\n```\n\n\nEven though it is not vanilla Markdown, GitLab knows how to interpret some\nHTML. I used this formatting trick fairly often since full-page screenshots\ncan occupy a lot of screen space, which leads to excessive scrolling.\n\n\n\nSo I decided to poke around our codebase to see how the other Markdown\nshortcuts worked. To my surprise, it was pretty straightforward. Each\nshortcut had a simple text input that mapped to each button. This\nimplementation was simple to replicate since I just needed to copy/paste and\nreplace a few words.\n\n\n![Image of Vue and Haml files with editor\nshortcuts](https://about.gitlab.com/images/blogimages/why-i-love-contributing-to-gitlab/vue-haml.png){:\n.shadow}\n\n\nThe Vue and Haml files with the new shortcut\n\n{: .note.text-center}\n\n\nI started a branch and began hacking away at the code. Now, I would never\ncall myself a Software Engineer, but I like to try and make things from time\nto time. I was able to add a new shortcut to the toolbar to insert this code\nsnippet for me in less than 10 minutes. No more memorizing! Making\ncontributions like this is what makes working at GitLab so special.\n\n\nNow, it wasn't ready for production, but I at least had something that\nworked. I shared it with my UX colleagues in Slack, and it started to gain\ntraction with several up-votes and few constructive comments on how to make\nit better.\n\n\nWith the functionality flushed out, a few other designers helped me get a\nbetter icon added to our SVG library. Using clear iconography is critical\nfor communicating information more clearly.\n\n\n| Initial Icon | Final Icon |\n\n| - | - |\n\n| ![SVG of chevron right\nicon](https://about.gitlab.com/images/blogimages/why-i-love-contributing-to-gitlab/chevron-right.svg)\n| ![SVG of details block\nicon](https://about.gitlab.com/images/blogimages/why-i-love-contributing-to-gitlab/details-block.svg)\n|\n\n\nThe last thing to do was resolve my failing tests, and I had several\nteammates help me do that.\n\n\n![Gif of the shortcut being\nused](https://about.gitlab.com/images/blogimages/why-i-love-contributing-to-gitlab/demo.gif){:\n.shadow}\n\n\nToday [this\nchange](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/54938) merged!\nNow I solved a pain point for me and others. It took a few months to go from\nidea to production, but the effort was super low. I'd say the return on my\ninitial investment, 10 minutes, is super high.\n\n\n> Having a direct impact on a product was never an option for me before\njoining GitLab.\n\n\n![Image of participants in the Merge\nRequest](https://about.gitlab.com/images/blogimages/why-i-love-contributing-to-gitlab/participants.png){:\n.shadow}\n\n\nThank you to everyone that helped me deploy this\n\n{: .note.text-center}\n",[9,829,2064],"AWS",{"slug":2066,"featured":6,"template":701},"why-i-love-contributing-to-gitlab","content:en-us:blog:why-i-love-contributing-to-gitlab.yml","Why I Love Contributing To Gitlab","en-us/blog/why-i-love-contributing-to-gitlab.yml","en-us/blog/why-i-love-contributing-to-gitlab",{"_path":2072,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":2073,"content":2078,"config":2083,"_id":2085,"_type":14,"title":2086,"_source":16,"_file":2087,"_stem":2088,"_extension":19},"/en-us/blog/why-its-crucial-to-break-things-down-into-smallest-iterations",{"title":2074,"description":2075,"ogTitle":2074,"ogDescription":2075,"noIndex":6,"ogImage":883,"ogUrl":2076,"ogSiteName":686,"ogType":687,"canonicalUrls":2076,"schema":2077},"Why iterative software development is critical","How we learned from our mistakes and adopted an iterative software development mentality to reduce the likelihood of shipping something that doesn't add value.","https://about.gitlab.com/blog/why-its-crucial-to-break-things-down-into-smallest-iterations","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why iterative software development is critical\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Matej Latin\"}],\n        \"datePublished\": \"2021-04-30\",\n      }",{"title":2074,"description":2075,"authors":2079,"heroImage":883,"date":2080,"body":2081,"category":870,"tags":2082},[1047],"2021-04-30","\n\nThis blog post was originally published on the GitLab Unfiltered blog. It was reviewed and republished on 2021-05-05.\n{: .note .alert-info .text-center}\n\nIn a previous blog post called [Small experiments, significant results](/blog/small-experiments-significant-results-and-learnings/) I shared our recent success with conducting small experiments, but, in reality, we didn't start with the most iterative software development approach. It was the Growth team's early failures to iterate that helped us embrace launching smaller experiments with measurable results.\n\nWhen the [Growth team](/handbook/engineering/development/growth/) formed at GitLab in late 2019, we had little experience with designing, implementing, and shipping experiments intended to accelerate the growth of our user base. We hired experienced people but it was still hard to predict [how long it would take to implement and ship an experiment](/handbook/engineering/development/growth/#running-experiments). The \"Suggest a pipeline\" experiment was the first one I worked on with the Growth:Expansion team. The idea was simple: Guide users through our UI to help them set up a [CI/CD pipeline](/blog/guide-to-ci-cd-pipelines/).\n\n![The guided tour entry](https://about.gitlab.com/images/blogimages/smallest-iterations/suggest.png)\nThe first iteration of the \"suggest a pipeline\" guided tour.\n{: .note.text}\n\n[See the original prototype of the \"suggest a pipeline\" guided tour.](https://www.sketch.com/s/1794d37d-c722-4d32-862e-9c6c5d831149/a/zn1Z9o/play)\n\nThe guided tour would start on the merge request page and ask the user if they want to learn how to set up a CI/CD pipeline. Those who opted in would be led through the three steps required to complete the setup. The team saw this as a simple three-step guide, so we committed ourselves to ship it without first considering if it was the smallest experiment we could complete. We wanted to create a guided tour because it hadn't been done yet at GitLab, but in the end, this wasn't the most iterative software development approach. Today, our thinking is: \"What's the smallest thing we can test and learn from?\"\n\nOne of GitLab's company values is [iteration](https://handbook.gitlab.com/handbook/values/#iteration) which means that we strive to do *the smallest thing possible and get it out as quickly as possible*. The concept of [MVC (minimal viable change)](https://handbook.gitlab.com/handbook/values/#minimal-viable-change-mvc) guides this philosophy:\n\n> We encourage MVCs to be as small as possible. Always look to make the quickest change possible to improve the user's outcome.\n\nWhile looking back, I realized we failed to embrace the MVC with the \"suggest a pipeline\" experiment, but I'm grateful for that mistake because it provided us with one of the most valuable lessons: Always strive to complete the smallest viable change first. The idea of iterative software development is valuable even, or maybe especially, with experiments.\n\nBelow are five reasons why it's important to break development down. Small iterations:\n\n- Gets value to the user faster.\n- Decreases the risk of shipping something that doesn't add value.\n- Are easier to isolate and understand the impact of the changes.\n- Ship faster so the team starts learning sooner.\n- Allow teams to begin thinking about further iterations sooner or decide to abandon the experiment earlier (saving both time and resources).\n\n![Small vs large iterations](https://about.gitlab.com/images/blogimages/smallest-iterations/chart.jpg)\nThe power of iterative software development is clear by the two workflows.\n{: .note.text}\n\n\nIn the \"non-experimental work\" figure above, team one shipped a smaller iteration quickly and updated it twice, while team two only shipped one large iteration in the same time. Team one learned from their first small iteration and adapted their solution twice in the time team two shipped a larger iteration. It took team two longer to ship the large iteration and they sacrificed earlier findings they could have used to optimize their solution.\n\nIn the \"experimental work\" figure, team one shipped a smaller first iteration and reviewed early results, which helped them make an evidence-based decision as to iterate further on their first idea, or abandon it and move on to a new idea. Through this iterative software development process, they could either ship three iterations of their first idea or abandon it and start working on the first iteration of idea two. Team one could accomplish all this development in the same amount of time it took team 2 to ship a larger first iteration of idea one. Team one is much more likely to come to successful results and learnings faster than team two.\n\n## How the \"suggest a pipeline\" experiment _should_ have been done\n\nIt's easy to reflect on our project today and see what we did wrong, but such reflection allows us to avoid repeating mistakes. The GitLab guided tour looked like a simple experiment to build and ship, but in the end it wasn't and took months to complete. Overall, the experiment was successful, but after it was implemented we took a second look and saw the project could be improved. We decided to implement some improvements by iterating on the copy in our first nudge to users to encourage more users to opt-in. Had we shipped a smaller experiment sooner, we could have iterated earlier and delivered an optimal version of the first nudge, allowing more users to benefit from the guided tour.\n\n![Had we shipped a smaller iteration, we would have improved the copy of our opt-in nudge to users sooner.](https://about.gitlab.com/images/blogimages/smallest-iterations/copy-changes.jpg)\nThe second iteration of our opt-in copy is much stronger. Shipping a smaller iteration would have encouraged more users to opt-in to our experimental \"guided tour\" feature.\n{: .note.text}\n\nBecause it took us months to complete the implementation of the experiment, it also took us months to iterate on it.\n\nIf I had to do a similar experiment now, I'd start much smaller, with something that could be built and shipped in less than a month, ideally even faster. For example, we could have shipped an iteration with that first nudge linking to an existing source that explains how to set up a pipeline. That would have enabled us to validate the placement of the nudge, its content, and its effectiveness. It would have significantly reduced the risk of the experiment.\n\nOr maybe we could have [shortened the guided tour to be just two steps](https://gitlab.com/gitlab-org/growth/product/-/issues/1662/), which is exactly what [Kevin Comoli](/company/team/#kcomoli), product designer on Growth: Conversion, did. But because our idea already seemed like a small iteration, we never felt the urgency to reduce it further. So here's another reason why it's important to really think about the smallest possible iteration first: you can never be sure that what you're aiming to do will actually be as quick and simple as expected. So even when you think that your idea is the smallest possible iteration, *think again*.\n\n## How we're applying lessons on iteration to future experiments\n\nWhen I started working on the [\"invite members\" experiment](/blog/small-experiments-significant-results-and-learnings/), my vision of how the experience should be was more complex than the \"suggest a pipeline\" guided tour experience. The idea behind the \"invite members\" experiment was that any user could invite their team members to a project and an admin user would have to approve the invitation. But because of our learnings from the pipeline tour we decided to simplify the first experiment. Instead of designing and building a whole experience, we decided to use a [painted door test](https://crstanier.medium.com/a-product-managers-guide-to-painted-door-tests-a1a5de33b473), which essentially means we are focusing on tracking the main call-to-action to gauge user interest. For the \"invite members\" experiment, the painted door test involved displaying an invite link that, once clicked, displayed a message to users that the feature wasn't ready and suggested a temporary solution. This allowed us to validate the riskiest part of the experiment: Do non-admin users even _want_ to invite their colleagues?\n\n![Modal showing \"invite members\" feature isn't ready yet](https://about.gitlab.com/images/blogimages/smallest-iterations/modal-not-ready.png)\nThe \"invite members\" painted door experiment involved displaying a modal showing that the feature wasn't ready yet, but helped us still gauge user interest in the feature before investing resources in developing the feature.\n{: .note.text}\n\n## Why iterative software development matters\n\nWe were lucky with the \"suggest a pipeline\" experiment. It was the first experiment we worked on, and it was \"low hanging fruit\", meaning it was a solution that required limited investment but still delivered big returns, which made the chance of failure lower. As we move away from obvious improvements and start exploring riskier experiments, we won't be able to rely on luck. We need to be diligent about iteration and break things down into MVCs and smaller experiments to reduce the risk of investing development time on projects that don't add value to the user experience, or fail to have a positive impact on GitLab's growth.\n\nPhoto by [Markus Spiske](https://unsplash.com/@markusspiske?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/pieces?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n",[1266,722,9],{"slug":2084,"featured":6,"template":701},"why-its-crucial-to-break-things-down-into-smallest-iterations","content:en-us:blog:why-its-crucial-to-break-things-down-into-smallest-iterations.yml","Why Its Crucial To Break Things Down Into Smallest Iterations","en-us/blog/why-its-crucial-to-break-things-down-into-smallest-iterations.yml","en-us/blog/why-its-crucial-to-break-things-down-into-smallest-iterations",{"_path":2090,"_dir":246,"_draft":6,"_partial":6,"_locale":7,"seo":2091,"content":2096,"config":2101,"_id":2103,"_type":14,"title":2104,"_source":16,"_file":2105,"_stem":2106,"_extension":19},"/en-us/blog/5-leadership-lessons-as-product-design-manager",{"title":2092,"description":2093,"ogTitle":2092,"ogDescription":2093,"noIndex":6,"ogImage":1200,"ogUrl":2094,"ogSiteName":686,"ogType":687,"canonicalUrls":2094,"schema":2095},"5 Leadership Lessons as Product Design Manager","Shortly after my promotion to Staff Product Designer, I was given the opportunity to act as Product Design Manager for CI/CD. These are some of the lessons I learned on design leadership at GitLab.","https://about.gitlab.com/blog/5-leadership-lessons-as-product-design-manager","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"5 Leadership Lessons as Product Design Manager\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Rayana Verissimo\"}],\n        \"datePublished\": \"2021-01-05\",\n      }",{"title":2092,"description":2093,"authors":2097,"heroImage":1200,"date":2098,"body":2099,"category":765,"tags":2100},[1342],"2021-01-05","\n\n{::options parse_block_html=\"true\" /}\n\n\n\nGitLab has [a number of career development opportunities](https://about.gitlab.com/handbook/engineering/career-development/), and during my time as an individual contributor (IC) I intentionally leaned towards leadership.\n\nIn October 2020, my manager decided to leave the organization and asked if I was ready to take on her position as Product Design Manager for CI/CD. The [acting manager](https://about.gitlab.com/handbook/engineering/career-development/#acting-manager) is an interim position dedicated to ICs experimenting with the role as they work on determining their career path. I took this role and started reporting directly to the Director of Product Design.\n\nIn parallel, I was promoted to Staff Product Designer! Wait, there's more: my team, Release Management, [was dissolved](https://gitlab.com/gitlab-com/Product/-/issues/1698) and I was assigned as shared resource between the Runner and Testing teams; meaning I had to handoff all my design work and onboard two new stage groups. I remember feeling overwhelmed and excited at the same time. I also remember thinking that growth is supposed to be uncomfortable, and if I had to go through all these new challenges in my professional life I was glad it was at GitLab.\n\nWhat follows are a few lessons I learned in my (ongoing) stint as the acting Product Design Manager for CI/CD. Eventually, I aim to become a manager again, and I hope to remember these lessons and learn even more.\n\n## 1. Define what success looks like for your new role\n\nI knew I had to trace a plan in order to effectively perform my new roles. I set a series of goals that were people and process focused, and that I wanted to eventually feed back into my personal development plan.\n\nAs an acting manager, I first focused on learning how I could help sustain a sense of stability and trust in the team. Performance Reviews and career growth conversations were my top concerns (meaning, learning the _what_ and _how_ of it). Another key element of success was to establish relationships with counterparts in order to understand what they care about, how they collaborate with UX, and what concerns they have. This foundational work provided insights on how I could help myself and others, as well as assess if what I thought was important really needed my attention.\n\nAs a Staff Designer, my plan was to set boundaries to the IC work, specifically regarding all the tactical design I knew I would not be able to deliver and communicate that soon and often to people around me.\n\nBecause we use GitLab for _everything_, I also took the opportunity to create some artifacts that could help automate the onboarding and planning for new acting managers, as well as a plan for my design handoff and onboarding:\n\n-   I defined my [quarterly goals](https://gitlab.com/rayana/plan/-/blob/master/goals/quarterly-goals.md) around my new roles and shared them with my manager and counterparts.\n-   I created an [issue template](https://gitlab.com/gitlab-com/people-group/Training/-/blob/master/.gitlab/issue_templates/acting-manager.md) for onboarding new acting managers.\n-   I made a [plan to transition all my design work](https://gitlab.com/groups/gitlab-org/-/epics/4815) and assigned it to new DRIs.\n-   I used my Group Manager's onboarding issues to get up to speed with understanding the [Runner](https://gitlab.com/gitlab-com/Product/-/issues/1685) and [Testing](https://gitlab.com/gitlab-com/Product/-/issues/1687) groups' visions, roadmaps, competitive landscapes, team health, processes, and partnerships across the organization.\n\n## 2. Managing your schedule is essential\n\nI inherited my previous manager's meetings, meaning my calendar was impossible to manage for a couple of weeks. A packed schedule means I am likely to be launched into an anxiety spiral. Because I am both IC and manager, this created a situation where I was splitting my brain and my attention trying to do too many things at once.\n\n[Darby Frey](https://about.gitlab.com/company/team/#darbyfrey), Sr. Engineering Manager for Verify, shared some kind words with me. He reminded me that I wouldn't be able to do everything I want or need to. _\"It’s impossible to do two full-time jobs. My advice is to do what you can; time-box things; set priorities for the calls; be deliberate about what you choose not to do.\"_\n\n-   I kept creating [a weekly plan](https://gitlab.com/rayana/plan/-/tree/master/tasks/2020) with my priorities. This helped me stay grounded and acknowledge I could only deliver so much in a week.\n-   I started being intentional about focus time by blocking my calendar, forcing myself to work on specific items rather than \"freestyle\" my tasks. This was in particular very painful.\n-   I picked up the habit of time-boxing my work using [Forest](https://www.forestapp.cc/) - a popular productivity app that helps you stay focused. This made me realize that working 3-4 hours without a break was unsustainable and that 30-minute to 1-hour blocks of focused work gives me a greater sense of accomplishment and is healthier.\n\nMy mantra in the last few months has been: be kind to yourself. I believe I still have a long way to go. In the meantime, these resources have helped me quite a bit:\n\n-   [Remote work: 9 tips for eliminating distractions and getting things done](https://about.gitlab.com/blog/eliminating-distractions-and-getting-things-done/)\n-   [7 Tips for Managing Your Schedule Like a Pro](https://www.entrepreneur.com/article/243962)\n\n## 3. Design Managers at GitLab are facilitators\n\nI thought I had a pretty good sense of what being a manager meant... until I became one myself. I've always enjoyed coaching, but there's a huge difference between being a buddy and a manager.\n\nFrom career development to design critique, I believe the true role of managers in the UX department is to facilitate great work and make sure our designers are being supported. I learned that this means getting to know what each designer needs individually - and building that relationship is a job of its own. [Servant-leader qualities](https://about.gitlab.com/company/culture/all-remote/being-a-great-remote-manager/#servant-leader-qualities) are especially true if you are now [managing people who used to be your peers](https://hbr.org/2012/12/how-to-manage-your-former-peer). There was certainly a change in the dynamics for me, but the end goal remained the same: wanting others to succeed.\n\nAn upside of being acting manager is spending more time consulting with the designers and following their work. I started having a better sense of what people are prioritizing and (more importantly) what type of support they need. This overview will be helpful once I transition back fully into my Staff role. Sure, the fact that I had previous context on different product areas was great, but I now I understand why design managers are not able to dive deep into everyday design tasks. This is why they listen and facilitate instead of coming up with solutions. Product Designers are the experts. That being said, I came to the conclusion that I'd rather be a manager that takes a leap of faith than being the person watching over someone's shoulders.\n\n[Valerie Karnes](https://about.gitlab.com/company/team/#vkarnes), Director of Product Design, taught me that you need to make confident decisions with the context you have. That also means trusting people so they can make their own decisions and move forward.\n\n-   Keep asking how you can better support the team. I do this in every 1:1 by asking \"how can I be a better manager for you?\" or \"how can I help you this week?\" People have different feelings about asking for help and I recognize I'm busy, so I find it important to leave that door always open.\n-   Adapt to what each report needs. Some conversations will be harder than others, so make sure you are listening.\n-   Seek ongoing feedback and support from your manager and peers. I meet with [Justin Mandell](https://about.gitlab.com/company/team/#jmandell), Product Design Manager, once every two weeks to talk about people management. I also connected with people who were once interim managers to get to know what challenges they faced and how they solved them.\n-   Be transparent and communicate that you are learning on the job: you don't know everything, and you can't possibly do everything right. If you're in a situation like me where you can't be a manager 100%, let people know that.\n\n## 4. Manager is a different career\n\nAs a new manager, I had to redefine what I call \"results.\" You go from being completely independent to being responsible for the team's output. As an IC, I can measure my output based on how many things I get out the door in a milestone. The usual metrics no longer apply when you're a manager. This can mess with your sense of self-worth, which is being tied for so long to visible, tactical design. Many days I sat in front of the computer feeling I wasn't moving the needle at all. I had to learn on the fly how to get satisfaction from a new way of operating.\n\nMy results now translate into being a network builder by thinking strategically, understanding and communicating the overall company direction, and aligning people's sense of purpose with where the company is going. You can't just pinpoint one specific deliverable that exemplifies all that.\n\nThe rewarding side of managing is watching the CI/CD designers shine: from communicating someone got a discretionary bonus for doing amazing work and exemplifying our company values, to giving positive feedback on a performance review, and helping people figure their career growth plans. This new approach to results made me experience a deep sense of pride for other people's accomplishments. Almost like magic moments of bliss. ✨\n\nOn the other hand, I had to handle my own disappointment in not being involved at the level I could help with the hands-on design work. I was unable to deliver feature proposals at the same pace as before. Even onboarding Testing and Runner proved to be a challenge; I couldn't do it at the speed I _wanted to_.\n\nI learned that becoming a manager is not an extension of my IC career: being a manager is either/or. If I want to be a good manager, I want to have the time to be a consistent manager.\n\n-   Ask yourself: are you ready to help design other people's careers instead of features?\n-   There’s a level of separation when you become a manager and you need to be comfortable with that. I found myself feeling isolated from the things that give me joy, like tactical design and stage group rituals.\n\n## 5. Share your learnings\n\nThe final lesson is a small one, but it can have a deep impact on our team of designers. Management opportunities are created based on [merit and company need](https://about.gitlab.com/handbook/engineering/career-development/#ux-department), and it is imperative that designers understand what challenges they might face and what the path to management looks like. Keep sharing what you've done and how you've done it to succeed as an IC. I became more self-aware of my accomplishments and I learned that people are craving actionable guidance. Becoming a manager is a beacon of hope!\n\nI am privileged for having the chance to experience the manager role before making the transition. [Leadership](https://about.gitlab.com/handbook/leadership/) is a long-term learning and I know have a ton to learn. I hope the lessons I shared are also valuable to you during your own journey.\n\nThank you for reading and thank you to GitLab for enabling my growth. 👣\n",[9,722],{"slug":2102,"featured":6,"template":701},"5-leadership-lessons-as-product-design-manager","content:en-us:blog:5-leadership-lessons-as-product-design-manager.yml","5 Leadership Lessons As Product Design Manager","en-us/blog/5-leadership-lessons-as-product-design-manager.yml","en-us/blog/5-leadership-lessons-as-product-design-manager",8,[679,706,730,751,777,797,816,837,857],1758326272654]