Typography plays a special role in user-experience design. It can help provide affordance for interaction, set up guideposts, and, most commonly, display information. The more complex a product is the more refined its typographic system needs to be.
Because we provide a software solution with such a wide variety of options, our use of type needs to be intentional and well thought out.
Our type system relies on a rigid set of 11 typographic styles that can be used in varying ways throughout our product. These styles have been designed to complement their respective fonts while maximizing the potential for visual hierarchy, readability, scannability and cognitive speed. Each style has an intended use-case and has been tested in a variety of environments.
The type scale can be divided into four categories: headings, body copy, meta info, and buttons.
Headings provide a way for users to quickly build a mental model of the content they are presented with. To aid in building this model, designers use six levels of headings throughout the platform. These headings could be loosely equivalent to the H1-H5 HTML tags and the UIAccessibilityTraitHeader on iOS. While Android does not have a semantic or accessible function for headings, “pane titles” can serve a similar purpose.
As the largest of our type styles, Display is used for the most pivotal moments (displaying account balance on the account details screen for example), and should only be used with shorter lines that require the highest emphasis. At 60pt/dp, any content set in Display will quickly run out of space on mobile devices.
Wrapping large blocks of text, especially on mobile devices, can create confusion and hinder usability. To avoid this, limit usage of this style to very short content. Sometimes it may not be possible to limit characters set to Display, so adaptively shrinking the text once the content reaches the limits of its container can prevent usability and readability issues. This is preferable to text wrapping, keeping the content as readable as possible without sacrificing typographic hierarchy. The only time display copy should wrap to a second line is if the adaptive shrinking would otherwise reduce the font size to 16px or below.
The Large Heading style is primarily intended for larger, expanded nav-bars and other wayfinding elements. It is typically too large to blend in with other design elements without attracting too much attention. The Large Heading should be reserved for top-level neighborhood titles. Do not use the Large Heading within the content or flow of an experience — it should always represent the title or location within the app.
Medium Heading is generally small enough to use within content blocks but should be used sparingly — only on content that demands special attention set in a busier view. One great use of Medium Heading is as the account balance size in a list of accounts. This allows the user to read their balances quickly without deteriorating the overall usability of the accounts list.
The Small Heading style is primarily intended for condensed nav-bars and similar wayfinding elements. When using this style, take care to make sure there is appropriate typographic contrast between it and any uses of Subtitle 1 because the two styles are relatively similar in weight and size.
Subtitle 1 is designed to function as a standard minimal heading style. It’s primary use can be found in the account name on the Accounts List view. It can also be used in the side-nav or other icon + text lists because of its economy (as opposed to the heading styles which are too large for this type of function). The style fits nicely with Body 1 because they are the same size, so it can also be used anywhere Body 1 copy needs lower-level section headings.
Subtitle 2 is a subtle style for any content demanding less attention than Subtitle 1 while needing more emphasis than a Body style. Subtitle 2 fits nicely with Body 2 because they are the same size. It can also be used anywhere Body 2 copy needs lower-level section headings.
Body copy is the main copy that users will take the time to consume and understand (while headings are generally scanned).
Body 1 is our primary type style. It has been designed to maximize readability and is the root of our system — all other styles have been scaled to complement it. It can be used for list content, tables, long-form content, and more. Generally speaking, this style should be left-aligned (or right-aligned if in a table). Only center-align Body 1 if the content is less than 3 lines. Body 1 copy can be bolded or italicized as needed. Take care when bolding the style so that it does not cause confusion with any nearby Subtitle 1 content.
Body 2 is a secondary body style intended for content that demands more economical type-setting but still requires high levels of readability. Generally speaking, this style should be left-aligned (or right-aligned if representing currency in a table). Only center-align Body 2 if the content is less than 3 lines. Body 2 copy can be bolded or italicized as needed. Take care when bolding the style so that it does not cause confusion with any nearby Subtitle 2 content.
Meta information provides insights about other content nearby. While meta info can live alone on the screen, in most cases it needs to be paired closely with another block of copy (body or heading) or a visual grouping of content.
Caption style is best used for content that requires little visual emphasis. The most common example of this would be the account number in the accounts list view. The style also functions well for longer form content that is less useful to the user (disclaimers within a view, for example). Because the style is set in such a small font size it doesn’t need to be italicized for long-form content, though it may be italicized when necessary.
Overline is our only all-caps style. Set at a very small size, this style is best used as supportive text for visual groupings of content. Whenever you think a sentence-cased variant of Overline would work well, try Caption instead. The character spacing in the Overline style is too large for sentence casing so the capitalization should not be adjusted.
The Button style should only be used for actionable elements that utilize a traditional CTA-style button. All button copy should be sentence-cased and use human language that gives the user a clear understanding of the action they will perform if they click or tap the button. This style should always be centered within the button and fit on one line.
The Alkami Platform aims to provide a familiar experience for the user while also providing branding options for clients. To accomplish this, we use two different approaches to the use of font families: Platform Fonts, and Branded Fonts.
Platform fonts utilize the system font of the user's device for all non-themed type treatments. For iOS and Mac users the system font is San Francisco Pro (SF Pro). For Windows users the system font is Segoe UI. For Android users, the system font is Product Sans — however this font is not yet available for anyone other than Google. Until Product Sans is available for 3rd party developers (like Alkami), we use Roboto as the system font on Android.
Please note: All design deliverables will be using SF Pro, but the expectation is that code-driven experiences will dynamically display the matching font family for the user’s device.
Branded fonts utilize a curated list of Google Fonts and can be selected within Theme Builder. At the moment custom typography libraries like Adobe Typekit or specialized, licensed fonts cannot be used without custom dev projects. In the future we have plans to open up selections from Google Fonts and other libraries, but at the moment the following font families can be utilized: Open Sans, Barlow Semi Condensed, Ubuntu, Roboto, Nunito Sans, IBM Plex Serif, Montserrat, Oswald, Roboto Slab, Lato, Raleway, Spectral, Nunito, Roboto Condensed, and Merriweather.
Branded font families are limited to the following levels of type within the type scale: Display, Large Heading, Medium Heading, Small Heading, and Button.
The following specs provide details around font family, font size, letter spacing, font weight and line height. Pixel values are used as a generic/relative size unit, and should be converted to the appropriate platform size units (Android = sp, iOS = pt).
Note: Defaults for font family should be the system font (SF Pro, Segoe UI, or Roboto). Defaults for font weight are represented in parenthesis.