1. You are here:
2. Handbook
3. Marketing
4. Brand and Product Marketing
5. Brand Design Handbook

On this page

• Welcome to the GitLab Brand Design Handbook
  • Overview
    • Purpose
    • Vision
    • Mission
    • Requesting Support
      • Brand & Marketing Design Issue Templates
      • Contacting the team
      • Team logo requests
    • Working with the brand
      • Partnership with third parties
      • Fanart
      • Team member resource group (TMRG) requests
  • How we work
    • Brand Design team structure
      • Responsibilities
      • Design approvals
    • Team workflow
      • Saving work
      • Using git and terminal
      • Ebooks, whitepapers, and one-pagers
      • Digital ads
      • Events
      • Brand Guidelines

Welcome to the GitLab Brand Design Handbook

We develop our brand visual identity design to ensure it stays relevant in the market and reflects the benefits and quality of our product. We are the creative partners for GitLab marketing. We create, conceptualize, and design high quality brand experiences.

Overview

Purpose

Why we exist

As stewards of the GitLab brand, our goal is to educate and enable the wider organization with resources to effetively and honestly communicate what the company does to our internal and external audiences.

Vision

Where we're going

The GitLab Brand Design team will elevate the brand beyond the logo and visuals - positioning ourselves as experts in brand strategy and behavior (how the brand presents itself, how it's perceived, and what makes it authentic)

Mission

What we do

Create simple, effective, and intentional brand experiences by solving complex problems; defining the what, why, and how, resulting in a message that's easy to understand.

Requesting Support

Please fill out one of these Issue Templates to request support. Please note, if these are not filled out we won't have the proper information for us to support your request.

Brand & Marketing Design Issue Templates

• Requesting a new design
  • Use this template to request a new design of a single asset
  • Do NOT use this template for complicated campaign design support
  • Do NOT use this template for brand reviews
• Requesting a Brand Refresh
  • Use this template to request re-branding design support (multiple or single asset)
  • What has changed with our branding?
    1. Logomark and Core Logo the rules around how to use it properly
    2. Font and typography guidelines
    3. Colors and color usage
    4. Marketing icons and illustration style
    5. Added photography guidelines for our brand
    6. Small adjustments to Tone of voice and co-branding guidelines
  • Do NOT use this template for complicated campaign design support
  • Do NOT use this template for brand reviews
• Requesting Brand review
  • Use this template to request a brand or design review
  • Do NOT use this template for requesting new assets or designs
• Requesting design concepting for integrated campaigns
  • Use this template to request design concepting for an integrated campaign
  • You may also use this template for a single-group campaign, but the ROI but be sufficient to utilize the resources
  • You must also complete a Design Requirements Issue for final files to be delivered.
  • Design concepting will be completed before the design requirements file is picked up.
• Design requirements
  • Use this template for capturing all the design requirements for an integrated campaign
  • Use this issue along with a Design Concepting Issue

Contacting the team

The best way to get in contact with the Brand design team is to fill out one of the above issue templates with your request, or to:

• Use the @gl-design tag in GitLab issues and epics for visibility
• @-mention individuals from the team in GitLab issues and epics
• Ask your question in the #marketing-design Slack channel

Team logo requests

In the past we have accommodated internal team logo requests, typically in the form of customized tanukis. As our company grows, this approach is not scalable for the Brand Design team. Additionally, altering the logo or using too many logos diminishes the integrity of our brand identity and dilutes our brand awareness. We understand the desire for teams within GitLab to have their own identity, but this should not be prioritized over the business value that comes from preserving our core branding. For this reason, all designs should complement and adhere to our brand guidelines.

If your team works on a larger initiative, please refer to our program lockup guidelines. These lockups should be used in conjunction with the GitLab logo and branding. If you are unsure if your program or initiative requires a lockup, please contact the Brand Design team.

Working with the brand

To learn more about our Brand Guidelines, self-service resources and assets, and training materials, check out the Brand Resources handbook. Below you will find more details about working with our brand and creative materials.

Partnership with third parties

In certain cases, the help of a third party agency or design partner may be brought in for a project. The following serves as criteria for when to outsource design:

• Smaller-scale projects, such as stickers or requests that do not meet our current business prioritization, where the brand guidelines provide sufficient creative direction and parameters for the third party to work with.
• Larger-scale projects where the Brand and Digital team need additional support given the timeline and/or scale of the request.

Whenever a third party is brought in to support design, the work must be shared with the Brand Design team to ensure brand integrity and that we are working transparently with one another.

Fanart

The GitLab brand has been a source of creative inspiration for team members and the wider community since its inception. In many cases, team members may find themselves creating spinoff art inspired by our values, software, and tanuki logo.

Artwork that draws inspiration from or is based on GitLab’s intellectual property (“Fanart”) is not always an accurate representation of our brand, product, and company, and may dilute our brand or infringe on our intellectual property rights. To protect our brand, GitLab team members must adhere to the following guidelines:

Do’s:

• Add an “unofficial fanart” label to the Fanart to clarify that the content is not official GitLab content. The text can be small, but make sure it’s conspicuous enough that anyone seeing the Fanart will also notice the label.
• Only share Fanart you are authorized to share, e.g. Fanart that you yourself have created. If in doubt, please reach out to the Legal team via the #legal Slack channel.
• Share only on the following approved platforms:
  • Internal GitLab Slack channels and private messages to friends.
  • You can share publicly to broader audiences from your personal social media accounts on Facebook, Twitter, Instagram, TikTok, or Reddit.
• For “public” shares:
  • LinkedIn sharing is prohibited due to the close association between one’s personal LinkedIn profile and their workplace.
  • If you want to share Fanart publicly on any other platform not mentioned above, reach out in the #brand Slack channel to discuss.

Don’ts:

• Do not create or share Fanart that uses the GitLab logo or wordmark.
  • If your Fanart incorporates any other GitLab IP (e.g., screenshots, likenesses, or imagery taken directly from GitLab materials), reach out to #brand for review.
• Do not imply that the Fanart is official GitLab content. For example:
  • Do not use Fanart in any GitLab materials, such as slide decks, printed collateral, or swag.
  • Don’t use or distribute Fanart to Gitlab customers, or at events that you attend on GitLab’s behalf.
• Do not sell or otherwise use Fanart for commercial purposes. For example:
  • Do not sell Fanart stickers or T-shirts.
  • Don’t use Fanart to advertise any businesses, services, or products.
• Do not create or share any Fanart that is potentially offensive or otherwise detrimental to GitLab’s brand or any other brand.
• Do not combine Fanart with other companies’ materials or anything else unrelated to GitLab.

If you have questions, reach out to the Brand Design and Brand Strategy teams via the #brand Slack channel.

Team member resource group (TMRG) requests

We take a unique, creative approach specifically for TMRGs. In lieu of custom logos for the groups, our team delivers expressive art that can be used for swag and other requested collateral. TMRGs are an essential part of our company's culture, and we tailor the graphics to capture each group's essence and values. TMRG graphics should always be paired with the GitLab logo and incorporate the TMRG name in plain text. All art should lean on the foundations of our core branding.

How we work

Brand Design team structure

We are all brand designers, brand champions, critically thinking problem solvers, strategists, and teammates – leveraging each others' strengths while growing our collective knowledge and expertise. We work by following GitLab’s values and using issues and epics to track our work.

Responsibilities

• Be lean and efficient: leverage everyone’s strengths and expertise and trust one another to make the best decisions for the team and our brand.
• Wear many hats: have the flexibility to tackle a variety of tasks demanded by the role - all for the greater good of the team and company.
• Develop creative concepts: drive the creative direction of your individual projects. For large-scale projects, Adam and Luke are responsible for core concept development, which is then presented to the wider team for discussion, feedback, and refinement.
• Carry out the creative: bring a creative direction to life with touch-point collateral informed by the creative direction, all while managing your time accordingly.
• Advocate for the GitLab Brand: know, contribute to, and uphold our brand standards, and review materials from within and outside our team to preserve our brand’s integrity.
• Know the tools: be proficient in the Adobe Suite and Figma (for designing), Mural and FigJam (for brainstorming), Canva (for creating self-service assets), and the Google Suite (for company-wide materials).

Design approvals

The team should feel empowered to make the best decisions possible for the GitLab brand while seeking both structured and direct feedback from the team as often as possible. Adam and Luke are here to make final decisions as needed, but do not need to be the bottleneck of progress.

Team workflow

• Team check-ins: We have three recurring team syncs: (1) Monday design hours call where we catch up and talk about work for the upcoming week. (2) Tuesday async GeekBot status reports in the #marketing-design slack channel. (3) Wednesday design hours call where we get feedback and collaborate on topics that need to be addressed.
• Working in issues: All design requests should use our issue templates and include the mktg-status::triage, corporate-marketing, and design issue labels to show up on our team’s triage board. Adam and Luke triage work at the beginning of the week, and team members are able to assign work to themselves, too. We use issue weights (1 weight = approx. 4 hours of work) to measure bandwidth and milestones to track capacity for each week. Everyone can see their work for the week by looking at their individual issue board.
• Collaborating together: We work together as a team by playing to each of our strengths. Work is usually triaged out to team members whose design skills fit the request, or we collaborate together on a project using our combined talents.
• Small projects: Smaller projects are typically assigned to one designer and completed within 2 weeks. Given the quick turnaround at GitLab, we work in small iterations, referred to as the MVC (minimum viable change) approach.
• Medium and large projects: For larger projects, we assess the request and then propose a timeline. For campaigns or projects with a unique concept, we kick off a brainstorming session either async or on a cross-functional call with the larger team, or whoever has been assigned, and then we pitch the concept(s) to the stakeholders.
• Sharing work: Work should be shared early and often, either in our design hours calls or async in our private #brand-design-team slack channel. Drafts are typically shared async with the stakeholder using the design tab in issues or as a screenshot in comments.

Saving work

We upload and pull work locally from the corporate-marketing repository. For confidential projects, we store files in the team Google Drive.

• The highest folder level is organized by project type (ie: publications, campaigns, events, etc.). From there, they are broken down by category (ebook, whitepaper, campaign name, event year, etc.) Once you are in the relevant folder, create a new folder with your project’s name.
• Creative explorations or work-in-progress files can be stored in your respective progress folder, but make sure that final files are stored in a relevant project folder.
• Each project folder should have at least two sub-folders: a folder for your source files (_artwork) and another folder for your exported files (ie: png, exports, pdf, etc.).
• File names should be lowercase and use hyphens in place of spaces. Include the file dimensions in the file name. Avoid acronyms.
• Both the Google Drive and repository save version history; for that reason, files can be saved over as edits to the file are made.

Using git and terminal

• Push and pull work frequently, at least once a day, to keep our work up-to-date. If you are working on a file that others may be in as well, communicate it with the team so that no one saves over someone else’s work.
• To get started, set up a local clone of the corporate-marketing repository to your machine. For your day-to-day work, here are the typical git commands for pulling and pushing work, in the order of which they should be used:
  • cd corporate-marketing - this command only needs to be used once upon opening the Terminal app. The cd command may need to be done multiple times, followed by the parent folder name where you’ve stored the repository on your device, until you get into the corporate-marketing folder
  • git pull - this updates your local repository to mirror any changes made by the rest of the team; do this command before starting work or pushing any new work
  • git status - optional command; this provides a summary of all the changes you’ve made locally that need to be pushed back the repository
  • git checkout [insert file path] - optional commnand; this can be used to remove any files you do not want to push to repository
  • git add . - use this command before pushing your work; it will add all the files you have made changes to
  • git commit -m “[insert description of changes]” - include a message with a summary of your changes; this is viewable to everyone and provides context
  • git push origin master - this will push all your changes back to the repository, including the commit message to describe the changes
  • git pull --rebase, followed by, git push origin master - use these two commands to reset if you receive an error when pushing

Ebooks, whitepapers, and one-pagers

• Design templates for each publication are located here.
• Our publications are often sent to Smartling for translation; save out a .zip file of the packaged artwork for easy download.
• Most one-pagers can be self-serviced using one of our Google Doc templates.

Digital ads

• Digital ads often need to be customized after creation, and for that reason we encourage Canva for easier self-service. Some ads need to be edited by Demandbase under certain specs and file requirements.

Events

• Trade Show booths should default to using our general GitLab brand. General events such as these are organized by year within the repository.
• Recurring events that we host (Sales Kickoff, Contribute, Commit) have a different theme each year, which inspires a new creative direction. These events have their own folder, and are then organized within by year.

Brand Guidelines

The Brand Design team mantains the Brand Guidelines on design.gitlab.com (Pajamas). For our team's purposes, we can make updates to the guidelines using Web IDE.

To get started, follow the workflow outlined below and check out our demo with the Product team.

Using Web IDE

1. Open Pajamas and navigate to the page you need to make updates to.
2. Scroll to the bottom of the page and select Open Web IDE.

Pajamas structure

Our Brand Guideline pages are located in the Contents folder and organized accordingly:

1. brand: This folder contains the Brand Guidelines Overview page.
2. brand-design: This contains pages related to design guidelines.
3. brand-logo: This contains pages relating to logo guidelines.
4. static > img > brand: The brand folder is where all media will be stored that links back to the Brand Guidelines.
5. nav.json: This file dictates the structure reflected in the navigation bar on Pajamas.

Creating a new page

1. Right click on the folder where the page will be located. Select New File.
2. Add your file name (this is what will be reflected in the URL path). End with the .md extension to denote a new markdown page.
3. Update the navigation bar with your new page by opening the nav.json file.
4. Follow the navbar configuration to organize your pages. Nesting pages below other pages will create dropdowns in the navigation bar.
   1. title is how you want your name to display on the page.
   2. path is what is reflected in the URL path (this should match the file name of the page you made).

Note: Pajamas uses markdown and the heading styles match the handbook. Add content as you normally would.

Optimizing and uploading media

1. .svg format is ideal because it scales with the page. Optimize your file before uploading by using SVGO.
2. .png or .jpg work well for graphics that contain images. Optimize your graphic before uploading.
3. .gif format is not accepted.
4. Upload all files to static > img > brand folder.
5. Videos can be embedded (either from Vimeo or YouTube).

Adding media

Add media using figures, which connect the visual with a caption. Here is the breakdown of their structure:

1. aria-label= This text can be the same as the fig caption.
2. img class= This formats the image's display size. img-50 scales the width down to 50% of the page. gl-p-5 scales to the full width of the page.
3. src= This correspond's with the image's location. This should match the file name that corresponds with what you’ve uploaded to the static > img > brand folder.
4. alt= This is alternate text that displays in the case that the media does not populate on the page; this should be more descriptive and unique from the aria-label and fig caption.
5. fig caption This is the descriptive text displayed below the graphic.

Pushing your merge request

Smaller commits make collaboration easier.

1. Use conventional commits. The title of your commit can be generic, and the merge request description can be more detailed. Type:feature covers most of the updates our team makes.
   1. type:feature: Effort to deliver new features, feature changes & improvements.
   2. type:maintenance: Up-keeping efforts & catch-up corrective improvements that are not Features nor Bugs.
   3. type:bug: Defects in shipped code and fixes for those defects.
   4. Commit example: feat(BrandMotion): embed samples.
      1. 'feat' indicates the 'type' of commit.
      2. 'BrandMotion' identifies the page the changes were made to.
      3. 'embed samples' describes the update that was made.
2. push your commit to a new branch. Then select create MR.
3. Use the merge request description to add more detail that would be helpful for the reviewer.
4. Assign the merge request to yourself.
5. Add the label that reflects the commit type you made.
6. Select create merge request.
7. Wait for the pipeline to complete, then assign either Jeremy or Taurie as the reviewer.
8. Once the pipeline has passed, check out the review app to preview changes.