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

Brand and Digital Design Handbook

About Marketing Brand and Digital

We build deliverables and experiences in both digital and physical realms such as the 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.

How we work

Working with issues, groups, and labels

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 group. For more information on this works, please see How it all fits together.

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


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


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


This board shows the status of all mktg-website issues filed using the website bug template.


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


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


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


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

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


We use the following criteria to assess issue priority:





Time & Cost


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


[ TODO : list tools, descriptions, uses, reasons ]


This section is related to A/B and multivariate testing on the marketing website, 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.


[ TODO : Document ]

Best practices

[ TODO : Document ]

[ TODO : Document ]