Brand Creative Handbook

Welcome to the GitLab Brand Creative 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

1. Brand Review Request

   Need a brand review? Please use this template to request a brand or design review of multiple or single assets.

   • For brand review only - do NOT use this template for requesting new assets or designs.
   • Do NOT use any of the below issues for brand review.

2. Content Design Request

   Please use this issue request template for net new creative or refreshes needed for the following asset types:

   • eBook / Solution Briefs
   • Infographic / Diagrams
   • One-Pager / Two-Pager
   • Quarterly Update of Executive Candidate Info Packet
   • Surveys
   • Whitepaper
   • Other but within the same category of assets

3. Event Asset Request

   Please use this issue template when requesting net new or refreshing any of the following event-related assets:

   • Event Booth
   • Event Signage
   • Event Social Posts
   • Event Swag + Giveaways

4. Illustration + Iconography Requests

   Please use this issue template for any illustration and iconography needs.

5. Presentation Request

   Please use this issue request template for updating existing presentation decks or when requesting design for net new decks.

6. Social Media Request

   Please use this issue template for net new or refreshing organic and/or paid social requests.

7. Swag Request

   This issue request is for general branded swag for the store or TMRG programs. Please use the Event Asset Request, listed above, for event-related swag.

8. General Design Request

   Does your design request not fall within one of the above categories? Please use this issue template to request a new design of multiple or a single asset.

   • Do NOT use this template for brand reviews.

Not sure if you need a brand refresh? Here’s 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

Request Instructions and Tips:

• When submitting your request, please title the request “CREATIVE REQUEST: [Descriptive name]”
• Please complete the issue form to the best of your ability. The more information our team can receive upfront, the quicker we can get started on your request.
• Please note, all requests need a minimum of a two-week turnaround.
• If the deadline for your request is under a two-week window, please ping our Senior Creative Operations Manager via Slack and include a link to your request, the deadline date, and why this is a quick-turn ask.
• When inputting your project deadline, please be mindful of time zone differences. For example, if you’re operating a day ahead of our Brand Design Team (PT / GMT-8 time zone) and need deliverables completed by Tuesday, Feb 20, please select Monday, Feb 19 as your deadline to accommodate for the time difference.
• If you have any questions, comments, or concerns regarding your creative request, please reach out to our Senior Creative Operations Manager.

Brand Video Issue Templates

1. New Brand Video Request

   Please use this issue when requesting a net new video.

2. Upload Video Request

   Please us this issue template when requesting to have a video uploaded to Vimeo, YouTube, or another similar platform.

3. Video Edit Request

   Please use this issue when requesting an update to an existing video or edits to video footage such as adding lower thirds, bumpers or slides to a zoom recording.

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.
• For video specific questions or assistance, please reach out in the #brand_video 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.

Brand extensions vs sub-brands

Brand extensions and sub-brands are both governed by our brand guidelines, but take on additional creative elements that complement the core branding. Brand extensions help distinguish projects and initiatives that directly promote either the company or the product. Sub-brands are used to classify GitLab programs that bring awareness to topics that extend beyond the company and product.

Brand Extension Strategy

Brand extensions are directly aligned with GitLab marketing initiatives and connect back to the company and/or product. Visually, they lean into GitLab core branding, while maintaining their own specific look and feel.

An example of a brand extension is the Partner Leadership Summit. This brand extension builds upon the core branding by incorporating new elements, such as the distinct arrow motif, that make it stand apart from our standard marketing collateral.

Here are the style guides for existing brand extensions:

• GitLab Duo
• Partner Leadership Summit

Sub-branding Strategy

Sub-brands are established for approved initiatives that generate awareness, but don’t explicitly connect back to our product. They typically have their own marketing strategy but can be included in ongoing initiatives as well. Sub-brands embrace the guidelines of the core GitLab brand (visually and tonally), while incorporating unique additional creative elements (i.e. a distinct logo, alternative illustration style, etc.). Sub-brands should reflect GitLab’s core branding and not feel like a complete departure from it.

An example of a sub-brand is Level Up, GitLab’s certification program. While Level Up offers technical training for the product, it has a broader focus on DevOps as a whole, which extends beyond the company and product.

Here are the style guides for existing sub-brands:

• Level Up
• TeamOps

Stock photography

When it comes to our brand, photography is a powerful medium that can better contextualize and humanize the complex stories we tell. Our team has gathered approved images in our photo library that are ready-to-use. If you need images beyond what are in that library (this will be common until the library becomes larger over time), the Brand Design team has a license to download unlimited images from Adobe Stock (Note: Premium images are not included in our license).

Review our photography guidelines before searching for new images. For approval, download, and questions, contact our team in Slack or the relevant issue.

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.

Canva best practices

Canva enables team members to self-service their design needs and create on-brand assets. Canva is a great tool for items that need a quick-turnaround or that have ever-changing content (like A/B ad testing). Canva supports print and digital designs, as well as video and animation; team members most frequently use it for digital ads and promotional items. For larger projects that require greater detail or concepting, we recommend you submit a design request to the Brand Design team instead.

To get started in Canva, please complete the checklist below:

1. Request access to the GitLab Enterprise account.
2. Explore Canva’s help center and YouTube channel for detailed tutorials (their Canva Pro playlist is a good place to start).
3. Read the best practices outlined below.
4. Watch our demo to orient yourself to the GitLab Enterprise account (must be logged into GitLab Unfiltered on YouTube to view).

