per Vivisol
Un design system vale quanto le sue fondamenta. Per Vivisol - provider di servizi homecare - abbiamo condotto un audit quantitativo (WCAG 2.2) e qualitativo, restituendo una roadmap concreta per rafforzare coerenza e accessibilità a partire da colori, tipografia, spaziature e token.
Negli ultimi anni il mondo tech ha visto i design system passare da tendenza a standard, permettendo di garantire coerenza e scalabilità a qualsiasi prodotto digitale. All’inizio, in molti hanno provato a creare il proprio design system commettendo errori, per la mancanza di best practice e di letteratura di riferimento.
Buildo si è sempre interessata profondamente a questo tema e ha maturato un’esperienza preziosa nella creazione e nella manutenzione di design system. Per questo oggi siamo attrezzati per guidare i nostri clienti in ogni fase del processo, dallo sviluppo iniziale all’evoluzione continua.
Il primo passo è sempre l’audit.
Vivisol, parte del Gruppo SOL, è un provider di servizi homecare che si dedica a migliorare la qualità della vita dei pazienti cronici la cui terapia viene erogata a domicilio o in strutture residenziali. Proprio per questo, il loro design system deve garantire un’esperienza coerente e accessibile su tutti i touchpoint.
I risultati dell’audit hanno offerto a Vivisol una valutazione completa dei punti di forza e di debolezza del proprio design system. Individuando i possibili problemi, l’assessment permetterà a Vivisol di migliorare il design system risolvendo le incoerenze e affinando il design del prodotto e la user experience nel complesso.
Così come la creazione di ogni design system parte dalle sue fondamenta, lo stesso vale quando iniziamo la nostra analisi di audit. Ogni miglioramento che suggeriamo su colori, tipografia e spacing può da solo avere l’impatto più significativo nel rework di un design system, perché si propaga senza sforzo a ogni componente, pattern e layout che li usa come token.
L’analisi qualitativa è partita dall’esperienza e dal know-how che Buildo ha maturato nella creazione, manutenzione e ristrutturazione di design system per i propri clienti. È stata poi integrata da un’analisi quantitativa basata sulle Web Content Accessibility Guidelines 2.2 (WCAG 2.2), definite dalla Web Accessibility Initiative (WAI), parte del World Wide Web Consortium (W3C).
Per quanto riguarda i colori, facciamo due verifiche principali: accessibilità e semantica.
Sul fronte dell’accessibilità, facciamo riferimento ai criteri WCAG 2.2 1.4.3, 1.4.6 e 1.4.11 per esaminare i contrasti tra le diverse combinazioni di colore nel design system. Raccogliamo tutti i colori usati e verifichiamo se rispettano i valori di contrasto nelle varie combinazioni. Non serve che tutte le combinazioni siano valide, ma una bassa percentuale di contrasti corretti è spesso un buon indicatore di possibili problemi di accessibilità nel design system.
Come ci insegna la psicologia del colore, ogni colore racchiude un significato semantico che gli permette di comunicare qualcosa in più del colore stesso.
Per questo è essenziale valutare con attenzione come usiamo i colori del brand nell’interfaccia. Nella nostra esperienza, notiamo come alcune aziende usino il rosso del proprio brand per segnalare interazioni potenzialmente dannose o azioni che potrebbero portare alla perdita di dati o di lavoro degli utenti. Meglio evitare di creare associazioni negative inconsce con il brand.
Per le aziende che usano il verde come colore del brand, come Vivisol, può sembrare una buona idea associare il colore del brand al successo, ma per gli utenti può risultare poco chiaro. Questa confusione è particolarmente forte quando il colore del brand viene usato anche per indicare l’interattività o come elemento puramente comunicativo del brand.
È cruciale scegliere una semantica dei colori che permetta agli utenti di distinguere a colpo d’occhio il ruolo dei diversi elementi sullo schermo.
Spesso, nel progettare le interfacce di un prodotto digitale, può servire qualcosa di più dei tipici tag tipografici del web. Ampliare e modificare la scala tipografica va bene, ma c’è il rischio che diventi troppo complessa e perda la sua utilità nell’organizzare e dare priorità alle informazioni testuali. Per evitarlo, dobbiamo semplificare e razionalizzare la tipografia, così da mantenere la gerarchia delle informazioni.
La maggior parte dei design system della prima era assegnava un token tipografico a quasi ogni elemento testuale dei componenti. Per esempio, un token dedicato veniva assegnato all’etichetta del Button e un altro al titolo della Card.
Negli ultimi anni, sempre più design system — Google Material 3 su tutti — hanno iniziato a creare scale tipografiche che descrivono i ruoli gerarchici affidati al testo. Questa classificazione permette di mantenere un numero ridotto di stili tipografici, capaci di soddisfare tutte le esigenze di design e di facilitare le scelte del designer.
Uno degli errori più comuni che abbiamo incontrato è la mancanza di una spacing scale nel design system.
Implementare un sistema di spacing coerente, che standardizzi dimensioni e allineamenti, può aumentare la coerenza dei prodotti, rendere più leggibile la gerarchia delle informazioni, facilitare la comunicazione tra i team di sviluppo e ridurre al minimo il numero di decisioni che i designer devono prendere durante il processo di design.
Di solito consigliamo una scala basata su 4 o su 8, riconosciuta in letteratura per flessibilità e scalabilità. Se però adottiamo una scala lineare con unità di base così piccole, rischiamo di avere troppi valori nella spacing scale. Questa flessibilità può sembrare utile all’inizio, ma il carico cognitivo che ne deriva diventa più oneroso, viste le minime differenze semantiche tra i valori più alti della scala.
La scala che abbiamo testato a lungo e che si è rivelata più flessibile ed efficiente è 0, 4, 8, 12, 16, 24, 32, 40, 80, 120 e 160.
I valori iniziali di questa scala sono più densi e flessibili, pensati soprattutto per la costruzione dei componenti. I valori finali sono più radi e riconoscibili, adatti a gestire le gerarchie di layout della pagina.
Meno impattante per l’utente ma molto insidiosa per chi lavora al design system, la mancanza di una nomenclatura coerente per i token può compromettere seriamente la manutenzione e l’evoluzione di un design system.
A sinistra, l’esempio mostra token il cui nome descrive il colore che rappresentano. I nomi dei token a destra descrivono invece come quei colori verranno usati nell’interfaccia. Entrambe le convenzioni di naming sono valide, ma standardizzare i nomi dei token può guidare le future evoluzioni del design system.
La nostra esperienza suggerisce che gestire i colori in un design system funziona meglio usando due gruppi:
Questo approccio è molto scalabile, perché ci permette di gestire in modo indipendente il numero di colori del design system e il numero di token usati per assegnare i colori agli elementi dell’interfaccia. Con questo metodo possiamo aumentare senza sforzo il numero di token — per esempio dopo aver creato nuovi componenti — e ridefinire lo stile del tema del design system quando serve, come dopo un redesign del brand o con l’introduzione di un dark theme.
Fonte dei dati: “How we document 2024” di ZeroHeight e “The future of design systems is accessible” di Figma.
L’audit del design system di Vivisol è stato un’analisi approfondita del loro design system, in particolare delle sue fondamenta, che ha aiutato a individuarne i punti di forza e le aree che necessitavano di ulteriori miglioramenti.
Il nostro report di audit ha fornito a Vivisol insight e raccomandazioni dettagliate, che possono usare come guida per far crescere e migliorare il proprio design system. Risolvendo incoerenze e criticità, Vivisol può offrire ai propri utenti un’esperienza più accessibile e semplice da usare.
Clinical Lab Update Service
Nei laboratori clinici, aggiornare software e firmware era un'operazione manuale e complessa, in un contesto regolamentato. Per Inpeco abbiamo sviluppato un servizio scalabile che li automatizza e gestisce da remoto, in conformità alle normative sui dispositivi medici.
Cell Therapy Software Design
CellPly doveva trasformare un dominio complesso in una suite semplice da usare. Con ricerca sugli utenti, co-design con gli stakeholder e un design system dedicato, abbiamo progettato il software di VivaCyte rendendone fluido l'handoff a più team di sviluppo.
Accessibility Assessment
Gruppo San Donato voleva una piattaforma accessibile a tutti gli utenti a prescindere dalle loro capacità. Abbiamo valutato l'accessibilità del sito su codice, UI e UX e costruito una roadmap prioritizzata per raggiungere la conformità WCAG.
