Gitlab hero border pattern left svg Gitlab hero border pattern right svg

Brand and Digital Design Handbook

Brand & Digital Department

Note: This handbook is currently WIP - estimated to be final by April 1, 2020


Mission

We build deliverables and experiences in both digital and physical realms such as the about.gitlab.com website, brand collateral, and more.

We assist with conversion design, growth marketing, user experience (UX), search-engine optimization (SEO), and performance metrics to build the logged out experience. We're involved with related marketing campaigns, events, lead-generation, and more. We guide the brand design and experience to assist with creating a cohesive identity.

Lean Design

Metrics & Measures

[ TODO : Document ]

Value-Focused

Objectives

[ TODO : Document ]

Design is Good Business

[ TODO : Document ] t

Co-Design

Inclusive

[ TODO : Document ]


Workflow

Prioritize

Value-focused

[ TODO : Document ]

Metrics

[ TODO : Document ]

Periscope Dashboards

[ TODO : Document ]

MVC

Product Performance Indicators

[ TODO : Document ]

Function Team Grooming

[ TODO : Document ]

Digital Board

[ TODO : Document ]

Iterative Co-Design

Design Systems

[ TODO : Document ]

We've broken out the GitLab interface into a set of atomic pieces to form our design system, Pajamas. Pajamas includes information such as our principles, components, usage guidelines, research methodologies, and more.

GitLab Product UX Guide

The goal of this guide is to provide written standards, principles and in-depth information to design beautiful and effective GitLab features. This is a living document and will be updated and expanded as we iterate.

Feedback & Validation

AB Testing

[ TODO : Document ] —

Contribute

Submit Early

Please submit your request early to allow for our team to plan accordingly. The earlier the better.

Website

Prioritization

We use the following criteria to assess issue priority:

Common

Critical

Differentiator

Reusable

Time & Cost

Deadlines

Issue Templates

In general issues, labels, boards, and milestones can all be created in either a project or a group. Epics can only exist in a group. Because the website exists as a project at the top level, labels and boards for our team should usually be created in the root gitlab.com group. For more information on this works, please see How it all fits together.

This is a temporary listing of templates for filing about.gitlab.com related website issues. These templates are likely to change soon.

These are sorted by frequency of use with most frequently requested items at the top.

*What is the difference between a redesign and an update? An update is a simple "update this information". A redesign is a complete change of look and feel, layout, etc.

Labels

At a minimum, website related issues should have the label mktg-website applied in order to populate appropriate boards.

They should also have a label for your team and/or subject matter (ex: blog, Digital Marketing, SEO). These labels need to exist in either the root GitLab.com group or the www-gitlab-com repository.

Issues should follow the standard marketing status labels flow labels, with a few additions.

Issues with an immovable due-date because of contractual and/or meatspace obligations should apply the hard-deadline label.

Examples of optional labels include:

Issue Boards

General

Design Handbook

This board shows the status of all mktg-website issues labeled design-handbook. These are issues relating to team documentation and NOT general issues with the handbook.

Brand Design

Design - Priority

This board shows the status of all Brand Design issues labeled with a design priority label.

Design - Outsource

This board shows the status of all outsourcable issues labeled with design.

Digital Design

Blocked

This board shows all mktg-website website issues with the mktg-status::blocked label.

CMO

This board shows the status of all mktg-website issues labeled mktg-website which have the CMO Attention label.

Debt

This board shows the status of all mktg-website issues labeled technical-debt.

OKR

This board shows the status of all mktg-website issues labeled OKR.

Mktg Web - Priority

This board shows the status of all mktg-website issues labeled with a design priority label.

Marketing Web - Outsource

This board shows the status of all outsourcable issues labeled mktg-website.

Team Dev

This board shows all issues assigned to a member of the marketing website design & delivery teams. It is recommended to filter this by a particular mktg-status:: label such as ::wip or ::groomed.

Hard Deadlines

This board shows the status of all mktg-website issues labeled hard-deadline (please refer to the definition on the label).

Team-subject boards

Digital Design

Brand Design

Issue Grooming Template

This template can be used while grooming an issue to prepare it for production.

# Goals

* Increase X
* Decrease Y
* etc

## Proposed methodology

