[{"data":1,"prerenderedAt":1068},["ShallowReactive",2],{"/en-us/blog/tags/ui/":3,"navigation-en-us":20,"banner-en-us":438,"footer-en-us":453,"UI-tag-page-en-us":664},{"_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/ui","tags",false,"",{"tag":9,"tagSlug":10},"UI","ui",{"template":12},"BlogTag","content:en-us:blog:tags:ui.yml","yaml","Ui","content","en-us/blog/tags/ui.yml","en-us/blog/tags/ui","yml",{"_path":21,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":23,"_id":434,"_type":14,"title":435,"_source":16,"_file":436,"_stem":437,"_extension":19},"/shared/en-us/main-navigation","en-us",{"logo":24,"freeTrial":29,"sales":34,"login":39,"items":44,"search":375,"minimal":406,"duo":425},{"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,185,190,296,356],{"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":167},"Product",true,{"dataNavLevelOne":93},"solutions",{"text":95,"config":96},"View all Solutions",{"href":97,"dataGaName":93,"dataGaLocation":28},"/solutions/",[99,124,146],{"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,136,141],{"text":134,"config":135},"Security & Compliance",{"href":129,"dataGaLocation":28,"dataGaName":134},{"text":137,"config":138},"Software Supply Chain Security",{"href":139,"dataGaLocation":28,"dataGaName":140},"/solutions/supply-chain/","Software supply chain security",{"text":142,"config":143},"Compliance & Governance",{"href":144,"dataGaLocation":28,"dataGaName":145},"/solutions/continuous-software-compliance/","Compliance and governance",{"title":147,"link":148,"items":153},"Measurement",{"config":149},{"icon":150,"href":151,"dataGaName":152,"dataGaLocation":28},"DigitalTransformation","/solutions/visibility-measurement/","visibility and measurement",[154,158,162],{"text":155,"config":156},"Visibility & Measurement",{"href":151,"dataGaLocation":28,"dataGaName":157},"Visibility and Measurement",{"text":159,"config":160},"Value Stream Management",{"href":161,"dataGaLocation":28,"dataGaName":159},"/solutions/value-stream-management/",{"text":163,"config":164},"Analytics & Insights",{"href":165,"dataGaLocation":28,"dataGaName":166},"/solutions/analytics-and-insights/","Analytics and insights",{"title":168,"items":169},"GitLab for",[170,175,180],{"text":171,"config":172},"Enterprise",{"href":173,"dataGaLocation":28,"dataGaName":174},"/enterprise/","enterprise",{"text":176,"config":177},"Small Business",{"href":178,"dataGaLocation":28,"dataGaName":179},"/small-business/","small business",{"text":181,"config":182},"Public Sector",{"href":183,"dataGaLocation":28,"dataGaName":184},"/solutions/public-sector/","public sector",{"text":186,"config":187},"Pricing",{"href":188,"dataGaName":189,"dataGaLocation":28,"dataNavLevelOne":189},"/pricing/","pricing",{"text":191,"config":192,"link":194,"lists":198,"feature":283},"Resources",{"dataNavLevelOne":193},"resources",{"text":195,"config":196},"View all resources",{"href":197,"dataGaName":193,"dataGaLocation":28},"/resources/",[199,232,255],{"title":200,"items":201},"Getting started",[202,207,212,217,222,227],{"text":203,"config":204},"Install",{"href":205,"dataGaName":206,"dataGaLocation":28},"/install/","install",{"text":208,"config":209},"Quick start guides",{"href":210,"dataGaName":211,"dataGaLocation":28},"/get-started/","quick setup checklists",{"text":213,"config":214},"Learn",{"href":215,"dataGaLocation":28,"dataGaName":216},"https://university.gitlab.com/","learn",{"text":218,"config":219},"Product documentation",{"href":220,"dataGaName":221,"dataGaLocation":28},"https://docs.gitlab.com/","product documentation",{"text":223,"config":224},"Best practice videos",{"href":225,"dataGaName":226,"dataGaLocation":28},"/getting-started-videos/","best practice videos",{"text":228,"config":229},"Integrations",{"href":230,"dataGaName":231,"dataGaLocation":28},"/integrations/","integrations",{"title":233,"items":234},"Discover",[235,240,245,250],{"text":236,"config":237},"Customer success stories",{"href":238,"dataGaName":239,"dataGaLocation":28},"/customers/","customer success stories",{"text":241,"config":242},"Blog",{"href":243,"dataGaName":244,"dataGaLocation":28},"/blog/","blog",{"text":246,"config":247},"Remote",{"href":248,"dataGaName":249,"dataGaLocation":28},"https://handbook.gitlab.com/handbook/company/culture/all-remote/","remote",{"text":251,"config":252},"TeamOps",{"href":253,"dataGaName":254,"dataGaLocation":28},"/teamops/","teamops",{"title":256,"items":257},"Connect",[258,263,268,273,278],{"text":259,"config":260},"GitLab Services",{"href":261,"dataGaName":262,"dataGaLocation":28},"/services/","services",{"text":264,"config":265},"Community",{"href":266,"dataGaName":267,"dataGaLocation":28},"/community/","community",{"text":269,"config":270},"Forum",{"href":271,"dataGaName":272,"dataGaLocation":28},"https://forum.gitlab.com/","forum",{"text":274,"config":275},"Events",{"href":276,"dataGaName":277,"dataGaLocation":28},"/events/","events",{"text":279,"config":280},"Partners",{"href":281,"dataGaName":282,"dataGaLocation":28},"/partners/","partners",{"backgroundColor":284,"textColor":285,"text":286,"image":287,"link":291},"#2f2a6b","#fff","Insights for the future of software development",{"altText":288,"config":289},"the source promo card",{"src":290},"/images/navigation/the-source-promo-card.svg",{"text":292,"config":293},"Read the latest",{"href":294,"dataGaName":295,"dataGaLocation":28},"/the-source/","the source",{"text":297,"config":298,"lists":300},"Company",{"dataNavLevelOne":299},"company",[301],{"items":302},[303,308,314,316,321,326,331,336,341,346,351],{"text":304,"config":305},"About",{"href":306,"dataGaName":307,"dataGaLocation":28},"/company/","about",{"text":309,"config":310,"footerGa":313},"Jobs",{"href":311,"dataGaName":312,"dataGaLocation":28},"/jobs/","jobs",{"dataGaName":312},{"text":274,"config":315},{"href":276,"dataGaName":277,"dataGaLocation":28},{"text":317,"config":318},"Leadership",{"href":319,"dataGaName":320,"dataGaLocation":28},"/company/team/e-group/","leadership",{"text":322,"config":323},"Team",{"href":324,"dataGaName":325,"dataGaLocation":28},"/company/team/","team",{"text":327,"config":328},"Handbook",{"href":329,"dataGaName":330,"dataGaLocation":28},"https://handbook.gitlab.com/","handbook",{"text":332,"config":333},"Investor relations",{"href":334,"dataGaName":335,"dataGaLocation":28},"https://ir.gitlab.com/","investor relations",{"text":337,"config":338},"Trust Center",{"href":339,"dataGaName":340,"dataGaLocation":28},"/security/","trust center",{"text":342,"config":343},"AI Transparency Center",{"href":344,"dataGaName":345,"dataGaLocation":28},"/ai-transparency-center/","ai transparency center",{"text":347,"config":348},"Newsletter",{"href":349,"dataGaName":350,"dataGaLocation":28},"/company/contact/","newsletter",{"text":352,"config":353},"Press",{"href":354,"dataGaName":355,"dataGaLocation":28},"/press/","press",{"text":357,"config":358,"lists":359},"Contact us",{"dataNavLevelOne":299},[360],{"items":361},[362,365,370],{"text":35,"config":363},{"href":37,"dataGaName":364,"dataGaLocation":28},"talk to sales",{"text":366,"config":367},"Get help",{"href":368,"dataGaName":369,"dataGaLocation":28},"/support/","get help",{"text":371,"config":372},"Customer portal",{"href":373,"dataGaName":374,"dataGaLocation":28},"https://customers.gitlab.com/customers/sign_in/","customer portal",{"close":376,"login":377,"suggestions":384},"Close",{"text":378,"link":379},"To search repositories and projects, login to",{"text":380,"config":381},"gitlab.com",{"href":42,"dataGaName":382,"dataGaLocation":383},"search login","search",{"text":385,"default":386},"Suggestions",[387,389,393,395,399,403],{"text":57,"config":388},{"href":62,"dataGaName":57,"dataGaLocation":383},{"text":390,"config":391},"Code Suggestions (AI)",{"href":392,"dataGaName":390,"dataGaLocation":383},"/solutions/code-suggestions/",{"text":109,"config":394},{"href":111,"dataGaName":109,"dataGaLocation":383},{"text":396,"config":397},"GitLab on AWS",{"href":398,"dataGaName":396,"dataGaLocation":383},"/partners/technology-partners/aws/",{"text":400,"config":401},"GitLab on Google Cloud",{"href":402,"dataGaName":400,"dataGaLocation":383},"/partners/technology-partners/google-cloud-platform/",{"text":404,"config":405},"Why GitLab?",{"href":70,"dataGaName":404,"dataGaLocation":383},{"freeTrial":407,"mobileIcon":412,"desktopIcon":417,"secondaryButton":420},{"text":408,"config":409},"Start free trial",{"href":410,"dataGaName":33,"dataGaLocation":411},"https://gitlab.com/-/trials/new/","nav",{"altText":413,"config":414},"Gitlab Icon",{"src":415,"dataGaName":416,"dataGaLocation":411},"/images/brand/gitlab-logo-tanuki.svg","gitlab icon",{"altText":413,"config":418},{"src":419,"dataGaName":416,"dataGaLocation":411},"/images/brand/gitlab-logo-type.svg",{"text":421,"config":422},"Get Started",{"href":423,"dataGaName":424,"dataGaLocation":411},"https://gitlab.com/-/trial_registrations/new?glm_source=about.gitlab.com/compare/gitlab-vs-github/","get started",{"freeTrial":426,"mobileIcon":430,"desktopIcon":432},{"text":427,"config":428},"Learn more about GitLab Duo",{"href":62,"dataGaName":429,"dataGaLocation":411},"gitlab duo",{"altText":413,"config":431},{"src":415,"dataGaName":416,"dataGaLocation":411},{"altText":413,"config":433},{"src":419,"dataGaName":416,"dataGaLocation":411},"content:shared:en-us:main-navigation.yml","Main Navigation","shared/en-us/main-navigation.yml","shared/en-us/main-navigation",{"_path":439,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"title":440,"button":441,"image":445,"config":448,"_id":450,"_type":14,"_source":16,"_file":451,"_stem":452,"_extension":19},"/shared/en-us/banner","is now in public beta!",{"text":68,"config":442},{"href":443,"dataGaName":444,"dataGaLocation":28},"/gitlab-duo/agent-platform/","duo banner",{"config":446},{"src":447},"https://res.cloudinary.com/about-gitlab-com/image/upload/v1753720689/somrf9zaunk0xlt7ne4x.svg",{"layout":449},"release","content:shared:en-us:banner.yml","shared/en-us/banner.yml","shared/en-us/banner",{"_path":454,"_dir":22,"_draft":6,"_partial":6,"_locale":7,"data":455,"_id":660,"_type":14,"title":661,"_source":16,"_file":662,"_stem":663,"_extension":19},"/shared/en-us/main-footer",{"text":456,"source":457,"edit":463,"contribute":468,"config":473,"items":478,"minimal":652},"Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license",{"text":458,"config":459},"View page source",{"href":460,"dataGaName":461,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/","page source","footer",{"text":464,"config":465},"Edit this page",{"href":466,"dataGaName":467,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/content/","web ide",{"text":469,"config":470},"Please contribute",{"href":471,"dataGaName":472,"dataGaLocation":462},"https://gitlab.com/gitlab-com/marketing/digital-experience/about-gitlab-com/-/blob/main/CONTRIBUTING.md/","please contribute",{"twitter":474,"facebook":475,"youtube":476,"linkedin":477},"https://twitter.com/gitlab","https://www.facebook.com/gitlab","https://www.youtube.com/channel/UCnMGQ8QHMAnVIsI3xJrihhg","https://www.linkedin.com/company/gitlab-com",[479,502,559,588,622],{"title":46,"links":480,"subMenu":485},[481],{"text":482,"config":483},"DevSecOps platform",{"href":55,"dataGaName":484,"dataGaLocation":462},"devsecops platform",[486],{"title":186,"links":487},[488,492,497],{"text":489,"config":490},"View plans",{"href":188,"dataGaName":491,"dataGaLocation":462},"view plans",{"text":493,"config":494},"Why Premium?",{"href":495,"dataGaName":496,"dataGaLocation":462},"/pricing/premium/","why premium",{"text":498,"config":499},"Why Ultimate?",{"href":500,"dataGaName":501,"dataGaLocation":462},"/pricing/ultimate/","why ultimate",{"title":503,"links":504},"Solutions",[505,510,513,515,520,525,529,532,536,541,543,546,549,554],{"text":506,"config":507},"Digital transformation",{"href":508,"dataGaName":509,"dataGaLocation":462},"/topics/digital-transformation/","digital transformation",{"text":134,"config":511},{"href":129,"dataGaName":512,"dataGaLocation":462},"security & compliance",{"text":123,"config":514},{"href":105,"dataGaName":106,"dataGaLocation":462},{"text":516,"config":517},"Agile development",{"href":518,"dataGaName":519,"dataGaLocation":462},"/solutions/agile-delivery/","agile delivery",{"text":521,"config":522},"Cloud transformation",{"href":523,"dataGaName":524,"dataGaLocation":462},"/topics/cloud-native/","cloud transformation",{"text":526,"config":527},"SCM",{"href":119,"dataGaName":528,"dataGaLocation":462},"source code management",{"text":109,"config":530},{"href":111,"dataGaName":531,"dataGaLocation":462},"continuous integration & delivery",{"text":533,"config":534},"Value stream management",{"href":161,"dataGaName":535,"dataGaLocation":462},"value stream management",{"text":537,"config":538},"GitOps",{"href":539,"dataGaName":540,"dataGaLocation":462},"/solutions/gitops/","gitops",{"text":171,"config":542},{"href":173,"dataGaName":174,"dataGaLocation":462},{"text":544,"config":545},"Small business",{"href":178,"dataGaName":179,"dataGaLocation":462},{"text":547,"config":548},"Public sector",{"href":183,"dataGaName":184,"dataGaLocation":462},{"text":550,"config":551},"Education",{"href":552,"dataGaName":553,"dataGaLocation":462},"/solutions/education/","education",{"text":555,"config":556},"Financial services",{"href":557,"dataGaName":558,"dataGaLocation":462},"/solutions/finance/","financial services",{"title":191,"links":560},[561,563,565,567,570,572,574,576,578,580,582,584,586],{"text":203,"config":562},{"href":205,"dataGaName":206,"dataGaLocation":462},{"text":208,"config":564},{"href":210,"dataGaName":211,"dataGaLocation":462},{"text":213,"config":566},{"href":215,"dataGaName":216,"dataGaLocation":462},{"text":218,"config":568},{"href":220,"dataGaName":569,"dataGaLocation":462},"docs",{"text":241,"config":571},{"href":243,"dataGaName":244,"dataGaLocation":462},{"text":236,"config":573},{"href":238,"dataGaName":239,"dataGaLocation":462},{"text":246,"config":575},{"href":248,"dataGaName":249,"dataGaLocation":462},{"text":259,"config":577},{"href":261,"dataGaName":262,"dataGaLocation":462},{"text":251,"config":579},{"href":253,"dataGaName":254,"dataGaLocation":462},{"text":264,"config":581},{"href":266,"dataGaName":267,"dataGaLocation":462},{"text":269,"config":583},{"href":271,"dataGaName":272,"dataGaLocation":462},{"text":274,"config":585},{"href":276,"dataGaName":277,"dataGaLocation":462},{"text":279,"config":587},{"href":281,"dataGaName":282,"dataGaLocation":462},{"title":297,"links":589},[590,592,594,596,598,600,602,606,611,613,615,617],{"text":304,"config":591},{"href":306,"dataGaName":299,"dataGaLocation":462},{"text":309,"config":593},{"href":311,"dataGaName":312,"dataGaLocation":462},{"text":317,"config":595},{"href":319,"dataGaName":320,"dataGaLocation":462},{"text":322,"config":597},{"href":324,"dataGaName":325,"dataGaLocation":462},{"text":327,"config":599},{"href":329,"dataGaName":330,"dataGaLocation":462},{"text":332,"config":601},{"href":334,"dataGaName":335,"dataGaLocation":462},{"text":603,"config":604},"Sustainability",{"href":605,"dataGaName":603,"dataGaLocation":462},"/sustainability/",{"text":607,"config":608},"Diversity, inclusion and belonging (DIB)",{"href":609,"dataGaName":610,"dataGaLocation":462},"/diversity-inclusion-belonging/","Diversity, inclusion and belonging",{"text":337,"config":612},{"href":339,"dataGaName":340,"dataGaLocation":462},{"text":347,"config":614},{"href":349,"dataGaName":350,"dataGaLocation":462},{"text":352,"config":616},{"href":354,"dataGaName":355,"dataGaLocation":462},{"text":618,"config":619},"Modern Slavery Transparency Statement",{"href":620,"dataGaName":621,"dataGaLocation":462},"https://handbook.gitlab.com/handbook/legal/modern-slavery-act-transparency-statement/","modern slavery transparency statement",{"title":623,"links":624},"Contact Us",[625,628,630,632,637,642,647],{"text":626,"config":627},"Contact an expert",{"href":37,"dataGaName":38,"dataGaLocation":462},{"text":366,"config":629},{"href":368,"dataGaName":369,"dataGaLocation":462},{"text":371,"config":631},{"href":373,"dataGaName":374,"dataGaLocation":462},{"text":633,"config":634},"Status",{"href":635,"dataGaName":636,"dataGaLocation":462},"https://status.gitlab.com/","status",{"text":638,"config":639},"Terms of use",{"href":640,"dataGaName":641,"dataGaLocation":462},"/terms/","terms of use",{"text":643,"config":644},"Privacy statement",{"href":645,"dataGaName":646,"dataGaLocation":462},"/privacy/","privacy statement",{"text":648,"config":649},"Cookie preferences",{"dataGaName":650,"dataGaLocation":462,"id":651,"isOneTrustButton":91},"cookie preferences","ot-sdk-btn",{"items":653},[654,656,658],{"text":638,"config":655},{"href":640,"dataGaName":641,"dataGaLocation":462},{"text":643,"config":657},{"href":645,"dataGaName":646,"dataGaLocation":462},{"text":648,"config":659},{"dataGaName":650,"dataGaLocation":462,"id":651,"isOneTrustButton":91},"content:shared:en-us:main-footer.yml","Main Footer","shared/en-us/main-footer.yml","shared/en-us/main-footer",{"allPosts":665,"featuredPost":1046,"totalPagesCount":1066,"initialPosts":1067},[666,692,712,733,754,778,800,820,839,858,879,900,923,944,965,984,1004,1026],{"_path":667,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":668,"content":676,"config":685,"_id":688,"_type":14,"title":689,"_source":16,"_file":690,"_stem":691,"_extension":19},"/en-us/blog/beautifying-our-ui-enhancing-gitlabs-deployment-experience",{"title":669,"description":670,"ogTitle":669,"ogDescription":670,"noIndex":6,"ogImage":671,"ogUrl":672,"ogSiteName":673,"ogType":674,"canonicalUrls":672,"schema":675},"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","https://about.gitlab.com","article","\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":669,"description":670,"authors":677,"heroImage":671,"date":679,"body":680,"category":681,"tags":682},[678],"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",[683,684,9,681,482],"design","UX",{"slug":686,"featured":6,"template":687},"beautifying-our-ui-enhancing-gitlabs-deployment-experience","BlogPost","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":693,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":694,"content":700,"config":706,"_id":708,"_type":14,"title":709,"_source":16,"_file":710,"_stem":711,"_extension":19},"/en-us/blog/beautifying-our-ui",{"title":695,"description":696,"ogTitle":695,"ogDescription":696,"noIndex":6,"ogImage":697,"ogUrl":698,"ogSiteName":673,"ogType":674,"canonicalUrls":698,"schema":699},"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":695,"description":696,"authors":701,"heroImage":697,"date":703,"body":704,"category":299,"tags":705},[702],"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",[684,9,683],{"slug":707,"featured":6,"template":687},"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":713,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":714,"content":720,"config":727,"_id":729,"_type":14,"title":730,"_source":16,"_file":731,"_stem":732,"_extension":19},"/en-us/blog/designing-in-an-all-remote-company",{"title":715,"description":716,"ogTitle":715,"ogDescription":716,"noIndex":6,"ogImage":717,"ogUrl":718,"ogSiteName":673,"ogType":674,"canonicalUrls":718,"schema":719},"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":715,"description":716,"authors":721,"heroImage":717,"date":722,"body":723,"category":724,"tags":725},[702],"2020-03-27","\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",[684,9,726],"remote work",{"slug":728,"featured":6,"template":687},"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":734,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":735,"content":741,"config":748,"_id":750,"_type":14,"title":751,"_source":16,"_file":752,"_stem":753,"_extension":19},"/en-us/blog/dont-hide-primary-actions",{"title":736,"description":737,"ogTitle":736,"ogDescription":737,"noIndex":6,"ogImage":738,"ogUrl":739,"ogSiteName":673,"ogType":674,"canonicalUrls":739,"schema":740},"Don't hide primary actions","In our testing, we found there was confusion in setting up subgroups with a wide range of research participants. We wanted to reduce confusion in setting up subgroups in GitLab.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749663397/Blog/Hero%20Images/logoforblogpost.jpg","https://about.gitlab.com/blog/dont-hide-primary-actions","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Don't hide primary actions\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Daniel Mora\"}],\n        \"datePublished\": \"2021-04-01\",\n      }",{"title":736,"description":737,"authors":742,"heroImage":738,"date":744,"body":745,"category":746,"tags":747},[743],"Daniel Mora","2021-04-01","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\u003C!-- ![Image of Batman stroking his chin in contemplation](https://media.giphy.com/media/a5viI92PAF89q/giphy.gif){: .shadow.right.wrap-text} -->\nOrganizing your projects into groups within GitLab should be a simple matter for new users. We conducted a Category Maturity Scorecard validation to see how we were correct to assume that it was easy to model your organization in GitLab so that teams could have clear boundaries between other groups. What we found during our initial testing, however, was far off from this assumption.\n\n### Problem\nLooking at this organization chart, we assumed our test participants would have no trouble creating this structure in a test environment.\n\n[![](https://mermaid.ink/img/eyJjb2RlIjoiZ3JhcGggVERcbiAgQVtJbmZvcm1hdGlvbiBUZWNobm9sb2d5IGFuZCBEYXRhIEFuYWx5dGljc10gXG4gIEEgLS0-IEVbSVQgRGlnaXRhbCBTZXJ2aWNlc11cbiAgRSAtLT4gRltEaWdpdGFsIFRyYW5zZm9ybWF0aW9uIEVudmlyb25tZW50XVxuICAgIEYgLS0-IE1bUHJvamVjdCBBbHBoYV1cbiAgICBGIC0tPiBOW1Byb2plY3QgQmV0YV1cbiAgICBGIC0tPiBPW1Byb2plY3QgQ29yZV1cbiAgRSAtLT4gR1tBcHBsaWNhdGlvbiBEYXRhYmFzZSBTZXJ2aWNlc11cbiAgRSAtLT4gSFtCdXNpbmVzcyBQcm9jZXNzIE1hbmFnZW1lbnRdXG4gICBIIC0tPiBQW1Byb2plY3QgWmV0YV1cbiAgIEggLS0-IExbUHJvamVjdCBCbGFua10iLCJtZXJtYWlkIjp7fSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)](https://mermaid-js.github.io/mermaid-live-editor/#/edit/eyJjb2RlIjoiZ3JhcGggVERcbiAgQVtJbmZvcm1hdGlvbiBUZWNobm9sb2d5IGFuZCBEYXRhIEFuYWx5dGljc10gXG4gIEEgLS0-IEVbSVQgRGlnaXRhbCBTZXJ2aWNlc11cbiAgRSAtLT4gRltEaWdpdGFsIFRyYW5zZm9ybWF0aW9uIEVudmlyb25tZW50XVxuICAgIEYgLS0-IE1bUHJvamVjdCBBbHBoYV1cbiAgICBGIC0tPiBOW1Byb2plY3QgQmV0YV1cbiAgICBGIC0tPiBPW1Byb2plY3QgQ29yZV1cbiAgRSAtLT4gR1tBcHBsaWNhdGlvbiBEYXRhYmFzZSBTZXJ2aWNlc11cbiAgRSAtLT4gSFtCdXNpbmVzcyBQcm9jZXNzIE1hbmFnZW1lbnRdXG4gICBIIC0tPiBQW1Byb2plY3QgWmV0YV1cbiAgIEggLS0-IExbUHJvamVjdCBCbGFua10iLCJtZXJtYWlkIjp7fSwidXBkYXRlRWRpdG9yIjpmYWxzZX0)\n\nSadly, this was not the case:\n- Five test participants could not complete the task in 30 minutes.\n- One confused the difference between Groups versus Projects but could (inaccurately) recreate the structure in GitLab in approximately 3 minutes.\n- Only one person was able to complete the task accurately in around 3 minutes.\n\n\u003C!-- ![Image of a young woman cringing](https://media.giphy.com/media/3FBwwRCNTSa52/giphy.gif){: .shadow.center} -->\n\n### Observations\nThe primary problem we found was that our participants could not find a way to create a subgroup. Success depended on creating subgroups, but the button to create a new subgroup was not easily discoverable. The participant would have to go into exploratory mode and click to see what was in the 'New project' dropdown to find it. This problem with button dropdowns and primary action discovery also occurred within the [Comment button in Merge Requests](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49614).\n\n![Image of dropdown button](https://about.gitlab.com/images/blogimages/2021-04-15-dropdown-button.png){: .shadow.center}\n\nThe second observation was that the user experience and logic of building an organizational system are not intuitive for new users. \n\nParticipants expected:\n- A more graphical user experience with interactive boxes and lines\n- A way to perform the task through the command line\n- A way to import the org structure from another system\n\nParticipants could not determine the difference between a group or a project or how they were related. There was no visual indicator of what the difference was or what features related to Groups or Projects.\n\n### Solution proposals\nFor an initial recommendation to address the confusion, we wanted to separate the primary dropdown button.\n\n![Image of 3 seperate buttons](https://about.gitlab.com/images/blogimages/2021-04-15-split-button.png){: .shadow.center}\n\nHiding features under dropdowns assumes the users understand they can access additional actions if they click the button's dropdown area. As well, two disparate interface actions shouldn't juxtapose if they have no direct relationship.\n\nWe assumed that we could split up this button into two for an MVC and have better results. After another round of testing, we were able to achieve far better results. Our test participants completed the task of creating the group and project structure quickly and found the task easy to complete.\n\n### This one simple trick\nBy breaking apart the 'New project' and 'New group' buttons, we could make the 'New group' action discoverable. After we made this change, participants had no trouble interpreting the scenario and executing the task within 5 minutes.\n\n\u003C!-- ![image of a young man dancing](https://media.giphy.com/media/3o7abldj0b3rxrZUxW/giphy.gif){: .shadow.center} -->\n\n### Next steps\nCurrently, we are looking at how we can improve sharing groups and features. We want to [remove the barrier between groups and projects](https://gitlab.com/groups/gitlab-org/-/epics/2885). We believe that this will help with some of the problems users have with sharing across groups, and they will be able to take advantage of features that provide them with a more connected set of groups. This change will also improve our information architecture by reducing the confusion around how objects are connected, making navigation and cross-team sharing easier in the future.\n","unfiltered",[683,9],{"slug":749,"featured":6,"template":687},"dont-hide-primary-actions","content:en-us:blog:dont-hide-primary-actions.yml","Dont Hide Primary Actions","en-us/blog/dont-hide-primary-actions.yml","en-us/blog/dont-hide-primary-actions",{"_path":755,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":756,"content":762,"config":772,"_id":774,"_type":14,"title":775,"_source":16,"_file":776,"_stem":777,"_extension":19},"/en-us/blog/from-monolith-to-microservices-how-to-leverage-aws-with-gitlab",{"title":757,"description":758,"ogTitle":757,"ogDescription":758,"noIndex":6,"ogImage":759,"ogUrl":760,"ogSiteName":673,"ogType":674,"canonicalUrls":760,"schema":761},"From monolith to microservices: How to leverage AWS with GitLab","GitLab recently spent time with Ask Media Group and AWS to discuss how modernizing from self-managed to a cloud native system empowers developers.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749679645/Blog/Hero%20Images/askmediablog-.jpg","https://about.gitlab.com/blog/from-monolith-to-microservices-how-to-leverage-aws-with-gitlab","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"From monolith to microservices: How to leverage AWS with GitLab\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Brein Matturro\"}],\n        \"datePublished\": \"2020-03-24\",\n      }",{"title":757,"description":758,"authors":763,"heroImage":759,"date":765,"body":766,"category":767,"tags":768},[764],"Brein Matturro","2020-03-24","\n\nAsk Media Group operates over 30 websites and provides enriched search results, articles, galleries, and shopping sites to over 100 million unique visitors each month. About two years ago, [Ask Media](https://www.askmediagroup.com/) was looking for ways to grow the business, draw advertisers, and expand its audience. Routine tasks like onboarding developers or releasing software took too long. The monolithic system that was in place had limited capabilities and added financial burdens for services that went unused. \n\nChenglim Ear, principal software engineer at Ask Media, recently sat down with [Trevor Hansen](https://www.linkedin.com/in/startuptrev), solutions architect at AWS, to discuss how adopting GitLab empowered developers to improve the customer experience, release software quicker, and leverage AWS cloud services. \n \n## Building microservices from monoliths\n\nAsk Media was looking to move away from a monolithic system to [microservices](/topics/microservices/) in order to modernize workflow and improve the overall business process. “We wanted to move over to microservices. We wanted to [leverage Kubernetes](/solutions/kubernetes/). It was a new container world that was shaping. When we looked at GitLab, it was very complete in providing what we needed to be able to build images, to run on containers,” according to Chenglim. “That was a very big deciding factor. GitLab had everything that we needed.” \n\nDevelopers can now break services into multiples and develop them independently, own the code, and have full visibility prior to deployment. “We're making the hidden logic transparent and we enable the parts of the logic to be independently developed in parallel. So you can have developers all working on their own, with different skillsets,” Chenglim says. \n\n## Containers, cost, and scalability\n\n“We needed a system that could handle change. When we look at what we did to speed up development, make it simple and transparent, and control the cost, we see a paradigm shift. GitLab gave us push-button releases. Docker and Kubernetes enabled us to switch to a microservices architecture and AWS enabled auto scaling,” says Chenglim. “On Amazon, we started building Kubernetes clusters and GitLab became our command and control interface.” \n \n Ask Media was looking for a tool that could scale and grow as needed. Cost, speed, and functionality are the tenets that AWS focuses on providing to its customers, according to Hansen. AWS works closely with Ask Media to ensure that the containers in place offer the scalability, flexibility, and timeliness they need. \n\nWith [GitLab and AWS](/partners/technology-partners/aws/), Ask Media developers built out a platform that enables the knowledge from all members of the teams. “With AWS, we wanted a product that was fairly complete and mature. AWS has a lot of history and lots of services. We definitely wanted to be able to leverage those services and to build on a platform that was a solid,” Chenglim says. “We set off to build Kubernetes clusters, right on EC2 instances. We continue to look at opportunities to leverage the resources available through AWS.”\n\nTo learn more about how Ask Media made the transition to cloud native, check out the full [webcast](/webcast/cloud-native-transformation/).\n\nCover image by [Eric Muhr](https://unsplash.com/@ericmuhr?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com)\n{: .note}","open-source",[769,770,771,9],"webcast","user stories","kubernetes",{"slug":773,"featured":6,"template":687},"from-monolith-to-microservices-how-to-leverage-aws-with-gitlab","content:en-us:blog:from-monolith-to-microservices-how-to-leverage-aws-with-gitlab.yml","From Monolith To Microservices How To Leverage Aws With Gitlab","en-us/blog/from-monolith-to-microservices-how-to-leverage-aws-with-gitlab.yml","en-us/blog/from-monolith-to-microservices-how-to-leverage-aws-with-gitlab",{"_path":779,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":780,"content":786,"config":794,"_id":796,"_type":14,"title":797,"_source":16,"_file":798,"_stem":799,"_extension":19},"/en-us/blog/get-started-ci-pipeline-templates",{"title":781,"description":782,"ogTitle":781,"ogDescription":782,"noIndex":6,"ogImage":783,"ogUrl":784,"ogSiteName":673,"ogType":674,"canonicalUrls":784,"schema":785},"How to use GitLab’s CI/CD pipeline templates","Learn how pipeline templates and Auto DevOps can get you up and running on GitLab CI/CD.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749667139/Blog/Hero%20Images/CI-pipeline-templates.jpg","https://about.gitlab.com/blog/get-started-ci-pipeline-templates","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"How to use GitLab’s CI/CD pipeline templates\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Chrissie Buchanan\"}],\n        \"datePublished\": \"2020-09-23\",\n      }",{"title":781,"description":782,"authors":787,"heroImage":783,"date":789,"body":790,"category":791,"tags":792},[788],"Chrissie Buchanan","2020-09-23","\nWriting deployment pipelines from scratch is a real pain in the branch. We want to make the [continuous integration](/topics/ci-cd/) experience more automatic so teams can get up and running quickly with [GitLab CI/CD](/topics/ci-cd/).\n\nAn easy way to get started is with GitLab’s CI/CD pipeline templates. Pipeline templates come in **more than 30** popular programming languages and frameworks. We’ll show you how to use these pipeline templates for your specific needs.\n\nFor an even more automatic continuous integration experience, we also offer [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) that does much of the legwork for you. Auto DevOps runs on pipelines automatically when a [Dockerfile or matching buildpack](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-build) exists, and identifies dependencies automatically.\n\n## What are CI pipeline templates?\n\n[Pipelines](https://docs.gitlab.com/ee/ci/pipelines/) are an integral component of both continuous integration (CI) and [continuous delivery (CD)](/topics/continuous-delivery/), and continuous deployment (the other \"CD\"). A deployment pipeline consists of two things:\n\n*   Jobs, which define _what_ to do. For example, jobs that compile or test code.\n*   Stages, which define _when_ to run the jobs. For example, stages that run tests after stages that compile the code.\n\nPipelines consist of one or more stages that run in order and can each contain one or more jobs that run in parallel. These jobs (or scripts) get run by agents, such as a [GitLab Runner](https://docs.gitlab.com/runner/).\n\nAt GitLab, pipelines are defined in a `gitlab-ci.yml` file. [CI/CD templates](https://docs.gitlab.com/ee/ci/examples/#cicd-templates) incorporate your favorite programming language or framework into this YAML file. Instead of building pipelines from scratch, CI/CD templates simplify the process by having parameters already built-in.\n\nYou can choose one of these templates when you create a `gitlab-ci.yml` file in the UI.\n\n![GitLab CI pipeline templates](https://docs.gitlab.com/ee/ci/img/add_file_template_11_10.png)\n\nBecause our CI/CD templates come in more than 30 popular languages, the chances are good that we have the template you need to get started in our [CI template repository](https://gitlab.com/gitlab-org/gitlab/tree/master/lib/gitlab/ci/templates).\n\n## What is Auto DevOps?\n\n[Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/) is a GitLab-exclusive feature that provides predefined CI/CD configurations that automatically detect, build, test, deploy, and monitor your applications. Rather than just accessing a template, Auto DevOps is a setting within your GitLab instance that is [enabled by default](https://docs.gitlab.com/ee/topics/autodevops/#enabled-by-default).\n\nOur [product vision for Auto DevOps](/direction/delivery/auto_devops/) is that everything is fully connected as part of one great GitLab experience. The term Auto DevOps actually comes from the different parts that are automated by Auto DevOps:\n\n*   \"Auto CI\" – Compile and test software based on best practices for the most common languages and frameworks.\n*   \"Auto review\" – Automatic analysis tools like Code Climate.\n*   \"Auto deploy\" – Based on [Review Apps](https://docs.gitlab.com/ee/ci/review_apps/) and incremental rollouts on Kubernetes clusters.\n*   \"Auto metrics\" – Collect statistical data from all the previous steps in order to guarantee performances and optimization of the whole process.\n\nAuto DevOps provides great defaults for all the stages and makes use of CI templates. You can [customize Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/customize.html) to meet your needs, and [manage Auto DevOps with GitLab APIs](https://docs.gitlab.com/ee/topics/autodevops/customize.html#extend-auto-devops-with-the-api).\n\nLearn more about Auto DevOps, check out this video:\n\n\u003C!-- blank line -->\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/0Tc0YYBxqi4\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\u003C!-- blank line -->\n\n## Other CI/CD resources\n\nGitLab also provides [CI/CD examples](https://docs.gitlab.com/ee/ci/examples/) so you can learn how to implement GitLab CI/CD for your specific use case. In addition to template files, you can find repositories with sample projects, and step-by-step tutorials for a variety of scenarios, including:\n\n*   [DevOps and Game Dev with GitLab CI/CD](https://docs.gitlab.com/ee/ci/examples/)\n*   [Test and deploy a Ruby application with GitLab CI/CD](https://docs.gitlab.com/ee/ci/examples/)\n*   [How to deploy Maven projects to Artifactory with GitLab CI/CD](https://docs.gitlab.com/ee/ci/examples/)\n*   ... And many others\n\nWith CI/CD templates and our Auto DevOps product feature, teams can start reaping the benefits of continuous integration without all of the manual configurations. For teams managing sometimes _hundreds_ of projects, it’s not realistic or doable to start from scratch. And with GitLab, you don’t have to.\n\nCurious about our best-in-class continuous integration? [Try GitLab free for 30 days](/free-trial/).\n\n## Related reads\n\n*   [\"A beginner's guide to continuous integration\"](/blog/a-beginners-guide-to-continuous-integration/)\n\n*   [\"Want a more effective CI/CD pipeline? Try our pro tips\"](/blog/effective-ci-cd-pipelines/)\n\n*   [\"3 CI/CD challenges to consider\"](/blog/modernize-your-ci-cd/)\n\nCover image by [chuttersnap](https://unsplash.com/@chuttersnap?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText) on [Unsplash](https://unsplash.com/s/photos/laboratory?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText)\n{: .note}\n","insights",[109,9,793],"DevOps",{"slug":795,"featured":6,"template":687},"get-started-ci-pipeline-templates","content:en-us:blog:get-started-ci-pipeline-templates.yml","Get Started Ci Pipeline Templates","en-us/blog/get-started-ci-pipeline-templates.yml","en-us/blog/get-started-ci-pipeline-templates",{"_path":801,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":802,"content":808,"config":814,"_id":816,"_type":14,"title":817,"_source":16,"_file":818,"_stem":819,"_extension":19},"/en-us/blog/gitlab-iconography-where-mvc-meets-visual-design",{"title":803,"description":804,"ogTitle":803,"ogDescription":804,"noIndex":6,"ogImage":805,"ogUrl":806,"ogSiteName":673,"ogType":674,"canonicalUrls":806,"schema":807},"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":803,"description":804,"authors":809,"heroImage":805,"date":811,"body":812,"category":299,"tags":813},[810],"Jeremy Elder","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",[683,9,684],{"slug":815,"featured":6,"template":687},"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":821,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":822,"content":828,"config":833,"_id":835,"_type":14,"title":836,"_source":16,"_file":837,"_stem":838,"_extension":19},"/en-us/blog/hey-icons-lighten-up",{"title":823,"description":824,"ogTitle":823,"ogDescription":824,"noIndex":6,"ogImage":825,"ogUrl":826,"ogSiteName":673,"ogType":674,"canonicalUrls":826,"schema":827},"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":823,"description":824,"authors":829,"heroImage":825,"date":830,"body":831,"category":299,"tags":832},[810],"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",[683,9,684],{"slug":834,"featured":6,"template":687},"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":840,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":841,"content":847,"config":852,"_id":854,"_type":14,"title":855,"_source":16,"_file":856,"_stem":857,"_extension":19},"/en-us/blog/interesting-things-ux-is-working-on-february-2021",{"title":842,"description":843,"ogTitle":842,"ogDescription":843,"noIndex":6,"ogImage":844,"ogUrl":845,"ogSiteName":673,"ogType":674,"canonicalUrls":845,"schema":846},"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":842,"description":843,"authors":848,"heroImage":844,"date":849,"body":850,"category":746,"tags":851},[702],"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",[683,9,684],{"slug":853,"featured":6,"template":687},"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":859,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":860,"content":866,"config":873,"_id":875,"_type":14,"title":876,"_source":16,"_file":877,"_stem":878,"_extension":19},"/en-us/blog/is-devops-for-designers",{"title":861,"description":862,"ogTitle":861,"ogDescription":862,"noIndex":6,"ogImage":863,"ogUrl":864,"ogSiteName":673,"ogType":674,"canonicalUrls":864,"schema":865},"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":861,"description":862,"authors":867,"heroImage":863,"date":869,"body":870,"category":871,"tags":872},[868],"Jordi Mon","2020-09-03","\n\nAccording to two legends on the field of Design, [Don Norman](https://en.wikipedia.org/wiki/Don_Norman) and [Jakob Nielsen](https://en.wikipedia.org/wiki/Jakob_Nielsen_(usability_consultant)), a successful user experience occurs when the user can fulfill his or her needs. A product designed with high UX standards in mind should have enough functionality and self-explanatory visual information for all its users to complete their tasks without help.\n\nGitLab is a complete [DevOps platform](/topics/devops-platform/) – meaning, good UX within GitLab equals good developer experience (DX). Following Nielsen and Norman's argument, good DX is the ability to not only use the product’s UI to serve a dev's needs, but also to find good documentation in context, a versatile API, and general compatibility with their working environment. Considering this succinct description of the GitLab app, one could easily infer that all its users are either software developers or system administrators, right?\n\nHowever, this assertion isn’t entirely true. There's no doubt that developers and operators are still the protagonists of DevOps, but more and more people from other professions (including graphic design, research, marketing, and even psychology) are contributing to software building. At GitLab, we acknowledge that in our vision.\n\n{::options parse_block_html=\"false\" /}\n\n\u003Cdiv class=\"center\">\n\n\u003Cblockquote class=\"twitter-tweet\">\u003Cp lang=\"en\" dir=\"ltr\">We've got a vision for our product and \u003Ca href=\"https://twitter.com/CLenneville?ref_src=twsrc%5Etfw\">@CLenneville\u003C/a>, VP of UX at GitLab, is sharing it live at \u003Ca href=\"https://twitter.com/hashtag/GitLabCommit?src=hash&ref_src=twsrc%5Etfw\">#GitLabCommit\u003C/a>. \u003Ca href=\"https://t.co/if4xVWgxqT\">pic.twitter.com/if4xVWgxqT\u003C/a>\u003C/p>— GitLab (@gitlab) \u003Ca href=\"https://twitter.com/gitlab/status/1298911891352367104?ref_src=twsrc%5Etfw\">August 27, 2020\u003C/a>\u003C/blockquote> \u003Cscript async src=\"https://platform.twitter.com/widgets.js\" charset=\"utf-8\">\u003C/script>\n\n\u003C/div>\n\nWe're already taken the first strides in this long-term vision for the GitLab product, and they aim to welcome designers to [DevOps](/topics/devops/). This post describes the first steps taken by GitLab's Product team to connect DevOps with design.\n\n## Is DevOps for designers?\nVisual design for applications is a completely different field than application development. For starters, designers work with designs, screens, user flows, prototypes, and so many other graphic assets, while developers only use [source code](/solutions/source-code-management/). Their workflows are also pretty different: While devs may find enough solace in push, pull, merge, and other operators useful to their daily routines with code, visual designers may require other sets of features that allow them to communicate, receive, and apply feedback on designs.\n\nIs a platform like GitLab a good place for designers to try DevOps? We think so. One of the foundations of DevOps is that [cross-functional teams deliver better products faster](http://cloudplatformonline.com/rs/248-TPC-286/images/DORA-State%20of%20DevOps.pdf). If that is the case, then why keep designers' collaboration platforms separate? Why make their workflows independent and disconnected, and why hand off deliverables when it should be all about constant iteration with handovers?\n\n[Figma](https://www.figma.com/) is a vector graphics editor and prototyping tool. Figma founder and CEO, [Dylan Field](https://twitter.com/zoink?ref_src=twsrc%5Egoogle%7Ctwcamp%5Eserp%7Ctwgr%5Eauthor), crunched some numbers and discovered that the designers: developer ratio had increased considerably among top players.\n\n![2.5x increase in desginer to dev ratio](https://about.gitlab.com/images/blogimages/2020-09-03-is-devops-for-designers-figma-plugin/designer-to-dev-ratio.png){: .shadow.center}\nScreenshot from [TechCrunch](https://techcrunch.com/2017/05/31/here-are-some-reasons-behind-techs-design-shortage/)\n{: .note.text-center}\n\nWhen we mention \"top players,\" we're not talking about adaptable, flexible startups. Quite the contrary, in fact.\n\n> \"The companies willing to go on the record were mostly enterprise, so this sample doesn’t even include the consumer startups that famously focus on design, like Airbnb. Facebook staffers told us the social network has quadrupled its designer hiring target in the last two years alone - but Facebook wouldn’t officially comment.\" - Dylan Field wrote in [TechCrunch](https://techcrunch.com/2017/05/31/here-are-some-reasons-behind-techs-design-shortage/)\n\nAt GitLab, we've learned that frictionless feedback loops are the best way to validate our work. The feedback loop is fastest when designers can work hand in hand with the developers that create the source code that will later give life to their visuals.\n\n## Let DesignOps connect with DevOps: GitLab ❤️ Figma\n\nWe want designers to work in GitLab, which is why we created a new product category called [Design Management](/direction/plan/design_management/#introduction) that strives to make Designers welcome within GitLab and support their workflows. The first step in this direction is to change the dreaded handoff to a more iterative handover that will more accurately capture the feedback loops of the last part of the design workflow. How Design Management works at large will be the subject of another, in-depth blog post coming soon. You can catch a brief sneak peek on [YouTube](https://youtu.be/5oo0m3s5Gfk).\n\nWe developed a plugin to connect GitLab to Figma, to simplify the handover process. Now, you can upload one or multiple frames to any issue. From then on designers, PMs, and engineers can discuss the designs within GitLab.\n\nNext, we explain why we picked Figma and then dive deeper into how to install and use the plugin.\n\n## Why did we choose to integrate with Figma?\n\nWatch the video below as [Jeremy Elder](/company/team/#jeldergl), senior product designer, FE/UX Foundations, Visual Design, explains why we chose Figma as the main tool for Product Designers in GitLab.\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/Qa9M74CfuXY?start=650&end=1040\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\nOnce Product Design was comfortable using Figma to work on GitLab's design, the decision to build a plugin came naturally, considering how much we value [dogfooding](https://handbook.gitlab.com/handbook/values/#dogfooding): Why not make the transition from Figma to GitLab much easier? GitLab team members are heavy Figma users ourselves (our Figma community is [here](https://www.figma.com/@GitLab)) and you can see how we use it for product design below:\n\n\u003Cfigure class=\"video_container\">\n\u003Ciframe style=\"border: 1px solid rgba(0, 0, 0, 0.1);\" width=\"800\" height=\"450\" src=\"https://www.figma.com/embed?embed_host=share&url=https%3A%2F%2Fwww.figma.com%2Fproto%2F73OcYdBfOaK2xlChC3tbNX%2FFigma-for-GitLab%3Fnode-id%3D2%253A61%26scaling%3Dscale-down&chrome=DOCUMENTATION\" allowfullscreen>\u003C/iframe>\n\u003C/figure>\n\nGitLab's own community was requesting we build the Figma plugin.\n\n> “When will the plugin be published? Because our entire development team works on Linux\n> machines and can't run the Desktop application. When is this plugin going to be published so > it would be possible also for the users with Linux-based systems, which are more or less\n> forced to use the Web app, to use this plugin? I think, this would bring both, Figma and GitLab, generally a huge step forward.” – Community member [Emanuel Bennici](https://gitlab.com/l0nax) commented in the ([issue](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/issues/2#note_371842296))\n\n>“I also work on Linux and this would be a huge improvement for me and my company.” – Community member [Gabriel Jann](https://gitlab.com/JAIABRIEL) commented in the ([issue](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/issues/2#note_371844752))\n\n## How do I get started with the Figma plugin?\n\n First and foremost [download the plugin](https://gitlab.com/gitlab-org/gitlab-figma-plugin) and get going with the first steps in the [User Guide](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/wikis/home). In the video below, [Christen Dybenko](/company/team/#cdybenko), Design Management PM, walks you through the installation and the first steps with the plugin in GitLab:\n\n\u003Cfigure class=\"video_container\">\n  \u003Ciframe src=\"https://www.youtube-nocookie.com/embed/KR2nuehGtrU\" frameborder=\"0\" allowfullscreen=\"true\"> \u003C/iframe>\n\u003C/figure>\n\n## What's next?\n\nTell us about your experience using the plugin by commenting on the [issue](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/issues/44).\n\nQuestions about the future of Design Management? Wondering about how it fits into our broader DevOps scheme? Check our [next steps](/direction/plan/design_management/#whats-next--why) and [long term strategy for Design Management](/direction/plan/design_management/#long-term-strategy).\n","engineering",[683,9,684],{"slug":874,"featured":6,"template":687},"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":880,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":881,"content":886,"config":894,"_id":896,"_type":14,"title":897,"_source":16,"_file":898,"_stem":899,"_extension":19},"/en-us/blog/iterate-like-a-gitlab-designer",{"title":882,"description":883,"ogTitle":882,"ogDescription":883,"noIndex":6,"ogImage":738,"ogUrl":884,"ogSiteName":673,"ogType":674,"canonicalUrls":884,"schema":885},"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":882,"description":883,"authors":887,"heroImage":738,"date":889,"body":890,"category":746,"tags":891},[888],"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",[683,684,9,892,893],"research","collaboration",{"slug":895,"featured":6,"template":687},"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":901,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":902,"content":908,"config":917,"_id":919,"_type":14,"title":920,"_source":16,"_file":921,"_stem":922,"_extension":19},"/en-us/blog/new-typefaces-in-gitlab",{"title":903,"description":904,"ogTitle":903,"ogDescription":904,"noIndex":6,"ogImage":905,"ogUrl":906,"ogSiteName":673,"ogType":674,"canonicalUrls":906,"schema":907},"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":903,"description":904,"authors":909,"heroImage":905,"date":911,"body":912,"category":913,"tags":914},[910,810],"Sascha Eggenberger","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","news",[683,915,916,681,9,684],"frontend","open source",{"slug":918,"featured":6,"template":687},"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":924,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":925,"content":931,"config":938,"_id":940,"_type":14,"title":941,"_source":16,"_file":942,"_stem":943,"_extension":19},"/en-us/blog/personal-profile",{"title":926,"description":927,"ogTitle":926,"ogDescription":927,"noIndex":6,"ogImage":928,"ogUrl":929,"ogSiteName":673,"ogType":674,"canonicalUrls":929,"schema":930},"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":926,"description":927,"authors":932,"heroImage":928,"date":934,"body":935,"category":913,"tags":936},[933],"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",[9,684,937],"contributors",{"slug":939,"featured":6,"template":687},"personal-profile","content:en-us:blog:personal-profile.yml","Personal Profile","en-us/blog/personal-profile.yml","en-us/blog/personal-profile",{"_path":945,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":946,"content":952,"config":959,"_id":961,"_type":14,"title":962,"_source":16,"_file":963,"_stem":964,"_extension":19},"/en-us/blog/polishing-gitlabs-ui-a-new-color-system",{"title":947,"description":948,"ogTitle":947,"ogDescription":948,"noIndex":6,"ogImage":949,"ogUrl":950,"ogSiteName":673,"ogType":674,"canonicalUrls":950,"schema":951},"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://res.cloudinary.com/about-gitlab-com/image/upload/v1749666775/Blog/Hero%20Images/cover.jpg","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":947,"description":948,"authors":953,"heroImage":949,"date":955,"body":956,"category":871,"tags":957},[954],"Pedro Moreira da Silva","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",[958,683,684,9],"inside GitLab",{"slug":960,"featured":6,"template":687},"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":966,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":967,"content":973,"config":978,"_id":980,"_type":14,"title":981,"_source":16,"_file":982,"_stem":983,"_extension":19},"/en-us/blog/refining-gitlab-product-experience",{"title":968,"description":969,"ogTitle":968,"ogDescription":969,"noIndex":6,"ogImage":970,"ogUrl":971,"ogSiteName":673,"ogType":674,"canonicalUrls":971,"schema":972},"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":968,"description":969,"authors":974,"heroImage":970,"date":975,"body":976,"category":299,"tags":977},[702],"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",[684,9],{"slug":979,"featured":6,"template":687},"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":985,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":986,"content":992,"config":998,"_id":1000,"_type":14,"title":1001,"_source":16,"_file":1002,"_stem":1003,"_extension":19},"/en-us/blog/starting-from-the-start-slippers-design-system",{"title":987,"description":988,"ogTitle":987,"ogDescription":988,"noIndex":6,"ogImage":989,"ogUrl":990,"ogSiteName":673,"ogType":674,"canonicalUrls":990,"schema":991},"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":987,"description":988,"authors":993,"heroImage":989,"date":995,"body":996,"category":871,"tags":997},[994],"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",[893,958,9,684],{"slug":999,"featured":6,"template":687},"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":1005,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1006,"content":1012,"config":1020,"_id":1022,"_type":14,"title":1023,"_source":16,"_file":1024,"_stem":1025,"_extension":19},"/en-us/blog/synchronous-collaboration-as-a-remote-designer-at-gitlab",{"title":1007,"description":1008,"ogTitle":1007,"ogDescription":1008,"noIndex":6,"ogImage":1009,"ogUrl":1010,"ogSiteName":673,"ogType":674,"canonicalUrls":1010,"schema":1011},"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":1007,"description":1008,"authors":1013,"heroImage":1009,"date":1017,"body":1018,"category":746,"tags":1019},[1014,1015,1016,888],"Alexis Ginsberg","Becka Lippert","Matej Latin","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",[683,684,9,726,893],{"slug":1021,"featured":6,"template":687},"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":1027,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1028,"content":1034,"config":1040,"_id":1042,"_type":14,"title":1043,"_source":16,"_file":1044,"_stem":1045,"_extension":19},"/en-us/blog/why-we-chose-echarts",{"title":1029,"description":1030,"ogTitle":1029,"ogDescription":1030,"noIndex":6,"ogImage":1031,"ogUrl":1032,"ogSiteName":673,"ogType":674,"canonicalUrls":1032,"schema":1033},"Why we chose ECharts for data visualizations","Learn why GitLab switched from D3.js to ECharts as our library of choice for rendering data visualizations.","https://res.cloudinary.com/about-gitlab-com/image/upload/v1749666699/Blog/Hero%20Images/banner.jpg","https://about.gitlab.com/blog/why-we-chose-echarts","\n                        {\n        \"@context\": \"https://schema.org\",\n        \"@type\": \"Article\",\n        \"headline\": \"Why we chose ECharts for data visualizations\",\n        \"author\": [{\"@type\":\"Person\",\"name\":\"Clement Ho\"}],\n        \"datePublished\": \"2019-09-30\",\n      }",{"title":1029,"description":1030,"authors":1035,"heroImage":1031,"date":1037,"body":1038,"category":871,"tags":1039},[1036],"Clement Ho","2019-09-30","\nAs GitLab continues to grow in depth and breadth across the [DevOps lifecycle](/topics/devops/), the use of charts and data visualizations has increased in frequency and complexity. Throughout the life of GitLab as a project, we've used multiple libraries to render beautiful charts. As the number of different libraries increased along with our charting requirements, we decided it was time to start unifying our charting libraries to help us move quickly.\n\nAt first, we wanted to unify our charts using D3.js but this was difficult because D3.js isn't a charting library. In their own words: \"D3.js is a JavaScript library for manipulating documents based on data,\" meaning it is a low level visualization tool. D3.js is powerful but it has a big learning curve. Our team did not have the time to develop the expertise without impacting our product development velocity. We also knew we had an ambitious hiring plan, and we would be adding time to our onboarding process by using D3.js.\n\nThe frontend team set out to investigate different charting libraries that we could use to gain more velocity. The library didn't have to do everything we needed, but it had to get us most of the way there. We investigated many libraries including ECharts, Britecharts, and Plotly as potential options. In the end, ECharts was the clear winner for us. Here's why:\n\n## Echarts robust yet flexible chart types\nOn the monitor stage frontend team, we have the [ambitious goal of replacing well-known monitoring tools like DataDog and Grafana](/direction/monitor/). It was absolutely critical that our charting library had enough flexibility for us to create our own custom charts, but it was also important that the library had existing charts so that we didn’t have to create every chart from scratch for the sake of development velocity.\n\nECharts has an [incredible showcase](https://echarts.apache.org/examples/en/) of the adaptability of their charts. This was a great starting point for us. We tested out styling ECharts to match our design system to determine how adaptable it was and we were very satisfied with the results.\n\n![design](https://about.gitlab.com/images/blogimages/why-we-chose-echarts/design.png)\n*Design spec for future GitLab charts.*\n\n![implementation](https://about.gitlab.com/images/blogimages/why-we-chose-echarts/implementation.png)\n*Evaluation implementation using ECharts.*\n\n## Echarts performance\nWhen we were evaluating ECharts, we took one of our most complex user interactions for charts to benchmark the performance of the charting library. Although ECharts wasn’t perfect, it fared better than the alternatives. Below are some gifs recorded from changing the chart values in our [evaluation project](https://gitlab.com/adriel/echarts-proof-of-concept). As you can see, performance does decrease as the data points increase but it is still usable and it is unlikely we would have that many points in such a small chart.\n\n![10 values](https://about.gitlab.com/images/blogimages/why-we-chose-echarts/10-points.gif)\n*Linked chart with 10 values.*\n\n![100 values](https://about.gitlab.com/images/blogimages/why-we-chose-echarts/100-points.gif)\n*Linked chart with 100 values.*\n\n![1000 values](https://about.gitlab.com/images/blogimages/why-we-chose-echarts/1000-points.gif)\n*Linked chart with 1000 values.*\n\n![4000 values](https://about.gitlab.com/images/blogimages/why-we-chose-echarts/4000-points.gif)\n*Linked chart with 4000 values.*\n\n## Growing ecosystem\n\nECharts isn’t perfect but it has [improved over time](https://incubator.apache.org/projects/echarts.html). It started off as an [open source project from Baidu](https://whimsy.apache.org/board/minutes/ECharts.html) but is still going through the process of being incubated into the Apache Software Foundation. The [majority of ECharts users still seem to be based in China](https://echarts.apache.org/en/committers.html), meaning the developer community and corresponding documentation is written primarily in Chinese. Despite some language barriers, the ECharts community does seem to be growing more internationally. We’ve come across a variety of companies from the United States and Mexico who are either evaluating or using ECharts internally.\n\nThe Podling Project Management Committee (PPMC) of ECharts, which is their core team in GitLab terms, has also been very welcoming and energetic about growing the ecosystem. As we decided on ECharts and began developing new charts and replacing old charts, we’ve been able to build a partnership with the company. They have been very kind to meet with us online every month to help answer questions and to guide us in using their library effectively. This has been extremely helpful. For example during one of our meetings, Shuang Su gave us a brief walkthrough of the codebase and it's architecture.\n\n## Where we are today with Echarts\n\nWe introduced [ECharts to the GitLab codebase in 11.6](https://gitlab.com/gitlab-org/gitlab-ce/issues/53147) and through ECharts have been rapidly building new chart types into our component library at a faster rate than ever before. We started with updating the charts in just our Monitor stage but have since introduced charts into the [Secure](https://gitlab.com/gitlab-org/gitlab-ee/issues/6954) and [Manage](https://gitlab.com/gitlab-org/gitlab-ee/issues/12079) stages.\n\nDepending on your use case, Apache ECharts could be a good fit for you too. For our team, ECharts has without a doubt increased our product development velocity over against what it was with D3.js.\n\n| Old chart in D3.js | New chart in ECharts |\n|",[958,9,915],{"slug":1041,"featured":6,"template":687},"why-we-chose-echarts","content:en-us:blog:why-we-chose-echarts.yml","Why We Chose Echarts","en-us/blog/why-we-chose-echarts.yml","en-us/blog/why-we-chose-echarts",{"_path":1047,"_dir":244,"_draft":6,"_partial":6,"_locale":7,"seo":1048,"content":1054,"config":1060,"_id":1062,"_type":14,"title":1063,"_source":16,"_file":1064,"_stem":1065,"_extension":19},"/en-us/blog/async-sketching",{"title":1049,"description":1050,"ogTitle":1049,"ogDescription":1050,"noIndex":6,"ogImage":1051,"ogUrl":1052,"ogSiteName":673,"ogType":674,"canonicalUrls":1052,"schema":1053},"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":1049,"description":1050,"authors":1055,"heroImage":1051,"date":722,"body":1058,"category":746,"tags":1059},[1056,1057],"Jacki Bauer","Inchul Yoo, Sunjung Park","\n\n{::options parse_block_html=\"true\" /}\n\n\n\n\nMany companies that normally work together in person have been suddenly thrust into an all-remote world. That can be scary for anyone, but especially for UX designers who rely heavily on face-to-face collaboration with their cross-functional peers.\n\nIf you’re in this situation, you may be thinking: How can I ideate without a whiteboard? How do I lead my team through sketching exercises without paper? WHAT DO I DO WITH ALL OF MY SHARPIES AND STICKY NOTES?!\n\nAt GitLab, our entire company is all remote and globally distributed. We’re used to finding ways to sketch, think and brainstorm asynchronously, so we can accommodate team members who live in time zones all over the world.\n\nYou need just a few ingredients.\n## Clear, simple guidelines and instructions\nGuidelines are really important in any design thinking activity, but when you’re asynchronous, they become extra important, because participants can’t ask clarifying questions or observe what others are doing. So it’s the designer’s role to communicate the activity’s purpose and goal, along with clear instructions and a sense of psychological safety. \n\nAnd just like with in-person activities, you also might want to provide timing advice. For example, consider how you want an individual's ideas to influence others. You might want to give everyone a day to ideate and then ask everyone to drop in their ideas at the same time, so they don’t inadvertently influence each other. Or, you might ask people to intentionally play off the ideas of others. It’s ultimately up your judgement about the goals of the session.\n\n\n## Shared understanding of context\nThe team should already understand some basics about the product or context they work in and the audience they are designing for. If you’re working with a newly formed team, you might try a couple synchronous workshops to get everyone on the same page.\n\n\n## A place for everyone to contribute their ideas\nThis one is easy. There are a lot of tools you can use, including Mural, Google Drive, or even \nSlack. At GitLab, we use Mural, and we also work within our own product to run collaborative design sessions. \n\nAll you need is a place where team members can quickly and easily add text, photos of sketches, images, or even videos, and then freely discuss them. To encourage creativity, you’ll likely want to pick a tool that offers flexibility. \u2028\u2028\u2028\n\n![Illustration of a sketch and chat windows](https://about.gitlab.com/images/blogimages/sketching-session.jpg){: .shadow.medium.center}\n\n## Facilitate team communication\nWhen a team meets in person, they get a lot of non-verbal feedback that can be really useful. People might smile at each other, nod when they hear a good idea, or sigh when someone suggests something that won’t work.\n\nIt’s important to offer a way to surface these reactions when you can’t use immediate nonverbal communication. As the team shares their ideas, provide supportive comments (that will encourage others to do the same). You might also use emojis to enhance communication.\n\n## Step just a little outside your comfort zone\nThis last one is important in any kind of design thinking environment. If you’re a designer working with a product or a client team, it’s likely that many (or most) of the participants in your sessions are not designers. Some participants might hate drawing, and some might be terrified of the idea of uploading something they drew to the internet. \n\nThis is where it helps to work with a team that has already established some rapport. As the designer and session leader, it’s also your job to set a relaxed and casual tone and a low bar for participation. \n\nAt GitLab we say “Everyone can contribute,” and we value action and results over perfection. Let people know it’s OK to not be perfect. As an example, this is how one designer at GitLab set the rules for her team sketching session:\n\n**Rules for the game**\n*  This is a 10-minute activity in total. You don't have to spend more than 5 minutes for each round.\n*  Let's not think about layouts such as the top-header, GitLab logo, and left menu.\n*  There are no right or wrong answers.\n*  It doesn't have to be beautiful. (You will be surprised to see how ugly mine is.)\n*  For round 2, you don't need to fill in all the blanks if it is hard for you. It's not an exam. :-)\n\nTo see this method in action, you can read through this [issue](https://gitlab.com/gitlab-org/geo-team/discussions/-/issues/4944) from February 2020. Believe it or not, this team was doing this exercise for the first time!\n\nCover image by [Mounzer Awad](https://unsplash.com/@mounzaw_) on [Unsplash](https://unsplash.com/s/photos/sketching)\n{: .note}\n\n",[893,683,726,9,684],{"slug":1061,"featured":6,"template":687},"async-sketching","content:en-us:blog:async-sketching.yml","Async Sketching","en-us/blog/async-sketching.yml","en-us/blog/async-sketching",3,[666,692,712,733,754,778,800,820,839],1753981656510]