Style guides: design, normalization and usability

What are Style Books? why are they not used? Some guidelines for creating Style Books for technology and application development departments.

The Technology and Information Systems areas of large companies are aware of the benefits of interface “standardization” in terms of its appearance.

In large technology departments made up of varied and numerous teams, each with its own uses and methodology, normalizing involves a change in work methodology that must be approached from a global and inclusive perspective.

The demand for web interface business applications and their opening to both internal and external users (entranet, internet) and the situation of inconsistency between environments has aroused a special sensitivity for graphic design and standardization.

The first step towards normalization are usually the “Style Books” and the so-called “Usability Manuals”.

What is a Style Guide

It is a document that includes basic regulations and patterns related to the “aspect” of an interface for its application in the development of new “screens” within a specific environment. (content website, new sections, business application environment).

We said “aspect”. From what other perspectives should a “Style Guide” be approached?

Conceptually, the user interface rests on 3 points:

• Meaning (what): is the base of the interface. Collect the content or information on the screen. Texts, form fields, buttons, menus…
• Behavior: deals with the operation of the interface. How it behaves when a user submits a form (validations), clicks on a link…
• Appearance: final appearance of a system: colors, typography, layout of the elements on the screen (layout).

Style Guides generally focus on “Look and Feel”. Points such as design and layout (colors, fonts and pixels), and it barely includes criteria or casuistry to apply in the interface design process (“Meaning”).

Style Guides are not Usability Manuals

The term “Style Guide” is often confused with “Usability Guide” and a design change leads to be defined as a “new usability”. (“We need to adapt the old applications to the new usability” (sic)).

There are people who identify “appearance” and “usability”: this leads to the fact that two applications can be radically opposed in usability, both meeting the guidelines of a “Style Guide”.

Taking a car for example: From a “meaning” perspective, a car is adapted for use by its characteristics (road, family, small, off-road, convertible) and not by its color (“appearance”).

Identifying “usability” and “design” is equivalent to saying:

– “I want a red car.”

– “What do you want it for? Road, mountain, children…”

– “What difference does it make? Let it be red.”

In order for a Style Guide to become a usability manual, it should touch points related to “meaning” offering criteria for, within a defined style, selecting the characteristics that adapt to the final destination of an application (objectives+users+context) .

Recipients of the Style Guides

The “Style Guides” are initially created as large, very attractive documents that illustrate the appearance of the interface of a system.

Its most serious problem is its lack of usability:

They are thought from a design and marketing perspective and do not take into account the needs of their true recipients: *Interface Designers and Programmers*.

A good Style Guide must be efficiently integrated into a programmer’s work process, offering criteria and helping in decision-making in aspects of interface design.

They should not be a burden: they must be accompanied by promotional and training actions and support materials that save the programmer work.

Characteristics of a useful Style Guide

A Style Guide should address the “meaning” perspective of the interface.

• Usable: invite to use. It must be comfortably integrated into a developer’s work process, giving answers to their own situations within the construction of an application’s interface.
• Visual: escape from the text. From experience, a Style Guide is not used, and this probability is drastically reduced when it is text-based leading to outdatedness and abandonment.
• Educational: rich in applicable AND REASONED examples that allow technical staff to develop minimum usability and aesthetic criteria.
• Updated: it must contain useful, current examples and materials for its direct application available through repositories.

Style Guide Problems: Nobody Reads

Experience shows that development teams do not rely on “Style Guides” to carry out their work.

Reasons:

• They are too abstract and simplistic: they are created from areas (marketing, business…) that lack vision of the complexity of the developer’s work, ignoring their daily problems.
• Lack of adaptation to development methods: The developer does not have time to read or assimilate a documentation that, in addition to being voluminous, is alien to him.
• Too much detail: the documentation goes into detail issues (separation pixels between elements, fonts, colors and hexadecimal values) inappropriate for the work of a developer.
• Lack of consistent maintenance: there is no Manual maintenance policy with an integrated vision of the entire development process.
• Lack of support: the Guide is published without promotion, training and support actions. The documentation expires due to non-use, which returns to a situation similar to the starting one.
• They have no real utility: the reuse of solutions (knowledge, components) between the different development teams is not promoted.

Create a Style Guide

Developing a “Style Guide” is a first step towards a cultural change in development methodologies that leads to the adoption of User Centered Design techniques.

A unique team of user interface specialists with a horizontal vision that integrates the set of systems and development processes is necessary to guarantee a consistent application environment.

The tasks of this team are:

• Document: create documentation of a visual nature, composed of essential literature, reasoned examples.
• Train: give introductory talks, short periodic courses with the aim of developing a usability criterion.
• Give support: from the start to the closure of the project, resolving doubts, detecting new needs that may arise and incorporating them into the Guide.
• Pattern detection: identification of patterns that can lead to reusable interface components for use by different development teams.

In order to abstract the design task scheduler, these objects must have embedded visual and aesthetic aspects. They must be made available to programming teams through a single updated repository.

• Research and innovation: having identified reusable patterns and components frees up resources from performing repetitive tasks with little added value for the detection of lines of improvement in the interface, methodology, and development processes. (Adaptation to technical standards, accessibility, improvements, alternative technologies).
• Schedule and carry out tests and tests with users: knowing the appreciation of the users of the incorporated solutions will allow corrections and improvements to be made.