Skip to content

Type scale exploration > Designer visual validation

Context

We have designed a new system for typography in GitLab. This new system changes the sizing and spacing to ensure visual hierarchy in the UI. This issue is to validate those changes before implementing them.

  1. Impact on reading and way finding - assumed not possible to test #1550 (comment 1359080572)
  2. Visual impact on UI - THIS ISSUE
  3. Markdown author expectations - #1613

Goals

Stress test the type scale by applying it to chosen contexts.

Goals of validation is to understand:

  • If the content hierarchy is clear.
  • If there's a flow to the content with meaningful visual anchors.
  • If the type scale is robust enough to handle any type of content or context we'd like to apply it to.
  • How the type scale would apply to the current UI.

Validation method

Recreate key parts of the UI, using the new type scales. Check for issues, and identify patterns.

Pages reviewed

Reviewed at 1920 and 390 viewport widths at 100% zoom.

List of 20 pages

Working file in Figma →

Outcomes

Following designer validation the following changes have been made to the type scale before implementation:

  • Simplify weight scale to a single value
  • Reduce largest font sizes
  • Use a non-linear scale to maximise the differences between h1–4
  • Create an underlying scale suitable for all UI typeography
Underlying scale Type metrics
image image

*\ naming subject to change

Additionally we were able to identify:

  • many pages without headings
  • many headings not using the existing system
  • supporting evidence for the need of page templates
  • gaps in system for spacing usage guidelines

Archive

There have been many revisions of the scope and goals of this issue.

Expand archive

Original goals

  1. Stress test the type scale by applying it in the following contexts:
    • UI only: Settings page with many form fields and sections
    • UI mixed with Markdown content: Issuable (issue or MR) with description and comments that use different heading levels
    • Markdown content only: README file or wiki page with different heading levels
  2. Run tests with users to ensure that the hierarchy matches expectations and that sections stand out as intended.

Goals of validation is to understand:

  • If the content hierarchy is clear.
  • If there's a flow to the content with meaningful visual anchors.
  • If markdown output matches expectations.
  • If the type scale is robust enough to handle any type of content or context we'd like to apply it to.

Proposed research

My initial assumption was we needed three different studies. It's been suggested we focus our effort in two areas:

  1. the impact on the UI (and by extension the designers who curate it). We could do this all ourselves, or as a collaborative effort with group designers.
  2. expectations of markdown authors.

This is because we don't know how we can research the impact on how people read and view things. It has been assumed not possible, or not feasible.

Validation effort: Creation

This research looks at the following validation goals:

  • If markdown output matches expectations.

Some additional notes from @pedroms:

in this research, I'm particularly interested in understanding if authors use of headings changes between comments and descriptions. This is something I noted in gitlab-org/manage/foundations/team-tasks#204 (comment 1285421570), and my assumption is that:

The hierarchy that content authors create for an object's description is quite different from the hierarchy of a comment. […] Today we treat and style them exactly the same, and that's why users often use a Markdown h2 or h3 as the top-most heading in their comments — because their hierarchy and meaning in the context of the whole issue page is different.”

Method

Show participants images containing raw markdown, and 2 rendered outputs. The original and the new. As participants for feedback, and which matches their expectations. For example:

image

Validation effort: impact on designers / impact on the UI

This research looks at the following validation goals:

  • If the type scale is robust enough to handle any type of content or context we'd like to apply it to.

Method

Recreate key parts of the UI, using the new typescales. Check for issues.

This could be done solely by foundations, or in conjunction with stage group designers.

Pages for review

Working file in Figma →

Decisions following first round of peer review

Decisions

Following the first round of wider feedback we will:

Increase differentiation between h1, h2, h3, and h4 (or optimise for h1–4)

Increase the fluid range to 30px–16px to allow for more size difference between levels.

Range chosen as we don't want to make h1's bigger than revision one, or h4's smaller than paragraph text. Specific values TBD.

Reduce differentiation between h4, h5, and h6 (or optimise for h1–4 continued)

Reduce size differences between lower level headings, increasing the available range for h1–4.

We want all text larger than 12px, leaving 16px–12px possible. We want h6 to be equal or greater than standard body, leaving 16–14px possible.

Semantic h5 or h6 was not found in type scale testing. We assume its safe to reduce how easy it is to differentiate between these using visual cues. Final decision blocked by decisions around differentiation between headings and body copy, and if every heading on the site should use the scale regardless of context.

Abstract out font size scale for use elsewhere

Create a font-size scale for use on all typography in GitLab, not just headings.

Its likely to not be design system consumer facing in its initial form, and should support existing type in the product. It would only be used for scale — context would determine other attributes like weight, colour, or margins.

Each variable would represent two values, a minimum and maximum, to allow fluid applications. For example

Name* Min value Max value
text-scale-500 20px 24px
text-scale-300 14px 14px

* All names and values placeholder to communicate idea

Edited by Dan MH