Visual guidelines

Overview

Minimum suported browser width: 1280px.

These guidelines are provided to ensure that the applications we develop are consistent in style and to provide an easy way to update various elements across many apps in a unified way. Frequently-used elements are specified here so that they can always be treated the same across all our products.

This style guide is based on Material Design, a UI metaphor and system developed by Google and utilized across their products. Material Design is also used in various ways and to various degrees by a number of other organizations in mobile and desktop products. By utlizing the extensive Material Design system, we at FastPay are able to adopt and customize standards rather than developing them from scratch, which not only provides greater efficiency, but also positions our products in a vanguard of visual design.

Details are important, because collectively they convey a particular impression of competence and trustworthiness. For example, did you notice the little flash of brand color when you scroll for the rubberband effect at the top and bottom? It's like a fancy pair of socks that only occasionally peeks out. It's only a couple lines of CSS, but it is one of many details that set us apart.

In addition to following the basic standards outlined in Google's Material Design Guidelines, we are utilizing Google's Angular Material library, which provides ready-to-use elements developed according to the Material Design Guidelines. If we need an element not provided here, Angular Material or the Material Design Guidelines should be consulted for a pattern.

Where practical code has been provided here to show how the Angular Material code can be customized to match FastPay's brand and other needs. For more complete information see the CSS file linked to this style guide. The Stylus file is also in the UX Github repository.

If some of the terms are unfamiliar to you, see this helpful glossary of design terms at Design School.

Iconography

Most iconography can be included simply via CSS, using several hundred Material Design icons. The full list of icons available is at Material Design icons. You will notice that in some elements here icons are included separately as SVGs either because they are custom or customized; they are available in the UX Github repository.

Transitions

Transitions and animations are important to helping the user understand changes occuring on a screen. Wherever a change occurs such as adding/deleting, show/hide, change in color or icon, it should be assumed an animation will be utilized. If one has not been specified, please ask. It should never be assumed that a UI change will occur without a transition.

As an example, notice the way this page loads. Go ahead, hit refresh now. Content is hidden until it is ready, and then the page fades in from a branded background. In this way we avoid the jerky loading of some elements and other elements flying around the page and changing shape. Let everything load, then have a graceful fade-in. By including such effects in this style guide it is intended that they be used in the final product. Adobe has a helpful discussion on the importance of functional animation.

Colors

Only the specified colors should be used, always with the exact color, never an approximation. If an additional color is needed, it should be requested and a color will be provided that is compatible with the FastPay brand.

Colors are not to be arbitrarily used. Each is meant to communicate something about its context, function or meaning. For example, the orange color is meant to indicate user action is needed, so it should not be used simply because one feels it might be an attractive aesthetic option.

Typography

Styling of typography has been adapted somewhat from the default styles for Material Design. Generally the default font size has been increased from 14px to 16px, so 1em should equal 16px. Headings, by contrast, have been reduced in size to reduce scrolling.

Please note that in some cases UI text has been rendered in all caps via CSS for various reasons. Text should never be written in ALL CAPS in the code because then if we change the style all the hard-coded caps will have to be found and changed. Where any UI element appears as all caps, that appearance should be governed by CSS applied to regular sentence-case text (text-transform: uppercase). Note also that wherever all caps are used letter-space should be increased.

For text, prefer ems to pixels. The font used is DIN, specificed by the FastPay brand guide. The font stack should be font-family: DIN, Roboto-Regular, Arial, sans-serif;. The other available weights are 'DIN Medium' and 'DIN Bold', and additional styles are 'DIN Italic', 'DIN Medium Italic' and 'DIN Bold Italic'. In general, prefer medium over bold when emphasis is required.

The following CSS will provide the necessary overrides to the Materialize headings.

h1

font-size: 1.5em !important
text-transform uppercase
letter-spacing .05em
font-family $base-font-family-medium
color $base-text-color-grey !important
margin-top 0px
font-weight normal

h2

font-size 1.4em
font-family $base-font-family-medium
font-weight normal

h3

font-size 1em
font-family $base-font-family-medium
text-transform uppercase
letter-spacing .05em
font-weight normal

Small

color $base-text-color-grey

Console

Tile

The tile is used in the Console view. Totals are dynamic; if the user clicks "Fund all" button for available invoices, for example, the total of "Coming up" changes with animation. See animation example. (Edit duration.) Here's another.

Lists