Based on A  do B to C (url)

* Reason(s) why
* Given constraints

Should change:

* D
* E
* etc

Won't change:

* F
* G
* etc

#### Stakeholders

* Internal or name(s) of stakeholder(s). Recommended to show @ username first then review during (name of meeting. Example: weekly brand+digital team meeting).

#### Deliverables phase 1

- [ ] Obtain before screenshots
- [ ] Measure preexisting page-speed of (subject pagename)
- [ ] Begin (information gathering. Ex: heatmap or analytics dashboard) test for baseline comparison known as the "before"

#### Deliverables phase 2

- [ ] Evaluate heatmap results from the baseline in order to inform data-driven design decisions

#### Deliverables phase 3

Prototype and/or wireframe containing:

- [ ] 1 updated (source pagename) section linking to
- [ ] 1 desktop view of (subject pagename) before event (example: form submit)
- [ ] 1 desktop view of (subject pagename) after event (example: form submit)
- [ ] 1 mobile view
- [ ] Obtain review approval from prototype

#### Deliverables phase 4

- [ ] Build updated pages
- [ ] Measure page-speed improvements of (subject pagename)
- [ ] Obtain review approval from review-app
- [ ] End previous heatmap
- [ ] Release updated pages
- [ ] Review on the production server to validate requirements including regression testing
- [ ] Create new (information gathering. Ex: heatmap or analytics dashboard) known as the "after"

#### Proposed deliverables phase 5

- [ ] Monitor statistics
- [ ] Report results

## Regression Risks

- [ ] Do any gated content forms still work?
- [ ] Does Cookiebot still work in CCR & GDPR?
- [ ] Do Marketo forms still present GDPR & Ukraine required fields?
- [ ] Any other regression risks
- [ ] etc

Tools

Adobe Creative Cloud / Suite

Adobe Creative Cloud is a set of applications and services from Adobe Inc. that gives subscribers access to a collection of software used for graphic design, video editing, web development, photography, along with a set of mobile applications and also some optional cloud services.

Sketch

Create, prototype, collaborate and turn your ideas into incredible products with the definitive platform for digital design.

Mural

MURAL is an Online Virtual Collaboration Space, Easy to Use Specially Designed for Teams. You can Post Stickies, Share Ideas, Brainstorm and Run Product Sprints.

Google Analytics

Google Analytics lets you measure your advertising ROI as well as track your Flash, video, and social networking sites and applications.

Sisense ( previously Periscope )

Sisense for Cloud Data Teams (previously Periscope Data) empowers data teams to quickly connect to cloud data sources, then explore and analyze data in a matter of minutes. Extend cloud investments with the Sisense analytics platform to build, embed, and deploy analytics at scale.

Hotjar

Hotjar is a powerful tool that reveals the online behavior and voice of your users. By combining both Analysis and Feedback tools, Hotjar gives you the ‘big picture’ of how to improve your site's user experience and performance/conversion rates.

Launch Darkly

LaunchDarkly is a Feature Management Platform that serves over 100 billion feature flags daily to help software teams build better software, faster.

Google Optimize

Google Website Optimizer was a free website optimization tool that helped online marketers and webmasters increase visitor conversion rates and overall visitor satisfaction by continually testing different combinations of website content.

Experiments

This section is related to A/B and multivariate testing on the marketing website, about.gitlab.com. It is a work in progress while we assess new testing tools for integration into our toolkit.

Until the toolkit assessment is finalized, please reference digital marketing's testing documentation.

Going forward, we hope newly created issues align with the growth team's testing template.

Before you experiment

Always gather relevant heatmaps, analytics, metrics, KPI (key performance indicators), etc.

Testing Tools

We are in the process of establishing a new toolset for running experiments. Our hybrid suite of tools will include:

Testing via feature flags

This is where we plan to do the bulk of our testing. We can run several of these at the same time. For full-page, partial-page, component, and small changes.

Feature flag best practices

Feature flags should be implemented in code similarly to the includes system. Example:

Testing via CDN

This is an advanced tool meant to test large-scale changes at a systemic level. For now we plan to run only one of these at a time.

Testing via WYSIWYG

