1. You are here:
2. Handbook
3. Marketing
4. Corporate Marketing at GitLab
5. Brand Activation Handbook
6. Brand Design Handbook

On this page

• Overview
  • Purpose
  • Vision
  • Mission
  • Requesting Support
    • Brand & Marketing Design Issue Templates
    • Contacting the team
    • Partnership with third parties
    • Team logo requests
• How we work
  • Team structure
    • Responsibilities
    • Design approvals
  • Team workflow
    • Saving work
    • Using git and terminal
    • Ebooks, whitepapers, and one-pagers
    • Digital ads
    • Events

Brand Design Handbook

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 precieved, 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)
  • 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

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.

Team logo requests

In the past we have accomodated 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.

How we work

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 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.