Designabile #13 - Color Luminance, Roving Tabindex e Gap tra Designer e Developer
in questo numero due argomenti tecnici e una riflessione sul rapporto tra designer e developer. Non esitare a scrivermi — trovi indirizzo nel footer — se vuoi approfondire qualche tema o più semplicemente suggerirne uno per le prossime uscite.
Buona lettura! 📖
Conoscere e Usare la Color Luminance
Quante volte, guardando un insieme di colori, ti sarà capitato di percepirne alcuni più luminosi di altri, a parità di luminosità (la B di HSB nei tool di design)?
Non ti preoccupare, non devi andare dall’oculista. Sono però i nostri occhi che ci traggono in inganno!
Accade infatti che la perceived luminance di un color (letteralmente quella percepita dal nostro occhio) differisce invece dalla physical luminance (quella intrinseca, dettata dalle proprietà del colore).
Ti consiglio di leggere questo articolo su UX Collective per conoscere meglio la perceived luminance e trarne vantaggio nel design.
Cos’è il “roving tabindex” e perché dovresti saperlo
L’uso della tastiera per navigare un’interfaccia è ancora oggi un principio valido per misurare l’accessibilità di un prodotto.
Il roving tabindex sembra una roba da nerd — solo un pochino — in realtà è una soluzione HTML che consente di interagire con un componente tramite tastiera al di fuori dell’evento :focus (spiegato qui se non sai di che si tratta).
Vuoi mettere la comodità di navigare le opzioni di una select o i tabs senza dover spostare ogni volta il puntatore del mouse?
➡️ Il “roving tabindex” spiegato bene
Il gap tra Designer e Developer
Negli ultimi anni gli strumenti a disposizione dei designers si sono evoluti moltissimo. È notizia di questi giorni infatti che Figma ha introdotto il branching.
se non sai cosa vuol dire “branching” oppure ne hai solo sentito parlare - leggi qui
Accade infatti che oggi il designer parla sempre più il linguaggio del developer: branching, version control, iterazioni, changelog (e così via). Nonostante ciò, la comunicazione tra queste due figure non è sempre “fluida”.
Un tipico scenario
Stai lavorando al Design System creando un nuovo componente. Trascorri molte ore per documentare tutti i casi d’uso e le proprietà che possono o non possono essere modificate. Alla fine, completi il lavoro e lo consegni agli sviluppatori per l’implementazione.
Da quel momento, penserai solamente: “Come faccio a tenere sotto controllo l’implementazione? E se poi aggiungono una modifica, devo aggiornare tutta la documentazione?”
Come colmiamo quindi il divario tra ciò che è progettato e ciò che è sviluppato, senza il sovraccarico di fare costantemente revisioni?
Rivedendo il processo di lavoro.
Il vecchio processo
Secondo UXPin, dobbiamo cioè progettare solo il livello di dettaglio richiesto per la documentazione e l’implementazione.
Nello scenario appena descritto il designer lavora al componente, le eventuali varianti, scrive la documentazione, pubblica la library e solo alla fine parla con gli sviluppatori.
Il nuovo processo
Nel nuovo processo, gli sviluppatori devono essere coinvolti prima, al momento della stesura della documentazione. Facendo un po’ di pairing design, il momento del “Publish to Library” non è più un incognita ma una certezza.
Segui tutti gli aggiornamenti di CSSUI, la library di interactive components in pure CSS.
GitHub - zetareticoli/cssui: A collection of interactive UI components in pure CSS
A collection of interactive UI components in pure CSS - GitHub - zetareticoli/cssui: A collection of interactive UI components in pure CSS
Al prossimo numero 👋
Ciao, Francesco