Cambiamenti visivi nei sistemi di progettazione

Rispettiamo le API del codice. Ma che dire di colore, tipo e spazio?

N. 4 di 6 della serie Releasing Design Systems:
Uscite | Cadenza | Versioni | Rottura | Dipendenze | Processi

I sistemi di progettazione stabiliscono uno stile visivo di base che è una dipendenza essenziale. Queste scelte - colore, tipografia, spazio e altro - sono specificate in maniera solida e dovrebbero cambiare stabilmente, prevedibilmente rilascio dopo rilascio. Quando un utente che esegue l'upgrade, un sistema di progettazione non dovrebbe interrompere in modo imprevisto le proprie cose.

Quindi, chiediti ...

Gli adottanti possono passare a una versione minore fiduciosi che la loro interfaccia utente non si interromperà a causa delle modifiche visive di un sistema?

Semantic Versioning (SemVer) offre criteri chiari per comunicare il cambiamento tra le versioni usando designazioni principali, minori e patch. Ogni sistema di progettazione che incontro utilizza SemVer e monitora le modifiche nell'interfaccia di programmazione dell'applicazione o API del loro pacchetto. Questo è un territorio familiare per gli sviluppatori che codificano i puntelli JavaScript e il markup HTML. Rompi l'API e la versione successiva deve incrementare la versione alla prossima versione principale, ad esempio dalla 1.4.0 alla 2.0.0.

Specificare un'interfaccia per lo stile visivo compositivo ci sfugge. È così difficile definire regole chiare e semplici per monitorare i cambiamenti di stile. I produttori di sistemi fanno fatica a capire cosa o perché "Cambiare questo stile rompe l'interfaccia utente di un adottante" contro "Cambiare quello stile non lo fa". Pochi team di sistema documentano tali criteri. Chiedo "Quali tipi specifici di cambiamenti visivi attivano una versione principale per te?" La loro risposta: ¯ \ _ (ツ) _ / ¯.

In questo articolo, propongo che almeno i colori, la tipografia e lo spazio garantiscano criteri che costituiscono un cambiamento radicale. Ci sono anche altre proprietà da considerare. Un sistema di progettazione è in grado di definire, documentare e comunicare questi criteri in modo che gli utenti possano aggiornare la versione in versione con sicurezza.

Colore di rottura

La maggior parte dei team di sistema si sente sicuro nell'ottimizzare il colore di sfondo di un pulsante principale. Forse la loro motivazione è quella di migliorare il contrasto rispetto a un'etichetta di testo generalmente bianca. "Scuriamo un po 'l'alzavola", dicono. "Miglioreremo il contrasto cromatico accessibile dei pulsanti da una classificazione AA a AAA".

Regolazione del colore di sfondo di un pulsante principale

Certamente, l'adozione di team non dovrebbe sostituire il set di colori di un pulsante primario standard. Sostituendo una scelta di sistema, la connessione con un sistema viene interrotta. A quel punto, un adottante è da solo. Pertanto, la regolazione dell'ombra del colore di sfondo del pulsante principale è sicura e non rappresenta un cambiamento sostanziale.

Tuttavia, cambiare i colori altrove può mettere in pericolo gli utenti. Considera i seguenti scenari.

Esempio: testo di sistema su sfondi personalizzati

Immagina un team di sistema che perfeziona il blu interattivo per migliorare il contrasto cromatico. Il blu interattivo della v1.4.0 era accessibile su uno sfondo bianco ma non funzionava sullo sfondo del carbone.

Controllo del contrasto del colore tramite contrast-grid.eightshapes.com

Quindi, per la versione 1.5.0, il team ha adattato il blu interattivo a un tono più chiaro e più saturo che ha funzionato sia sul bianco che sul carbone.

Regolazione del colore del testo di un'etichetta del pulsante fantasma su sfondi imprevedibili

Tuttavia, un adottante aveva usato il pulsante Ghost in base a quel colore su uno sfondo grigio chiaro. Dopo la modifica del sistema, il contrasto del colore del testo dell'etichetta è inaccessibile. Il tuo sistema ha rotto il loro prodotto.

Esempio: sfondi di sistema con testo sovrapposto personalizzato

Allo stesso modo, immagina che un sistema oscuri il colore di sfondo del componente Card. L'area del contenuto della carta include una zona di contenitore del contenuto "sicura" in cui gli utenti adottano il contenuto e il markup che desiderano.

Regolazione del colore di sfondo di una scheda che consente il contenuto personalizzato contenuto

In quella zona presumibilmente sicura, un adottante ha aggiunto un testo secondario che, sebbene leggermente grigio moderato, ha superato un test di contrasto del colore. Dopo la modifica del sistema, il contrasto del colore non è più accessibile. Il tuo sistema ha rotto il loro prodotto.