Much of our products consists of lists. Previously we presented this data in a tabular format. The Material Design list is typically designed to handle less information, but the off-the-shelf format provided by Angular Material is adaptable to our needs with a few minor changes. Note the overrides required. Icon assets are in the Github UX repository.

Client invoice list

The client invoice list allows for basic information about the item financed, including type of revenue, status, actions where applicable for imported invoices and the ability to trash an item. Note also in the below examples how tooltips are used; not for everything, only for certain information.

{{invoice.number}}

{{invoice.client}}

{{invoice.advance}}

{{invoice.advanceDate}}

{{invoice.invoiceAmount}} {{invoice.invoiceDate}}

{{invoice.debtor}}

delete

Ops invoice list

Internally we need more information on a list item than the client does, such as the client's name and an ability to see who is assigned the invoice (with hover). This example also shows the batch select function. To see enabled states, change disabled="true" to disabled="false"

Demo: Toggle enabled states

Select all

Fund

Delay until: Status: {{status.name}} Apply

attach_file

delete

Invoice number

Client name

Amount Advanced Jan 1

Amount Invoiced Jan 1

Debtor name

delete

Empty list

If there are no items in a list, the following style is used to indicate that (h2.empty-list.sad).

You have not received any payments yet.

Sometimes it's a good thing that a list is empty (h2.empty-list.happy):

No actions are needed.

In a modal or other similarly constrained space, the icon is not used (h2.empty-list):

No available contracts

List item detail

Show invoice detail Show company detail Show payment detail

Payoneer

×

Paid	Amount
Currency	ISO code
Processed	Date
Foreign exchange fee	Amount
Transaction	Number

Use native Angular Material dialog functionality; the payment detail example is hacked for presentation here. Also close by clicking outside dialog. Payment detail transition needs work.

The invoice detail has a different set width for clients and ops. Note that min-width is used. This keeps an acceptable set width while setting the same number as width produces a narrower set width for some reason. This is something deep inside Angular Material and it's probably best to just live with it!

The company detail is to be used for vendors, clients and debtors. Note that the header is intended to change colors according to status (like the invoice detail):

• Active: $color-fp-action
• Inactive: $base-text-color-grey
• Unregistered: as shown in example
• On hold: $color-client-action

Note also that the company detail does not have a pixel width. Rather than setting a width and then truncating content to fit, this modal is designed to have a flexible width so that information can flow and be easily seen. So please don't set a fixed width!

Did you notice that the payment detail is not centered and does not have a mask like the company detail does? That's because the payment detail has no interactive elements. In general, open a div above/below the element clicked to show information; open a centered modal with a mask if there are actions to be taken in the modal.

Buttons

Primary buttons are always to the right; if a secondary action (i.e., not the primary purpose of the form, such as "Cancel") is included, it is to the left of the primary action. Never use a "Clear all" or "Reset" button.

Call to action button

Do this now

Add class .cta to the primary raised button.

Raised button

Primary

Raised buttons are used in FastPay applications to complete a process or respond to a call to action.

Flat button

Flat

Flat buttons are usually used within elements that already have depth like cards or modals, to initiate/continue a process or as a cancel option.

Button options

Cancel Do it

When a cancel option is presented, the requested/expected action is to the right, the cancel to the left, with both being right-aligned. The cancel button assumes the default text color.

Floating action button

add

For the primary action of an application screen, use the floating action button.

Disabled buttons

Call to Action Raised Flat file_upload

Buttons are disabled until necessary actions have been completed by the user.

Functional links

Show More

For simple actions such as hide/show, a plain text link can be used.

Forms

Many form elements are provided by the Angular Material framework. Here we will deal only with those that require customization or where more than one option is provided.

Do not use asterisks to indicate required fields. We assume all fields are required. If a field is not required, add "(optional)" to the label/placeholder.

Text input field

City Email

Please check your email format and try again.

Please note the method for returning an inline error. Also please use the proper HTML5 input type (text, password, telephone, email, url, number, etc.).

For online validation and messaging, line color remains default until field loses focus. Do not start out a field requiring validation with a red line or message. Try the email input for an example.

Fieldset

Legend

Option 1

Option 2

XL input field

Invoice amount

Use this pattern where the user is entering the amount of an invoice or advance. This should then be the most prominent input in the form and generally at the top, spanning the horizontal space available.

<div class="xl-input">
   <md-input-container>
      <label>Invoice amount</label>
      <input>
   </md-input-container>
</div>

Select

