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.
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.
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:
SEO). These labels need to exist in either the root
GitLab.com group or the
Issues should follow the standard marketing status labels flow labels, with a few additions.
mktg-status::triagethis work is in the pre-planning stage. We're still discussing what to do.
mktg-status::planthis work is in the planning stage. We know what we want to do but don't know how we want to do it yet.
mktg-status::designthis issue needs some prototyping or other UX designs before we know where we're going.
mktg-status::groomedthis issue has been planned and detailed. We know what needs to be done. We can start building it.
mktg-status::wipthis issue is actively being worked on.
mktg-status::blockedsomething is blocking progress on this issue.
mktg-status::reviewenough work has been completed that this is ready for review and approval.
mktg-status::scheduledthis issue cannot be merged until a scheduled date but the work is complete and approved.
Issues with an immovable due-date because of contractual and/or meatspace obligations should apply the
Examples of optional labels include:
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.
This board shows the status of all Brand Design issues labeled with a design priority label.
This board shows the status of all outsourcable issues labeled with 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.
This board shows the status of all mktg-website issues labeled with a design priority label.
This board shows the status of all outsourcable issues labeled mktg-website.
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.
This board shows the status of all mktg-website issues labeled hard-deadline (please refer to the definition on the label).
We use the following criteria to assess issue priority:
Time & Cost
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, 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.
Always gather relevant heatmaps, analytics, metrics, KPI (key performance indicators), etc.
We are in the process of establishing a new toolset for running experiments. Our hybrid suite of tools will include:
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 flags should be implemented in code similarly to the includes system. Example:
/source/experiments/1234-control.html.haml, where experiments is the folder name instead of includes and 1234 is the id number of the associated issue. "Control" refers to the baseline measurement you are testing against.
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.
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 ]
[ TODO : Document ]
[ TODO : Document ]