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.

Google Drive without text becomes completely unusable

Can you continue to use this product? Can you perform the main actions? Can you find the necessary information?

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.

Your choice of a Typeface affects the overall look and feel of the application. Here — Google Drive with a stylish Comic Sans!

On top of that, the relationship between text elements and their hierarchy defines the information architecture for digital products.

Messing with the hierarchy of typography makes UI really confusing

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.

Results of an analysis of 39 publicly available Design Systems

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.

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:

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 .

UXPin Typographic Inventory

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.

An attempt to create a harmonious scale based on Perfect Fourth and Major Third

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.

Realistic typographic scale fits UXPin needs

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:

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.

Documented Scale

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.