GitLab Enterprise access

If you regularly create designs in Canva, we ask that you work in the GitLab Enterprise Canva Pro account instead of using a free or personal account. To gain access, please submit an access request issue. Once this is completed, someone from the Brand Design team will grant you access.

We have a limited number of seats available, so we encourage teams to consolidate the number of people on their team who need access. Note: Shared logins are prohibited.

Benefits of working in the GitLab Enterprise account:

• Full-functionality: working within our account gives you access to all of Canva’s Pro features.
• Visibility: having all our assets organized in one account offers greater transparency and iteration.
• Workflow: collaborating is made easy with quick access to our brand assets, templates, and design team approvals.

Extra tips:

• Make sure you are logged in to your GitLab Enterprise account when in Canva, as it is easy to be logged into the wrong one if you have pre-existing logins.
• You can toggle between your designs (Projects) and the team’s designs (GitLab Enterprise) on the left navigation menu.
• Contact the Brand Design team if you need to change your permissions in Canva. Team members who join the account are automatically set to member status, which allows editing and sharing of files.

Files and folders

Folders can contain Canva design files, sub-folders, and assets you upload from your device. Once you create a folder, it will default to your folders under Projects. You must manually share the folder with GitLab Enterprise in order for it to be seen and/or edited by the rest of our organization.

• Select Projects from the navigation menu on the left > Hover over your Folder > Click the three dots > Share > Select the eye icon (view access) or pencil icon (edit access) from the GitLab Enterprise drop down

Designing in Canva

Templates

• Canva has a multitude of its own templates, but it is best to refrain from using these. They require more work to re-design, and they introduce branding that doesn’t follow our guidelines.
• The templates in our GitLab Enterprise account are a great starting point for creating on-brand designs. We have templates in all ad sizes, in addition to other promo and resources.
  • Note: Our templates are located in the Folders tab in the GitLab Enterprise account; this is so we can organize the templates in folders instead of the Templates tab, which lacks that structure.
• If you click on a template file, Use this template is shown in a purple button. Selecting this option will automatically create a copy that you can start designing in.
  • Note: Do not select Edit Original unless you have prior approval from the Brand Design team. This alters the template for everyone.
• Remember to rename your new design, remove any unused pages or instructions in the file, and move it to a relevant folder in the GitLab Enterprise account.

New files

• You can create new designs with custom sizes, move, and rename files.
• File names should be lowercase and use hyphens in place of spaces. Include the file dimensions in the file name. Avoid acronyms.

Pages

• A single Canva file can contain up to 200 pages, which is helpful if you are creating multiple assets that have the same size and are related.
• You can duplicate, delete, and name each page within a Canva file.
• Copy and paste keyboard shortcuts work for duplicating elements from one page to another, or even from one file to another.
• Easily resize your file if you are replicating the design in different dimensions. Resize the elements on your design accordingly, as they get shifted when the file is resized.

Brand kit

• The Styles tab on the left navigation menu will pull up our color palette and font (Inter) from the GitLab brand kit.
• The Logos tab will show our logo, which you can drag and drop into your design.

Typography

• Add text from either the Text or Styles tab; this will automatically populate text boxes for you with Inter and the appropriate font weight. These text boxes will still need to be formatted according to our typography guidelines, though:
  • Left-align all text.
  • Use Inter Semi Bold for headlines and calls-to-action and use Inter Regular for subheads and body copy.
  • Set the line spacing to 1.2 and keep the letter spacing at 0.
  • For call-to-action styling, copy from an existing templates or reference the guidelines.
  • For legibility purposes, keep all text on a solid background.
  • Use either White or Charcoal text for accessibility purposes.

Graphics

• You can search and add graphics from the Elements tab, but please use with discretion. This tab is great for finding basic shapes, lines, and image frames; beyond that, use graphics from the GitLab icon library to keep your design on-brand.
• All elements can be dragged and dropped into your design. Upload branded assets in the Uploads tab. The .png file format with a transparent background works best.
• For most Canva elements, you can adjust the color of the graphic to make sure you’re using GitLab’s color palette. Refer to the color guidelines and use the accent colors sparingly.
• You can also change the line weight of some Canva elements. To keep consistent with our illustration guidelines, a line weight of 1-2 works best.

Photography

• If you need to add photos into your design, it is best to use our approved images from our photo library instead of Canva’s photography shown in the Elements tab.
• Reference our photography guidelines when selecting and placing imagery.
  • You can request for the Brand Design team to source images from Adobe Stock for you, if you need additional options.

Layout and alignment

• Use Canva’s recommended margin spacing for your file; these display as magenta lines when you move elements around in your design.
• Dashed magenta lines will highlight if elements are aligned to one another.
• Items can be locked in place, grouped, aligned, flipped, rotated, scaled, and layered, using the tools in the tool bar.

Exporting

To export your design, select Share in the upper right corner > Download > select your file type > and click Download to have the assets downloaded to your device. From the Share menu, you can also invite others to collaborate in the file with you. Depending on your Canva permissions, you may be able to share the file as a template by selecting Template > Publish Template.

Requesting design approval

Always share your work for review. If you are working from an existing Canva template, you will see the option to request design approval in the top right of the file. If you are creating your own design, you can open a brand review issue and link your file. For expedited requests, please reach out in the #marketing-design channel on Slack with a link to the issue or file.

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. Michelle, the Creative Operations Manager on the team, triages 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.