Currency {{currency.code}} Status {{status.name}}

The currency select utilizes an svg flag library via CSS in conjunction with the ng-repeat.

Done switch

Used to indicate completion of a step. User should be able to toggle back to undone state. Note that semantically this is a checkbox.

<label class="done”>
   <input type="checkbox">
   <div class="slider round"></div>
</label>

Progress bar

• Registration
• Application
• Review
• Agreement
• Funding prep

<ul class="progress-bar direct" layout="row" layout-align="space-between center">
   <li class="progress">Registration</li>
   <li class="progress progress-done">Application</li>
   <li>Review</li>
   <li>Agreement</li>
   <li>Funding prep</li>
</ul>


Tables

First name	Last name	Company
Don	Draper	Sterling Cooper
Joan	Harris	Holloway Harris
Michael	Steadman	Michael & Elliott Co.
Darrin	Stephens	McMann & Tate
Larry	Tate	McMann & Tate

Coach marks

Coach marks can be easily marked up as an aside with a class of .coachmark. Position it absolutely. Note that the .coachmark-right-bottom class is given as an example of flipping and positioning the triangle image bubble-corner.svg, which can be used as an example for other positions. Width can vary within reason to fit in the available space, i.e., with a proper measure for the text.

Messaging

Alerts can indicate success, offer a warning or indicate failure. They fade in and remain for five seconds (or X seconds depending on global revisions) and then fade out. Alerts are fixed in position relative to the window position: fixed;, not the page, so they are visible no matter where the user is on the page.

An alert format is used if:

• The result of the action is not immediately visible on the current screen.
• Some additional effect off the current screen needs to be noted.

So, for example, if the user has changed some data and hits the save button, and the edits remain visible, there is no need for a confirmation message.

Success

A success message provides feedback to the user that an action is complete.

You have accomplished something great. Undo

Error

An error message provides feedback to the user that something went wrong — the action failed, but we provide a way to solve the problem.

Sorry, something went wrong. Please try again.

Warning

A warning message provides feedback to the user that a requested action was partially completed but there is some additional consideration.

7 invoices were imported; 3 were not imported. Download a list of files that were not imported.

Progress indicator

For an indeterminate length of time:

[Removed temporarily due to Angular Material bug]

Images

Header background images help to differentiate various FastPay products and applications. Note that all utilize a css screen over the image except the Media payments (vendor) portal.

Funding portal

Operations

FastLane

Underwriting

Collections

Footer

Hey, did you notice the footer has changed? Notice the sliding reveal which also solves the problem of what to do with pages that have little content (throw out the old code that just added blank space to the page!). This implementation will require an extra div to the page (here it has a class of .page-container), so please take note of that as you build out the page structure.

Written content guidelines

Foundations

Primary among the considerations about how copy and microcopy is determined for our products is consistency. For this reason, particular approaches must be implemented for various needs, even if an argument can be validly made for a different approach. We can always switch to a different consistent approach if it becomes apparent it's a better solution, but then changes should be made globally for the sake of consistency.

For example, consider the use of "my" vs. "your." Sometimes a decision may be made that a user's documents be referred to as "My Documents." But what about settings? Aren't they proper to the user? And what about widgets, or password, or favorites? But if we add "my" to every label in the interface, does it contribute anything beyond clutter? In such a case, a clear decision to not use "my" in any case provides a clear direction and avoids such problems.

Another important consideration is walking the line between being too formal or too casual. "Invalid entry" is very formal for the wrong password. Generally using a sentence would make it more personable, but we don't want to go overboard: "Dude, that password sucks." No, probably better is "We don't recognize that password. Please try again." Another example: Using Title Case For Everything Is Very Formal And Stiff. Using sentence case is more approachable, but not too casual.

Clarity is also important in the words we use. The user should have a clear idea of what she is doing. Merely labeling a button "Ok", for example, is not very descriptive of what will happen. You can see people trying to compensate for this sort of affordance sometimes by additional wording like "By clicking the 'Ok' button the following will happen..." That's generally an admission that the interface is unclear.

There are other considerations that form these guidelines, but the above are a good start to keep in mind.

Case

With the exception of the name of a product or page, which is title case, prefer sentence case for headings and UI affordances (e.g., labels).

The title of this page is "FastPay Product Style Guide." Therefore it's in title case, that is, each word is capitalized.

Subsequent headings are always sentence case, that is, only the first word in the heading is capitalized. You may notice an exception for h1 and h3—which are all caps—but that is specified by CSS; the actual text is still sentence case.

