Una guida alle linee guida

Lo scorso anno sono stato coinvolto in un progetto di redesign e re-implementazione di una applicazione di internet banking. Il mio ruolo era quello di definire l'interfaccia utente, e dunque buona parte dei miei deliverable erano wireframe.
Personalmente non ho mai amato i software per la creazione di wireframe come balsamiq o axure; sarà la mia natura nerd, ma preferisco scrivere codice che disegnare componenti. Tenuto conto che uno dei requisiti del progetto era che l'applicazione fosse responsive, e che - almeno ai tempi - i software citati non gestivano la cosa se non triplicando il lavoro, ho deciso che i miei wireframe sarebbero stati in html. Ai tempi pensavo di essere molto originale, ma recentemente ho scoperto che è una tendenza che sta prendendo piede: 2015 Subtraction.com Design Tools Survey | The Tools Designers Are Using Today.

Il problema era che il perimetro dell'applicazione contava quasi 130 voci, ovvero più di 250 pagine. Farle in html, a mano, sarebbe stato impensabile. Pertanto, ho deciso di utilizzare un software java che avevo scritto, e che ho via via adattato alla applicazione, la cui funzione è quella di leggere dei dati scritti con un linguaggio di markup (yaml) e generare le pagine html attraverso degli appositi template.

Oltre alla velocità nel creare ed aggiornare le pagine html, il vantaggio maggiore dell'utilizzo del software è stato quello di garantire una forte consistenza interna. Iterazione dopo iterazione, attraverso i template avevo creato delle regole su come le pagine, gli oggetti, le funzioni, gli elementi comuni dovessero funzionare, e queste regole venivano applicate automaticamente, sistematicamente, dal mio programma. Il limite maggiore di questo approccio era che le regole erano del tutto implicite, incarnate nei template, e dunque difficili da comunicare, condividere, validare e testare all'interno del team e con il committente.
Con il senno di poi, mi sono reso conto che un documento che descrivesse queste regole avrebbe facilitato di molto il processo comunicativo con gli altri stakeholder. Un documento di linee guida; o forse una guida di stile.

L'utilità nel riconoscere i propri errori di processo è che questo ci permette di organizzarci in modo che, la prossima volta, saremo più preparati. Finito quel progetto, ho dunque deciso di creare una bozza di documento di guideline che mi possa tornare utile la prossima volta. Nel farlo, però, ho incontrato una serie di difficoltà. Il problema maggiore era che mi sono reso conto che una parte importante delle regole implicitamente implementate nei miei template (e nell'architettura del mio programma) erano ad un livello concettualmente più astratto di quello generalmente rappresentato nelle linee guida che, nel frattempo, avevo consultato. Ai tempi, avevo espresso questa differenza parlando di ux styleguide. Avevo provato a sondare il terreno attraverso un post sul gruppo facebook Usabilità e Architettura dell'Informazione. La discussione che ne uscì fu molto interessante ma, fra le altre cose, mi permise di capire che avevo le idee molto confuse.

Nel frattempo, ho provato a chiarirmi le idee, e ho riformulato la questione in termini linguistici, ridefinendo quella che avevo chiamato ux guideline in termini di una grammatica della user experience (ne parlerò a Better Software 2015, a Firenze, il 17 novembre).

In ogni caso, mi sono studiato l'argomento linee guida, guide di stile, e qui provo a fare una sintesi dell'argomento.

Guideline, style guide, pattern

Da quello che emerge in letteratura, spesso i termini guideline e style guide sono usate in maniera intercambiabile. Questo è giustificato anche dal fatto che alcuni framework sono, contemporaneamente, delle linee guida e delle guide di stile. Basti pensare alle Material design - Google design guidelines. Google le chiama - giustamente - guideline, ma nel documento vengono stabiliti anche dei princìpi di stile. Inoltre, alcuni dei documenti che abbiamo citato nel benchmark sono definiti Human interface guideline.

Una possibile distinzione può basarsi sui livelli di Garrett:

• le guide di stile si riferiscono principalmente al quinto piano, la superfice, ovvero il visual design;
• le Human interface guideline si riferiscono principalmente al quarto piano di Garrett, lo scheletro: information design, interface design, navigation design;
• guide di stile e hig sono tipologie di linee guida.

Le librerie di pattern, infine, si differenziano dalle guide in quanto sono

• meno prescrittive: identificano possibili soluzioni ad un problema in un contesto
• garantiscono principalmente la consistenza esterna: identificano dei pattern nelle soluzioni adottate da altri
• sono generalmente strutturate in base a delle regole di documentazione
  • nome e classificazione del pattern
  • intento: gli scopi e le ragioni per usarlo
  • lo scenario, il contesto dove generalmente si applica
  • l'applicabilità
  • l'implementazione del pattern
  • degli esempi di utilizzo
  • eventuali pattern collegati

Definizioni

Secondo il Merriam-Webster una guideline è una regola o un'istruzione che indica come qualcosa debba essere fatta. Secondo Wiktionary è un principio o una regola non specifica che offre una direzione all'azione o al comportamento; un piano o una spiegazione che guida nello stabilire degli standard o determinare il corso di una azione.

Una guida di stile, secondo Wiktionary, è un insieme di standard per progettare e scrivere documenti, sia per uso generale che per delle pubblicazioni o organizzazioni specifiche, e può definire standard di tipografia, grammatica e sintassi.

Per semplificare, potremmo considerare le guide di stile come delle linee guida specifiche per il visual design e della scrittura dei contenuti.

Le finalità di un documento di linee guida sono molteplici:

• costituisce uno dei documenti di riferimento nella progettazione e nelle iterazioni
• fornisce un linguaggio comune per designer, sviluppatori, project manager, product manager, marketing
• garantisce consistenza dell'interfaccia, del linguaggio, del look and feel all'interno di un ecosistema (crosscanalità)
• agevola lo sviluppo e l'adozione di buone pratiche
• riduce i tempi di progettazione e di sviluppo
• stabilisce uno stile, per migliorare la comunicazione
• dettaglia gli elementi, i moduli, i componenti
• costituisce la base per la valutazione euristica

Benchmark

Dopo aver dato una breve definizione di linee guida e style guide, elencherò una serie di risorse utili.

W3C

I documenti del W3C sono delle linee guida speciali, in quanto costituiscono gli standard del webdesign.
Sono, necessariamente, estremamente generali, e non potrebbe essere altrimenti, visto che la loro applicabilità dev'essere il più possibile universale.

Sebbene le specifiche del W3C siano molto di basso livello, nelle specifiche html5 vi sono degli elementi finalizzati a definire la macro-struttura delle pagine web, gli HTML structural elements - W3C Wiki.

Siti governativi statunitensi

Usability.gov è un sito, curato dal governo statunitense, che pubblica un esteso documento di linee guida (Guidelines | Usability.gov).
Nel documento vengono affrontati numerosi argomenti: il processo di design, l'accessibilità, il layout, la navigazione, gli aspetti grafici, i contenuti, i test di usabilità.
Uno dei punti di forza del documento, oltre alla sua estensione, è la presenza di un indice che stima la Strength of Evidence di ogni linea guida.

Recentemente, inoltre, lo U.S. Digital Service della Casa Bianca ha pubblicato un documento, gli U.S. Web Design Standards. Il documento, pubblicato anche su Github , copre i seguenti argomenti: Visual style, Grid, Buttons, Labels, Tables, Alerts, Accordions, Form controls, Form templates, Search bar, Side navigation, Footers.

Punti di forza, il fatto che, per ogni sezione della guida, vengano citati sia gli aspetti legati all'accessibilità, sia a delle indicazioni per massimizzare l'usabilità.

Esempio

Buttons

Accessibility

• Buttons should display a visible focus state when users tab to them.
• Avoid using
  or tags to create buttons. Screen readers don't automatically know either is an usable button.
• When styling links to look like buttons, remember that screen readers handle links slightly differently than they do buttons. Pressing the Space key triggers a button, but pressing the Enter key triggers a link.

Usability

When to use

• Use buttons for the most important actions you want users to take on your site, such as "download," "sign up," or "log out."
• When to consider something else
• If you want to lead users between pages of a website. Use links instead.
• Less popular or less important actions may be visually styled as links.

Guidance

• Generally, use primary buttons for actions that go to the next step and use secondary buttons for actions that happen on the current page.
• Style the button most users should click in a way that distinguishes from other buttons on the page. Try using the “large button” or the most visually distinct fill color.

Gov.uk

Da alcuni anni il Government Digital Service del Regno Unito sta lavorando ad un processo di standardizzazione dei propri servizi digitali. Fra le risorse disponibili citiamo i design principles, il Government Service Design Manual, i Design patterns,

GOV.UK elements è il documento di style guide di gov.uk.

Esempio

Labels

• all form fields should be given labels
• don't hide labels, unless the surrounding context makes them unnecessary
• labels should be aligned above their fields
• label text should be short, direct and in sentence case
• avoid colons at the end of labels
• labels should be associated with form fields using the for attribute

Anche questa style guide è su Github.

Confederazione Svizzera

Anche la Configurazione Svizzera ha pubblicato delle guide di stile, le Swiss Styleguide, direttamente su Github. Secondo la presentazione

The Confederation Web Guidelines define the design specifications for the presentation of the Swiss Federal Administration on the Internet and are binding for all websites within the domain admin.ch. These guidelines specify how the websites of the Federal authorities have to look and how they should behave. At the same time they give the government departments and public offices the necessary flexibility to be able to optimize their online communications to the requirements of their specific business purposes.

Confesso che non mi entusiasma né il modo in cui le cose sono state organizzate, né lo stile grafico.

