It is important to be clear about what user interface guidelines are, what they can do, and what they cannot do. User interface guidelines provide a reference for common user interface patterns to ensure that whenever a user sees a particular pattern, they can comprehend exactly how it will work before they attempt to use it. What guidelines will do is ensure that products visually will appear uniform and cohesive while allowing some differentiation appropriate to specfic tasks and usage of the products.
What guideliness cannot do is ensure that a user interface is usable. It is possible to follow the guidelines to the letter and still create a user interface where people are unable to successfully complete tasks. This is because the look and feel provided by following guidelines only covers the visuals, which, while affecting usability, is only one dimension of usability and does nothing to ensure that terminology in use is understandable and that UI elements are laid out in a manner expected by the user to be intuitive. There still needs to be proper analysis of the user's tasks to design the flow of screens and craft the interaction to be intuitive, and investigation into nomenclature familiar to the target users and so forth to ensure the user interface is understandable and usable.
How To Use
First, it is vital to understand the tasks users will carry out with the UI and understand the path they need to take through the UI to complete tasks. It's also important to know the priority of the tasks and the elements of the UI in support of those tasks. This information is what is needed to apply the guidelines in a way that will make complex UIs easier to use, as much as is possible with visual changes alone.
Avoid more than one "Primary" heading per page.
Try to avoid more than two "Secondary" headings per page.
There should never be more than one Primary (or Default) action button per page. (The "Primary" or "Default" action is what will happen if the user loads the page and hits the Enter key without doing anything else.)
By way of example, let's suppose in the Workflow product UI the most primary thing the user will do is take some kind of action, and the second-most thing the user will do is assign team members or reassign tasks to team members. Armed with that information, we can apply the primary heading style to the Actions section and the Secondary heading style to the Team Members area, and apply Tertiary and alternate section styles to remaining areas of the UI, based on relative priority, as seen in this example.
For more background information to help apply visual styles from the guideline to UI, please review this presentation.
Layout
There is a common top header section. The top left navigation is reserved for switching between applications in the Lead To Money suite, and for the main navigation of the current application. The top right is reserved for help contents and profile management of the currently logged in user. The main content area can be subdivided in halves or thirds both horizontally and vertically to accomodate neede panels and display of various content together.
Everything should be laid out on a 5-pixel grid as much as possible. Margins and padding for the page should be 20 pixels, major content areas should be either 10 or 20 pixels to separate sections of text. Margins should 'collapse' between content areas. In other words, avoid having two content areas next to each other with margins resulting in 40 pixels in between them but only 20 pixels around the outside. Margins need to be set so that there is never more than a 20-pixel combined margin around content areas. Content should never be placed in the margin area, it is only to be used for spacing between content sections.
Design Style
All elements are in a flat, borderless style (with some exceptions, e.g. form inputs). Fonts are Helvetica Neue / sans-serif. This is both the state of the art in UI and makes it very easy for applications to appear consistent on multiple target devices and operating systems. There is a detriment that some visual affordances to indicate interaction are compromised with a flat style (3-D makes it obvious what can be pressed, flat requires other ways to distinguish), so opportunities to integrate interaction affordances back in will be identified as the guidelines mature.
The top header section is white, to not pull attention away from the main content/data area of applications. The top left navigation is reserved for switching between applications in the Lead To Money suite, and for the main navigation of the current application. The top right is reserved for help contents and profile management of the currently logged in user. The main content should have a white background and all text by default is a dark gray #636466. Black is reserved only for <H#> headings and <STRONG> elements. Borders and backgrounds behind the default text color should always be lighter, never the same or darker. (Specific colors to use are detailed in the colors section.)
Everything should be laid out on a 5-pixel grid as much as possible. Margins and padding for the page should be 20 pixels, major content areas should be either 10 or 20 pixels to separate sections of text. Margins should 'collapse' between content areas. In other words, avoid having two content areas next to each other with margins resulting in 40 pixels in between them but only 20 pixels around the outside. Margins need to be set so that there is never more than a 20-pixel combined margin around content areas.
Static Content Vs Interactive Content
In mobile, just about everything is interactive. Almost everything can be touched, dragged, swiped, resized. But across devices and platforms, if a decision must be made for the visual style, prefer square corners for static content and round corners for interactive content.
Fonts
Font face is Helvetica Neue. In CSS, the spec including fallback fonts is
Roboto is for Google Android devices and is first because Android at time of writing has larger market share (consider China/Asia). Helvetica Neue is to cover Apple iOS devices. Arial covers Microsoft Windows devices and sans-serif covers everything else.
Font size should start with the browser default, and prefer using relative CSS font sizes to handle setting variations in size. For example, use font-size: smaller; or font-size: larger; only when absolutely necessary to distinguish specific lines of text. Additionally, semantic markup like <strong> rather than <b> should be used. Otherwise, structural markup appropriate for the content (e.g. H1, H2, H3, etc.) should be relied on to provide the size and weight for text.
The color palette is not just a range of colors to be used at will. Each color in the palette was chosen from the mockups where each color has a specific use. The palette was initialized from specific colors found in the Callidus corporate identity and in products of the suite. When two colors are adjacent, e.g. text on a background, it's important that the two colors have sufficient contrast to be perceptible.
Base Palette
Headline #000000
Body text #636466
Background #FFFFFF
Accent #1 #00A8E3
Accent #2 #fee1a9
The base palette is the designer's reference to evaluate the overall look. See the UI Color Palette below for all the specific colors and their usage.
UI Color Palette
Grayscale
Color and Usage
#000000
Example H4
Usage: Heading text with no background color
#47484a
1st level
^
2nd level
^
3rd level
Usage: Mobile main hamburger menu item background, 3rd level
#555557
1st level
^
2nd level
Usage: Mobile main hamburger menu item background, 2nd level
#636466
Example of normal page text
Usage: Default page text color, mobile hamburger menu 1st level background
#919293
Menu item
Menu item
Usage: Mobile main hamburger menu border lines
#bfbfbf
Example borders
Usage: Gridlines and input borders
#d9d9d9
Tertiary grid heading
Row 1
Row 2
Usage: Tertiary grid heading background and mobile menu text color
#e5e5e5
Parent menu item
Child menu item
Child menu item
Usage: iOS in-page menu child menu item background
#ececec
Heading
Row 1
Row 2 (banded)
Usage: Grid banding for even rows only (secondary, tertiary, alternate grids only)
#f3f3f3
Example Subsection Heading and subsection content
Usage: Subsection heading background and subsection content background
#f2f2f2
Empty page margins with page content inside white area.
Usage: Page margins (below the global header and outside of page content)
#FFFFFF
Usage: Global header background, primary page content (widget/section) backgrounds
Usage: Grid banding for even rows only (primary grids only)
#FDB823
Heading
Row 1
Row 2 hovered
Usage: Hover or selected by the user, also warning color (without text on top)
#fee1a9
Heading
Row 1
Row 2 selected, but focus/action is somewhere else
Usage: Selected but not in focus, or selected by the system.
#f5f3f0
Empty page margins with page content inside white area.
Usage: Page margins (below the global header and outside of page content)
Reserved Colors For Traffic Lighting / Status Notification
#ad3a3a
100
Errors
Usage: Traffic lighting with white text only over the color
#d9b500
100
Warnings
Usage: Traffic lighting with white text only over the color
#309030
100
Success
Usage: Traffic lighting with white text only over the color
#ff0000
0%
Usage: Traffic lighting with no text over the color
#FDB823
50%
Usage: Traffic lighting with no text over the color
#00c000
100%
Usage: Traffic lighting with no text over the color
#98C83C
Done.
Usage: Spinner and progress bar final success color
#bde573
100% complete
Usage: Progress bar final success color for sub-component progress
Data Visualization For graphic charts only
Apply the cool series first. Use the warm series only if needed for large number of data series on one visualization. (Do not alternate the cool series on one visualization and the warm series on another visualization.) If there are significant number of data series to be displayed, wrap the series back to the first cool color in the cool series and use hover/highlighting to help the user identify a particular data series. The purple highlight is only to be used for temporal hover or selection of a data series on a visualization. Do not use purple as a fixed color for a data series on any visualization.
Cool Color Series
#1667bd 1
#00a5ef 2
#97b68c 3
#467dc8 4
#56b397 5
#277876 6
#529bbd 7
#8dd9b5 8
#899884 9
Warm Color Series
#88714b 10
#cbc62e 11
#c38746 12
#7eb070 13
#ffc024 14
#6ca58a 15
#888016 16
#8dd9b5 17
#899884 18
Mixed Color Series
#1667bd 1
#00a5ef 2
#88714b 3
#cbc62e 4
#467dc8 5
#97b68c 6
#c38746 7
#7eb070 8
#277876 9
#56b397 10
#ffc024 11
#6ca58a 12
#888016 13
#529bbd 14
#8dd9b5 15
#899884 16
Transitional Colors
#9E57A2 hover select
Examples
Legend
Data series 1
Data series 2
Data series 3
Data series 4
Data series 5
Data series 6
Data series 7
Data series 8
A very even pie chart
Legend
Data series 1
Data series 2
Data series 3
Data series 4
Data series 5
Data series 6
Data series 7
Data series 8
Data series 9
Data series 10
Data series 11
Data series 12
Data series 13
Data series 14
Data series 15
Data series 16
Example of how the color series works with a very dense line chart using the mixed color series. Hover over the line or legend.
Iconography
Iconography should be flat, solid color. It's recommended to start with the Icomoon library. The default Bootstrap icon library is possible as well. (Reference information on the Icomoon web site.) Pay careful attention to file names and only use icons exactly as originally intended by the file names. DO NOT use icons simply because they look like something that might work. If an icon for a feature peculiar to Sales Management cannot be found in the library, based on file name not image, then a custom icon will need to be created with a new, unique visual metaphor for the purpose. AVOID using social media emojis / smileys.
Depending on the context, either 16pt or 32pt are acceptable. Try to avoid 24pt with Icomoon as only multiples of 16 are clear.
The structure of the top banner area is a global Callidus suite bar and a product-level bar. The top-most bar is only global Lead To Money suite elements - the CallidusCloud brand, application switching navigation, options pertaining to the current login and possibly any global suite-level help that might be provided. The top banner is visually white in order to reserve darker/higher contrast for primary use areas of the UI. The second bar will be colored and have the navigation specific to the current product. The second product navigation bar could be hidden into a "hamburger" menu on mobile devices. Any other links or inputs should be avoided in the brand bar, other than perhaps global help for the suite.
Menus are temporal (except for in-page) therefore a dark color is used for hover to get attention. This is the same color used for selection on the default header bar that has no menus. Avoid iconography in menus, other than checkmarks for currently selected options for menu items that are not actions.
Page content needs to be visually prioritized based on frequency of use, or average duration of use per session, or sequence of tasks within a user's workflow. To aid in this, there are primary, secondary, tertiary styles. View an example of all these styles applied.
There should only be one primary section per page. Avoid more than one secondary heading also. There shouldn't be more than 2-3 tertiary headings. Use the alternate heading for any additional sections. The subsection is for callout panels, details, explanations, etc.
Like sections of a page, grids and lists need to be visually prioritized based on frequency of use, or average duration of use per session, or sequence of tasks within a user's workflow. To aid in this, there are primary, secondary, tertiary grid styles.
Usage: for all other tables on a page, or combine with an appropriate heading with buttons below the heading to create tables with a toolbar. See example.
Reserve a row space for toolbar actions and filters. Use text for actions as much as feasible. For very common operations that have a well-known metaphor, an icon button is acceptable. If an action will be used frequently, then it should be a text-based button to make it a larger target, possibly style it as a primary action if that is the case.
Page Heading Used As Grid Heading
Heading
Heading
Heading
Non-banded row
Data cell
Data cell
Banded row
Data cell
Data cell
Non-banded row
Data cell
Data cell
Banded row
Data cell
Data cell
Hover row
Data cell
Data cell
Selected row
Data cell
Data cell
Forms
Inputs and their labels should be lined up on a grid system to make them easier to visually scan and locate a particular field on a page. Inputs should be sized appropriately for the expected value. This further helps visually distinguish specific inputs and avoid errors by users attempting to put the wrong value in the incorrect field simply because all the inputs were the same size. Inputs should be seeded with valid defaults as much as possible so that potentially the user could simply hit submit without having to modify any inputs.
Labels primarily should be oriented above the input they identify to allow for translation text expansion and to maintain a uniform grid pattern, regardless of label length, along the left (or right margin depending on language direction) for easy visual scanning. The rare exception might be a login where there are only 2-3 inputs and whitespace, visual scanning and readability are not at risk. Sufficient whitespace should be used above form labels to ensure the label is only visually associated with the one input it identifies (if there are two inputs equidistant between a label, it can be ambiguous which field the label is identifying).
Button Alignment
This section describes alignment of various buttons in various situations.
Long Page (where buttons would have ended up off-screen)
Buttons pinned top right (always visible), primary far right.
Long Page with Search / Filter This is an exception
This is a different pattern as the buttons here are intended as a toolbar for a page and not a form submit mechanism. Buttons pinned top left (always visible), primary far left. Search / filter always top right.
Dialogs and Mobile
Buttons centered (always visible), primary right. This puts the actions in proper proximity on screen for thumb / hand-held usage.
Input Layout
If a well-known layout pattern for a set inputs is known (e.g. addresses) it should be used.
Required Fields
The 'required' attribute should be set and the word 'Required' should be parenthetically suffixed to the label for the field. If all inputs in a form or page are required, there only needs to be a note to that effect at the start of the form. If only a few inputs are required, those inputs should be marked as required individually. If the majority of the inputs are required with only a few inputs optional, there should be a note at the start of the form that all inputs are required except as noted, and the optional fields marked accordingly.