Il sistema minimo di progettazione praticabile

Sistema di progettazione UXPin in crescita archiviato nella libreria del sistema di progettazione UXPin

Nelle ultime due settimane ho avuto il piacere di parlare dell'approccio di UXPin alla costruzione di un sistema di progettazione su più incontri e webinar (puoi vederne uno qui). Mi sono divertito molto a condividere le nostre esperienze apprese molto attraverso tutte le conversazioni adorabili dopo i miei discorsi.

Una domanda che mi è stata posta più volte, che è emersa anche durante le mie conversazioni con il nostro team di UXPin, è stata:

Quanto tempo ci vuole per costruire un sistema di progettazione?

Non ci sono domande sbagliate e sono stato felice di rispondere ogni volta. Tuttavia, ogni volta che sento questa domanda, sento che indica un problema più profondo: i sistemi di progettazione sono ancora fraintesi e confusi con un vecchio approccio alla costruzione di una guida di stile.

L'eredità della Guida allo stile di zombi

In passato, uno sfortunato membro del team di progettazione o sviluppo front-end si sarebbe fidato del compito di documentare tutte le convenzioni approvate dal team. Tavolozze di colori, stili di testo, standard di codice, a volte anche modelli di interfaccia utente.

Sembra un sistema di progettazione? Hai ragione. Sembra un sistema di progettazione, ma non lo è.

Questo vecchio approccio alla costruzione di una guida di stile mirava a produrre un artefatto. Dovrebbe essere un derivato di un processo di documentazione. E ogni volta ...

Prima che la guida di stile fosse finita, si era già trasformata in uno zombi.

Perché? Semplicemente perché il dinamico mondo dello sviluppo del prodotto, in cui i cambiamenti avvengono costantemente, non risponde bene alle risorse statiche che richiedono settimane per essere costruite. Mentre un martire del design / sviluppo stava lottando per documentare ogni convenzione, le convenzioni continuavano a cambiare. Costruire una guida di stile era un compito di Sisifo.

L'impossibilità di costruire e mantenere guide di stile ha incoraggiato il nostro settore a ripensare il processo di mantenimento della coerenza di esperienza e codice. Inserisci il sistema di progettazione.

Il sistema di progettazione è un processo

A differenza delle guide di stile statiche, i sistemi di progettazione sono dinamici. Cosa significa? La guida di stile è un artefatto, il sistema di progettazione è un processo.

Gli artefatti sono statici, i processi dinamici.

Invece di delegare una persona alla creazione di documentazione, nel mondo del sistema di progettazione, pianifichiamo un nuovo flusso di lavoro che continua ad aggiungere, sottrarre e modificare tutte le informazioni per creare esperienze utente.

Invece di pensare in termini di data di consegna, i team del sistema di progettazione (in genere chiamati team di Design Operations) pianificano di aiutare le organizzazioni a migliorare gradualmente la coerenza interna dell'interfaccia e di consegnare i grandi progetti sul mercato più rapidamente.

Gestione dell'entropia con una guida di stile e un sistema di progettazione

Uniti contro l'entropia

Proprio come con qualsiasi sistema chiuso, l'entropia di un prodotto digitale continua ad aumentare, a meno che non sia gestita deliberatamente. Ogni nuova funzionalità, ogni nuovo membro del team, ogni nuovo livello di gestione o interazione stakeholder / cliente, aggiunge l'entropia dell'esperienza.

L'esperienza del prodotto diventa gradualmente caos.

La crescita dell'entropia è una costante e può essere controllata solo attraverso un'azione costante. Ecco perché il gioco finale per un team di Design Operations non è un artefatto statico, è un flusso di lavoro in cui un'organizzazione unita di designer, sviluppatori, PM e altri membri del team costruiscono un sistema di progettazione per creare esperienze utente.

Prodotto minimo praticabile senza fine

Chiedere la data di consegna di un sistema di progettazione sembra avere un'ipotesi nascosta, che ci sia un certo momento in cui il sistema di progettazione è "fatto". La natura processuale di un sistema di progettazione annulla questa ipotesi.

Il sistema di progettazione è un processo e quindi è sempre pronto e mai fatto contemporaneamente.

Un sistema di progettazione rimane in uno stato costante di prodotto minimo realizzabile. Il momento in cui un sistema di progettazione acquista improvvisamente valore non esiste. Una volta stabilito e concordato il processo del sistema di progettazione, viene raggiunto il valore minimo. Con ogni versione successiva, il sistema di progettazione diventa più potente, ma non raggiunge mai il valore finale. L'entropia continua a crescere, l'interfaccia continua a cambiare e il sistema di progettazione deve evolversi, come processo, senza fine.

Inizia spesso piccola nave

Un sistema di progettazione nasce quando un'organizzazione riconosce che la crescente incoerenza dell'interfaccia utente deve essere risolta attraverso nuovi flussi di lavoro.

L'entropia smette di espandersi con la prima convenzione concordata e implementata da un'organizzazione di progettazione. A differenza di una guida di stile, il valore di un sistema di progettazione può essere sperimentato immediatamente. Il sistema di progettazione inizia ad aggiungere valore quasi immediatamente, anche se la prima convenzione è solo un insieme di 5 colori primari con la convenzione di denominazione corrispondente. In effetti direi che:

Il sistema di progettazione con un colore definito, correttamente denominato, implementato e accettato da un'organizzazione è meglio di una guida di stile statica completa.

Perché? Perché questo colore sta immediatamente diminuendo l'entropia, a differenza di una guida di stile statica che rimane sempre obsoleta e mai implementata.

Invece di preoccuparti della data di consegna di un sistema di progettazione, accetta la sua natura processuale, inizia in piccolo e spedisci spesso. Sei in guerra con il caos e ogni piccola battaglia conta.

In bocca al lupo.

Vuoi vedere come stiamo costruendo il nostro sistema di progettazione? Segui i nostri sprint di Design Operations:

  • Design Systems Sprint 0: The Silver Bullet of Product Development.
  • Design Systems Sprint 1: The Inventory Interface
  • Design System Sprint 2: una tavolozza di colori per dominarli tutti
  • Design System Sprint 3: gestione delle nozioni di base
  • Design System Sprint 4: Principi di progettazione
  • Design System Sprint 5: gestione della tipografia
  • Design System Sprint 6: le icone più veloci sulla Terra

Ed ecco una prospettiva più ampia sui sistemi di progettazione:

I sistemi di progettazione sono un linguaggio. E questo sta cambiando per sempre lo sviluppo del software.

Iscriviti: https://www.uxpin.com/design-systems-early-access