Design System Sprint 5: Managing Typography
A brief introduction: I’m Marcin: a former UX manager and now co-founder and CEO at UXPin — the full stack UX design platform. In this series of posts, I’m reporting on UXPin’s journey of creating our own design system. We started by discussing the reasons to build a design system and subsequently I shared stories from our Design Operations sprints:
- Sprint 1: Building a design inventory
- Sprint 2: Building a unified color palette
- Sprint 3: Managing basic style properties
- Sprint 4: Defining design principles
Today, we’re going to cover one of the last fundamental building blocks of the UXPin design system — our typography.
Typography in need of a Design System
Call me old school, but I firmly believe that typography still makes or breaks a digital design. Without great typography, even the most outstanding idea ends up as an unbearable user experience.
If you disagree and think that in this day and age it’s all about the motion and flat visual style, try to remove all the text from your favorite digital product (doesn’t matter whether, it’s a web app, mobile app or desktop software).
To help you visualize how drastic of a change that is, here’s Google Drive stripped of all text.
Can you continue to use this product? Can you perform the main actions? Can you find the necessary information?
Of course not.
Without text, there’s hardly anything substantial left in the interface. Your favorite app quickly becomes unusable.
But it’s not only the mere presence of interface text that plays a decisive role. Numerous different properties of text (size, color, line height, x-height, weight…) are crucial to the readability, usability, and the overall look and feel of a digital product.
If you change the Roboto typeface to Comic Sans in the Google Drive interface, you end up with a playful and non-serious experience in place of a plain business UI. If you decrease the line-height of a block of a text, consumption of content might become extremely hard, if not impossible. Make the text too small or too large and it’s going to completely change the experience as well.
Typography truly hangs on all the tiny details.
On top of that, the relationship between text elements and their hierarchy defines the information architecture for digital products.
The bottom line: every text style property is crucial to the overall experience of users and needs to be carefully managed.
Because great typography requires so many details to go exactly right, its long term maintenance becomes extremely difficult. Checking all the style parameters every single time is a tedious task, so designers frequently (I’m guilty as charged!), either eyeball text properties from the past projects, or make completely new design decisions that fit the context of their current work. Either way, the overall experience is becoming less and less cohesive with every project. The gradual increase in entropy makes your product less understandable and predictable for the user and harder to maintain for the team. We actually discussed this problem in detail in the first article of the series.
So how can we manage typography consistently? With a carefully managed design system, of course!
Different Approaches to Typography in a Design System
Nearly every design system we analyzed has a section devoted to typographic styles.
The way this part of a design system is being structured though differs a lot from system to system.
Some design systems have a comprehensive explanation of every single typographic detail, while also providing a flexible framework for different design projects. Sounds confusing? Here’s an example: IBM Carbon uses a normalized major second type scale (font size in pixels gets multiplied by 1.125) that defines 19 different, yet visually balanced, font sizes.
Carbon also defines rules for using different font weights and provides tools to calculate line-height (1.5x font size for standard text and 1.25x for headlines).
This approach provides a true typographic decision making framework for IBM designers and gives them a lot to chose from.
Flexibility comes at price though. There are no easy typographic choices in the Carbon Design System. We have to also remember that different sizes of headings may represent the same level of importance in different parts of IBM, so there’s a higher risk of an inconsistent interface and confusing information architecture (versus a design system with a more limited typographic scale). With great power comes great responsibility.
To address this issue, other systems use a more strict framework.
For example, Salesforce Lightning, defines 4 different heading styles and 2 body styles. A strong contrast with 19 different sizes defined in IBM Carbon!
Limited choice makes typographic design decisions easier and helps with building a consistent user experience. If in a project there’s a need for a strong, primary, headline then ‘heading large’ is the only option. While definitely constraining for a designer’s creativity, this approach is more bulletproof for consistency. The downside is the lack of flexibility. If designer wishes to make a headline really prominent, she will have to play with other design elements rather than a font size.
Is one of these approaches better than the other? No. Both come with certain limitations and might be great for different kinds of teams and products.
The IBM Carbon-like typographic system might better serve really big teams working on a variety of different products and experiences (including marketing landing pages), while Salesforce Lightning will better fit products and experiences where consistency is more important than visual robustness (most likely not marketing landing pages).
Unique Challenges at UXPin
After analyzing different approaches to typography in design systems, we had to decide how to standardize it in our own system. Quite the challenge. At first, we’ve definitely felt lost in the weeds of this massive undertaking. So many choices!
To make this task easier, together with the Design Operations team, we listed our goals for the typography section of our Design System:
- Building and distributing the typographic standard consistent with the newest part of UXPin (design editor), that details:
- Font-family
- Sizes of all the headlines and body text
- Line-height
- Font weights
- Basic text color
2. Providing a typographic scale universal enough to serve all the parts of our product.
3. Improving access to the typographic standard in the design system through:
- Cleaning up text related Less mixins and variables
- Distributing standard text styles to design tools used in our design process
As you can see, we aimed to build a typographic system and distribute it conveniently among our designers and developers. We also didn’t want to break the newest part of UXPin, which we decided to treat as a gold standard.
Listing these goals gave us so much clarity and confidence that we just went straight ahead to the next step — analyzing what we have.
Fortunately that part of the challenge was fairly easy. During the inventorization of our interface (you can read more about it here) I formed simple typography scales based on what we actually have in the system. Creation of these scales was really easy — I simply used inspector from Chrome Developer tools, traversed the code on production servers and listed all the text styles .
By looking at this typography inventory, we realized we can’t build the scale based on our HTML markup. H1 in the editor and on the dashboard might look completely different and this is fine. Markup semantics must make sense within the context of a given ‘page’, but they don’t really need to comply with the entirety of the system.
We needed to build our typographic scale independent of fixed markup tags. To do so, we had to come up with Less Mixins (to clarify: our team uses Less, but it could be any other CSS preprocessor) that will generate the right styling for any piece of markup.
Before we built anything though, we had to find one scale that actually makes sense for all the parts of the product. Looking at the differences between the UXPin editor and dashboard certainly didn’t make us optimistic about this endeavour. But at least the base text size was consistent. We knew that whatever we needed to create would use 14px Proxima Nova as a foundation.
One Scale to Rule them All
Inspired by IBM Carbon, we started to play with the concept of building a new scale based on one of the harmonious scales (perfect fourth, major third — here’s a great tool to play with: http://type-scale.com/). It would have to be really close to what we have in the product, with maybe couple of extra steps defined for the future.
Unfortunately nothing fit naturally into what we already had in the interface. Any dramatic change would likely mean that our graphic designers would rebel against design operations and that would be…unproductive, to say the least. Readjusting typography in such an enterprise product like UXPin would take weeks of work and probably wouldn’t significantly improve the experience of our users. All in all, not a job worth doing at the current stage of our design system.
After this early failure, we decided to take a less idealistic approach:
- Organize what we have in a consistent scale
- Eliminate unnecessary styles
- Name every step in a scale in a clear and concise manner.
The results were much better.
This simple scale covers 100% of the UXPin interface. The benefits of setting it as a standard, at least to us, were very clear:
- It’s an immediate reference point for designers;
- It improves code by using right mixins everywhere;
- It doesn’t significantly or unpredictably change the UI of the app;
So, unlike our unified palette, which drastically reduced the colors used in UXPin, the unified typographic scale solidified the standard we already had in place.
It’s truly a great start for our system. With future corrections of some of the patterns, we might further refine it.
Code Solution
Once we formed our scale, we had to take care of the actual delivery of it to the designers and developers. We started with two simple steps:
- We’ve defined the key properties as variables in our Less files:
- Font sizes. Example:
@font-size-base: 14px;
@font-size-headline-1: 30px;- Line heights. Example:
@line-height-base: 18px;
@line-height-headline-1: 36px;- Colors. Example:
@text-color-base: @gray-base;
@text-color-headline: @gray-base;2. We’ve prepared Less mixins generating the right styles for every step in our typographic scale. For example:
.text-base(@color: @text-color-base, @size: @font-size-base, @line-height: @line-height-base) {
color: @color;
font-size: @size;
line-height: @lineHeight;
}.headline-1(@color: @blue-base, @size: @font-size-headline-1, @line-height: @line-height-headline-1) {
color: @color;
font-size: @size;
line-height: @lineHeight;
font-weight: 300;
}
These little Less tools are approved by our web-developers and already make their jobs much easier.
The Design Solution
Delivering these styles to designers was really easy as well.
First of all, we ended our process of defining the typographic scale with shared documentation. While it’s not exactly actionable and doesn’t live in a design tool, at least it served as an early reference point for the team.
To make it really useful and adoptable, we had to deliver it right to their tools. Our design uses primarily UXPin (surprise!) and Sketch. Both tools make it possible to save text style. An added benefit of UXPin is that all the text styles are clearly visible in the design system library and are shared across the entire account.
Once we had the typographic scale ready, we simply added it to the library and our team got access immediately. This is how using it looks in practice:
Putting it all together
Good typography consists of many details. Its complexity can easily lead to inconsistency in the interface. Managing it with a design system seems like a massive task, but can really be brought to something practical and fairly easy to implement.
Through out of Design System journey on various different occasions we’ve noticed that being practical brings much better results than being idealistic. Setting up our typography standard was no different.
Are you looking for all the articles in this series? Here they are:
- Design Systems Sprint 0: The Silver Bullet of Product Development.
- Design Systems Sprint 1: The Interface Inventory
- Design System Sprint 2: One Color Palette to Rule them All
- Design System Sprint 3: Managing the Basics
- Design System Sprint 4: Design Principles
- Design System Sprint 5: Managing Typography
- Design System Sprint 6: The Fastest Icons on Earth
And you’re into more in-depth thoughts on Design Systems:
