The most fundamental way to ensure consistency of user interface across diverse product offerings, implemented using diverse technologies, and developed by diverse groups, is to develop a UI style guide that can guide UI design decisions in every project.

The UI style guide would provide the necessary dictates for the development of UI, such that if those dictates were adhered to, the resulting UI would be consistent across all product offerings and technologies.

2.2.1.1. UI Style Guide Extends General Style Guide

UI consistency can be achieved as an artifact of code reuse by developing and offering standard libraries of UI widgets for different technologies as part of a UI platform to be used in developing various products for those different technologies.

In order to encourage developers to use the standard libraries, a good inducement is if using the standard libraries both meets their criteria and makes development easier upfront while also making maintenance easier over the long term. If developers shy away from using standard libraries, then it indicates a failure in the design of the standard libraries.

One can support consistency by defining standard UI elements upfront.

Definitions should be formalized for all UI elements likely to be needed at some point, including buttons, checkboxes, headings, panels, radio buttons, text inputs, drop lists, tabs, etc. In the absence of detailed definitions for all these elements that cover the different situations in which they will arise, developers will apply their own creativity to get the job done. With enough "creativity" being applied on a case-by-case basis, one will end up with a mishmash of different stylistic treatments.

A perfect example of creativity being applied is when it comes to buttons. How many different stylistic treatments of buttons does one need? How many different sizes can buttons have? How many different states can a button have? How many different colors can a button be? In the case of buttons, try to limit the set of variations and know why they need to exist and have a rules for deciding which of the standard treatments should be used in different situations.

The UI should be consistent with its use of active style (e.g. "Change Settings") vs passive style (e.g. "Settings").

For example, if buttons are to use a "call to action" / verb / action phrase style of language, then this style should be used consistently. There shouldn't be some buttons with labels like "Set Call Forwarding Rules" and other buttons with labels like "Music on Hold". The same principle applies to section headings. Passive language is recommended for section headings, while active language is recommended for buttons and links that perform actions when invoked. To use an example, a section that addresses call forwarding rules can be labeled "Call Forwarding Rules", while a button that may bring up UI for changing the rules can be labeled "Edit Call Forwarding Rules", "Change Call Forwarding Rules", "Set Call Forwarding Rules", etc.

Terms introduced to the user should be used consistently to reinforce their learned understanding of those terms.

For example, if a section is titled "Music On Hold", a button in that section should not be labeled "Set On Hold Music" or "Change Music While Holding". A user should not have to wonder whether "music on hold" means the same as "on hold music" means the same as "audio on hold" means the same as "music while waiting". The user is already overwhelmed enough as it is by terms they may not deal with on a daily basis, so to remove doubts from their minds about what instructions in the UI may be referring to, be religious about using exactly the same term everywhere to refer to the same thing.

Just as it is useful to use terms consistently, it is also useful to established standardized words or phrases with which the user can become familiar.

One should consistently use the same word / phrase for substantially equivalent actions across all products and all parts of products. So, for example, if one is going to have a bunch of different dialogs in the app for modifying different types of settings, settle on a word like "save" for the save button. Don't use "save" in some places and "done" or "submit" or "finished" or "apply" or "set" in other places. In a link alongside settings that might bring up a dialog for editing the settings, don't use "edit" in one place and "modify" or "change" in other places. In places with links for showing more information, don't use "more..." in one place and then "more info..." or "further details..." in other places - settle on a standard phrase for such links. The same applies to "delete" vs "remove".

In general, establish a lexicon of standard phrases, just in the same way one would establish a set of standard visual designs for common controls.

Establish a tone for the organization that can be applied consistently throughout the UI.

There should be an understanding of what the intended tone, such as playful, casual, matter of fact, professional / businesslike, etc. Without formal guidance, the tone of language will be inconsistent across different products. It's possible that a single tone may not be viable if the products or audiences are too diverse, but any variance in tone should be deliberate / by design rather than as an accidental consequence of the changing mix of personalities of different product managers, visual designers, engineers, etc. involved in different products at different times.

The rules of language use in applications should be governed by a formalized language style guide.

Following the language style guide will help to achieve a consistent voice throughout the different applications and different parts of the applications. The language style guide can provide grammatical guidelines, a lexicon of standardized words and phrases, guidelines on tone, etc.

As it applies to compiled applications, the loading of the code and resources is hard to defer as these are typically compiled into the app and the cost of fetching those resources across the network as needed can hurt the user experience.

On the flip side, an application that is built using Web technologies and that is delivered to the user over the network will suffer a generally worse user experience if the entire app and resources needed by all its features are packaged into a single package and sent over the network. For Web apps, whether delivered to desktop, notebook, or mobile devices, resources for features should be packaged and delivered only when needed. In order to improve the performance of progressive loading, the number of HTTP requests should be reduced - ideally down to a single package - this is possible with inlining of images in CSS, and subsequent wrapping of CSS in JavaScript modules and packaging along with all other needed JavaScript modules.

For both native applications as well as apps built using Web technologies, UI should only be constructed for features as those features are invoked.

So, for instance, for UI that might be presented in a tabbed style of interface, UI within tabs or sections that are not yet revealed should not be built until revealed and needed. Therefore, there should not be a reliance upon connection between views - if two or more views reflect information derived from a common source / data model, it should be possible to safely change the information without having all the views already created. Views should be able to latch onto the underlying data at any time and synchronize to reflect the correct state. Once created, however, the app should reuse UI, even if the data source is changed.

Every interactive element should be large enough to accommodate a fingertip, and ideally large enough so that some part of the element remains visible outside the fingertip to reinforce the user's belief that they are touching on the element (i.e. their fingertip is within the boundaries of the element).

Every interactive element that is only large enough to accommodate a fingertip and that doesn't have additional "breathing room" should have sufficient clearance around it to eliminate the possibility of accidentally touching adjacent interactive elements.

If the element is oversized in any axis, then clearance around the element is less critical in that axis. For example, column headers in a table may have sufficient width for comfortable, unambiguous touch, but may need clearance above and below then if they are not tall enough. Buttons that appear inside rows of a data table should be given sufficient clearance if they are sized smaller than is ideal for touch in order to allow the table to show more data.

In order to provide assurance to the user, the touched state for UI components such as buttons should be visually highlighted.

On touch interfaces, the touched state can be highlighted using the same treatment as the mouse down state for non-touch interfaces. Because of the inherent imprecision of touch interfaces, users need as much feedback as possible to indicate exactly what UI action they are about to initiate by releasing their finger from the interface surface. This becomes especially valuable in cases where the UI becomes busier and there is more chance of accidentally activating adjacent / nearby controls.

The interactive elements of the UI should be designed with the mind to the fact that users on touch devices will not have the benefit of mouseover tooltips.

Therefore, interactive elements should be self explanatory. Ideally, all buttons that show icons should also show labels below or alongside the icons, so that their action is clear.

5.1.4.1. Irreversible Effects

To address this trend, it is recommended that frequently accessed UI elements be clustered towards the bottom of an app's UI.

There is simply no reason to force users to endure the constant annoyance of fumbling to reach awkwardly located UI that risks them dropping their device in the process. And the fact that UI has historically been designed with menu controls at the top of an app is not a good enough reason to impose that layout paradigm to newer mobile devices. Users will quickly get used to using controls that are convenient for them to access, even if it appears unusual at first glance. They will appreciate the choice of location over the lifetime use of the application.

To make rows and columns more easily eye-trackable, alternating background colors should be used for rows and columns.

Rows can alternate between white and a light colored background, while columns can alternate between unlightened and lightened. Priority is given to eye-tracking for rows, since columns are wider than rows are high, and eye-tracking is more commonly needed across multiple columns of a row than multiple rows of a column.

A benefit of the alternating background colors approach is that it serves the added purpose of providing a separation between data in different rows and columns and obviates the need for cluttering border lines.

To make is easier to understand the correlation between column data and the column headers, columns headers should remain present / fixed at the top of lists, even as the list data is scrolled.

When using a resource oriented design for a Web application, and where each area of the application is represented by a URI and navigable to (deep linking), it becomes possible to let the user perform a natural language search for an area of the application.

For example, if the user wanted to find the area for configuring a call forwarding feature of the application, the user could type "forwarding", "call forwarding", etc. into a search bar. Among the search results would be a link to the area of the application for configuring the call forwarding feature.

While a native application might not follow a resource oriented design, since the model originated in the Web sphere and doesn't apply as naturally to native apps, it should still be possible to provide some level of feature search capability.

Examples of feature search in native apps can be found in Mac OS, where search from the Help menu lets the user find features as they are exposed through options in the various menus of an application - even deeply nested menu options. Ideally, feature search in native apps would extend beyond just menu option text and would include description meta data for the features exposed through menu options. Furthermore, if an application's features were connected to a search engine, the search results for natural language searches of features could be ranked based upon click-through of users.

With a feature search facility in applications, it becomes theoretically possible to search for features that might only be conditionally reachable.

For example, if the user searched for a call forwarding feature in order to configure call forwarding, but if this feature were only reachable if the user had a particular account level, the user should still see the feature in the search results, be able to link to the feature and see the feature in a disabled state with an explanation as to why it is disabled. This approach could be used to good business effect by providing upsell opportunities to the user when searching for features that would require account upgrades or additional purchases.

