Idea principale

La catena abituale di progettazione dell'interfaccia va in un solo senso: si disegna una schermata in Figma, poi uno sviluppatore front-end la reimplementa. Il mockup è una rappresentazione — mostra ciò che si vuole ottenere, e nulla di ciò che contiene è direttamente riutilizzabile.

Lo statuto cambia quando il design system viene ricostruito a partire dal repository invece di essere mantenuto a parte: componenti che esistono davvero, stati realmente gestiti, convenzioni di sviluppo del team, aggiornamenti man mano che il repository evolve. Il mockup non esprime più un'intenzione in un vocabolario estraneo al codice, compone elementi che esistono. Ciò che produce diventa una prima base che lo sviluppo può riprendere.

Lo spostamento riguarda la posizione nella catena, non lo strumento. Figma resta eccellente per progettare schermate; ciò che cambia è quanto vale il suo output a valle.

Perché è importante

È il caso più dimostrativo dell'inversione: la progettazione è la fase che si crede più lontana dal codice, perché lo precede. Mostrare che anch'essa può nutrirsi del repository indica che il confine tra progettazione, implementazione e documentazione si riduce da entrambe le estremità.

Sposta anche il punto di attenzione di un team di design: mantenere la corrispondenza tra il design system e il codice diventa più decisivo della qualità del disegno stesso.

Sfumature e limiti

Un design system derivato dal codice chiude la progettazione nell'esistente. Rende fluida la composizione di schermate a partire da ciò che è già implementato e ostile a ciò che non esiste ancora — proprio là dove la progettazione ha più valore.

E la ricostruzione è utile solo se viene tenuta aggiornata: un design system derivato una volta e poi lasciato lì torna a essere una rappresentazione, con un ritardo in più rispetto a un mockup dichiaratamente tale.

Domande aperte

• Come fa una progettazione che parte dall'esistente a conservare la capacità di proporre ciò che il prodotto non sa ancora fare?