3. OUR
ideato e extrategy ora sono Flowing:
una community inclusiva di persone
che condividono passione per
l’innovazione e bisogno costante di
evoluzione. Abbiamo cocreato
insieme questa nuova realtà, e
insieme a chi condivide i nostri
valori continuiamo a farla crescere
giorno per giorno.
PEOPLE
3
7. Pattern
Funzionali
Sono i design pattern che
descrivono soluzioni relative a
problemi funzionali
dell’interfaccia come menu,
bottoni, form, actionbar, etc
etc
Componente
un implementazione di un
design pattern
Sinonimi
7
Pattern
Library
una lista organizzata di
componenti con relativa
documentiazione
Design Pattern
Each pattern describes a
problem that occurs over and
over again in our environment,
and then describes the core of
the solution to that problem.”
— Christopher Alexander
8. Pattern
Percettivi
Le qualità “senza nome” che
caratterizzano esteticamente il
design system. La loro somma
definisce l’individualità del
prodotto.
Styleguide
l’implementazione dei pattern
percettivi
Sinonimi
8
9. Vocabolario
è la rappresentazione dell’uso
corretto delle parole in un
dato momento storico
Linguaggio
è un sistema di comunicazione
tra “parlanti” in cui il significato
e l’uso delle parole è definito e
condiviso ed è espressione di
una cultura comune. Un frase
scritta da un parlante, quando
letta da un altro- anche in un
luogo e un momento diverso -
avrà lo stesso significato.
Definizioni
9
Letteratura
è un’istanza d’uso del linguaggio
derivata dalla cultura condivisa
sul significato e l’uso delle
parole. Con un linguaggio
condiviso un testo può essere
scritto da più persone come se
avessero un’unica mente.
Pattern Library Design System
Interfaccia
12. Un Design System è un insieme interconnesso di pattern e di
pratiche condivise organizzate in modo da raggiungere lo
scopo del prodotto digitale.
Pattern = elementi ripetuti e combinati per comporre
l’interfaccia
Pratiche = modo in cui vengono usati i pattern
Che cos’è un Design System
12
13. Non è una styleguide
Non è un pattern-library
Non è un lavoro da Designer
Non è UX
Non è una checklist di cose da fare
Cosa NON è un Design System
13
14. Business Model
Personas o Proto-Personas
Jobs to be done
User Journey
User Interface
Che informazioni servono per un
Design System?
14
15. Perché ci permette di realizzare un prodotto sano
aiutandoci ogni volta a prendere micro e macro
decisioni sane in funzione degli obiettivi di business
e tenendo conto delle esigenze degli utenti.
Perché un Design System?
15
16. L’interazione delle parti del nostro design è ciò che
influisce sull’emotività dell’esperienza del nostro
utente.
Un linguaggio comune in tutto il team è fonte di
allineamento.
Mappare lo stato componentistico del nostro
software ne permette una buona manutenzione.
Perché un Design System?
16
17. Esiste qualche scorciatoia?
17
Design System
Pattern Percettivi
Material Design?
Principi di Design
Governance
Parametri e regole
d’uso comuni
Linguaggio Condiviso
Pattern Funzionali
Custom Variables?
19. Il principio è un concetto, un enunciato che sta alla
base di un ragionamento.
Non è una regola ma sono l’insieme dei principi a
funzionare come una mappa che orientano le tue
scelte.
Cos’è un principio?
19
20. Perché è tramite i principi che ci assicureremo che la
nostra progettazione rispetti gli scopi del prodotto.
Perché i principi in un Design System?
20
21. Vengono definiti da tutto il team.
Sono in genere da 3 a 5 con le seguenti caratteristiche:
- Autentici e genuini
- Pratici e applicabili
- Con un chiaro punto di vista
- Facilmente ricordabili
I principi di un Design System
21
22. I principi non devono essere generici o scontati.
Devono orientarti su qualcosa ed è importante che non dia
adito ad interpretazioni diverse nel team.
Esempio errato:
“funzionale”
Esempio corretto:
“non un pixel in più a quelli richiesti per la funzionalità”
1 - Autentici e genuini
22
23. I principi devono comunicarvi una strada o una scelta.
Pensalo come un consiglio, e non solo come un termine
giusto.
Esempio errato:
“completezza”
Esempio corretto:
“mostrare tutte le opzioni piuttosto che dare una
direzione”
2 - Pratici e applicabili
23
24. I principi devono aiutarci a definire priorità ed equilibrio
anche se a volte ci sono situazioni conflittuali.
Esempio errato:
“completezza e piacevolezza”
Esempio corretto:
“Seguire le seguenti priorità: prima completezza delle
informazioni di contesto poi piacevolezza estetica”
3 - Con un chiaro punto di vista
24
25. Se un team non ricorda i principi probabilmente sono
migliorabili. Vanno usati spesso, resi visibili, utilizzati per
feedback e perché no creati acronimi per ricordarli meglio.
Esempio d’uso errato:
non fare mai riferimento ai principi nelle discussioni
Esempio d’uso corretto:
stampo i principi su fogli A4 che ci accompagnano in ogni
confronto
4 - Facilmente ricordabili
25
26. Esercizio: Completa la lista dei Principi
Sulla base dello scenario dell’applicazione a cui stai lavorando ipotizza altri
principi che guideranno il design system.
➔ ricorda, le basi per per formulare un principio utile sono:
◆ deve “servire” l’obiettivo del software
◆ deve fornire un principio pratico e applicabile sulla UI
◆ deve essere facilmente ricordabile
◆ deve dare un punto di vista preciso
➔ la “prova del 9” è chiedersi “il contrario del mio principio potrebbe essere
valido per un altro design system?”
Template slide 4:3 Tipografia e colori
26
29. 29
Design System: Governance
➔ Quale è il team? Livello di delega?
➔ Quali sono gli strumenti?
➔ Come si rendono visibili i risultati? Canali?
➔ Quali sono i riti?
33. Un Design Pattern rappresenta una soluzione
progettuale generale ad un problema ricorrente.
- Christopher Alexander -
Cos’è un Design Pattern
33
34. Ogni Design Pattern descrive un problema ricorrente
nel nostro scenario e di conseguenza anche il nucleo
della soluzione a tale problema. Per questo è
utilizzabile milioni di volte senza mai applicarlo allo
stesso identico modo.
Cos’è un Design Pattern
34
35. L’elenco dei Design Pattern definiscono la Pattern
Library della nostra applicazione.
Più Design Pattern interconnessi tra loro definiscono il
Design Language della nostra applicazione.
I Design Pattern nel Design System
35
36. I Pattern Funzionali sono i blocchi tangibili
dell'interfaccia. Il loro scopo è quello di abilitare o
incoraggiare determinati comportamenti degli utenti.
I Pattern Funzionali
36
37. Il Pattern evolve ma il comportamento rimane lo
stesso.
Definire quali sono i pattern e a quale scopo servono
aiuta a non generare duplicati e ci permette di
evolverli insieme al nostro software.
I Pattern Funzionali
37
38. I Pattern Percettivi sono l’essenza estetica del nostro
elemento.
Essi sono sempre presenti anche in un componente
puramente funzionale.
I Pattern Percettivi
38
39. Anche se sono lo strato più esterno, i Pattern
Percettivi funzionano bene quando vivono nel core
del brand ed evolvono con il prodotto.
Il Pattern Percettivo per eccellenza è quello che
caratterizza e differenzia il nostro prodotto.
I Pattern Percettivi
39
40. Carta e matita
Sketch (https://www.sketchapp.com/)
Invision (https://www.invisionapp.com/)
Adobe XD (https://www.adobe.com/it/products/xd.html)
Figma (https://www.figma.com/)
...
Tool per i Design Pattern
40
42. Come definire i design pattern?
➔ Interface inventory ( http://bradfrost.com/blog/post/interface-inventory/ )
➔ Processo induttivo da UI+User Journey ai Pattern (design driven)
➔ Va fatto periodicamente e dopo aver progettato (bene) l’interfaccia
➔ devono essere presenti: frontenders, designers, persone che si occupano di copy (4/ 8p)
➔ L’outcome che ci aspettiamo è una lista di pattern standardizzabili sotto forma di schizzi
➔ Il processo è più importante del risultato
42
43. 1. Identificare l’area di analisi
43
Identificare un segmento della user journey che
corrisponda a una delle macro-attività da sostenere
Fatturazione
44. 2. Dividere l’attività analizzata in azioni
44
visualizza la
lista dei
preventivi
emessi
45. 2. Dividere l’attività in azioni: esercizio
A partire dall UI della tua applicazione “tagga” (con un post it) ogni azione
presente in ogni schermata che sostiene il comportamento della schermata
➔ esempi concreti:
◆ filtra la lista dei fascicoli
◆ condivide l’articolo
◆ fotografa l’andamento finanziario di un portafoglio cliente
◆ cambia la modalità di visualizzazione dei look
➔ ogni azione ha per soggetto implicito la parte di interfaccia taggata
45
46. 3. Raggruppare gli elementi per scopo
46
presenta un
overview di un
elemento
➔ raggruppare gli elementi che sostengono azioni analoghe (svolgono la
stessa funzione)
➔ il livello di granularità degli elementi raggruppati deve essere il medesimo,
non avremo un elemento atomico come “bottone” nello stesso gruppo di
“elenca i fascicoli”
➔ siete voi a dover decidere i grado di specificità del gruppo
47. 3. Raggruppare gli elementi per scopo: esercizio
Raggruppa tutti gli elementi che sostengono la stessa azione
➔ esempi concreti di gruppo:
◆ elenca i fascicoli
◆ cerca articoli
◆ naviga nell’applicazione (menu)
◆ triggera un’azione
➔ il livello di granularità degli elementi raggruppati deve essere il medesimo,
non avremo un elemento atomico come “bottone” nello stesso gruppo di
“elenca i fascicoli”
➔ siete voi a dover decidere i grado di specificità del gruppo
➔ cose che “appaiono” diverse potrebbero stare nello stesso gruppo
➔ la discussione è il vero obiettivo!
47
48. 4. Definisci i pattern
48
genericospecifico
lista fascicoli
lista preventivi
lista fattura
lista fascicoli
lista documenti fiscali
lista content
block
“Se modifico le fatture voglio che si
modifichino anche i preventivi?”
49. 4. Definisci i pattern: esercizio
Definisci i Pattern:
➔ Ogni pattern può essere più specifico o più generico
➔ esempi:
◆ lista fascicoli E lista preventivi VS lista generica
◆ lista radio E vista articoli VS lista generica
◆ primary menu E tabs VS menu generico
◆ header E action bar VS header with actions generica
➔ la “prova del 9” quando uniamo due pattern in uno è “quando modifico A
voglio che cambi anche B?”
➔ Considera che ogni pattern potrà avere delle varianti
49
50. 5. Struttura dei contenuti: elementi
50
Lista documenti contabili
➔ Data
➔ Numero
➔ Destinatario
➔ Causale
➔ Imponibile
➔ Anticipo
➔ Stato
➔ Riporta in bozze
➔ Accetta preventivo
➔ [...]
51. 5. Struttura dei contenuti: gerarchia
51
Lista documenti contabili
➔ Data
➔ Numero
➔ Destinatario
➔ Causale
➔ Imponibile
➔ Anticipo (solo per preventivo)
➔ Stato
➔ Azioni
◆ Riporta in bozze (solo per preventivo)
◆ Accetta preventivo (solo per preventivo)
◆ Incasso (solo fattura)
◆ [...]
52. Azioni
5. Struttura dei contenuti: wireframe & varianti
52
Data Numero Destinatario Causale Imponibile Stato
Riporta in bozze
Accetta
Rifiuta
Lista documenti contabili: variante preventivo
AzioniData Numero Destinatario Causale Imponibile Stato
Storna
Incasso
Lista documenti contabili: variante fattura
anticipo
Fattura
53. 5. Struttura dei contenuti: esercizio
Struttura dei contenuti:
➔ elenca per ogni pattern gli elementi (immagini, testo, titolo, meta, etc etc) di
contenuto
➔ determina la loro gerarchia e gli eventuali elementi varianti e/o opzionali
➔ Definisci con un wireframe la struttura visuale del pattern
➔ Definisci eventuali varianti della struttura visuale
53
54. 6. Naming: esercizio
Naming:
➔ definisci un nome per ogni pattern che rifletta il suo grado di specificità
➔ esempi:
◆ grado di specificità alto: Lista Preventivi
◆ grado di specificità medio: Lista Documenti Contabili
◆ grado di specificità basso: Lista
54
56. La Pattern Library è uno strumento per documentare
e condividere i Design Pattern.
Cos’è una Pattern Library
56
57. Ordine alfabetico, gerarchico o per funzionalità.
L’importante è che sia fatta come è abituato a
pensare il team.
Struttura di una Pattern Library
57
59. Se utile è possibile aggiungere anche:
versioning
membri del team
pattern correlati
dos e don’t
Struttura di una Pattern Library
59
60. Esiste ma non viene usata
Viene usata solo da una parte del team
Anti-pattern di una Pattern Library
60
61. Condividete il modo in cui farlo.
O siete rigidi e disciplinati nell’accettare nuovi
componenti e avete un sistema che vi aiuta a capire se
il pattern esiste già e/o se potete modificarlo oppure
inserite un nuovo pattern solo se è stato riusato
almeno “n” volte.
Update di una Pattern Library
61
68. Esercizio: Implementa il Componente Progettato
➔ Utilizza il repository del tuo scenario di applicazione:
◆ ius maior:
https://github.com/adellava/ius-maior-design-system-sketch
◆ day:
https://github.com/Violo/day-design-system-sketch
◆ banca soldo
https://github.com/Violo/bancasoldo-design-system-sketch
◆ modatrendy42
https://github.com/Violo/modatrendy42-design-system-sketch
➔ Fare una fork, clonare il repo, seguire il readme
Template slide 4:3 Tipografia e colori
68
71. Alternative allo sviluppo dei Componenti
71
➔ Usare un framework UI
◆ Integrato con il framework di front-end (es. material UI)
◆ Integrabile con il framework di front-end (es. Bootstrap)
◆ CSS only (es. Bulma)
➔ Scrivere i componenti con il framework di front-end + CSS
➔ Web Components
◆ molto costosi
◆ web standard
77. Esercizio: Implementa il Componente
dotato di Comportamento
Utilizza questo repository come esempio:
➔ simple-web-components-with-manipulation
https://github.com/adellava/simple-web-components-with-manipulation
Template slide 4:3 Tipografia e colori
77