All large lists of data should be searchable with a consistent and easy-to-use yet powerful search interface.

10.2.1.1. Parametric Search

10.2.1.2. Simple Search

In addition to the ability to search data presented in tabular form, ideally a search facility would be provided to search complex structured data.

This feature would be most comparable to the kind of system wide search that one can perform in a native operating system, where the search is able to index content stored in multiple formats and editable through multiple different applications. As the data set that an application exposes to the user becomes more complex, with different features / wizards available for manipulating data in different areas, it becomes increasingly hard to find where data is exposed.

10.2.2.1. An Example

The tiny size for UI components should be used very sparingly, because of the difficulty of using them with touch interfaces.

Tiny controls should only be used in situations of very limited display real estate, such as in rows of table data, and care should be taken to abide by the principle of sufficient clearance.

The small size for UI components should be used for subordinate controls that are ancillary.

Examples of ancillary controls would be...

The medium size is the standard size that should be used for UI controls.

The exact height chosen for the medium size should strike the right balance between usability for touch and efficient use of available display real estate.

As with the tiny size for UI components, the large size should be used sparingly.

The intent behind the large size is to allow a user interface to emphasize certain components very strongly - usually CTA type buttons (e.g. "SIGN UP FOR FREE TRIAL"). The large size is to UI components as all-caps is to messaging - too many components using the large size is like yelling at the user and dilutes the impact that the large size has.

If the user is presented with a slideshow of photos with forward and back navigation buttons, those buttons should remain in the exact same position as the user navigates through the slideshow.

If the position of the buttons were to be affected by the different widths of different photos, because it looked more aesthetically pleasing to have the buttons always snugly at the edges of the photos, then this design choice would increase user work, since they would have to locate the constantly changing position of the navigation controls with each new slide. The same navigation principle would apply to navigating through different months of a year in a calendar control. Rather than the navigation buttons being wrapped snugly around the month name (which would constantly change width), the buttons should be in a fixed location.

If the user is presented with a UI to let them select multiple items before taking an action on them, a collection type interface can be provided.

In the collection type interface, it is expected that the user may want to often collect contiguous chunks of items. An example of this would be a dialog UI for a social network app that lets a user select multiple users to send friend invites to. In the collection type interface, items that are selected by the user triggering a selection control (such as a checkbox, or an add button) are immediately moved out of the list and the remaining items are shifted in position so that the selector for the next remaining item is exactly where the user had just clicked or tapped. This means that the most frictionless interaction for the user is to repeatedly "peck" at the same position, thereby increasing the user's productivity and the virality of the application.

In situations where the user is presented with a toggling behavior, the toggler control should remain in the same position.

For example, if the user can click on an arrow icon to expand a collapsed section, then the icon to collapse the section again should be in the same place as the expand icon. That way, the user can easily collapse the section if they see at a glance that it doesn't contain what they are interested in. Contrast this approach to a "more..." link that sits under a section heading which then moves down to beneath the expanded contents of the section in the form of a "less" link, in which case the user has to visually locate the collapse control and move to trigger it in its new location. And because the control was in a new location, the user had to correspond that new control with the expand control, whereas maintaining the same location relates the expand and collapse controls by their identical location.

Content inside collapsed sections is buried enough as it is without training the user to have a negative inclination towards looking inside sections because of the added cost of collapsing the sections again. This same principle applies also to value togglers. Wherever there is a control that lets a user switch between on and off / enabled and disabled states for a setting, this should be provided through a toggler control where the control can be repeatedly toggled in exactly the same position.

Settle on a single meaning for interaction highlights, preferably as an indicator of clickability / touchability.

For instance, don't use interaction highlights in some parts of the UI to indicate clickability and in other parts of the UI merely to highlight the area of the UI (such as a data table row or some layout panel) that the user is engaged with (e.g. mousing over), or establish a discernibly and consistently applied alternative means for calling out a currently focused / working area in the UI.

When fallback / catch all error messaging is provided for an error for which no pretty messaging is provided, the generic error message should be technically correct.

For example, the error messaging should not state that one of a few possible problems occurred if, in fact, none of the stated problems did occur. The error message should not serve as a catch all bucket if the messaging only lists a few of the possible problems in the bucket, making it not truly a catch all bucket, thereby misleading the user and complicating customer support. For instance, if obscure problem D occurred, the catch all messaging should not state "Your action could not be completed because [problem A], [problem B], or [problem C] occurred." The error message could, instead, state that "Your action could not be completed because [problem A], [problem B], or [problem C] occurred, or some other problem was encountered (error code: [error code for problem D])."