Rilascio di sistemi di progettazione

Fornire output interconnessi agli utenti nel tempo

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

Le aziende realizzano il valore di un sistema di progettazione quando adottano prodotti che utilizzano un sistema per creare e spedire esperienze utilizzate dai propri clienti. Come parte di quella catena del valore, il sistema rilascia funzionalità nel tempo. Questo mette il sistema nelle mani del suo cliente: progettisti e ingegneri che svolgono il loro lavoro.

Team di sistemi forti prendono sul serio le versioni. Non si vedono come rilasci solo il codice della libreria dei componenti. Forniscono invece molti più output: token di progettazione, documentazione, risorse di progettazione e altre risorse.

Questa serie descrive molti aspetti del rilascio di sistemi di progettazione. Inizia definendo i molti output di un sistema e dove vengono consegnati. Gli articoli successivi trattano argomenti di cadenza, controllo delle versioni, interruzione delle modifiche, dipendenze e approccio graduale.

Queste storie riflettono ciò che ho imparato rilasciando sistemi che lavorano con team come Discovery Education, Morningstar, Target e REI. Sono rafforzati dalle intuizioni dei colleghi di Salesforce, Adobe, Atlassian, Shopify e Financial Times. Grazie per aver gentilmente condiviso il tuo tempo e le tue pratiche!

Output: cosa viene rilasciato?

I programmi di sistemi di progettazione rilasciano molti tipi di output, non solo di codice. Di conseguenza, un sistema dovrebbe differenziare e comunicare questa gamma di output con versione a sviluppatori, progettisti e altri clienti.

Codice, la fonte della verità

La maggior parte dei sistemi offre un'unica fonte di verità del codice del livello di presentazione come:

  • Libreria dei componenti dell'interfaccia utente come markup HTML e CSS. Spesso definito "CSS", il consumo di questo pacchetto si basa sull'utilizzo o sulla compilazione di CSS come base di riferimento coerente per lo stile di visualizzazione unita al riutilizzo di snippet HTML.

e / o ...

  • Libreria dei componenti dell'interfaccia utente come Javascript: molti sistemi racchiudono HTML e CSS con JavaScript per rafforzare la logica, incapsulare lo stile e facilitare l'integrazione e la manutenzione più direttamente in un quadro di scelta. Mentre la maggior parte delle biblioteche si rivolge a un framework specifico (React, Vue, Ember, Angular, ...), i segnali del settore suggeriscono un passaggio alla creazione di componenti Web per tutti i framework. I miei ultimi sei sforzi di sistema? Più tardi 2017: Vanilla HTML, Vanilla HTML. All'inizio del 2018: React, Vue. Più tardi 2018: componenti Web, componenti Web.

Inoltre, altre uscite importanti possono essere rilasciate separatamente:

  • Token di progettazione che stabiliscono uno stile visivo tramite coppie proprietà-valore semanticamente significative. I token sono variabili disponibili in molti formati per l'uso su piattaforme (web, iOS, Android), preprocessori (Sass e LESS) e framework (come React). Alcuni sistemi gestiscono i token in un repository separato dal codice componente dell'interfaccia utente. Di conseguenza, la loro libreria - insieme ad altre implementazioni - può dipendere anche dal token come pacchetto.
  • App / siti dimostrativi come ambiente con esempi di pagine creati utilizzando la libreria dei componenti. La demo è anche per tutorial e prototipazione rapida, anche dai designer!
  • Componenti multipiattaforma adatti per iOS, Android e Windows.

Risorse di progettazione

La maggior parte dei team limita la comprensione di ciò che rilasciano al semplice "rilascio del codice". È sorprendente per loro rendersi conto che pubblicano così tanti altri strumenti che cambiano nel tempo. Loro includono:

  • Design Toolkit come file modello e librerie di simboli offerti nel software di progettazione. Oggi, quasi sempre Sketch. Domani, Figma, Invision Studio e altri concorrenti emergenti?
  • Caratteri, icone e persino set di immagini di Origami a causa del ruolo spesso previsto di un sistema nella distribuzione e nella versione di tali librerie.
  • Altre risorse di progettazione come file ASE / CLR di campioni di colore e illustrazione come trampolino di lancio per opere d'arte su misura. Queste raccolte cambiano lentamente, in modo meno formale e tramite contributi dei membri della comunità non fanno parte di un nucleo centrale del sistema. Tuttavia, dal punto di vista del cliente e delle comunicazioni del sistema, fa parte del sistema.

Sito della documentazione

I sistemi di progettazione hanno bisogno di una casa, un luogo che tutti sanno di poter trovare un percorso verso tutto ciò che avrà l'ultima e la più grande. Ospitato in un URL memorabile, è spesso costruito con componenti dell'interfaccia utente specifici per la sua missione.

  • I siti di documentazione descrivono funzionalità (come un pulsante), a bordo di nuovi utenti e attivano processi come ottenere aiuto o contribuire. I team creano siti più spesso utilizzando un generatore di siti statici o meno spesso con un sistema di gestione dei contenuti.
  • I componenti della documentazione - code-example-pair, do-dont, hex-code, component-explorer - dipendono dalla libreria dei componenti dell'interfaccia utente e servono di solito solo il sito del documento. Tali componenti possono essere sottoposti a versione con il sito della documentazione o come terza libreria con versione separata relativa a doc e ai componenti dell'interfaccia utente tra cui si trovano.

Destinazioni: dove va?

Quando si distribuiscono codice e si progettano risorse, è fondamentale offrire il codice nelle maniere più facilmente consumate dagli ingegneri adottivi. Ciò significa che alcuni sistemi devono offrire una scelta tra molte opzioni, mentre altri possono fare affidamento su un'unica scelta come standard organizzativo.

Per il codice

  • MIGLIORE: registri come npmjs (o una controparte interna come il nesso di Sonatype) che forniscono l'accesso e la gestione dei pacchetti di codice rilasciati. Gli sviluppatori usano quindi strumenti come pergola, npm, filato, webpack e babel per integrare e aggiornare quel codice senza problemi nei loro ambienti.
  • MIGLIORE: risorse ospitate su CDN per collegamenti diretti allo stile e allo script con versione, nonché caratteri e icone che cambiano più lentamente.
  • SOLO OK: accesso al repository di Github, Bitbucket o simili per clonare, fork o altrimenti compilare, usare e forse - eventualmente - contribuire.
  • SE NECESSARIO: download di codice diretto, generalmente del "file ZIP" di risorse di sistema compilate o non compilate dal sito del documento per uso locale e / o integrazione manuale in un repository separato.

Bootstrap e Material Design Lite sono esempi di rilascio in 2+ destinazioni.

Per i toolkit di progettazione

  • MIGLIORE: Crea Nuovo come percorso incorporato e sincronizzato nel menu di uno strumento di progettazione per creare una nuova istanza da un modello.
  • MIGLIORE: versione e distribuzione utilizzando software di gestione delle risorse di progettazione basato su autorizzazioni come Abstract o Lingo.
  • BUONO: download diretto del toolkit da un sito di documentazione, con la versione chiara indicata e il documento introduttivo associato nelle vicinanze.
  • SOLO OK: unità condivisa, tramite URL interno ben pubblicizzato e possibilmente semplificato (come http: //system.uitoolkit).
  • NON BUONO ABBASTANZA: sepolto in una pagina di quarto livello in un sito wiki a malapena organizzato che molte persone non riescono a trovare.

Successivo → # 2. Cadenza