To frame this post, I’d like to share a tweet by Irina Bednova:
Apparently everyone in our team interpreted "lgtm" in Github reviews differently. The interpretation were:— Irina Bednova (@jafrog) February 1, 2019
- Lets get this merged
- Looks good to me
This is one of those situations where everyone assumed their way of doing things is the way everyone does things.
The websites I work on have a lot of text content. Because of this, it is very common for a component to be placed after a paragraph.
Components tend to have a discrete outermost border. This makes it easy to understand the component’s boundaries.
Text is a little different.
When you place text on an artboard in design tooling, it provides four different “bottom edges” you can measure from:
In typography, the baseline is an invisible line that glyphs sit on. There’s a little more nuance to this, but this is a post about measurement, not typographic nitty-gritty.
A descender is the part of a glyph that descends past the baseline. Letters like j, p, and q are all good examples of glyphs that utilize them.
3. Em height
4. Bounding box
A bounding box is the outermost bounds of a selection you have made in a design tool. It is typically represented by a thin outline, with squares on the corners to indicate the selected content can be resized.
At first blush, each one of these properties hypothetically makes a good origin point to start measuring from. However, there’s some nuance to consider:
A baseline is a common thread that passes through an entire font. It is also invisible. If a design tool does not support highlighting the baseline (both Sketch and Figma do), it can be difficult to discover.
The bottommost point of a descender is easy to see visually, but descender length isn’t always uniform.
In addition, the bottommost point of many descenders’ overshoot doesn't always cleanly align to the pixel grid:
Em height is also invisible, and therefore has the same issue as the baseline.
Em height is also variable between different fonts—there is no one “standard” proportion everyone must observe. This is by design and is due to each font’s aesthetic and functional needs.
This can get weird when multiple typefaces and font sizes are used, but a stakeholder expects a set pixel difference between visible between components as opposed to a proportionate scale value. There are some efforts underway to address this, but it's still a long ways off.
In most design tools, adding text to an artboard creates an editable object whose bounding box height is the same size as the font’s em height.
You can also manually adjust the height of a bounding box to be longer or shorter than the set text length. This is commonly done to express the minimum or maximum amount of content something can receive.
Because of this, a bounding box’s size isn’t necessarily reflective of the content’s em height.
Smashing them all together
In our organization there are designers we know and speak with. There are also an unknown number of unknown designers outside our organization who consume our design systems.
The real issue is these websites are worked on by multiple people, and each person assumes the way they’re doing it is the way everyone else is doing it.
This creates a ton of variance in the distances between things, which creates divergence. This spacing divergence immediately becomes design debt.
There is also the assumption that each person uses one way to measure distance consistently in both a single design file and every single file they have, or will work on, which may not always be true.
A downstream effect is the developers who reference these design files may take one of a few approaches. Developers may:
- Design system guidance (provided it is written), or
- Staging or production instances that look similar.
- Measure from the bottommost baseline, descender, em height box, or bounding box and use the:
- Measured pixel value (ew, no),
- Closest approximate spacing abstraction, or
- Previously measured value from a similar design.
- Ask their peers what to do, creating an unknown amount of de-facto standards.
Much like designers, there is also the assumption a developer will use the same measuring method consistently on the project, as well as projects they’ll work on in the future.
We also have a similar organizational situation for developers as we do designers. There are the developers we're aware of, as well as an unknown number of unknown developers outside our organization who consume our design systems.
What does this create and what can you do about it?
This is a great example of design tooling’s limitations around expression of intent.
The measured distance is an expression, and a lack of codification about one of the distance’s origin points manifests system-wide uncertainty. This uncertainty is distributed design and development debt that is extremely difficult to rectify.
You can (and should) collectively decide on a standard and document it, but documentation is only as good as people who read and practice it.
So what can we do about this?
I’m honestly not sure. Good onboarding practices, design system governance, design and code reviews, and scheduled design debt work can all help, but they’re all reactive.
If you know of good practices in this space, please let me know.
So, what do you measure from?