This is a rudimentary tool for small-scale changes with few safeguards and important caveats. We can use this for small items like colors and copy but not layout. This is mainly meant as a tool for non-developers.

Brand

Issue Templates

Labels

[ TODO : Document ]

The Design label helps us find and track issues relevant to the Design team. If you create an issue where Design is the primary focus, please use this label.

[ TODO : Document ]


Brand Guidelines

Home

How we work

[ TODO : Document ]

Partnership with third parties

[ TODO : Document ]

Requesting design help

  1. Create an issue in the corresponding project repository.
    1. For tasks pertaining to about.gitlab.com create an issue in the www-gitlab-com project.
    2. For all other marketing related tasks create an issue in the corporate marketing project.
  2. Add all relevant details, goal(s), purpose, resources, and links in the issue description. Also @ mention team members who will be involved.
  3. Set due date (if possible) — please leave at least 2 week lead time in order to generate custom design assets. If you need them sooner, ping @luke in the #marketing-design Slack channel and we will make our best effort to accommodate, but can't promise delivery.
  4. Add the Design and Website Redesign (if applicable) label(s) to your issue.

Project prioritization

Per the Design team's discretion, the prioritization of design projects will be based on the direct impact on Marketing.

To get a better sense of corporate marketing project prioritization, you can view the Design Issue Board.

Design projects within the www-gitlab-com project can be tracked using the Website label. The prioritization of projects for about.gitlab.com can be viewed on the Website Issue Board.

Any design requests that do not fall in line with the goals and objectives of Marketing will be given a lower priority and factored in as time allows.

Team logo request guidelines

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, so we've created these guidelines to help direct your request:

Privacy

[ TODO : Document ]

License

[ TODO : Document ]

What's new

[ TODO : Document ]

Design principles

Generate value

[ TODO : Document ]

Omni-channel experiences

[ TODO : Document ]

Everyone can contribute

[ TODO : Document ]

Grow a community

[ TODO : Document ]

Foundations

Personality

[ TODO : Document ]

Writing style

[ TODO : Document ]

Logos

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 logo

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.

Logo safe space

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:

Logo x-height

Logo safe space

Icon safe space

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:

Stacked logo safe space

Minimum logo size

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

Horizontal logo minimum size

Stacked logo

Stacked logo minimum size

Icon

Icon minimum size

Using other logos

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:

The tanuki logo should also not have facial features (eyes, ears, nose…); it is meant to be kept neutral, but it can be accessorized.

The Tanuki

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.

Brand oversight

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!

Trademark

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:

Typography

The GitLab brand 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

Color

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.

Hex/RGB

GitLab Hex/RGB Colors

Buttons

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.

Primary Button 1
.btn.cta-btn.orange

OR

Primary Button 2
.btn.cta-btn.purple

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:

Secondary Button 1
.btn.cta-btn.ghost-orange
Secondary Button 2
.btn.cta-btn.ghost-purple

Illustration

Illustration library

[ TODO : Document ]

Iconography

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. The GitLab iconography currently consists of "label icons" and "content icons", each are explained in further detail below:

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.

Label icons example

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.

Icon library

Icon pattern

Social media

Photography

Photo library

[ TODO : Document ]

Brand resources

Templates

Issue templates

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.

Presentation kits

Event kits

[ TODO : Document ]

Swag kit

[ TODO : Document ]

[ TODO : Document ]


Teams

Brand

Overview

The Design team has a rather wide reach and plays a big part in almost all marketing efforts. Design touchpoints range from the GitLab website to print collateral, swag, and business cards. This includes, but certainly not limited to:

Web & Digital

Field Design & Branding

Content Design

In the spirit of 'everyone can contribute' (as well as version control and SEO) we prefer webpages over PDFs. We will implement a print.css component to these webpages so that print PDFs can still be utilized for events and in-person meetings without the headache of version control

Team

Contact Us

[ TODO : Document ]

Digital

Overview

[ TODO : Document ]

Team

[ TODO : Document ]

[ TODO : Document ]

Domain Name Process DRI

[ TODO : Document ]

Growth

Overview

[ TODO : Document ]

Team

[ TODO : Document ]

[ TODO : Document ]

Homepage merchandising schedule & other revelant calendars

[ TODO : Document ]