All UI instructions, labels and messages are also in sentence case. So for example, we do not say "Get Paid On The 1st Of Each Month." It is rather "Get paid on the 1st of each month." It's not "Enter Search Term," but "Enter search term." You get the idea.

References:

• Are you Team Title Case or Team sentence case?, Sticky Content
• Reader Poll: Big Letters in Headlines or little letters in headlines?, Gawker
• Should we use 'Title Case' or 'Sentence case' for headlines and buttons?, User Experience on Stack Exchange
• Title Case and Sentence Case Capitalization in APA Style, APA Style
• Headings, Butterick's Practical Typography
• Capitalization & punctuation, Google Material Design Guidelines

Tone and voice

Person

Messaging, instructions and labeling should be in the second person, i.e., "you" and "your" rather than "I" and "my."

Consistency is important in the UI, and that includes the person of microcopy. Insertion of first person almost always introduces inconsistency. Consider rewriting to avoid use of "I" or "my." Example: instead of "Forgot my password" use "Forgot password."

References:

• Your vs. My, Designing Social Interfaces
• Your vs. My, Yahoo Design Pattern Library
• Yours vs. Mine, Dustin Curtis
• Language, Google Material Design Guidelines

Hyperlinks

The text of a contextual hyperlink should always indicate the user's desired end. For example, "See the FasyPay web site" rather than "To see the FastPay web site, click here." Never use "click here" for a link.

References:

• Your Links Should Never Say “Click Here”, Smashing Magazine
• The curse of ‘click here’, UX for the Masses
• Writing Hyperlinks: Salient, Descriptive, Start with Keyword, Nielsen Norman Group
• Tips for Better Hyperlink UX, Interaction Design Foundation

Error messages

The purpose of an error message is not to state that there was an error; the purpose is to guide the user to complete the desired action or to make an informed decision on how to proceed.

Therefore, the word error should not be used in an error message. That makes it seem like the user did something wrong, which is probably not the case. Rather, the message should state what happened in a way that is clear to the user and offer a solution with complete sentences rather than fragments.

Adopt an apologetic tone if the error message resulted from the system: unknown error, inability to decipher user input, decision on what file format to allow.

Some examples follow.

• Bad: Request failed due to an error
• Good: Sorry, there was an issue with the import. Please try again.

• Bad: Error: credential failure
• Good: Sorry, we didn't recognize either that username or password. Please check and try again.

• Bad: Invalid input
• Good: The Social Security Number must be nine digits. Please check your entry and try again.

• Bad: Submission failed
• Good: Your email address is required. Please provide it and submit again.

References:

• Should error messages apologize?, User Experience on Stack Exchange
• Avoid Being Embarrassed by Your Error Messages, UX Matters
• Are You Saying “No” When You Could Be Saying “Yes” in Your Web Forms?, UX Magazine
• Handling User Error with Care: Getting Users Back on Track, UX Booth

Button text

Button text should always state the desired action. That action should be specific (e.g., "Upload," "Change password") except in the generic cases below.

Avoid the button labels below.

References:

• Why the ‘Ok’ Button is No Longer Okay, UX Movement
• Simplicity, It’s Complicated, UX Magazine
• Why Your Form Buttons Should Never Say ‘Submit’, UX Movement
• The Grammar of Interactivity, UX Booth

Date formats

In our applications we use relative date formats rather than the dd/mm/yyy format some may expect. The dd/mm/yyyy format was developed to save ink and paper in the days when repeating Jauary 21, 1955, for example, over and over could literally add reams of paper to a document or book. This abbreviation came with a price: it requires decoding in order to understand what date is being representing. Once or twice is not such an issue, but faced with along list and the need to understand what each of thee dates are and how they relate to each other requires significant cognitive effort.

In addition, the dd/mm/yyyy format is country-specific. For example, while in the United States 11/04/2015 means November 4, in other countries such as the UK that same abbreviation would mean April 11. Thus there is added possibility for even more significant error in decoding.

Since computers allow us to dynamically display the date, we are no longer tied to the paper-and-ink conventions of the 20th Century, allowing a clearer indication of time elapsed and its relation to other items on the screen.

Here are examples of how relative dates are used, assuming the date is Monday, January 5, 2015:

References:

• Data formats, Google Material Design Guidelines
• Absolute vs. Relative Timestamps: When to Use Which, UX Movement