[ TODO : Document ]
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:
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.
As the company continues to grow, incoming requests for internal team logos are increasing at a rate that is not scalable for the Brand Design team. We understand the desire for teams within GitLab to have their own identity, but please take into consideration business value before making a request:
[ TODO : Document ]
[ TODO : Document ]
[ TODO : Document ]
[ TODO : Document ]
[ TODO : Document ]
[ TODO : Document ]
[ TODO : Document ]
GitLab's brand has a personality that is reflected in everything we do. It doesn't matter if we are hosting a fancy dinner with fortune 500 CIOs, at a hackathon, or telling our story on about.gitlab.com…across all our communication methods, and all our audiences, GitLab has a personality that shows up in how we communicate.
Our personality is built around four main characteristics.
These four characteristics work together to form a personality that is authentic to GitLab team-members, community, and relatable to our audience. If we were quirky without being human we could come across as eccentric. If we were competent without being humble we could come across as arrogant.
GitLab has a higher purpose. We want to inspire a sense of adventure in those around us so that they join us in contributing to making that mission a reality.
The following guide outlines the set of standards used for all written company communications to ensure consistency in voice, style, and personality, across all of GitLab's public communications.
See the Blog Editorial Style Guide for more.
The tone of voice we use when speaking as GitLab should always be informed by our Content Strategy.
Logos used on the about.gitlab.com site should always be in full color and be used to the specifications provided by the owner of that logo, which can usually be found on the owners website. The trust marks component found throughout the site is the only exception and should use a neutral tone:
Our website uses the Source Sans Pro font family. Headers (h1, h2, etc.) always have a weight of 600 (unless used in special situations like large, custom quotes) and the body text always has a weight of 400. Headers should not be given custom classes, they should be used as tags and tags alone (h1, h2, etc.) and their sizes or weights should not be changed, unless rare circumstances occur. Here are typography tags.
H1: Header Level 1
H2: Header Level 2
H3: Header Level 3
H4: Header Level 4
p: Body text
Buttons are an important facet to any design system. Buttons define a call to action that lead people somewhere else, related to adjacent content. Here are buttons and their classes that should be used throughout the marketing website:
Note: Text within buttons should be concise, containing no more than 4 words, and should not contain bold text. This is to keep things simple, straightforward, and limits confusion as to where the button takes you.
Primary buttons
Primary buttons are solid and should be the default buttons used. Depending on the color scheme of the content, purple or orange solid buttons can be used depending on the background color of the content. These primary buttons should be used on white or lighter gray backgrounds or any background that has a high contrast with the button color. They should also be a %a tag so it can be linked elsewhere and for accessibility. Buttons should also be given the class margin-top20 if the button lacks space between itself and the content above.
Secondary buttons
There will be times when two buttons are needed. This will be in places such as our jobs page, where we have a button to view opportunities and one to view our culture video. In this example, both buttons are solid, but one is considered the primary button (orange), and the other is the secondary button (white). The CSS class for the solid white button is
.btn.cta-btn.btn-white.
This is the proper use of two buttons, both being solid, but different colors based on hierarchy. If the background is white or a lighter color that doesn't contrast well with a white-backgound button, a ghost button should be used as a secondary button, and should match in color to the primary button beside it as shown below:
DO NOT: Do not use these ghost buttons styles as standalone buttons. They have been proven to be less effective than solid buttons in a number of studies. They should only be used as a secondary button, next to a solid primary button that already exists. Here are the classes for the secondary buttons:
To download the GitLab logo (in various formats and file types) check out our Press page.
The GitLab logo consists of two components, the icon (the tanuki) and the wordmark:
GitLab is most commonly represented by the logo, and in some cases, the icon alone. GitLab is rarely represented by the wordmark alone as we'd like to build brand recognition of the icon alone (e.g. the Nike swoosh), and doing so by pairing it with the GitLab wordmark.
Safe space acts as a buffer between the logo or icon and other visual components, including text. this space is the minimum distance needed and is equal to the x-height of the GitLab wordmark:
The x-height also determines the proper spacing between icon and wordmark, as well as, the correct scale of the icon relative to the wordmark:
Here are the recommended minimum sizes at which the logo may be reproduced. For legibility reasons, we ask that you stick to these dimensions:
Logo
Stacked logo
Icon
The tanuki is a very smart animal that works together in a group to achieve a common goal. We feel this symbolism embodies GitLab's mission that everyone can contribute, our values, and our open source stewardship.
The tanuki logo should also not have facial features (eyes, ears, nose…); it is meant to be kept neutral, but it can be accessorized.
Occasionally the old GitLab logo is still in use on partner websites, diagrams or images, and within our own documentation. If you come across our old logo in use, please bring it to our attention by creating an issue in the Marketing issue tracker. Please include a link and screenshot (if possible) in the description of the issue and we will follow-up to get it updated. Thanks for contributing to our brand integrity!
GitLab is a registered trademark of GitLab, Inc. You are welcome to use the GitLab trademark and logo, subject to the terms of the Creative Commons Attribution Non-Commercial ShareAlike 4.0 International License. The most current version of the GitLab logo can be found on our Press page.
Under the Creative Commons license, you may use the GitLab trademark and logo so long as you give attribution to GitLab and provide a link to the license. If you make any changes to the logo, you must state so, along with the attribution, and distribute under the same license.
Your use of the GitLab trademark and logo:
Examples of improper use of the GitLab trademark and logo:
gitlab.company.com or gitlab.citool.io.The GitLab brand uses the Source Sans Pro font family.
While the brand is ever-evolving, the GitLab brand currently consists of six primary colors that are used in a wide array of marketing materials. RGB and CMYK swatch libraries can be found here.
Illustration within the GitLab is represented and directed by our values, from concept to execution. We use illustration as both a communication tool and to visually support our ideas.
Icons are a valuable visual component to the GitLab brand; contributing to the overall visual language and user experience of a webpage, advertisement, or slide deck.
Label icons
Label icons are intended to support usability and interaction. These are found in interactive elements of the website such as navigation and toggles.
Content icons
Content icons are intended to provide visual context and support to content on a webpage; these icons also have a direct correlation to our illustration style with the use of bold outlines and fill colors.
A few examples include our event landing pages and Resources page.
Badges [TODO: Document]
Patterns [TODO: Document]
What Are The SDLC Icons
Each stage of our software development lifecycle is represented visually by an icon, these icons can be used together to represent the full lifecycle or individually to represent the specific stage.
Using the SDLC Icons
The software development lifecycle icons were designed to with a huge amount of information in mind. To make sure everyone is using the icons correctly we have outlined some direction below.
Color
Size
Full Set vs Individual Icons
Print vs Web
[ TODO : Document ]
[ TODO : Merge with the "how to request work" section ]
To work more efficiently as an asynchronous team, everything should begin in an issue or merge request as opposed to Slack or email.
Creating an issue may seem like an added burden, but the long-term benefit of having context around a given piece of work prevents knowledge gaps from occurring. Issue templates exist to make the process of creating issues easier. If you find yourself starting similar issues over and over, look through existing issue templates. If a suitable one does not exist, consider creating one in the appropriate repository.
For more on how to make beautiful templates, check out GitLab's Markdown Guide. To add an emoji in an issue, begin by typing : and the title of the emoji. A list of emoji markup is here.
Remember to always add Related Issues and Epics after you've created your issue so others have context on what issues connect to this work.
general-project-template in a newly-created Corporate Marketing Issue. This template is pre-populated and beautified with emojis and descriptors for common sub-sections such as Background, Details and reach, Goals and key messages, and Due dates, DRI(s) and next steps/to-dos.[ TODO : Document ]
[ TODO : Document ]
[ TODO : Document ]