Interessante, invece la lista di pagine di esempio, che definiscono una sorta di tassonomia delle tipologie di pagine, a mio avviso molto utili.

Le sezioni principali sono Design principles, Base layout, Navigation modules, Content modules, Example pages.

Esempio

Slideshow

The slideshow uses the jQuery plugin (Blueimp Bootstrap Image Gallery) to display images in fullscreen from the basic carousel. Be sure to add the correct layout before your closing tag, as explained in the example below.

Accessibility issue

The slideshow component is not compliant with accessibility standards. If you need to be compliant, please consider other options for presenting your content.

Apple

Apple ha pubblicato delle Human Interface Guidelines (HIG) sia per OS X che per iOS.

Le OS X Human Interface Guidelines, definiscono le linee guida per progettare per Mac OS X. Le linee guida suggeriscono, fra l'altro: Interaction and Input, Branding, Wording Terminology and Wording.

Windows

Design Universal Windows Platform (UWP) app - Windows app development sono le linee guida per progettare applicazioni per Windows 10. La sezione design basics si divide in:

• UI basics: descrive l'anatomia dell'applicazione, e alcuni pattern
• Navigation design basics dedicate alla navigazione
• Command design basics: gli elementi che permettono all'utente di portare a termine delle azioni
• Content design basics: i contenuti dell'applicazione.

<!--- There are three main content scenarios:

• Consumption: A primarily one-way experience where content is consumed. It includes tasks like reading, listening to music, watching videos, and photo and image viewing.
• Creation: A primarily one-way experience where the focus is creating new content. It can be broken down into making things from scratch, like shooting a photo or video, creating a new image in a painting app, or opening a fresh document.
• Interactive: A two-way content experience that includes consuming, creating, and revising content. -->
• Responsive design

Le Guidelines for Universal Windows Platform invece elencano una serie di linee guida più specifiche. Fra gli argomenti trattati: Animations, App settings and data, Controls and patterns, Custom user interactions, Files, data, and connectivity, Globalization and localization, Help and instructions, Identity and security, Launch, suspend, and resume, Layout and scaling, Maps and location, Text and input, Tiles and notifications.

Esempio

Guidelines for filtering and sorting - Windows app development

Filter

A filter command hides content within a list based on some criteria. For example, you might want to view store apps based on "Best rated."

When to enable filters: Any list that contains more than few items can benefit from filtering. Lists that are large enough to require scrolling benefit the most.

Recommendations

• Be sure to inform the user whenever a filter is active. Otherwise, the user might not realize that there some items are being hidden.
• Always provide an easy way to clear the filter. Typical users will want to try a variety of filtering options; providing an easy mechanism for clearing the filter encourages the user to experiment.
• Make it obvious when filtering options are exclusive or additive, so that users know what behavior to expect.

Google Material Design

Material design sono delle design guidelines pubblicate da Google, che le intende come un linguaggio visivo che sintetizza i princìpi classici del buon design con l'innovazione e la tecnologia. Fra gli scopi del linguaggio, creare una esperienza coerente fra le diverse piattaforme.

TODO: esempio

Esempi di linee guida

Sono molte anche le aziende che pubblicano le proprie guide di stile. Ne elenchiamo qualcuna.

Lonely Planet

Lonely Planet ha pubblicato Rizzo; anche in questo caso il codice è su Github. Nel progettare Rizzo, i designer volevano creare una styleguide facile da mantenere.

La guidelyne distingue fra Design elememts (colori, tipografia, icone) e UI Components (una lunga lista di componenti: cards, alerts, badges, tiles e così via).

MailChimp

MailChimp ha pubblicato una Pattern Library. L'approccio sottostante lo sviluppo della libreria è descritto in un post in cui si introduce il concetto di Systemic Design.

Nella libreria vengono definiti Grid System, Typography, Form Elements, Navigation, Tables, Lists, Slats, Stats/Data, Feedback, Dialogs

Altri esempi

Ubuntu Design

Lightning Design System è un framework di Salesforce. Nelle loro linee guida, distinguono fra design, components e voice and tone.

Code for America Style Guide

Yelp Styleguide

Pattern Library | DoSomething.org

Risorse utili

Website Style Guide Resources è un elenco di risorse sulle style guide

Atomic Design | Brad Frost introduce il concetto di Atomic Design.

How to create beautiful style guides online | DesignHooks

29 Well-Designed Online Style Guides - Web Design Ledger

UI Style Guides | Experience Dynamics

50 Meticulous Style Guides Every Startup Should See Before Launching – Design School

Conclusioni

In questo post ho condiviso con voi la mia indagine sulle linee guida. Questo escursus mi ha permesso di conoscere lo stato dell'arte delle linee guida, ma non ha risolto la mia necessità di rendere esplicite regole che ho incorporato nei miei template. Una parte importante di questa conoscenza si colloca ad un livello di astrazionee più alto, e dunque dovrò identificare una forma di documentazione in parte diverso.
Ma di questo ne scriverò la prossima volta.