Immagina che la versione minore del tuo sistema includesse tali aggiustamenti. Compatibile con le versioni precedenti, hai detto? Nessun rischio nell'aggiornamento, si sono fidati? No! Il tuo sistema ha rotto il loro prodotto!

Pertanto, valutare le proprietà dei colori modificate per determinare se un sistema è cambiato, ad esempio:

  • Colore del testo che potrebbe apparire al di sopra del colore di sfondo, dell'immagine o di altra trama di un adottante.
  • colore di sfondo su cui è sovrapposto il colore del testo di un adottante.
  • colore di sfondo, colore del bordo, colore del testo, ombra della casella o altra proprietà composta accanto, sopra o sotto il bordo o il contenuto di un altro componente in modo da ridurre il contrasto tra gli elementi.

L'accessibilità ha guidato questi esempi. C'è anche un rischio estetico, in quanto i cambiamenti di sistema ben intenzionati potrebbero interrompere la colorata armonia raggiunta da un progettista di prodotti. Le interazioni di colore abbondano nell'interfaccia utente che un progettista di sistema non controlla né ha visibilità.

Takeaway: inizia a interrompere la conversazione di modifica con criteri di colore. È più facile comunicare il rischio, è oggettivamente misurabile ed è legato all'accessibilità che stimola le passioni. Con alcuni criteri, puoi passare ad altre preoccupazioni.

Tipografia di rottura (avvolgendo)

La tipografia è un aspetto fondamentale di qualsiasi stile visivo. I team vogliono farlo nel modo giusto. E ci sono così tanti quadranti da mettere a punto: famiglia di caratteri, spessore del carattere, dimensione del carattere, trasformazione del testo, altezza della linea, spaziatura tra lettere e altro ancora.

Non tutte le esperienze rischiano di rompersi se un sistema regola la tipografia. Per esperienze ricche di contenuti, i contenuti di ciascun elemento possono essere imprevedibili, di varia lunghezza e progettati per avvolgere e rispondere alle modifiche della larghezza della finestra.

Per interfacce più dense, la tipografia deve essere precisa. I progettisti macinano per ore la tipografia di fine tuning, disponendo le etichette per adattarle ad aree compatte. Se si regola la tipografia del sistema, i relativi elementi possono essere avvolti o ritagliati in modi inaspettati.

Esempio: le schede di avvolgimento sono orribili

Immagina che il tuo sistema regola il peso del tab lab da normale a grassetto.

Dopo un aggiornamento di versione minore, le schede non rispondono. Non bene.

Un adottante si aggiorna. Le loro schede non rispondenti esistenti superano lo spazio allocato, quindi vanno a capo. Ghastly! Il tuo sistema ha rotto il loro prodotto.

Esempio: Letter Spacing Mayhem

Le linee guida del marchio si evolvono, producendo una nuova gerarchia e stile di intestazione. Pertanto, il sistema si adatta aumentando la spaziatura tra le lettere di ciascuna intestazione.

Un adottante aggiorna la sua densa app per radiologia a pagina singola che è tradotta in 14 lingue, composta da una miriade di pannelli di controllo, ognuno pieno zeppo di elementi del modulo e titoli. Si aggiornano e l'interfaccia utente è piena di titoli imprevedibilmente ritagliati. Chiamano una riunione di crisi. Invitano gli ingegneri dei dati back-end, per l'amor del cielo! Il tuo sistema ha rotto il loro prodotto!

La regolazione della tipografia del sistema può essere pericolosa. Per te, è una rinfrescante evoluzione tipografica distribuita senza sforzo in una biblioteca. Per loro, il testo inizia a comportarsi male. Ti danno la colpa. Forse ti danno fuoco nel canale Slack # system-design. Nessuno ne ha bisogno.

Takeaway: prima della 1.0.0, lavora diligentemente per sperimentare, perfezionare e finalizzare stili di tipo adatti alla varietà del cliente. Una volta superato 1.0.0, mantenere una base stabile e considerare il cambiamento con cautela. Considera di riservare turni pericolosi alla prossima versione principale. Fino ad allora, aggiungere in modo incrementale funzionalità contenute, come un componente Testo lungo per lo styling della sola copia dell'articolo.

Spazio e dimensioni di rottura

Almeno puoi vedere il colore e la tipografia. Spazio e dimensioni? Quelli che sono più difficili da definire come riutilizzabili concretamente, figuriamoci monitorare per interrompere il cambiamento.

In HTML, quando si modificano le proprietà del modello di riquadro di un componente - riempimento, margine, larghezza, altezza, visualizzazione, ridimensionamento del riquadro, posizione, sinistra, destra, alto, basso - si rischia di influire sulla composizione del layout che organizza quel componente con altri elementi della pagina.

Esempio 1: rimozione della spaziatura verticale

Il team di sistema decide di rimuovere i controlli del modulo applicato di spaziatura verticale sotto forma di margine inferiore. Ciò ha un impatto su ,